getent / group / LDAP problem

[hike]

2008/5/30 Ryan Golhar <golharam at umdnj.edu>:

> I have RHEL 5 running as an LDAP server, and am trying to configure a
>>> second server to mimic the first one.  I have created multiple groups in
>>> LDAP and assigned various users to these groups.  On the second server,
>>> running 'id' from the shell doesn't show those secondary groups.
>>>
>>
>> What LDAP product are you using (openldap, FDS, Apache DS, etc)
>>
>
> I'm using OpenLDAP from the RPMs provided by RedHat
>
>  'id' doesn't report the secondary groups either.  'id' on the first LDAP
>>> server shows something like:
>>>
>>> uid=501(golharam) gid=501(sansuser)
>>> groups=500(users),501(sansuser),85(cvs) context=user_u:system_r:unconfined_t
>>>
>>> On the second LDAP server, I get:
>>> uid=501(golharam) gid=500(users) groups=500(users)
>>> context=user_u:system_r:unconfined_t
>>>
>>> There should be a second group as 'cvs' with gid=85.   Does anyone know
>>> why I wouldn't see secondary groups in my second LDAP server?
>>>
>>
>> This very much depends on how exactly the entry is listed in your ldap
>> database.
>>
>
> At first I thought it was my ACLs so I corrected them and everything seemed
> to function and the problem reappeared after adding another user.  I deleted
> the cvs (problem secondary group) and recreated it and it seems be okay.
>  I'm worried the problem may resurface.
> Here is what my ldap ldif and ACLs looks like, only showing relevant
> information:
>
> # cbii.umdnj.edu
> dn: dc=cbii,dc=umdnj,dc=edu
> dc: cbii
> o: cbii
> objectClass: dcObject
> objectClass: organization
> objectClass: top
>
> # People, cbii.umdnj.edu
> dn: ou=People,dc=cbii,dc=umdnj,dc=edu
> ou: People
> objectClass: organizationalUnit
> objectClass: top
>
> # Group, cbii.umdnj.edu
> dn: ou=Group,dc=cbii,dc=umdnj,dc=edu
> ou: Group
> objectClass: organizationalUnit
> objectClass: top
>
> # users, Group, cbii.umdnj.edu
> dn: cn=users,ou=Group,dc=cbii,dc=umdnj,dc=edu
> cn: users
> gidNumber: 500
> objectClass: posixGroup
> objectClass: top
> memberUid: user1
> memberUid: user2
> memberUid: user3
> memberUid: user4
> memberUid: user5
> memberUid: user6
>
> # user1, People, cbii.umdnj.edu
> dn: uid=user1,ou=People,dc=cbii,dc=umdnj,dc=edu
> uid: user1
> objectClass: top
> objectClass: posixAccount
> objectClass: shadowAccount
> objectClass: organizationalPerson
> objectClass: inetOrgPerson
> uidNumber: 501
> gidNumber: 500
>
> # user2-user6 are similar in structure
>
> # cvs, Group, cbii.umdnj.edu
> dn: cn=cvs,ou=Group,dc=cbii,dc=umdnj,dc=edu
> cn: cvs
> objectClass: posixGroup
> objectClass: top
> gidNumber: 85
> memberUid: user1
> memberUid: user2
> memberUid: user3
> memberUid: user4
>
> # ACLs in slapd.conf:
> access to attrs=userPassword
>        by self write
>        by anonymous auth
>        by dn="uid=user1,ou=People,dc=cbii,dc=umdnj,dc=edu" write
>        by dn="uid=user2,ou=People,dc=cbii,dc=umdnj,dc=edu" write
>        by * none
>
> # Allow admins to add users
> access to dn.subtree="ou=People,dc=cbii,dc=umdnj,dc=edu"
>        by dn="uid=user1,ou=People,dc=cbii,dc=umdnj,dc=edu" write
>        by dn="uid=user2,ou=People,dc=cbii,dc=umdnj,dc=edu" write
>        by * read
>
> # Allow admins to add users to groups
> access to dn.children="ou=Group,dc=cbii,dc=umdnj,dc=edu"
>        by dn="uid=user1,ou=People,dc=cbii,dc=umdnj,dc=edu" write
>        by dn="uid=user2,ou=People,dc=cbii,dc=umdnj,dc=edu" write
>        by * read
>
> # allow the world read access
> access to *
>        by * read
>
> It seems to be working now so I assume everything is okay.
>
> --
> redhat-list mailing list
> unsubscribe mailto:redhat-list-request at redhat.com?subject=unsubscribe
> https://www.redhat.com/mailman/listinfo/redhat-list
>



Previously,,,,,,

> users:x:500:user1,user2,user3
>
> whereas on the first server, I see:
>
> users:*:500:user1,user2,user3

> Why the difference in the second field?

This is just different shadow syntax, both of these point the password
field to gshadow, nothing to worry about


I would be careful to distinguish "x" and "*" in the second field.

Our site is RHELv4 only.
We do not have LDAP but in "plain old" RHELv4, there is a big difference
between "x" and "*".  If the passwd file has a "*", the user cannot log into
the server; the symbol must be a "x".
Our Tru64 servers use "*" and we must convert the splats to "x" when we copy
& paste the passwd file entires.

HTH