Learn more about these different git repos.
Other Git URLs
Hi,
We have CentOS 7.2 hosts Authenticating with SSSD and AD/POSIX.
Users are seeing secondary group name resolution issues when ssh'ing into the client and changing file ownership to a secondary group.
Subsequent logins intermitently see secondary group names preserved and ‘chown’ works. Other times we need to run ‘id’ to pull in the groups. This seems to be random (to me) but I can recreate the issue by refreshing group cache with sssd_cahce -G.
I tested chown by group id which works consistently (do not need to run 'id' beforehand). The issue seems to be with group name resolution.
I have attached logs, however needed to remove sensitive data relating to domains, users etc. So let me know and I can email over the logs in their entirety.
[tuser@myhost ~]$ date; chown tuser:mygroup02@mysubdomain.com /var/tmp/test Sat 16 Jul 22:58:16 BST 2016 chown: invalid group: ‘tuser:mygroup02@mysubdomain.com’
The attached sssd_01.txt was taken from the sssd log during the above ‘invalid group’ results.
Expected behaviour would be:
We have to run the below ‘id’ to pull in the secondary group names before running any file modifications relating to secondary group names.
[tuser@myhost ~]$ id uid=57101(tuser) gid=57006(mygroup01@mysubdomain.com) groups=57006(mygroup01@mysubdomain.com),57002(mygroup02@mysubdomain.com),57007(mygroup03@mysubdomain.com),57009(mygroup04@mysubdomain.com),57010(mygroup05@mysubdomain.com),57011(mygroup06@mysubdomain.com),57012(mygroup07@mysubdomain.com),57013(mygroup08@mysubdomain.com) [tuser@myhost ~]$ date; chown tuser:mygroup02@mysubdomain.com /var/tmp/test Sat 16 Jul 23:08:28 BST 2016 [tuser@myhost ~]$ echo $? 0
The attached sssd_02.txt was taken from the log during the above ‘id’ and successful ‘chown’
We are running SSSD version:
sssd-krb5-common-1.13.0-40.el7_2.9.x86_64 sssd-ldap-1.13.0-40.el7_2.9.x86_64 sssd-ipa-1.13.0-40.el7_2.9.x86_64 sssd-common-1.13.0-40.el7_2.9.x86_64 sssd-common-pac-1.13.0-40.el7_2.9.x86_64 sssd-krb5-1.13.0-40.el7_2.9.x86_64 sssd-proxy-1.13.0-40.el7_2.9.x86_64 sssd-1.13.0-40.el7_2.9.x86_64 sssd-client-1.13.0-40.el7_2.9.x86_64 sssd-ad-1.13.0-40.el7_2.9.x86_64
The sssd.conf looks like this:
[sssd] domains = mydomain.com config_file_version = 2 services = nss, pam, pac [domain/mydomain.com] id_provider = ad ad_server = mydc.mydomain.com ad_hostname = myhost.mydomain.com auth_provider = ad chpass_provider = ad access_provider = ad ldap_id_mapping = False
Any help would be appreciated.
Thanks,
attachment sssd_01.txt
attachment sssd_02.txt
Hi, please let me know if you need any further information to help progress this.
The logs capture only sssd startup, can we see logs that capture the lookup (sss_cache would invalidte the cache and force LDAP search on next lookup)
Hi, do you have a mail address where I could send the logs? There is sensitive data I would rather not attach to this ticket.
my nick at redhat dot com
Thanks, I have sent the logs.
I didn't receive any logs. Can you resend? jhrozek@redhat.com..
I have resent, please acknowledge receipt.
Yes, I got the logs. mzidek would look at them.
owner: somebody => mzidek
Hi, have you guys been able to review the logs at all? Thanks.
I just took a look and replied.
Me and Pavel send mails with request for more information, but we can't move the ticket forward w/o having answers to those questions. please reopen the ticket when we can get the debugging data we asked for. Thank you.
resolution: => worksforme status: new => closed
Metadata Update from @sssd321: - Issue assigned to mzidek - Issue set to the milestone: NEEDS_TRIAGE
SSSD is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in SSSD's github repository.
This issue has been cloned to Github and is available here: - https://github.com/SSSD/sssd/issues/4133
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Login to comment on this ticket.