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.