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.
I thought there might be something wrong with nsswitch.conf, but 'getent
group' is reporting the secondary groups and the users but with a 'x' in
the second field:
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?
'id' doesn't report the secondary groups either. 'id' on the first LDAP
server shows something like:
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?
--
redhat-list mailing list
unsubscribe mailto:redhat-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/redhat-list
05-30-2008, 07:33 PM
Pat Riehecky
getent / group / LDAP problem
On Wed, 2008-05-28 at 13:51 -0400, Ryan Golhar wrote:
> Hi all,
>
> 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 thought there might be something wrong with nsswitch.conf, but 'getent
> group' is reporting the secondary groups and the users but with a 'x' in
> the second field:
RHEL provides a nifty lazy tool system-config-authentication which in my
experience works 100% of the time with LDAP. You may want to give it a
look for the setup bits, it eliminates typos and is all around
successful.
>
> 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
>
> '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.
Pat
--
redhat-list mailing list
unsubscribe mailto:redhat-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/redhat-list
05-30-2008, 08:08 PM
Ryan Golhar
getent / group / LDAP problem
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:
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:
# 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@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/redhat-list
05-31-2008, 12:12 AM
hike
getent / group / LDAP problem
2008/5/30 Ryan Golhar <golharam@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@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
--
redhat-list mailing list
unsubscribe mailto:redhat-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/redhat-list
getent / group / LDAP problem
