Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
None
-
Platform: All, OS: Linux
Description
Currently Hudson only checks for attribute member in LDAP groups. However, it is
also quite common to use attribtute uniqueMember to store member list.
In WEB-INF/security/LDAPBindSecurityRealm.groovy, an one-line change that makes
Hudson search for both member=
can be done as follows:
authoritiesPopulator(DeferredCreationLdapAuthoritiesPopulator,initialDirContextFactory,"ou=groups")
{
// groupRoleAttribute = "ou";
groupSearchFilter = "(|(member=
))"
}
Thanks to Kohsuke.Kawaguchi@sun.com for the above code.
Attachments
Issue Links
- is duplicated by
-
JENKINS-2314 Supporting uniqueMember in LDAP
-
- Closed
-
Activity
alvin_chang
created issue -
Code changed in hudson
User: : kohsuke
Path:
trunk/hudson/main/core/src/main/java/hudson/security/DeferredCreationLdapAuthoritiesPopulator.java
trunk/www/changelog.html
http://fisheye4.cenqua.com/changelog/hudson/?cs=13087
Log:
[FIXED JENKINS-2256] Added two more lookups as reported in this issue.
In 1.261.
| Field | Original Value | New Value |
|---|---|---|
| Resolution | Fixed [ 1 ] | |
| Status | Open [ 1 ] | Resolved [ 5 ] |
zumkehr
added a comment - We downloaded 1.261 and tested with our Ldap. Unfortunately, authorisation still
does not work. Hudson Logs only show:
FINE: Authentication success:
org.acegisecurity.providers.UsernamePasswordAuthenticationToken@3cb8dfca:
Username: org.acegisecurity.userdetails.ldap.LdapUserDetailsImpl@3d0bbf6d;
Password: [PROTECTED]; Authenticated: true; Details:
org.acegisecurity.ui.WebAuthenticationDetails@255f8: RemoteIpAddress: 127.0.0.1;
SessionId: d07bc8256f3dd73af73c2106c98da368; Granted Authorities:
So no authorities have been granted, not even 'authenticated', as referenced in
project-based matrix security. Only the rights granted to the user name and
anonymous have been applied. More detailed logging might be helpfull.
Is that a different bug or should this one be reopened?
zumkehr
added a comment - We downloaded 1.261 and tested with our Ldap. Unfortunately, authorisation still
does not work. Hudson Logs only show:
FINE: Authentication success:
org.acegisecurity.providers.UsernamePasswordAuthenticationToken@3cb8dfca:
Username: org.acegisecurity.userdetails.ldap.LdapUserDetailsImpl@3d0bbf6d;
Password: [PROTECTED] ; Authenticated: true; Details:
org.acegisecurity.ui.WebAuthenticationDetails@255f8: RemoteIpAddress: 127.0.0.1;
SessionId: d07bc8256f3dd73af73c2106c98da368; Granted Authorities:
So no authorities have been granted, not even 'authenticated', as referenced in
project-based matrix security. Only the rights granted to the user name and
anonymous have been applied. More detailed logging might be helpfull.
Is that a different bug or should this one be reopened? zumkehr
made changes -
| Resolution | Fixed [ 1 ] | |
| Status | Resolved [ 5 ] | Reopened [ 4 ] |
zumkehr
added a comment - We finally got it to work with memberUid (thanks to alvin_chang):
The attribute memberUid is specific to the object class posixGroup and only
contains the username. This is different to groupOfNames, which uses member or
uniqueMember, containing the full DN of the user. So the comparison has to be
adapted:
uid=
{0} uses the full DN of the useruid={1} uses the username
which leads to
groupSearchFilter = "(|(member={0}
) (uniqueMember=
{0}) (memberUid=
{1}))"
zumkehr
added a comment - We finally got it to work with memberUid (thanks to alvin_chang):
The attribute memberUid is specific to the object class posixGroup and only
contains the username. This is different to groupOfNames, which uses member or
uniqueMember, containing the full DN of the user. So the comparison has to be
adapted:
uid=
{0} uses the full DN of the user
uid={1} uses the username
which leads to
groupSearchFilter = "(|(member={0}
) (uniqueMember=
{0}
) (memberUid=
{1}
))" zumkehr
added a comment - Is this issue scheduled somewhere or has it just been forgotten? If anybody
would find some time to change a 0 to a 1 it would be fixed... Thanks
zumkehr
added a comment - Is this issue scheduled somewhere or has it just been forgotten? If anybody
would find some time to change a 0 to a 1 it would be fixed... Thanks actually in 1.280 the whole query setting was lost, as
DeferredCreationLdapAuthoritiesPopulator was deprecated and the settings there
not moved over to the groovy file. I'll move those over, and make the 0->1 change.
| Status | Reopened [ 4 ] | Open [ 1 ] |
Code changed in hudson
User: : mindless
Path:
trunk/hudson/main/war/resources/WEB-INF/security/LDAPBindSecurityRealm.groovy
trunk/www/changelog.html
http://fisheye4.cenqua.com/changelog/hudson/?cs=16009
Log:
[FIXED JENKINS-2256] DeferredCreationLdapAuthoritiesPopulator was deprecated
in 1.280, so the groupSearchFilter used there was lost. Moved this to
groovy file so the uniqueMember query works again, and changed
to
{1}in the memberUid query to fix that one.
| Resolution | Fixed [ 1 ] | |
| Status | Open [ 1 ] | Resolved [ 5 ] |
| Link |
This issue is duplicated by |
| Status | Resolved [ 5 ] | Verified [ 10000 ] |
| Status | Verified [ 10000 ] | Closed [ 6 ] |
| Workflow | JNJira [ 132329 ] | JNJira + In-Review [ 201327 ] |
Jenkins IRC Bot
made changes -
| Component/s | _unsorted [ 19622 ] | |
| Component/s | security [ 15508 ] |
Our organisation uses 'memberUid', so while your at it, could you add this as
well? Of course, configuration options as proposed by Issue 1909 would be fine
as well.