RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1432982 - sssd missing AD group memberships when using tokengroups (the default)
Summary: sssd missing AD group memberships when using tokengroups (the default)
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: sssd
Version: 7.3
Hardware: All
OS: Linux
unspecified
medium
Target Milestone: rc
: ---
Assignee: SSSD Maintainers
QA Contact: sssd-qe
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-03-16 13:58 UTC by Chris Irwin
Modified: 2024-03-25 14:58 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-05-03 20:48:21 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
sssd config file (528 bytes, text/plain)
2017-09-01 07:40 UTC, ttt 		no flags Details
sssd log file (229.52 KB, text/plain)
2017-09-01 07:41 UTC, ttt 		no flags Details
View All

Description Chris Irwin 2017-03-16 13:58:00 UTC 
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.
Comment 2 Sumit Bose 2017-03-16 14:39:55 UTC 
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.
Comment 3 Chris Irwin 2017-03-16 17:01:18 UTC 
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.
Comment 4 Sumit Bose 2017-03-16 17:34:37 UTC 
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
Comment 5 Jakub Hrozek 2017-05-03 20:48:21 UTC 
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.
Comment 6 ttt 2017-09-01 07:40:25 UTC 
Created attachment 1320858 [details]
sssd config file
Comment 7 ttt 2017-09-01 07:41:26 UTC 
Created attachment 1320859 [details]
sssd log file
Comment 8 ttt 2017-09-01 07:49:13 UTC 
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.
Comment 9 Sumit Bose 2017-09-01 08:28:25 UTC 
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).
Comment 10 ttt 2017-09-01 16:18:26 UTC 
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' not found in Kerberos database while getting initial credentials

But when I run kinit with the useraccount:
~]# kinit testuser
Password for testuser:

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
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
Comment 11 Sumit Bose 2017-09-01 16:31:34 UTC 
(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' 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:
> 
> 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
> 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'?
Comment 12 ttt 2017-09-04 08:06:21 UTC 
    kinit -k REDHAT1$@DOMAIN.LOCAL

is giving me the error:

kinit: Keytab contains no suitable keys for REDHAT1DOMAIN.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 (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 host/REDHAT1 (des-cbc-crc)
   3 host/REDHAT1 (des-cbc-md5)
   3 host/REDHAT1 (aes128-cts-hmac-sha1-96)
   3 host/REDHAT1 (aes256-cts-hmac-sha1-96)
   3 host/REDHAT1 (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
Comment 13 Jakub Hrozek 2017-09-04 08:25:42 UTC 
I think you need to quote the principal to avoid expanding the dollar-sign, e.g.     'kinit -k REDHAT1$@DOMAIN.LOCAL'
Comment 14 ttt 2017-09-04 09:28:09 UTC 
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.
Comment 15 Sumit Bose 2017-09-04 09:48:02 UTC 
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?
Comment 16 ttt 2017-09-04 12:31:05 UTC 
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!
Note You need to log in before you can comment on or make changes to this bug.