I'd appreciate some guidance on debugging this problem.
At least on RHEL7, with sssd-1.13.0-40.el7_2.1, we've noticed that the ad backend doesn't always expand nested AD groups properly.
For example, we have group_1 with 5 members and group_2 with 7 members. One user is in both groups. The group_all group has two members: group_1 and group_2.
But if I do "getent group group_all", sometimes only 10 members are displayed, not 11. And the missing member is always the same user: me.
If I stop sssd, delete the cache files, and restart sssd, then "getent group group_all" properly returns all 11 members.
For now, I've turned on full debugging (0xffff) for the domain. I'm hoping that if I can catch the incorrect group expansion, the logs will show me why the expansion is incorrect.
Is there anything else I should be looking at to debug this problem?
Thanks!
P.S.: I don't know if it's related, but I noticed that "getent group 'domain users'" no longer lists every single user as a member of the 'domain users' group. Was this a change for 1.13? Or is this another problem?
On Mon, Feb 01, 2016 at 03:54:28PM -0500, James Ralston wrote:
I'd appreciate some guidance on debugging this problem.
At least on RHEL7, with sssd-1.13.0-40.el7_2.1, we've noticed that the ad backend doesn't always expand nested AD groups properly.
For example, we have group_1 with 5 members and group_2 with 7 members. One user is in both groups. The group_all group has two members: group_1 and group_2.
But if I do "getent group group_all", sometimes only 10 members are displayed, not 11. And the missing member is always the same user: me.
If I stop sssd, delete the cache files, and restart sssd, then "getent group group_all" properly returns all 11 members.
For now, I've turned on full debugging (0xffff) for the domain. I'm hoping that if I can catch the incorrect group expansion, the logs will show me why the expansion is incorrect.
Is there anything else I should be looking at to debug this problem?
In addition to the logs, it would be nice to see ldbsearch of working and non-working cache plase. You'd need to install the ldb-tools package and then run: ldbsearch -H /var/lib/sss/db/cache_$domain '(|(objectclass=user)(objectclass=group))'
Feel free to send these data directly, if you feel they contain confidential data.
Thanks!
P.S.: I don't know if it's related, but I noticed that "getent group 'domain users'" no longer lists every single user as a member of the 'domain users' group. Was this a change for 1.13? Or is this another problem?
The Domain Users group is a bit special in the sense it doesn't contain member/membreof links towards the users:
$ ldapsearch -Y GSSAPI -H ldap://dc.win.trust.test -b "CN=Domain Users,CN=Users,DC=win,DC=trust,DC=test" -s base SASL/GSSAPI authentication started SASL username: ADCLIENT$@WIN.TRUST.TEST SASL SSF: 56 SASL data security layer installed. # extended LDIF # # LDAPv3 # base <CN=Domain Users,CN=Users,DC=win,DC=trust,DC=test> with scope baseObject # filter: (objectclass=*) # requesting: ALL #
# Domain Users, Users, win.trust.test dn: CN=Domain Users,CN=Users,DC=win,DC=trust,DC=test objectClass: top objectClass: group cn: Domain Users description: All domain users distinguishedName: CN=Domain Users,CN=Users,DC=win,DC=trust,DC=test instanceType: 4 whenCreated: 20150905193639.0Z whenChanged: 20150905193639.0Z uSNCreated: 12348 memberOf: CN=Users,CN=Builtin,DC=win,DC=trust,DC=test uSNChanged: 12350 name: Domain Users objectGUID:: gskx06V5AEGi56AD5QXY1w== objectSid:: AQUAAAAAAAUVAAAAnAgacb3Gr3OQQ4kVAQIAAA== sAMAccountName: Domain Users sAMAccountType: 268435456 groupType: -2147483646 objectCategory: CN=Group,CN=Schema,CN=Configuration,DC=win,DC=trust,DC=test isCriticalSystemObject: TRUE dSCorePropagationData: 20150905193639.0Z dSCorePropagationData: 16010101000001.0Z
It's a primary group of AD users, so we keep adding the individual members to the group as they are requested, but can enumerate all users just with getent group..
sssd-users@lists.fedorahosted.org