Only one Administrator with Jenkins 1.580.1 server on Win 8.1

[Steve K]

Hello,

I am experiencing very odd access behavior on two different Jenkins servers.  Both servers are Win. 8.1 and both use Jenkins 1.580.1

Both servers use "Jenkins own User Database" and "Matrix based security".

I selected "Administrator" rights for 3 different users.
Now, only one of those three users has Administrator privilege

I have set up very similar configurations in the past, but have never been faced with this

Thank you!

[Steve K]

As a workaround, I removed one of the users who was supposed to have Administrator rights but did not (i.e., The Administrator checkbox was checked in the "Matrix-based security" form, but the user had no Administrator capabilities).
I then re-added the user and added the user to the "Matrix-based security" form.  I checked the Administrator checkbox and now the user does have Administrator capabilities.
That's a pretty drastic workaround for, what appears to be, a bug.
So, I'm still wondering if anyone else has experienced this.

[Daniel Beck]

Make sure the user name is in the correct, same case (e.g. lowercase, or first letter uppercase, etc.) everywhere. In the user DB/LDAP/..., when logging in, in the security configuration.

> --
> You received this message because you are subscribed to the Google Groups "Jenkins Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-use...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/0a013636-b1a3-4962-86d5-93cdb7275adf%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Steve K]

Update:  The user that I re-added had Administrator capability for a while, but now that user no longer has Administrator rights.  The check-boxes in Matrix Based Security have not been changed.

[Steve K]

Daniel is on to something regarding matching case.  When it comes to case [in]sensitivity, however, the behavior of Jenkins is a bit of a mystery.

When I was using a Linux machine as the Jenkins server, there was no mystery.  A mixed case login ID was always treated with case sensitivity.

Now that I have been moved to a Windows based server, the rules seem to have changed.

My Security Realm is set to "Jenkins' own database" and I allow users to sign up.
As an example, I can have a user signup as "JamesYoung".
I can then go to the Matrix-based security under Authorization and add the user "JamesYoung" (note the mixed case).
I can give "JamesYoung" Overall Adminstrator rights.
For a while, "JamesYoung" will have Adminstrator rights and things seem to be going as expected.
At some point, however, "JamesYoung" no longer has Administrator rights.

When I look at the Users list, I see that "JamesYoung" was added as "jamesyoung", even though the user specified mixed case when he signed up.

These are the aspects of Jenkins' behavior that I think are odd:
(1) Jenkins down-cases the User ID's of users who sign up.
(2) Even though Jenkins has down-cased the ID, the ID can be entered into the Matrix-based security in mixed case.
(3) The mixed-case ID that was added to the matrix and granted Administrator rights actually has Administrator rights for a while, then he/she no longer has those rights.

[Richard Bywater]

If I recall correctly (and I probably don't :) ) users get added based off of SCM users of the jobs you are running. If James Young had a SCM entry with jamesyoung, I wonder if Jenkins is matching the JamesYoung entry (possibly due to the Windows case insensitivity as I think users are stored @ the file system level?) and then "rewriting" it as the lower case version making it not work now for the authentication?

Richard.

--
You received this message because you are subscribed to the Google Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-use...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/b3e4ccb6-9ca1-49aa-8b6e-aa675774a8ad%40googlegroups.com.