Hide Forgot
Description of problem: RHEL7.3 machine, joined to an Active Directory domain. When attempting to run `id username` (or any other mechanism for inspecting users), some group memberships are missing (in one user's case, all group memberships beyond the primary "Domnain Users" is missing). Setting `ldap_use_tokengroups = false` works around the issue for direct memberships, with the downside of not supporting nested groups. Version-Release number of selected component (if applicable): # cat /etc/redhat-release Red Hat Enterprise Linux Server release 7.3 (Maipo) # yum list installed | grep sssd certificate verify failed python-sssdconfig.noarch 1.14.0-43.el7_3.11 @rhel-7-server-rpms sssd.x86_64 1.14.0-43.el7_3.11 @rhel-7-server-rpms sssd-ad.x86_64 1.14.0-43.el7_3.11 @rhel-7-server-rpms sssd-client.i686 1.14.0-43.el7_3.11 @rhel-7-server-rpms sssd-client.x86_64 1.14.0-43.el7_3.11 @rhel-7-server-rpms sssd-common.x86_64 1.14.0-43.el7_3.11 @rhel-7-server-rpms sssd-common-pac.x86_64 1.14.0-43.el7_3.11 @rhel-7-server-rpms sssd-ipa.x86_64 1.14.0-43.el7_3.11 @rhel-7-server-rpms sssd-krb5.x86_64 1.14.0-43.el7_3.11 @rhel-7-server-rpms sssd-krb5-common.x86_64 1.14.0-43.el7_3.11 @rhel-7-server-rpms sssd-ldap.x86_64 1.14.0-43.el7_3.11 @rhel-7-server-rpms sssd-proxy.x86_64 1.14.0-43.el7_3.11 @rhel-7-server-rpms How reproducible: Every time for certain users. Not all users appear to be affected, but those that are are consistently affected. Steps to Reproduce: 1. Have sssd use tokengroups with sss-ad provider (the default) 2. id `username` 3. Reconcile group memberships with AD Actual results: uid=12484(username) gid=3513(domain users) groups=3513(domain users) Workaround results: uid=12484(username) gid=3513(domain users) groups=3513(domain users),16304(AD Group 2) Expected results: uid=12484(username) gid=3513(domain users) groups=3513(domain users),16304(AD Group 2),15500(Nested AD Group 3) Additional info: Can provide more detailed information on request, but not sure what additional information would be helpful at this time. Appears to be related to #1417170 (RHEL6 bug) and #1372440, but the latter is restricted and I can't view it.
Please attach sssd.conf and the sssd_domain.name.log file with 'debug_level = 10' in the [domain/...] section of sssd.conf (see https://fedorahosted.org/sssd/wiki/Troubleshooting for details). One typical reason for tokengroups to fail is a disabled subdomain provider.
Is there anything in particular I can look for in those logs? This is interfacing with an AD & users that are not my responsibility, and I'd never get approval to post a debug log with that data (SIDs, hostnames, etc). Specific errors or excerpts (which I can review & redact) shouldn't be an issue.
Cab you send a redacted version of sssd.conf? The tokengroups processing starts in the log with 'Requesting attrs: [tokenGroups]'. Then the processing of the returned SIDs follow. For special SIDs like 'SID S-1-5-32-*' it is ok to see 'Domain not found' messages. But for all SIDs like S-1-5-21-5435432-413423-325443-1234 the domain should be available and if the SID was not found in the cache it should be read from AD with 'ldap_search_ext'. HTH bye, Sumit
I'm sorry, but it has been more than a month since requesting the additional information, so I'm going to close this bug. If you can reproduce the issue, please reopen the bug report and include the information requested in comment #4.
Created attachment 1320858 [details] sssd config file
Created attachment 1320859 [details] sssd log file
Hi, I am having exactly the issue as reported by the original bug reporter. I provided the requested configuration and log file as attachments to the ticket - see above. The sssd version I am using is 1.14.0-43.el7_3.18 The Active Directory that is queried has a Active Directory domain and forest functional level of Windows Server 2003. The redacted log file is showing the lookup for a user where only the primary group is returned but it should return 28 groups that the user is member of. If you need further information let me know. I hope I can help to resolve this bug.
Thank you for the logs. The tokenGroups lookup did not return any result. As can be seen in e.g. https://msdn.microsoft.com/en-us/library/cc223395.aspx tokenGroups require that a global catalog is present. Is this the case in your enviroment? Does the following search return any result for you: kinit -k ldapsearch -Y GSSAPI -H ldap://adserver1.domain.local -b 'CN=Test User,OU=Benutzer normal,OU=Benutzer,DC=domain,DC=local' -s base tokenGroupsNoGCAcceptable (for 'kinit -k' you have to be root, you can kinit as any other AD user as well but with 'kinit -k' you would use the same principal as SSSD uses).
Thank you for the quick response. Our environment is very simple. It has a single domain controller which is also the global catalog server. When I run as local root ~]# kinit -k it gives the error: kinit: Client 'host/redhat1.domain.local@DOMAIN.LOCAL' not found in Kerberos database while getting initial credentials But when I run kinit with the useraccount: ~]# kinit testuser Password for testuser@DOMAIN.LOCAL: It succeeds and the ldapsearch works and gives these results: ~]# ldapsearch -Y GSSAPI -H ldap://adserver1.domain.local -b 'CN=Test User,OU=Benutzer normal,OU=Benutzer,DC=domain,DC=local' -s base tokenGroupsNoGCAcceptable SASL/GSSAPI authentication started SASL username: testuser@DOMAIN.LOCAL SASL SSF: 56 SASL data security layer installed. # extended LDIF # # LDAPv3 # base <CN=Test User,OU=Benutzer normal,OU=Benutzer,DC=domain,DC=local> with scope baseObject # filter: (objectclass=*) # requesting: tokenGroupsNoGCAcceptable # # Test User, Benutzer normal, Benutzer, domain.local dn: CN=Test User,OU=Benutzer normal,OU=Benutzer,DC=domain,DC=local tokenGroupsNoGCAcceptable:: AQUAAAAAAAUVAAAA/UNGHhMWEAkWwOoyZwQAAA== tokenGroupsNoGCAcceptable:: AQIAAAAAAAUgAAAAKwIAAA== tokenGroupsNoGCAcceptable:: AQIAAAAAAAUgAAAAIQIAAA== tokenGroupsNoGCAcceptable:: AQUAAAAAAAUVAAAA+kqtY8ywEdN+ffPHtQQAAA== tokenGroupsNoGCAcceptable:: AQUAAAAAAAUVAAAA+kqtY8ywEdN+ffPHSgkAAA== tokenGroupsNoGCAcceptable:: AQUAAAAAAAUVAAAA+kqtY8ywEdN+ffPHxwkAAA== tokenGroupsNoGCAcceptable:: AQUAAAAAAAUVAAAA+kqtY8ywEdN+ffPHVAQAAA== tokenGroupsNoGCAcceptable:: AQUAAAAAAAUVAAAA+kqtY8ywEdN+ffPH6AQAAA== tokenGroupsNoGCAcceptable:: AQUAAAAAAAUVAAAA+kqtY8ywEdN+ffPHiwgAAA== tokenGroupsNoGCAcceptable:: AQUAAAAAAAUVAAAA+kqtY8ywEdN+ffPH6gQAAA== tokenGroupsNoGCAcceptable:: AQUAAAAAAAUVAAAA+kqtY8ywEdN+ffPH8AQAAA== tokenGroupsNoGCAcceptable:: AQUAAAAAAAUVAAAA+kqtY8ywEdN+ffPH5QQAAA== tokenGroupsNoGCAcceptable:: AQUAAAAAAAUVAAAA+kqtY8ywEdN+ffPHkAgAAA== tokenGroupsNoGCAcceptable:: AQUAAAAAAAUVAAAA+kqtY8ywEdN+ffPHZQkAAA== tokenGroupsNoGCAcceptable:: AQUAAAAAAAUVAAAA+kqtY8ywEdN+ffPHrQgAAA== tokenGroupsNoGCAcceptable:: AQUAAAAAAAUVAAAA+kqtY8ywEdN+ffPHPwkAAA== tokenGroupsNoGCAcceptable:: AQUAAAAAAAUVAAAA+kqtY8ywEdN+ffPHkggAAA== tokenGroupsNoGCAcceptable:: AQUAAAAAAAUVAAAA+kqtY8ywEdN+ffPHSwkAAA== tokenGroupsNoGCAcceptable:: AQUAAAAAAAUVAAAA+kqtY8ywEdN+ffPHRQkAAA== tokenGroupsNoGCAcceptable:: AQUAAAAAAAUVAAAA+kqtY8ywEdN+ffPHQwkAAA== tokenGroupsNoGCAcceptable:: AQUAAAAAAAUVAAAA+kqtY8ywEdN+ffPHjwgAAA== tokenGroupsNoGCAcceptable:: AQUAAAAAAAUVAAAA+kqtY8ywEdN+ffPHewkAAA== tokenGroupsNoGCAcceptable:: AQUAAAAAAAUVAAAA+kqtY8ywEdN+ffPHngQAAA== tokenGroupsNoGCAcceptable:: AQUAAAAAAAUVAAAA+kqtY8ywEdN+ffPHZAkAAA== tokenGroupsNoGCAcceptable:: AQUAAAAAAAUVAAAA+kqtY8ywEdN+ffPHjQgAAA== tokenGroupsNoGCAcceptable:: AQUAAAAAAAUVAAAA+kqtY8ywEdN+ffPHAQIAAA== tokenGroupsNoGCAcceptable:: AQUAAAAAAAUVAAAA+kqtY8ywEdN+ffPHQQkAAA== tokenGroupsNoGCAcceptable:: AQUAAAAAAAUVAAAA+kqtY8ywEdN+ffPHTAkAAA== tokenGroupsNoGCAcceptable:: AQUAAAAAAAUVAAAA+kqtY8ywEdN+ffPHjggAAA== tokenGroupsNoGCAcceptable:: AQUAAAAAAAUVAAAA+kqtY8ywEdN+ffPHjAgAAA== tokenGroupsNoGCAcceptable:: AQUAAAAAAAUVAAAA+kqtY8ywEdN+ffPH5wQAAA== # search result search: 4 result: 0 Success # numResponses: 2 # numEntries: 1
(In reply to ttt from comment #10) > Thank you for the quick response. > > Our environment is very simple. It has a single domain controller which is > also the global catalog server. > > When I run as local root > ~]# kinit -k > > it gives the error: > kinit: Client 'host/redhat1.domain.local@DOMAIN.LOCAL' not found in Kerberos > database while getting initial credentials ah, sorry, please try kinit -k REDHAT1$@DOMAIN.LOCAL (you can use 'klist -k' to list the keytab content and there should be a principal with a '$' sign in it). > > But when I run kinit with the useraccount: > ~]# kinit testuser > Password for testuser@DOMAIN.LOCAL: > > It succeeds and the ldapsearch works and gives these results: > > ~]# ldapsearch -Y GSSAPI -H ldap://adserver1.domain.local -b 'CN=Test > User,OU=Benutzer normal,OU=Benutzer,DC=domain,DC=local' -s base > tokenGroupsNoGCAcceptable > SASL/GSSAPI authentication started > SASL username: testuser@DOMAIN.LOCAL > SASL SSF: 56 > SASL data security layer installed. > # extended LDIF > # > # LDAPv3 > # base <CN=Test User,OU=Benutzer normal,OU=Benutzer,DC=domain,DC=local> with > scope baseObject > # filter: (objectclass=*) > # requesting: tokenGroupsNoGCAcceptable > # Does it show the same list if you use 'tokenGroups' instead of 'tokenGroupsNoGCAcceptable'?
kinit -k REDHAT1$@DOMAIN.LOCAL is giving me the error: kinit: Keytab contains no suitable keys for REDHAT1DOMAIN.LOCAL@DOMAIN.LOCAL while getting initial credentials but 'klist -k' is listing the host in the keytab file: klist -ek Keytab name: FILE:/etc/krb5.keytab KVNO Principal ---- -------------------------------------------------------------------------- 3 host/redhat1.domain.local@DOMAIN.LOCAL (des-cbc-crc) 3 host/redhat1.domain.local@DOMAIN.LOCAL (des-cbc-md5) 3 host/redhat1.domain.local@DOMAIN.LOCAL (aes128-cts-hmac-sha1-96) 3 host/redhat1.domain.local@DOMAIN.LOCAL (aes256-cts-hmac-sha1-96) 3 host/redhat1.domain.local@DOMAIN.LOCAL (arcfour-hmac) 3 host/REDHAT1@DOMAIN.LOCAL (des-cbc-crc) 3 host/REDHAT1@DOMAIN.LOCAL (des-cbc-md5) 3 host/REDHAT1@DOMAIN.LOCAL (aes128-cts-hmac-sha1-96) 3 host/REDHAT1@DOMAIN.LOCAL (aes256-cts-hmac-sha1-96) 3 host/REDHAT1@DOMAIN.LOCAL (arcfour-hmac) 3 REDHAT1$@DOMAIN.LOCAL (des-cbc-crc) 3 REDHAT1$@DOMAIN.LOCAL (des-cbc-md5) 3 REDHAT1$@DOMAIN.LOCAL (aes128-cts-hmac-sha1-96) 3 REDHAT1$@DOMAIN.LOCAL (aes256-cts-hmac-sha1-96) 3 REDHAT1$@DOMAIN.LOCAL (arcfour-hmac) Maybe an issue with the used/available key encryption? The ldap search is showing the same list when I use 'tokenGroups' instead of 'tokenGroupsNoGCAcceptable' Best regards
I think you need to quote the principal to avoid expanding the dollar-sign, e.g. 'kinit -k REDHAT1$@DOMAIN.LOCAL'
using kinit -k 'REDHAT1$@DOMAIN.LOCAL' did the trick. Running the ldapsearch in this context is now showing no results when searching for 'tokenGroups' or 'tokenGroupsNoGCAcceptable': # kinit -k 'REDHAT1$@DOMAIN.LOCAL' # ldapsearch -Y GSSAPI -H ldap://adserver1.domain.local -b 'CN=Test User,OU=Benutzer normal,OU=Benutzer,DC=domain,DC=local' -s base tokenGroups SASL/GSSAPI authentication started SASL username: REDHAT1$@DOMAIN.LOCAL SASL SSF: 56 SASL data security layer installed. # extended LDIF # # LDAPv3 # base <CN=Test User,OU=Benutzer normal,OU=Benutzer,DC=domain,DC=local> with scope baseObject # filter: (objectclass=*) # requesting: tokenGroups # # Test User, Benutzer normal, Benutzer, domain.local dn: CN=Test User,OU=Benutzer normal,OU=Benutzer,DC=domain,DC=local # search result search: 4 result: 0 Success # numResponses: 2 # numEntries: 1 But that is not the case for all users. When I search for other users I get no results for some but for others I get results. I found out that it seems to depend on how the user is created. When I create a new user the ldapsearch with context kinit -k 'REDHAT1$@DOMAIN.LOCAL' does not return results for 'tokenGroups' or 'tokenGroupsNoGCAcceptable'. But when I create a new user on the domain controller in MMC 'Active Directory Users and Computers' by copying from an existing user, where the search works, it also works for the new user.
This sounds like a permission issue. Can you compare in e.g. MMC's 'Users and Computers' in the 'Securitiy' tab the permissions for 'Authenticated Users' for a working and a non-working account?
You are right - the permissions were the cause of the issue. For the non-working accounts the right “Read remote access information” was missing. As soon as this is set the tokenGroups are read successfully. Now I also found an article that also mentions this requirement: https://outsideit.net/realmd-sssd-ad-authentication/ chapter "Required security permissions in AD" Thank you very much for your help!