user removed from ldap group but Linux groups command still shows user as member of the group
Hi,
I removed a user from an LDAP group about a week ago. Today, this user still shows as member of the group with the Linux command groups. Also, the group (Administrators) appears twice in the output of the command id: uid=10000(username) gid=10000(Administrators) groups=10001(users),10005(devel),10011(video),10015(ansible),10000(Administrators)
The command getent though shows the proper group assignation: getent group | grep username | cut -d: -f1 users devel video ansible
All of those groups are LDAP group.
Does someone knows why and would know how to fix this?
Thanks,
On 02/24/17 08:55 -0500, Bernard Fay wrote:
I removed a user from an LDAP group about a week ago. Today, this user still shows as member of the group with the Linux command groups. Also, the group (Administrators) appears twice in the output of the command id: uid=10000(username) gid=10000(Administrators) groups=10001(users),10005(devel),10011(video),10015(ansible),10000(Administrators)
The command getent though shows the proper group assignation: getent group | grep username | cut -d: -f1 users devel video ansible
All of those groups are LDAP group.
Is this from a long running shell? If so, start a new shell or run newgrp.
Otherwise, verify that it is not cached (such as with nscd), and trouble shoot as an nss ldap problem.
On 24.02.2017 14:55, Bernard Fay wrote:
Hi,
I removed a user from an LDAP group about a week ago. Today, this user still shows as member of the group with the Linux command groups. Also, the group (Administrators) appears twice in the output of the command id: uid=10000(username) gid=10000(Administrators) groups=10001(users),10005(devel),10011(video),10015(ansible),10000(Administrators)
Can you please let us know about your nss configuration /etc/nsswitch.conf . IMHO it looks ok that the administrators is the primary group and also in the groups enumeration.
The command getent though shows the proper group assignation: getent group | grep username | cut -d: -f1 users devel video ansible
All of those groups are LDAP group.
Does someone knows why and would know how to fix this?
you can't find primary groups for a user with your command, grepping throug "getent group" . In modern systems aka sssd it is not a good idea, because enumeration ist by default set to false.
best regards
Michael
Thanks,
On Fri, Feb 24, 2017 at 9:12 AM, Michael Wandel m.wandel@t-online.de wrote:
On 24.02.2017 14:55, Bernard Fay wrote:
Hi,
I removed a user from an LDAP group about a week ago. Today, this user still shows as member of the group with the Linux command groups. Also, the group (Administrators) appears twice in the output of the command id: uid=10000(username) gid=10000(Administrators) groups=10001(users),10005(devel),10011(video),10015(
ansible),10000(Administrators)
Can you please let us know about your nss configuration /etc/nsswitch.conf . IMHO it looks ok that the administrators is the primary group and also in the groups enumeration.
The command getent though shows the proper group assignation: getent group | grep username | cut -d: -f1 users devel video ansible
All of those groups are LDAP group.
Does someone knows why and would know how to fix this?
you can't find primary groups for a user with your command, grepping throug "getent group" . In modern systems aka sssd it is not a good idea, because enumeration ist by default set to false.
]# grep -Ev "^#|^$" /etc/nsswitch.conf passwd: files sss ldap shadow: files sss ldap group: files sss ldap hosts: files dns bootparams: nisplus [NOTFOUND=return] files ethers: files netmasks: files networks: files protocols: files rpc: files services: files sss netgroup: files sss ldap publickey: nisplus automount: files ldap aliases: files nisplus
The user has been removed from the groups Administrators so it should not show.
I do not use sssd as our LDAP is not secured so I use nscd. This LDAP is confined a lab.
Thanks,
stop nscd and check again.
Stopping nscd did not change anything. "groups username" still shows user as member of Administrators.
On Fri, Feb 24, 2017 at 9:50 AM, Mark Coetser mark@pkfnet.co.za wrote:
stop nscd and check again.
-- Thank you,
Mark Adrian Coetser mark@pkfnet.co.za
... bleakness ... desolation ... plastic forks ...
On 24/02/2017 16:40, Bernard Fay wrote:
On Fri, Feb 24, 2017 at 9:12 AM, Michael Wandel <m.wandel@t-online.de mailto:m.wandel@t-online.de> wrote:
On 24.02.2017 14 <tel:24.02.2017%2014>:55, Bernard Fay wrote: > Hi, > > I removed a user from an LDAP group about a week ago. Today, thisuser > still shows as member of the group with the Linux command groups. Also, > the group (Administrators) appears twice in the output of the command id: > uid=10000(username) gid=10000(Administrators) > groups=10001(users),10005(devel),10011(video),10015(ansible) ,10000(Administrators) >
Can you please let us know about your nss configuration /etc/nsswitch.conf . IMHO it looks ok that the administrators is the primary group and also in the groups enumeration. > The command getent though shows the proper group assignation: > getent group | grep username | cut -d: -f1 > users > devel > video > ansible > > All of those groups are LDAP group. > > Does someone knows why and would know how to fix this? you can't find primary groups for a user with your command, grepping throug "getent group" . In modern systems aka sssd it is not a good idea, because enumeration ist by default set to false.]# grep -Ev "^#|^$" /etc/nsswitch.conf passwd: files sss ldap shadow: files sss ldap group: files sss ldap hosts: files dns bootparams: nisplus [NOTFOUND=return] files ethers: files netmasks: files networks: files protocols: files rpc: files services: files sss netgroup: files sss ldap publickey: nisplus automount: files ldap aliases: files nisplus
The user has been removed from the groups Administrators so it should not show.
I do not use sssd as our LDAP is not secured so I use nscd. This LDAP is confined a lab.
Thanks,
On 24.02.2017 15:56, Bernard Fay wrote:
Stopping nscd did not change anything. "groups username" still shows user as member of Administrators.
please can you make an ldapsearch for the object username and the output from getent passwd username.
best regards Michael
On Fri, Feb 24, 2017 at 9:50 AM, Mark Coetser <mark@pkfnet.co.za mailto:mark@pkfnet.co.za> wrote:
stop nscd and check again. -- Thank you, Mark Adrian Coetser mark@pkfnet.co.za <mailto:mark@pkfnet.co.za> ... bleakness ... desolation ... plastic forks ... On 24/02/2017 16:40, Bernard Fay wrote: On Fri, Feb 24, 2017 at 9:12 AM, Michael Wandel <m.wandel@t-online.de <mailto:m.wandel@t-online.de> <mailto:m.wandel@t-online.de <mailto:m.wandel@t-online.de>>> wrote: On 24.02.2017 14 <tel:24.02.2017%2014> <tel:24.02.2017%2014>:55, Bernard Fay wrote: > Hi, > > I removed a user from an LDAP group about a week ago. Today, this user > still shows as member of the group with the Linux command groups. Also, > the group (Administrators) appears twice in the output of the command id: > uid=10000(username) gid=10000(Administrators) > groups=10001(users),10005(devel),10011(video),10015(ansible),10000(Administrators) > Can you please let us know about your nss configuration /etc/nsswitch.conf . IMHO it looks ok that the administrators is the primary group and also in the groups enumeration. > The command getent though shows the proper group assignation: > getent group | grep username | cut -d: -f1 > users > devel > video > ansible > > All of those groups are LDAP group. > > Does someone knows why and would know how to fix this? you can't find primary groups for a user with your command, grepping throug "getent group" . In modern systems aka sssd it is not a good idea, because enumeration ist by default set to false. ]# grep -Ev "^\#|^$" /etc/nsswitch.conf passwd: files sss ldap shadow: files sss ldap group: files sss ldap hosts: files dns bootparams: nisplus [NOTFOUND=return] files ethers: files netmasks: files networks: files protocols: files rpc: files services: files sss netgroup: files sss ldap publickey: nisplus automount: files ldap aliases: files nisplus The user has been removed from the groups Administrators so it should not show. I do not use sssd as our LDAP is not secured so I use nscd. This LDAP is confined a lab. Thanks,
On Fri, Feb 24, 2017 at 10:06 AM, Michael Wandel m.wandel@t-online.de wrote:
On 24.02.2017 15:56, Bernard Fay wrote:
Stopping nscd did not change anything. "groups username" still shows user as member of Administrators.
please can you make an ldapsearch for the object username and the output from getent passwd username.
Thanks Michael,
getent passwd username showed me the mistake. The user has Administrators as primary group. In our setup, all users being regular or admin users, should all be in the users group. Changing this fixed my problem.
Thanks
Bernard Fay wrote:
passwd: files sss ldap shadow: files sss ldap group: files sss ldap
This mix makes no sense at all. Either you use nss_sss to query sssd (which has its own cache in /var/lib/sss/db) or you use nss_ldap (direct or via nss-pam-ldapd).
Decide which components you really want to use and clean your config before going any further.
Ciao, Michael.
sssd is not running and even removed. At beginning we thought of using it as it is the recommended way to go. But sssd requires the use of a secured LDAP which we do not use as this LDAP is confined in a lab. We use nscd.
On Fri, Feb 24, 2017 at 9:56 AM, Michael Ströder michael@stroeder.com wrote:
Bernard Fay wrote:
passwd: files sss ldap shadow: files sss ldap group: files sss ldap
This mix makes no sense at all. Either you use nss_sss to query sssd (which has its own cache in /var/lib/sss/db) or you use nss_ldap (direct or via nss-pam-ldapd).
Decide which components you really want to use and clean your config before going any further.
Ciao, Michael.
On 24.02.2017 16:02, Bernard Fay wrote:
sssd is not running and even removed. At beginning we thought of using it as it is the recommended way to go. But sssd requires the use of a secured LDAP which we do not use as this LDAP is confined in a lab. We use nscd.
This ist not correct, sssd need this only for the authprovider , the idprovider can be used with plain ldap.
best regards
Michael
On Fri, Feb 24, 2017 at 9:56 AM, Michael Ströder <michael@stroeder.com mailto:michael@stroeder.com> wrote:
Bernard Fay wrote: > passwd: files sss ldap > shadow: files sss ldap > group: files sss ldap This mix makes no sense at all. Either you use nss_sss to query sssd (which has its own cache in /var/lib/sss/db) or you use nss_ldap (direct or via nss-pam-ldapd). Decide which components you really want to use and clean your config before going any further. Ciao, Michael.
On Fri, Feb 24, 2017 at 10:07 AM, Michael Wandel m.wandel@t-online.de wrote:
On 24.02.2017 16:02, Bernard Fay wrote:
sssd is not running and even removed. At beginning we thought of using it as it is the recommended way to go. But sssd requires the use of a secured LDAP which we do not use as this LDAP is confined in a lab. We use nscd.
This ist not correct, sssd need this only for the authprovider , the idprovider can be used with plain ldap.
best regards
I do not understand what is not correct in this. The man page of sssd-ldap is clear about it.
Michael
On Fri, Feb 24, 2017 at 9:56 AM, Michael Ströder <michael@stroeder.com mailto:michael@stroeder.com> wrote:
Bernard Fay wrote: > passwd: files sss ldap > shadow: files sss ldap > group: files sss ldap This mix makes no sense at all. Either you use nss_sss to query sssd (which has its own cache in /var/lib/sss/db) or you use nss_ldap (direct or via nss-pam-ldapd). Decide which components you really want to use and clean your config before going any further. Ciao, Michael.
On 24.02.2017 16:21, Bernard Fay wrote:
On Fri, Feb 24, 2017 at 10:07 AM, Michael Wandel <m.wandel@t-online.de mailto:m.wandel@t-online.de> wrote:
On 24.02.2017 16 <tel:24.02.2017%2016>:02, Bernard Fay wrote: > sssd is not running and even removed. At beginning we thought of using > it as it is the recommended way to go. But sssd requires the use of a > secured LDAP which we do not use as this LDAP is confined in a lab. We > use nscd. This ist not correct, sssd need this only for the authprovider , the idprovider can be used with plain ldap. best regardsI do not understand what is not correct in this. The man page of sssd-ldap is clear about it.
IMHO it is better to use for this question the sssd mailing list or per pm.
best regards
michael
Michael > > > > On Fri, Feb 24, 2017 at 9:56 AM, Michael Ströder <michael@stroeder.com <mailto:michael@stroeder.com> > <mailto:michael@stroeder.com <mailto:michael@stroeder.com>>> wrote: > > Bernard Fay wrote: > > passwd: files sss ldap > > shadow: files sss ldap > > group: files sss ldap > > This mix makes no sense at all. Either you use nss_sss to query sssd > (which has its own > cache in /var/lib/sss/db) or you use nss_ldap (direct or via > nss-pam-ldapd). > > Decide which components you really want to use and clean your config > before going any > further. > > Ciao, Michael. > >
On 24.02.2017 15:56, Michael Ströder wrote:
Bernard Fay wrote:
passwd: files sss ldap shadow: files sss ldap group: files sss ldap
This mix makes no sense at all. Either you use nss_sss to query sssd (which has its own cache in /var/lib/sss/db) or you use nss_ldap (direct or via nss-pam-ldapd).
You are right michael, this is not for beginners , but you can make funny things in combination sssd and nss-ldap ;-)
best regards Michael
Decide which components you really want to use and clean your config before going any further.
Ciao, Michael.
Michael Wandel wrote:
On 24.02.2017 15:56, Michael Ströder wrote:
Bernard Fay wrote:
passwd: files sss ldap shadow: files sss ldap group: files sss ldap
This mix makes no sense at all. Either you use nss_sss to query sssd (which has its own cache in /var/lib/sss/db) or you use nss_ldap (direct or via nss-pam-ldapd).
You are right michael, this is not for beginners , but you can make funny things in combination sssd and nss-ldap ;-)
Sorry, the above realla makes no sense at all: nss-pam-ldapd (aka nslcd) requires nscd for caching these particular maps which does not play well with sssd caching the *same* maps. You can run both in parallel but disable the nscd map caches for maps served by sssd (passwd, group etc.).
And you can do the same funny things with sssd and several LDAP domains. (This is not necessarily meant to endorse sssd over another NSS/PAM implementation. It's just for motivating the original poster to clean his config now.)
Ciao, Michael.
openldap-technical@openldap.org
-
Bernard Fay -
Dan White -
Mark Coetser -
Michael Ströder -
Michael Wandel