#3100 SSSD, POSIX, AD invalid group
Closed: Invalid None Opened 7 years ago by sssd321.

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.

  1. tuser logs in via ssh and authenticates with AD password.
  2. Runs the below ‘chown’ and receives ‘invalid group’ for secondary group.
  3. tuser runs ‘id’ then ‘chown works’

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:

  1. User logs in via ssh and authenticates with AD password.
  2. Runs ‘chown’ and the command executes successfully

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,


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

7 years ago

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.

Thank you for understanding. We apologize for all inconvenience.

Login to comment on this ticket.

Metadata