what is the structure for groups in your LDAP and what are your LDAP settings in
Hudson? the group query must not be finding your group memberships.

This is the class doing the group lookup:
http://www.acegisecurity.org/acegi-security/apidocs/org/acegisecurity/providers/ldap/populator/DefaultLdapAuthoritiesPopulator.html

and in Hudson this class is configured in:
WEB-INF/security/LDAPBindSecurityRealm.groovy

Here is the group in our LDAP directory that I was trying to verify against
(with the details anonymised)

dn: cn=example-dev,ou=Groups,dc=example,dc=net
objectClass: top
objectClass: posixGroup
cn: example-dev
gidNumber: 10014
description: Group account

and here is the similarly anonymous Hudson LDAP config

LDAP
server: 127.0.0.1
root DN: dc=example,dc=net
User search base: ou=People
User search filter: uid=

Group search base: ou=Groups
Manager DN: <empty>
Manager Password: <empty>

I initially tried leaving some of these fields blank as suggested in the help
buttons, but it didn't work at all for me then. When I add example-dev to the
permissions matrix, it seems to recognise it as a group suggesting to me that
the LDAP part is working, at least there. Should I perhaps be using the full
path for the Group (ou=Groups,dc=example,dc=net)?

Thanks.

BTW Apart from this Hudson is working beautifully, very nice piece of software
and a model for a WAR deployment that works out of the box.

when you say "seems to recognise it as a group" you mean the little icon that
appears to the left of the name? yup, validating a group name and looking up a
user's groups are 2 different queries so one could be working while the other
doesn't.
you didn't list how a user's membership in a group is defined in your LDAP.. I
looked at the acegi code and it appears the default is member=

is
the DN of the user. You can change the query in your
WEB-INF/security/LDAPBindSecurityRealm.groovy by adding:
groupSearchFilter = "..."
in the authoritiesPopulator block. The "..." could be "yourFieldName=

" to
query on user DN or "yourFieldName=

" to query on username only.

I wonder if the "Unix user database" secuirty realm is better for you. Your LDAP
schema appears to be modeled around that, and that one is far less error prone.

@mindless

dn: uid=hudson,ou=People,dc=example,dc=net
sn: hudson
givenName: builder
uid: hudson
cn: hudson
homeDirectory: /home/hudson
loginShell: /bin/bash
uidNumber: 10012
gidNumber: 10013
gecos: hudson
objectClass: posixAccount
objectClass: shadowAccount
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: gosaAccount
description: User account

@kohsuke

If I change to "Unix user database" security realm - will it still use my LDAP
server or what will it use as the authentication source?

if this LDAP is really just a mirror of your unix users/groups, then I agree
with kohsuke.. just use that security type. it'll authenticate users against
their unix username/password I suppose, though I haven't tried this security
type myself.
if you stick with LDAP you need to figure out how to query for a user's groups..
if the gidNumber on the user's record is the only indicator of their group
membership, I don't know how you can configure acegi to find that.

I've seen info from other people with "posixGroup" type groups that the group
has "memberUid=

" entries for the group members.. does your LDAP have
this? If so, 1.289 will query on this field. Let us know if there is anything
more we can do, or if this issue can be closed, thanks.

Yes, we use memberUid in our groups - I'll test 1.289 when it's released and let
you know if it fixes the problem (that would be great).

Thanks for the update.

Hi,

