2008/5/30 Ryan Golhar <golharam@xxxxxxxxx>: > 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@xxxxxxxxxx?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
-- redhat-list mailing list unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe https://www.redhat.com/mailman/listinfo/redhat-list
