SSSD / sssd

#3437 cifs_idmap_sss.so unable to resolve SID→UID/GID when sssd-ldap used to query AD?
Closed: worksforme Opened by dwm99.

Closed: worksforme
Reopen Issue

Version: 1.13.4 (specifically, binary package 1.13.4-1ubuntu1.5)

SSSD appears to be unable to resolve SIDs to UID/GID for cifs_idmap_sss.so when its configured to use the LDAP, rather than AD, backend to communicate with an Active DIrectory installation.

I have SSSD configured to use AD as the source for user and group information on a host. It's using the LDAP, rather than AD, backend, because the host lacks a keytab. It instead uses an obfuscated LDAP passphrase.

I'm attempting to set up ID mapping such that running getcifsacls on a CIFS filesystem mount returns resolved names rather than bare SIDs. The CIFS mount works, the kernel correctly invokes request-key, which in turn correctly invokes cifs.idmap, the cifs.idmap library symlink in /etc/cifs-utils correctly points to the appropriate SSSD library, and SSSD is receiving and processing BE_REQ_USER_AND_GROUP queries when a user runs getcifscreds.

However, SSSD is not successfully resolving SIDs to the corresponding UID/GID—according to logs, it's failing to find any matching objects, even though I've verified that the SID its looking up exists, is correct.

The logs generated by SSSD look like this:

(Mon Jun 26 15:31:11 2017) [sssd[be[MY.AD.FQDN.HERE]]] [be_get_account_info] (0x0200): Got request for [0x1012][FAST BE_REQ_USER_AND_GROUP][1][name=s-1-5-21-…-…-…-513]
(Mon Jun 26 15:31:11 2017) [sssd[be[MY.AD.FQDN.HERE]]] [be_req_set_domain] (0x0400): Changing request domain from [MY.AD.FQDN.HERE] to [MY.AD.FQDN.HERE]
(Mon Jun 26 15:31:11 2017) [sssd[be[MY.AD.FQDN.HERE]]] [sdap_get_groups_next_base] (0x0400): Searching for groups with base [DC=my,DC=ad,DC=fqdn,DC=here]
(Mon Jun 26 15:31:11 2017) [sssd[be[MY.AD.FQDN.HERE]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(cn=s-1-5-21-…-…-…-513)(objectClass=group)(cn=*))][DC=my,DC=ad,DC=fqdn,DC=here].
(Mon Jun 26 15:31:11 2017) [sssd[be[MY.AD.FQDN.HERE]]] [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no errmsg set
(Mon Jun 26 15:31:11 2017) [sssd[be[MY.AD.FQDN.HERE]]] [sdap_get_groups_process] (0x0400): Search for groups, returned 0 results.
(Mon Jun 26 15:31:11 2017) [sssd[be[MY.AD.FQDN.HERE]]] [sysdb_search_by_name] (0x0400): No such entry
(Mon Jun 26 15:31:11 2017) [sssd[be[MY.AD.FQDN.HERE]]] [sysdb_delete_group] (0x0400): Error: 2 (No such file or directory)
(Mon Jun 26 15:31:11 2017) [sssd[be[MY.AD.FQDN.HERE]]] [sdap_search_user_next_base] (0x0400): Searching for users with base [DC=my,DC=ad,DC=fqdn,DC=here]
(Mon Jun 26 15:31:11 2017) [sssd[be[MY.AD.FQDN.HERE]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(name=s-1-5-21-…-…-…-513)(objectclass=user)(name=*)(objectSid=*))][DC=my,DC=ad,DC=fqdn,DC=here].
(Mon Jun 26 15:31:11 2017) [sssd[be[MY.AD.FQDN.HERE]]] [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no errmsg set
(Mon Jun 26 15:31:11 2017) [sssd[be[MY.AD.FQDN.HERE]]] [sdap_search_user_process] (0x0400): Search for users, returned 0 results.
(Mon Jun 26 15:31:11 2017) [sssd[be[MY.AD.FQDN.HERE]]] [sdap_get_users_done] (0x0040): Failed to retrieve users
(Mon Jun 26 15:31:11 2017) [sssd[be[MY.AD.FQDN.HERE]]] [sysdb_search_by_name] (0x0400): No such entry
(Mon Jun 26 15:31:11 2017) [sssd[be[MY.AD.FQDN.HERE]]] [sysdb_delete_user] (0x0400): Error: 2 (No such file or directory)
(Mon Jun 26 15:31:11 2017) [sssd[be[MY.AD.FQDN.HERE]]] [sysdb_search_object_by_str_attr] (0x0400): No such entry.
(Mon Jun 26 15:31:11 2017) [sssd[be[MY.AD.FQDN.HERE]]] [sysdb_delete_by_sid] (0x0400): search by sid did not return any results.
(Mon Jun 26 15:31:11 2017) [sssd[be[MY.AD.FQDN.HERE]]] [acctinfo_callback] (0x0100): Request processed. Returned 0,0,Success

(I've redacted/mangled some domain and SID fields.)

If my reading is accurate, the SSSD LDAP backend is performing queries against the backing AD, searching for objects where either the 'name' or 'cn' field matches the pretty-printed SID depending on whether it is looking up a user or group, respectively. This naturally fails; it would need to instead search using the appropriate binary form of the objectSid field.

As a consequence, SSSD returns failure to the cifs.upcall process, ultimately causing the getcifscreds utility to return bare SIDs rather than resolved names.

My current hypothesis is that the BE_REQ_USER_AND_GROUP query being issued by the cifs_idmap_sss.so plugin to SSSD would normally be specially interpreted by the sssd-ad backend as being a SID→UID/GID lookup query, thus triggering some suitable logic, whereas the sssd-ldap backend lacks any such specialised logic, and so defaults to a conventional query on the 'name=' or 'cn=' fields, attempting to find a user or group named with the literal string that it is passed.

If my understanding is correct, it would be good if this limitation could be documented—or, ideally, eliminated!

Can you add you sssd.conf? In general it might be easier in your case to use the AD provider but disable SASL authentication and add your bind DN and ldap password

ldap_sasl_mech = none
ldap_default_bind_dn = ....
ldap_default_authtok = ....

should be sufficient here.

Here's a copy of the original sssd.conf file I was attempting to use, with obvious redactions.

sssd.conf

I did not realise that the sssd-ad backend could be used without a keytab; the sssd-ad man page indicated one was necessary:

This provider requires that the machine be joined to the AD domain and a keytab is available.

Indeed, I've tried to configure this as you suggest, and run into problems when the AD backend tries to initialise:

(Wed Jun 28 11:07:17 2017) [sssd[be[MY.AD.FQDN.HERE]]] [ad_set_sdap_options] (0x0100): Option krb5_realm set to MY.AD.FQDN.HERE
(Wed Jun 28 11:07:17 2017) [sssd[be[MY.AD.FQDN.HERE]]] [sdap_set_sasl_options] (0x0100): Will look for testhost@MY.AD.FQDN.HERE in default keytab
(Wed Jun 28 11:07:17 2017) [sssd[be[MY.AD.FQDN.HERE]]] [select_principal_from_keytab] (0x0200): trying to select the most appropriate principal from keytab
(Wed Jun 28 11:07:17 2017) [sssd[be[MY.AD.FQDN.HERE]]] [find_principal_in_keytab] (0x0020): krb5_kt_start_seq_get failed.
(Wed Jun 28 11:07:17 2017) [sssd[be[MY.AD.FQDN.HERE]]] [find_principal_in_keytab] (0x0020): krb5_kt_start_seq_get failed.
(Wed Jun 28 11:07:17 2017) [sssd[be[MY.AD.FQDN.HERE]]] [find_principal_in_keytab] (0x0020): krb5_kt_start_seq_get failed.
(Wed Jun 28 11:07:17 2017) [sssd[be[MY.AD.FQDN.HERE]]] [find_principal_in_keytab] (0x0020): krb5_kt_start_seq_get failed.
(Wed Jun 28 11:07:17 2017) [sssd[be[MY.AD.FQDN.HERE]]] [find_principal_in_keytab] (0x0020): krb5_kt_start_seq_get failed.
(Wed Jun 28 11:07:17 2017) [sssd[be[MY.AD.FQDN.HERE]]] [find_principal_in_keytab] (0x0020): krb5_kt_start_seq_get failed.
(Wed Jun 28 11:07:17 2017) [sssd[be[MY.AD.FQDN.HERE]]] [find_principal_in_keytab] (0x0020): krb5_kt_start_seq_get failed.
(Wed Jun 28 11:07:17 2017) [sssd[be[MY.AD.FQDN.HERE]]] [select_principal_from_keytab] (0x0080): No suitable principal found in keytab
(Wed Jun 28 11:07:17 2017) [sssd[be[MY.AD.FQDN.HERE]]] [select_principal_from_keytab] (0x0010): Failed to read keytab [default]: No such file or directory
(Wed Jun 28 11:07:17 2017) [sssd[be[MY.AD.FQDN.HERE]]] [ad_set_sdap_options] (0x0040): Cannot set the SASL-related options
(Wed Jun 28 11:07:17 2017) [sssd[be[MY.AD.FQDN.HERE]]] [load_backend_module] (0x0010): Error (2) in module (ad) initialization (sssm_ad_id_init)!
(Wed Jun 28 11:07:17 2017) [sssd[be[MY.AD.FQDN.HERE]]] [be_process_init] (0x0010): fatal error initializing data providers

By inspection, there seems to be an unconditional call chain where ad_get_id_options(…) calls ad_set_sdap_options(…), which calls sdap_set_sasl_options(…), which calls select_principal_from_keytab(…). I can't see any path where the lack of a valid keytab doesn't cause the AD backend to abort with a fatal error.

(Though I could try faking a syntactically valid keytab for testing purposes, this does not appeal for a production deployment!)

I tested your sssd.conf with a recent version of SSSD and it is working as expected:

[root@vm-136 sssd]# systemctl stop sssd ; rm -rf /var/log/sssd/* /var/lib/sss/db/* ; systemctl start sssd
[root@vm-136 sssd]# python
Python 2.7.5 (default, Jan 23 2017, 09:42:02) 
[GCC 4.8.5 20150623 (Red Hat 4.8.5-11)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import pysss_nss_idmap
>>> pysss_nss_idmap.getnamebysid('S-1-5-21-1622806234-1442095631-4165425077-41097')
{'S-1-5-21-1622806234-1442095631-4165425077-41097': {'type': 1, 'name': u'testuser39991'}}
>>> pysss_nss_idmap.getnamebysid('S-1-5-21-1622806234-1442095631-4165425077-41096')
{'S-1-5-21-1622806234-1442095631-4165425077-41096': {'type': 1, 'name': u'testuser39990'}}
>>> pysss_nss_idmap.getnamebysid('S-1-5-21-1622806234-1442095631-4165425077-512')
{'S-1-5-21-1622806234-1442095631-4165425077-512': {'type': 2, 'name': u'domain admins'}}
>>> pysss_nss_idmap.getsidbyname('Administrator')
{'Administrator': {'type': 1, 'sid': u'S-1-5-21-1622806234-1442095631-4165425077-500'}}
>>>

The python methods use the same interfaces as the cifs-utils. Do you have the chance to test your configuration with a newer version of SSSD?

About using the AD provider. Sorry, I didn't realize we unconditionally check for a keytab. Nevertheless you do not have to fake the keytab. You can create a keytab for the account you used for authentication. For this you have to use the Kerberos principal of this account which is 'samAccountName@YOUR.AD.REALM'. You can check if it is correct by calling kinit with this principal.

Now you can use ktutil to create keytab entries for this principal:

# ktutil 
ktutil:  addent -password -p samAccountName@YOUR.AD.REALM -k 2 -e arcfour-hmac
Password for samAccountName@YOUR.AD.REALM: 
ktutil:  addent -password -p samAccountName@YOUR.AD.REALM -k 2 -e aes256-cts-hmac-sha1-96
Password for samAccountName@YOUR.AD.REALM: 
ktutil:

The two encryption types from above should be sufficient for most AD DCs. To be on the save side you might want to add des-cbc-crc, des-cbc-md5 and aes128-cts-hmac-sha1-96 as well. Now you can write the keys with wkt to a keytab file. To test it call 'kinit -k -t keytab.file'.

Finally you should set 'ldap_sasl_authid = samAccountName@YOUR.AD.REALM' in sssd.conf and point ldap_krb5_keytab to the keytab file if you used a different one than /etc/krb5.conf.

HTH

Metadata Update from @sbose:
- Custom field cc adjusted to sbose

Thank you very much for your assistance!

The python bindings are very valuable, and has allowed me to confirm that getsidbyname works, while getnamebysid doesn't:

>>> pysss_nss_idmap.getsidbyname('user')
{'user': {'type': 1, 'sid': u'S-1-5-21-…-…-…-…'}}
>>> pysss_nss_idmap.getnamebysid(pysss_nss_idmap.getsidbyname('user')['user']['sid'])
{}

However, your trick for generating a valid keytab works (I should have thought of this!) — and switching to the sssd-ad backend causes ID mapping to start working for all SIDs in the upstream AD.

I note that it's also necessary to specify:

krb5_validate = false

… as otherwise SSSD will (quite reasonably!) try to verify TGTs it fetches by requesting service-specific tickets for the principal stored in our keytab, which AD doesn't permit.

I did find one SID that didn't translate; investigating, that was a machine-local ID which does not exist in the AD, so quite naturally SSSD couldn't discover it's name. This may or may not be why the 'cifsacl' mount option doesn't work for me on this volume, but that's an independent problem.

For anyone else following along, I'd also note that — at least as of kernel 4.8 — the cifs.ko driver does not support ACL queries using getcifsacl or the like for SMB2+, so the above hoops are only worth jumping through if you're using the default CIFS/SMB1 protocol.

(That said, some patches were just added to the upstream cifs.ko driver last week to implement the required functionality: https://git.samba.org/sfrench/?p=sfrench/cifs-2.6.git;a=commit;h=7634f4efadfd8fdd430a2ec90d824745d6dbd0d0 — so this should appear in a Linus kernel Real Soon Now™.)

Thank you very much for your help; as well as reporting that this issue doesn't exist in newer versions of SSSD, you've also enabled me to workaround it in the version I'm supplied.

(Unfortunately, upgrading to a newer version of SSSD now would mean not using my upstream's stream of security and bugfix patches, which is unattractive — but I now have the option of either using this workaround, or waiting until next year when Ubuntu incorporate a current version of SSSD into their next LTS release.)

With many thanks,
—dwm

I guess we can close this ticket now since there is nothing to do from the upstream point of view?

Unless you're keen to try to figure out why Ubuntu's historical version of SSSD doesn't quite behave as expected, then yes, this ticket can be closed.

Kind regards,
—dwm

Unless you're keen to try to figure out why Ubuntu's historical version of SSSD doesn't quite behave as expected, then yes, this ticket can be closed.
Kind regards,

Or you would like to test with latest 1.13 upstream version from git :-) because 1.13 is LTM branch

Unless you're keen to try to figure out why Ubuntu's historical version of SSSD doesn't quite behave as expected, then yes, this ticket can be closed.
Kind regards,
—dwm

I think this is a job better suited for the Ubuntu developers :-)

Metadata Update from @jhrozek:
- Issue close_status updated to: worksforme
- Issue status updated to: Closed (was: Open)

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/4464

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.
Metadata
None
None
None
None
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.