Sorry for the delay on getting back to this. I've now gotten around to testing
this with the latest Hudson (1.292 - there is no changelog for this yet which
worries me a little - should the problem be fixed there too?

I did the following. Downloaded 1.292 war and dropped it into
/var/lib/tomcat6/webapps - Hudson seemed to auto-upgrade (good work on this
guys, very painless).

I then did the following. Added a new group to LDAP - ldaptestgrp which resulted
in the following entry in LDAP:

dn: cn=ldaptestgrp,ou=Groups,dc=example,dc=net
objectClass: top
objectClass: posixGroup
cn: ldaptestgrp
gidNumber: 10017
description: Group account

I then added a user account with the above as it's default group resulting in
the following entry:

dn: uid=ldaptest,ou=People,dc=example,dc=net
sn: test
givenName: ldap
uid: ldaptest
cn: ldaptest
homeDirectory: /home/ldaptest
loginShell: /bin/bash
uidNumber: 10015
gidNumber: 10017
gecos: ldaptest
objectClass: posixAccount
objectClass: shadowAccount
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: gosaAccount
description: User account

NOTE: these are associated by gidNumber in the user entry rather than by
memberUid in the group entry (because this is the user's primary group).

I then added a second test group to LDAP and made ldaptest a member of it -
resulting in the following entry,

dn: cn=ldaptestgrp2,ou=Groups,dc=example,dc=net
objectClass: top
objectClass: posixGroup
cn: ldaptestgrp2
gidNumber: 10018
description: Group account
memberUid: ldaptest

Note that this time it does use memberUid as Hudson expects.

I then tried adding first ldaptestgrp and then ldaptestgrp2 to the permissions
matrix and enabling most permissions (except the admin ones). In both test cases
(using ldaptestgrp and ldaptestgrp2) - I still get the following error in Hudson
immediately after logging in

Access Denied

ldaptest is missing the Read permission

There is no additional information in the Hudson logs (Hudson logging is running
with all defaults, not sure if I need to enable something specific to see
details of authentication?).

what did you enter into Hudson's permissions matrix? try entering
ROLE_ldaptestgrp / ROLE_ldaptestgrp2 instead of just the group name, and see if
that makes a difference.

any update?

Hi,

Apologies for the delay. I originally used just the group name and Hudson seems
to recognised that as a valid LDAP group (it puts a little group icon beside it
in the security matrix).

I tried adding a new group which is ROLE_ldaptestgroup and it doesn't get
recognised as a group. Furthermore, when I attempt to login as the ldaptestuser
(a member of this group), I get the "user no read permission" error.

Hudson ver. 1.292 (I can't see anything in the Changelog's up to 1.299 that
indicates any LDAP changes have been made).

the inconsistency between the name-check icon and what is actually used has been
filed as issue #3459. but I was definitely hoping putting ROLE_ prefix in your
permission matrix would cause the group permissions to apply.. sorry, not sure
what to try next without really getting in there to debug and see what LDAP
queries and results are happening.

I bumped into the same problem. After reading a bit more carefully the default
configuration of acegi that mindless pointed I found the "problem".

It is in the last 2 properties acegi uses in the default bean config.
<bean id="ldapAuthoritiesPopulator"
class="org.acegisecurity.providers.ldap.populator.DefaultLdapAuthoritiesPopulator">
<constructor-arg><ref local="initialDirContextFactory"/></constructor-arg>
<constructor-arg><value>ou=groups</value></constructor-arg>
<property name="groupRoleAttribute"><value>ou</value></property>
<!-- the following properties are shown with their default values -->
<property name="searchSubTree"><value>false</value></property>
<property name="rolePrefix"><value>ROLE_</value></property>
<property name="convertToUpperCase"><value>true</value></property>
</bean>

In other words if your group is:
dn: cn=ldaptestgrp2,ou=Groups,dc=example,dc=net
objectClass: top
objectClass: posixGroup
cn: ldaptestgrp2
gidNumber: 10018
description: Group account
memberUid: ldaptest

as for smulcahy's example you have to add the
ROLE_LDAPTESTGRP2
and then your user ldaptest will receive the proper authorization.

It would be helpful however if the group validation and the acegi config use the
same rules. And even better if those are exposed to the Advanced settings in the
LDAP section.

I am sure some people would prefer having Roles enforced in all capitals (they
jump to attention in bigger companies), but on the other hand I would like to
use the lower-cased version, since with just a few entries it looks nicer.

Hi,

Apologies for the delay in following up - I've only gotten a chance to test
this. now. Thanks for the detailed feedback. It sounds like you might be on the
right track with this, but I did a quick test this morning and still got a read
access denied error. I did the following,

1. Recreated my LDAP test user ldaptestuser and added it to group ldaptestgroup
2. Logged into Hudson as admin and added ROLE_LDAPTESTGROUP to the permissions
matrix.
3. Logged out of Hudson and attempted to login as ldaptestuser and

SUCCESS!

I successfully logged in as that user.

Might be worth pointing to this bug in the Hudon documentation for those
configuring up LDAP auth. These default config options in ACEGI are surprising
(and a bit random) - I imagine it'd be better to default to not using a prefix
or changing the case and let users customise the behaviour if they have explicit
requirements.

Thanks for your assistance in this.

Hi, just re-read my last comment and to noted that the second sentence is
incorrect. To clarify, the suggested fix works and my ldaptestuser did login
without any errors (read or otherwise).

thanks and apologies for the confusion (not enough coffee).

ok, going to close this one and use #3459 to track the fix. I'll summarize the
results of all these comments over there. Thanks morlach01 for the help in
tracking down the settings causing this problem!

• • • This issue has been marked as a duplicate of 3459 ***