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 Fri, Feb 24, 2017 at 9:12 AM, Michael Wandel <m.wandel(a)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, 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,

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(a)pkfnet.co.za <mailto:mark@pkfnet.co.za>> wrote: stop nscd and check again. -- Thank you, Mark Adrian Coetser mark(a)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(a)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,

passwd: files sss ldap shadow: files sss ldap group: files sss ldap

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(a)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(a)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 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(a)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 ;-)