I got around this by changing the ldap.conf.
pam_filter objectclass=posixAccount
pam_member_attribute uniquemember
I haven;t tested this but you can also map the memberuid and memberof to
Uniquememember. So the nss_ldap checks the uniquemember value every time.
nss_map_attribute memberuid uniqueMember
nss_map_attribute member uniqueMember
My Group looks like this.
dn: cn=GROUP1,ou=Group,dc=DOMAIN,dc=COM
objectClass: groupOfUniqueNames
objectClass: posixGroup
objectClass: top
gidNumber: 3300
uniqueMember: uid=userid1,ou=People,dc=DOMAIN,dc=COM
uniqueMember: uid=userid2,ou=People,dc=DOMAIN,dc=COM
uniqueMember: uid=userid3,ou=People,dc=DOMAIN,dc=COM
uniqueMember: uid=userid4,ou=People,dc=DOMAIN,dc=COM
uniqueMember: uid=userid5,ou=People,dc=DOMAIN,dc=COM
Rick Dicaire wrote:
On Tue, May 4, 2010 at 7:07 AM, John A. Sullivan III
<jsullivan at
opensourcedevel.com
<
https://admin.fedoraproject.org/mailman/listinfo/389-users> > wrote:
>> Why doesn't the group I'd added the user to show?
>>
>>
> I do not know if it is the same issue but I found I had to add the
> posixgroup objectclass to the group; I had to add the memberuid
>
As a followup, is this group issue something specific to 389, or ldap
in general?
ldap in general
I'm wondering if I should try another ldap server
implementation.
you'll probably have to do the same or similar with another ldap server
Thanks