I found it necessary to change the GID of a POSIX group defined in LDAP. But when I log in with a user that is a member of this group, I find that the user's group membership still reflects the old GID.
At this point, I've tried removing the user from the group, and adding it back--it still comes up with the old GID when logged in (or, specifically, typing "groups" at the command prompt lists a group associated with the old GID), even though I can't see *anything* referencing the old GID in the LDAP database.
I am stumped. Anyone have ideas about what might be going on here?
On Mon, 2012-05-07 at 01:57 -0300, zoolook wrote:
El may 7, 2012 1:37 a.m., "Braden .
I am stumped. Anyone have ideas about what might be going on here?
Maybe nscd is running?
Nope; it's not even installed.
Or restarted sssd?
What is your OS?
Have you googled for ldap cache and your os?
What else have you tried?
Chris Jacobs Systems Administrator, Technology Services Group
Apollo Group | Apollo Marketing & Product Development | Aptimus, Inc. 1501 4th Ave | Suite 2500 | Seattle, WA 98101 direct 206.839.8245 | cell 206.601.3256 | Fax 206.644.0628 email: chris.jacobs@apollogrp.edu
----- Original Message ----- From: openldap-technical-bounces@OpenLDAP.org openldap-technical-bounces@OpenLDAP.org To: openldap-technical@openldap.org openldap-technical@openldap.org Sent: Sun May 06 22:18:24 2012 Subject: Re: Cached user info?
On Mon, 2012-05-07 at 01:57 -0300, zoolook wrote:
El may 7, 2012 1:37 a.m., "Braden .
I am stumped. Anyone have ideas about what might be going on here?
Maybe nscd is running?
Nope; it's not even installed.
-- Braden McDaniel braden@endoframe.com
This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system.
On Sun, 2012-05-06 at 22:21 -0700, Chris Jacobs wrote:
Or restarted sssd?
I've restarted both the client machine and the server; so, yes.
What is your OS?
Fedora 17 prerelease.
Have you googled for ldap cache and your os?
I have. I haven't come up with much, so far.
Might pam be caching any of this stuff?
What else have you tried?
If I remove the user from the group in LDAP, that is reflected in the output of "groups". But, when I add it back, "groups" shows the (local) group associated with the old GID, not the new one.
So it's as if something on the client side has gotten the group *name* from LDAP and has locally cached an association with the old GID. The old GID is getting passed along and is associated with the group that it maps to locally by a tool like "groups".
On Monday, 7 May 2012 08:04:34 Braden McDaniel wrote:
On Sun, 2012-05-06 at 22:21 -0700, Chris Jacobs wrote:
Or restarted sssd?
I've restarted both the client machine and the server; so, yes.
What is your OS?
Fedora 17 prerelease.
Have you googled for ldap cache and your os?
I have. I haven't come up with much, so far.
Might pam be caching any of this stuff?
What else have you tried?
If I remove the user from the group in LDAP, that is reflected in the output of "groups". But, when I add it back, "groups" shows the (local) group associated with the old GID, not the new one.
So it's as if something on the client side has gotten the group *name* from LDAP and has locally cached an association with the old GID.
You have a local group and an LDAP group, with the same name, and different GIDs? Depending on your nss configuration (in /etc/nsswitch.conf), you will either get the local group, or the LDAP group definition.
The old GID is getting passed along and is associated with the group that it maps to locally by a tool like "groups".
If I understand your setup, this is the correct behaviour.
Provide the output of 'id username'. If none of your groups have spaces in the name, the following might also be useful:
$ for i in `groups username|awk -F: '{print $2}'`;do getent group|grep "^$i:";done
Regards, Buchan
On Mon, 2012-05-07 at 11:27 +0200, Buchan Milne wrote:
On Monday, 7 May 2012 08:04:34 Braden McDaniel wrote:
On Sun, 2012-05-06 at 22:21 -0700, Chris Jacobs wrote:
Or restarted sssd?
I've restarted both the client machine and the server; so, yes.
What is your OS?
Fedora 17 prerelease.
Have you googled for ldap cache and your os?
I have. I haven't come up with much, so far.
Might pam be caching any of this stuff?
What else have you tried?
If I remove the user from the group in LDAP, that is reflected in the output of "groups". But, when I add it back, "groups" shows the (local) group associated with the old GID, not the new one.
So it's as if something on the client side has gotten the group *name* from LDAP and has locally cached an association with the old GID.
You have a local group and an LDAP group, with the same name, and different GIDs?
Not "have"; *had*. I changed the LDAP group GID to match the local grou GID. But "groups" still shows the local group associated with the old GID.
Depending on your nss configuration (in /etc/nsswitch.conf), you will either get the local group, or the LDAP group definition.
The old GID is getting passed along and is associated with the group that it maps to locally by a tool like "groups".
If I understand your setup, this is the correct behaviour.
Provide the output of 'id username'.
$ id braden uid=1000(braden) gid=100(users) groups=100(users),497(desktop_admin_r),988(ccache),990(pulse-access)
And here are the POSIX groups I've defined in LDAP:
$ ldapsearch -x -H ldap://ldap.endoframe.net -D "cn=Manager,dc=endoframe,dc=net" -W "objectClass=posixGroup" Enter LDAP Password: # extended LDIF # # LDAPv3 # base <dc=endoframe,dc=net> (default) with scope subtree # filter: objectClass=posixGroup # requesting: ALL #
# users, Groups, endoframe.net dn: cn=users,ou=Groups,dc=endoframe,dc=net objectClass: top objectClass: posixGroup cn: users gidNumber: 100 memberUid: braden
# ccache, Groups, endoframe.net dn: cn=ccache,ou=Groups,dc=endoframe,dc=net objectClass: top objectClass: posixGroup cn: ccache gidNumber: 988 memberUid: braden
# desktop_admin_r, Groups, endoframe.net dn: cn=desktop_admin_r,ou=Groups,dc=endoframe,dc=net objectClass: top objectClass: posixGroup gidNumber: 497 cn: desktop_admin_r memberUid: braden
# desktop_user_r, Groups, endoframe.net dn: cn=desktop_user_r,ou=Groups,dc=endoframe,dc=net objectClass: top objectClass: posixGroup gidNumber: 496 cn: desktop_user_r
# mock, Groups, endoframe.net dn: cn=mock,ou=Groups,dc=endoframe,dc=net objectClass: top objectClass: posixGroup cn: mock gidNumber: 989 memberUid: braden
# search result search: 2 result: 0 Success
# numResponses: 6 # numEntries: 5
If none of your groups have spaces in the name, the following might also be useful:
$ for i in `groups username|awk -F: '{print $2}'`;do getent group|grep "^$i:";done
$ getent group | grep "^pulse-access:" pulse-access:x:990: $ getent group | grep "^mock:" mock:x:989:
The mock group in LDAP used to have GID 990; I changed it to 989 (as shown in the ldapsearch results above).
On Monday, 7 May 2012 16:22:58 Braden McDaniel wrote:
On Mon, 2012-05-07 at 11:27 +0200, Buchan Milne wrote:
On Monday, 7 May 2012 08:04:34 Braden McDaniel wrote:
If I remove the user from the group in LDAP, that is reflected in the output of "groups". But, when I add it back, "groups" shows the (local) group associated with the old GID, not the new one.
So it's as if something on the client side has gotten the group *name* from LDAP and has locally cached an association with the old GID.
You have a local group and an LDAP group, with the same name, and different GIDs?
Not "have"; *had*. I changed the LDAP group GID to match the local grou GID. But "groups" still shows the local group associated with the old GID.
So, you no longer have local and LDAP groups with the same *name* ?
If so, there is something weird.
If you *do* have group with the same name locally and in LDAP, you should experience what you are experiencing with your current setup.
Regards, Buchan
On Mon, 2012-05-07 at 17:11 +0200, Buchan Milne wrote:
On Monday, 7 May 2012 16:22:58 Braden McDaniel wrote:
On Mon, 2012-05-07 at 11:27 +0200, Buchan Milne wrote:
On Monday, 7 May 2012 08:04:34 Braden McDaniel wrote:
If I remove the user from the group in LDAP, that is reflected in the output of "groups". But, when I add it back, "groups" shows the (local) group associated with the old GID, not the new one.
So it's as if something on the client side has gotten the group *name* from LDAP and has locally cached an association with the old GID.
You have a local group and an LDAP group, with the same name, and different GIDs?
Not "have"; *had*. I changed the LDAP group GID to match the local grou GID. But "groups" still shows the local group associated with the old GID.
So, you no longer have local and LDAP groups with the same *name* ?
I do; but that name is not what shows up in the out put of "groups" (or "id"). There is no corresponding group name "pulse-access" in LDAP and there is no LDAP group with GID 990.
If so, there is something weird.
That is my impression.
openldap-technical@openldap.org
-
Braden McDaniel -
Buchan Milne -
Chris Jacobs -
zoolook