I'll start out by saying that I don't know if sssd is the culprit in my problem or not; but if not, I hope someone here with more knowledge of the moving parts at play can point me in the right direction.
I have two machines: one with Fedora 16 and one with the Fedora 17 prerelease. I had initially created a posixGroup in LDAP for mock with GID 990. But then I realized that my two installations had different GIDs for the mock group. So, I decided to change the GID in LDAP and on the Fedora 16 box to match the GID for mock on the Fedora 17 installation (989). The Fedora 16 box seems to be just fine. However, the Fedora 17 box still seems to think that my user is a member of the group with GID 990 (which happens to be pulse-access): $ groups users desktop_admin_r ccache pulse-access $ getent group | grep mock mock:x:989: $ getent group | grep 990 pulse-access:x:990: At this point, *there is no group in LDAP with GID 990*: $ 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 And here's the really goofy bit (from my perspective): if I remove braden from the LDAP mock group, "groups" output no longer lists "pulse-access"; if I add braden back to the LDAP mock group, "groups" lists "pulse-access" once again. It seems (to me) like something has cached the association of the LDAP mock group with GID 990; and now the group *name* is being got from LDAP, associated with the old GID, and that old GID is being conveyed to tools that (rightfully) associate GID 990 with the local pulse-access group. Can anyone shed some light on what might be happening here? -- Braden McDaniel <bra...@endoframe.com> _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel