sssd-users October 2020

sssd-users@lists.fedorahosted.org

12 participants
11 discussions

sssd performance on large domains
by zfnoctis＠gmail.com 03 Feb '22

03 Feb '22

Hi, I'm wondering if there are any plans to improve sssd performance on large active directory domains (100k+ users, 40k+ groups), or if there are settings I am not aware of that can greatly improve performance, specifically for workstation use cases. Currently if I do not set "ignore_group_members = True" in sssd.conf, logins can take upwards of 6 minutes and "sssd_be" will max the CPU for up to 20 minutes after logon, which makes it a non-starter. The reason I want to allow group members to be seen is that I want certain domain groups to be able to perform elevated actions using polkit. If I ignore group members, polkit reports that the group is empty and so no one can elevate in the graphical environment. Ultimately this means that Linux workstations are at a severe disadvantage since they cannot be bound to the domain and have the normal set of access features users and IT expect from macOS or Windows. Distributions used: Ubuntu 16.04 (sssd 1.13.4-1ubuntu1.1), Ubuntu 16.10 (sssd 1.13.4-3) and Fedora 24 (sssd-1.13.4-3.fc24). All exhibit the same problems. I've also tried "ldap_group_nesting_level = 1" without seeing any noticeable improvement with respect to performance. Putting the database on /tmp isn't viable as these are workstations that will reboot semi-frequently, and I don't believe this is an I/O bound performance issue anyways. Thanks for your time.

6 29

sssd: AD range retrieval fails when enumeration is enabled
by R Davies 09 Aug '21

09 Aug '21

Hi, When enumeration is enabled (required due to legacy application), and where a group has > 1500 members, and AD's MaxValRange is at the default 1500, then sssd fails to show more than 1500 group members. Group lookups are no longer accurate. A further interesting aspect is that if the sssd cache is expired (sssctl cache-expiry -E), then the correct group membership is shown until such time as enumeration is processed again (i.e. at most ldap_enumeration_refresh_timeout + memcache_timeout) src/providers/ldap/sdap.c's sdap_parse_entry() states: /* This attribute contained range values and needs more to > * be retrieved > */ > /* TODO: return the set of attributes that need additional retrieval > * For now, we'll continue below and treat it as regular values. > */ As enumeration is enabled the subsequent ASQ/deref work is never undertaken. As such sssd only ever processes the initial range retrieved members (0-1499) (NB that nested groups members are evaluated). We have looked at the relevant source code, but can't find a way to trigger Attribute Scope Queries (ASQ)/deref. Indeed, no manner of sssd configuration settings (other than disabling enumeration - which we sadly cannot do) appears to change this behaviour. Increasing MaxValRange on AD defeats the purpose of having MaxValRange. Has anyone run into this before? Or, should I raise a new issue? Many Thanks. R.

5 7

ID Views for IPA ID Views for AD users inconsistent resolution
by Louis Abel 01 Aug '21

01 Aug '21

I didn't get a response in #sssd, so I figured I'll try here at the mail list. # rpm -q sssd ipa-server sssd-1.16.0-19.el7_5.5.x86_64 ipa-server-4.5.4-10.el7_5.3.x86_64 I've been scratching my head trying to resolve this particular issue. I'm having issues with AD users where when they login, they'll get the UID/GID assigned in the ID views correctly, but only some of the time. Other times, they won't get the id view assigned to them. This is all done in the default trust view. What makes this issue even more interesting is that out of my 6 domain controllers, sometimes it'll be one server out of the six that does it, sometimes it's two. But it's never the same ones, so it's difficult to track the particular issue down. What's even more interesting is this is not occurring with some users (like my own). I have yet to see it occur with my account or even the rest of my team's accounts. One of the things I tried to do is delete the ID views of the offending users and recreate them to no avail. I put SSSD into debug mode on the IPA servers and tried to get some relevant logs and such to try and figure this out. Below is my SSSD configuration, ldb info, and debug logs (removing private information where possible). I'm trying to determine if this is either a bug within SSSD or if this is a misconfiguration on my part. $ ldbsearch -H cache_ipa.example.com.ldb name=user.name(a)ad.example.com originalADuidNumber uidNumber originalADgidNumber gidNumber asq: Unable to register control with rootdse! # record 1 dn: name=user.name(a)ad.example.com,cn=users,cn=ad.example.com,cn=sysdb originalADuidNumber: 55616902 originalADgidNumber: 55616902 uidNumber: 55616902 gidNumber: 55616902 $ ipa idoverrideuser-show "Default Trust View" user.name(a)ad.example.com Anchor to override: user.name(a)ad.example.com UID: 40001 GID: 40001 Home directory: /home/user.name Login shell: /bin/bash $ ldbsearch -H timestamps_ipa.example.com.ldb | less dn: name=user.name(a)ad.example.com,cn=users,cn=ad.example.com,cn=sysdb objectCategory: user originalModifyTimestamp: 20180823172515.0Z entryUSN: 92632390 initgrExpireTimestamp: 1535133621 lastUpdate: 1535128235 dataExpireTimestamp: 1535133635 distinguishedName: name=user.name(a)ad.example.com,cn=users,cn=ad.example.com,cn=sysdb ## DEBUG LOGS (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [sysdb_set_entry_attr] (0x0200): Entry [name=user.name(a)ad.example.com,cn=users,cn=ad.example.com,cn=sysdb] has set [ts_cache] attrs. (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [ldb] (0x4000): commit ldb transaction (nesting: 0) (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [sdap_id_op_connect_step] (0x4000): reusing cached connection (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [ipa_get_ad_override_connect_done] (0x4000): Searching for overrides in view [Default Trust View] with filter [(&(objectClass=ipaOverrideAnchor)(ipaAnchorUUID=:SID:S-1-5-21-922099545-2851689246-2917073205-16902))]. (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [sdap_print_server] (0x2000): Searching 172.20.23.190:389 (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(objectClass=ipaOverrideAnchor)(ipaAnchorUUID=:SID:S-1-5-21-922099545-2851689246-2917073205-16902))][cn=Default Trust View,cn=views,cn=accounts,dc=ipa,dc=chotel,dc=com]. (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 32 (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [sdap_op_add] (0x2000): New operation 32 timeout 6 (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [sdap_process_result] (0x2000): Trace: sh[0x55f30a5d1080], connected[1], ops[(nil)], ldap[0x55f30a5d0f90] (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [sdap_process_result] (0x2000): Trace: end of ldap_result list (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [sdap_process_result] (0x2000): Trace: sh[0x55f30a5d1940], connected[1], ops[0x55f30a645310], ldap[0x55f30a5ce320] (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY] (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [sdap_parse_entry] (0x1000): OriginalDN: [ipaanchoruuid=:SID:S-1-5-21-922099545-2851689246-2917073205-16902,cn=Default Trust View,cn=views,cn=accounts,dc=ipa,dc=chotel,dc=com]. (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [objectClass] (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [loginShell] (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [uidNumber] (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipaAnchorUUID] (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [gidNumber] (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [homeDirectory] (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipaOriginalUid] (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [sdap_process_result] (0x2000): Trace: sh[0x55f30a5d1940], connected[1], ops[0x55f30a645310], ldap[0x55f30a5ce320] (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT] (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no errmsg set (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [sdap_op_destructor] (0x2000): Operation 32 finished (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [ipa_get_ad_override_done] (0x4000): Found override for object with filter [(&(objectClass=ipaOverrideAnchor)(ipaAnchorUUID=:SID:S-1-5-21-922099545-2851689246-2917073205-16902))]. (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [sdap_id_op_destroy] (0x4000): releasing operation connection (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [sysdb_apply_default_override] (0x4000): Override [uidNumber] with [40001] for [name=user.name(a)ad.example.com,cn=users,cn=ad.example.com,cn=sysdb]. (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [sysdb_apply_default_override] (0x0080): Override attribute for [gidNumber] has more [2] than one value, using only the first. (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [sysdb_apply_default_override] (0x4000): Override [gidNumber] with [40001] for [name=user.name(a)ad.example.com,cn=users,cn=ad.example.com,cn=sysdb]. (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [sysdb_apply_default_override] (0x4000): Override [homeDirectory] with [/home/user.name] for [name=user.name(a)ad.example.com,cn=users,cn=ad.example.com,cn=sysdb]. (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [sysdb_apply_default_override] (0x4000): Override [loginShell] with [/bin/bash] for [name=user.name(a)ad.example.com,cn=users,cn=ad.example.com,cn=sysdb]. (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x55f30a6819a0 (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x55f30a681a60 (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Running timer event 0x55f30a6819a0 "ltdb_callback" (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Destroying timer event 0x55f30a681a60 "ltdb_timeout" (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Ending timer event 0x55f30a6819a0 "ltdb_callback" (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [safe_original_attributes] (0x4000): Original object does not have [sshPublicKey] set. (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x55f30a683c50 (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x55f30a683d10 (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Running timer event 0x55f30a683c50 "ltdb_callback" (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Destroying timer event 0x55f30a683d10 "ltdb_timeout" (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Ending timer event 0x55f30a683c50 "ltdb_callback" (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [sysdb_ldb_msg_difference] (0x2000): Replaced/extended attr [uidNumber] of entry [name=user.name(a)ad.example.com,cn=users,cn=ad.example.com,cn=sysdb] (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [ldb] (0x4000): start ldb transaction (nesting: 0) (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x55f30a68d1c0 (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x55f30a68d280 (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Running timer event 0x55f30a68d1c0 "ltdb_callback" (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Destroying timer event 0x55f30a68d280 "ltdb_timeout" (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Ending timer event 0x55f30a68d1c0 "ltdb_callback" (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [ldb] (0x4000): commit ldb transaction (nesting: 0) (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [sysdb_set_entry_attr] (0x0200): Entry [name=user.name(a)ad.example.com,cn=users,cn=ad.example.com,cn=sysdb] has set [cache, ts_cache] attrs. (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x55f30a68d330 (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x55f30a688900 (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Running timer event 0x55f30a68d330 "ltdb_callback" (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x55f30a689320 (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x55f30a6893e0 (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Destroying timer event 0x55f30a688900 "ltdb_timeout" (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Ending timer event 0x55f30a68d330 "ltdb_callback" (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Running timer event 0x55f30a689320 "ltdb_callback" (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x55f30a634920 (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x55f30a6349e0 (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Destroying timer event 0x55f30a6893e0 "ltdb_timeout" (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Ending timer event 0x55f30a689320 "ltdb_callback" (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Running timer event 0x55f30a634920 "ltdb_callback" (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Destroying timer event 0x55f30a6349e0 "ltdb_timeout" (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Ending timer event 0x55f30a634920 "ltdb_callback" (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [ipa_initgr_get_overrides_step] (0x1000): Processing group 0/1 (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [ipa_initgr_get_overrides_step] (0x1000): Fetching group S-1-5-21-922099545-2851689246-2917073205-20676 (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [sdap_id_op_connect_step] (0x4000): reusing cached connection (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [ipa_get_ad_override_connect_done] (0x4000): Searching for overrides in view [Default Trust View] with filter [(&(objectClass=ipaOverrideAnchor)(ipaAnchorUUID=:SID:S-1-5-21-922099545-2851689246-2917073205-20676))]. (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [sdap_print_server] (0x2000): Searching 172.20.23.190:389 (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(objectClass=ipaOverrideAnchor)(ipaAnchorUUID=:SID:S-1-5-21-922099545-2851689246-2917073205-20676))][cn=Default Trust View,cn=views,cn=accounts,dc=ipa,dc=chotel,dc=com]. (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 33 (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [sdap_op_add] (0x2000): New operation 33 timeout 6 (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [sdap_process_result] (0x2000): Trace: sh[0x55f30a5d1940], connected[1], ops[0x55f30a63f270], ldap[0x55f30a5ce320] (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [sdap_process_result] (0x2000): Trace: end of ldap_result list (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [sdap_process_result] (0x2000): Trace: sh[0x55f30a5d1940], connected[1], ops[0x55f30a63f270], ldap[0x55f30a5ce320] (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT] (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no errmsg set (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [sdap_op_destructor] (0x2000): Operation 33 finished (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [ipa_get_ad_override_done] (0x4000): No override found with filter [(&(objectClass=ipaOverrideAnchor)(ipaAnchorUUID=:SID:S-1-5-21-922099545-2851689246-2917073205-20676))]. (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [sdap_id_op_destroy] (0x4000): releasing operation connection (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [ipa_initgr_get_overrides_step] (0x1000): Processing group 1/1 (Fri Aug 24 16:30:12 2018) [sssd[be[ipa.example.com]]] [ipa_get_ad_memberships_send] (0x0400): External group information still valid. ## /etc/sssd/sssd.conf [domain/ipa.example.com] cache_credentials = True krb5_store_password_if_offline = True # krb5_realm = IPA.EXAMPLE.COM ipa_domain = ipa.example.com ipa_hostname = entl01.ipa.example.com # Server Specific Settings ipa_server = entl01.ipa.example.com ipa_server_mode = True subdomain_homedir = %o fallback_homedir = /home/%u default_shell = /bin/bash id_provider = ipa auth_provider = ipa access_provider = ipa chpass_provider = ipa ldap_tls_cacert = /etc/ipa/ca.crt [sssd] services = nss, sudo, pam, ssh domains = ipa.example.com [nss] filter_users = root,ldap,named,avahi,haldaemon,dbus,radiusd,news,nscd,tomcat,activemq,informix,oracle,xdba,grid,dbadmin,weblogic,operator,postgres,devolog memcache_timeout = 600 homedir_substring = /home [pam] [sudo] [autofs] [ssh] [pac] [ifp]

2 1

file provider with multiple kerberos realms
by Techie 18 Dec '20

18 Dec '20

Main goal is to authenticate against multiple Kerberos Realms, AD domains without joining the Linux box to AD. We have an AD forest with 2 trusted domains and as a result 2 kerberos realms, 1 per domain. On RHEL5,6,7 I used pam_krb5 for authentication and passwd/group files for the user store. This allowed me to authenticate against AD for users in the passwd file that match the KBR5 principal. In system-auth/password-auth I would stack pam entries for each KRB5 REALM Parent: EXAMPLE.COM Domain1: ADA.EXAMPLE.COM Domain2:ADB.EXAMPLE.COM passwd user: joe_doe krb5 principal: joe_doe(a)ADA.EXAMPLE.COM passwd user: joe_blow krb5 principal: joe_blow(a)ADB.EXAMPLE.COM system-auth auth sufficient pam_krb5.so realm=ADA.EXAMPLE.COM use_first_pass auth sufficient pam_krb5.so realm=ADB.EXAMPLE.COM use_first_pass In this case either joe_doe or joe_blow can log in via AD credentials and pam would iterate through the stacked pam_krb5 entries to locate the matching krb5 principal I am trying to replicate this on redhat enterprise linux 8. I am aware pam_krb5 is not an option and that sssd is the default for this use case. What I cannot figure out is how to authenticate against multiple Domains in SSSD. If I define 1 domain in sssd.conf with id_provider = files. I can authenticate fine against the single domain/kerberos5 realm. If I add multiple domains, sssd does not iterate through them, it fails if it does not find the user in the first domain. [sssd] config_file_version = 2 reconnection_retries = 3 sbus_timeout = 30 services = nss, pam domains = ADA.EXAMPLE.COM,ADB.EXAMPLE.COM [pam] #pam_local_domains = all [domain/ADA.EXAMPLE.COM] id_provider = files auth_provider=krb5 krb5_server = adadc.ada.example.com krb5_kpasswd = adadc.ada.example.com krb5_realm = ADA.EXAMPLE.COM dns_discovery_domain =ADA.EXAMPLE.COM krb5_validate = false [domain/ADB.EXAMPLE.COM id_provider = files auth_provider=krb5 krb5_server = adbdc.adb.example.com krb5_kpasswd = adbdc.adb.example.com krb5_realm =ADB.EXAMPLE.COM dns_discovery_domain = ADB.EXAMPLE.COM krb5_validate = false Is what I am attempting possible without joining AD and using the provider of AD? I would like to avoid this at all costs. Thanks

2 3

sssd-krb5, krb5_ccachedir, DIR-cache-store...
by Jostein Fossheim 15 Dec '20

15 Dec '20

We are working with several kerberos-REALMS and are trying to get our clients to store their kerberos tickets in a DIRECTORY. This seems to work nicely for clients not authenticating at login, with the following configuration set in /etc/krb5.conf. ... [libdefaults] ... default_ccache_name = DIR:/tmp/krb5cc_%{uid} ... user@server:~$ klist Ticket cache: DIR::/tmp/krb5cc_888/tkt Default principal: user@REALM Valid starting Expires Service principal 09/22/19 17:35:50 09/23/19 17:35:48 krbtgt/user@REALM Each ticket is stored in a separate file. For clients using sssd for login, I want to set up the same behavior. But when I attempt to login the system creates an "/tmp/krb5cc_${UiD}" - but here the directory don't get the excutable bit set (that is the directory get 0600-permission), and the login fails. In the man-page from Debian-buster (sssd-version: 1.16.3), there are to settings that seems to regulate this behaviour : krb5_ccachedir (string) Directory to store credential caches. All the substitution sequences of krb5_ccname_template can be used here, too, except %d and %P. The directory is created as private and owned by the user, with permissions set to 0700. Default: /tmp krb5_ccname_template (string) Location of the user's credential cache. Three credential cache types are currently supported: "FILE", "DIR" and "KEYRING:persistent". The cache can be specified either as TYPE:RESIDUAL, or as an absolute path, which implies the "FILE" type. In the template, the following sequences are substituted: [...] If the template ends with 'XXXXXX' mkstemp(3) is used to create a unique filename in a safe way. When using KEYRING types, the only supported mechanism is "KEYRING:persistent:%U", which uses the Linux kernel keyring to store credentials on a per-UID basis. This is also the recommended choice, as it is the most secure and predictable method. The default value for the credential cache name is sourced from the profile stored in the system wide krb5.conf configuration file in the [libdefaults] section. The option name is default_ccache_name. See krb5.conf(5)'s PARAMETER EXPANSION paragraph for additional information on the expansion format defined by krb5.conf. NOTE: Please be aware that libkrb5 ccache expansion template from krb5.conf(5) uses different expansion sequences than SSSD. Default: (from libkrb5) ... I have tried to both set and unset, the two parameters in question like this: krb5_ccachedir = /tmp/krb5cc_%U krb5_ccname_template = DIR: %d krb5_ccname_template = DIR:%d/krb5cc_%U_XXXXXX But the configuration-options seems to be ignored, no matter what I do, and I have the same behavior: A non-executable directory is created and the user is unable to login. If I set the +x bit on the directory manually as the root-user, everything works.

4 5

sssd with samba
by Edouard Guigné 20 Nov '20

20 Nov '20

Dear sssd users, I would like to get informations about the use of sssd with samba (centos 7, samba 4.8.3). I need it because I configured a samba share, accessible with sssd. The authentication is against a windows AD. My /etc/nsswitch.cnf is configured only with sssd : /passwd: files sss// //shadow: files sss// //group: files sss/ For an other purpose, I set an sftpd access also configured with sssd against the AD. I followed some discussions on the samba user list about samba + sssd. I would like to understand if there are some issues with sssd and samba 4.8.3 on centos 7 ? Or is it with next RHEL 8 ? /The RHEL 8 documentation states this: // //// //"Red Hat only supports running Samba as a server with the winbindd // //service to provide domain users and groups to the local system. Due to // //certain limitations, such as missing Windows access control list (ACL) // //support and NT LAN Manager (NTLM) fallback, SSSD is not supported." // //// //https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/deploying_different_types_of_servers/assembly_using-samba-as-a-server_deploying-different-types-of-servers//// //// //What's confusing is that the RHEL 7 documentation says: // //// //"Prior to Red Hat Enterprise Linux 7.1, only Winbind provided this // //functionality. In Red Hat Enterprise Linux 7.1 and later, you no longer // //need to run Winbind and SSSD in parallel to access SMB shares. For // //example, accessing the Access Control Lists (ACLs) no longer requires // //Winbind on SSSD clients." // //// //and // //// //"4.2.2. Determining Whether to Use SSSD or Winbind for SMB Shares // //For most SSSD clients, using SSSD is recommended:" // //// //and most worrisome, in my use case: // //// //"In environments with direct Active Directory integration where the // //clients use SSSD for general Active Directory user mappings, using // //Winbind for the SMB ID mapping instead of SSSD can result in // //inconsistent mapping." / In my case, running samba 4.8.3 with SSSD on centos 7 do I need to : - enable and start winbind service , in conjunction to sssd ? - or only sssd is enough with samba ? - Do I have to fear issues in next release of sssd for the support of samba ? especially for acls support ?/ / A nsswitch.conf like : passwd: files sss winbind shadow: files sss winbind group: files sss winbind or passwd: files winbind sss shadow: files winbind sss group: files winbind sss Does not seem to work... I test and this is not stable. Best Regards, Edouard

5 6

I'm being a toad. SSSD on Centos authenticating to LDAPS configured AD domain
by Tory M Blue 22 Oct '20

22 Oct '20

I've got SSSD working local via AD for unix account authentication, however we are joining a new mother ship and we are not on their LAN and thus don't have access to their AD network. They setup an LDAPS configuration and while I can query it via ldapsearch, I can't get sssd to find anything. getent nor id return anything, but I see the requests in the sssd_domain.log. I'm sure I'm tripping up trying to refactor my AD config to work in the new LDAPs environment. I understand my ldapsearch is doing a full blown query list and obviously if I give it a filter of my user for example, I get all my data (sssd doesn't need all that data but i need something). I've spent a week banging my head and searching and trying different examples and really failing :) So any assistance would be appreciated. I've tried the search, trial and error, read and figured I've exhausted my understanding and exhausted my attempts at copying others configurations and now I'm just running in circles. Thanks in advance. So basic data: CentOS 7 sssd 1.16.4 LDAPS endpoint on a windows AD domain. sssd.conf [domain/LDAP] # Return debug level to 0 once working debug_level = 9 default_domain_suffix = aads.com enumerate = false cache_credentials = false id_provider = ldap auth_provider = ldap #access_provider = ldap sudo_provider = ldap chpass_provider = ldap # timing config entry_cache_timeout = 10 # entry_cache_nowait_timeout = 10 # entry_cache_nowait_percentage = 10 #use_fully_qualified_names = true ldap_id_use_start_tls = true ldap_service_port = 636 ldap_tls_reqcert = allow ldap_force_upper_case_realm = true ldap_uri = ldaps://aadds.com ldap_search_base = dc=aadds,dc=com ldap_user_object_class = posixAccount ldap_default_bind_dn = aadds\sssd ldap_default_authtok_type = password ldap_default_authtok = somearbitrarycrap ldap_tls_cacertdir = /etc/openldap/cacerts # Unix to AD attribute mapping ldap_schema = rfc2307bis #ldap_schema = rfc2307 ldap_user_object_class = person ldap_group_object_class = group ldap_user_home_directory = unixHomeDirectory ldap_user_modify_timestamp = whenChanged ldap_user_principal = userPrincipalName ldap_user_name = sAMAccountName ldap_user_gecos = displayName ldap_user_uid_number = uidNumber ldap_user_gid_number = gidNumber ldap_user_shell = loginShell ldap_group_name = uniqueMember Some data has been secured. #> ldapsearch -v -x -D AADDS\\sssd -b "dc=aadds,dc=com" -H ldaps:// aadds.com -W "(cn=tory blue)" ldap_initialize( ldaps://aadds.com:636/??base ) Enter LDAP Password: filter: (cn=tory blue) requesting: All userApplication attributes # extended LDIF # # LDAPv3 # base <dc=aadds,dc=com> with scope subtree # filter: (cn=tory blue) # requesting: ALL # # Tory Blue, AA Users, aadds.com <bunch of data pertaining to my user deleted> #> id tory.blue(a)aads.com #> id tory.blue #> sssd debug: Wed Oct 21 23:37:42 2020) [sssd[be[LDAP]]] [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit (Wed Oct 21 23:37:42 2020) [sssd[be[LDAP]]] [dp_get_account_info_handler] (0x0200): Got request for [0x1][BE_REQ_USER][name=tory.blue(a)aadds.com] (Wed Oct 21 23:37:42 2020) [sssd[be[LDAP]]] [dp_attach_req] (0x0400): DP Request [Account #8]: New request. Flags [0x0001]. (Wed Oct 21 23:37:42 2020) [sssd[be[LDAP]]] [dp_attach_req] (0x0400): Number of active DP request: 1 (Wed Oct 21 23:37:42 2020) [sssd[be[LDAP]]] [sss_domain_get_state] (0x1000): Domain LDAP is Active (Wed Oct 21 23:37:42 2020) [sssd[be[LDAP]]] [sdap_id_op_connect_step] (0x4000): reusing cached connection (Wed Oct 21 23:37:42 2020) [sssd[be[LDAP]]] [sdap_search_user_next_base] (0x0400): Searching for users with base [dc=aadds,dc=com] (Wed Oct 21 23:37:42 2020) [sssd[be[LDAP]]] [sdap_print_server] (0x2000): Searching SECURED:636 (Wed Oct 21 23:37:42 2020) [sssd[be[LDAP]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(|(userPrincipalName= tory.blue@aadds.com)(mail=tory.blue@aadds.com ))(objectclass=person)(sAMAccountName=*)(&(uidNumber=*)(!(uidNumber=0))))][dc=aadds,dc=com]. (Wed Oct 21 23:37:42 2020) [sssd[be[LDAP]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectClass] (Wed Oct 21 23:37:42 2020) [sssd[be[LDAP]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sAMAccountName] (Wed Oct 21 23:37:42 2020) [sssd[be[LDAP]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [userPassword] (Wed Oct 21 23:37:42 2020) [sssd[be[LDAP]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [uidNumber] (Wed Oct 21 23:37:42 2020) [sssd[be[LDAP]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [gidNumber] (Wed Oct 21 23:37:42 2020) [sssd[be[LDAP]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [displayName] (Wed Oct 21 23:37:42 2020) [sssd[be[LDAP]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [unixHomeDirectory] (Wed Oct 21 23:37:42 2020) [sssd[be[LDAP]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [loginShell] (Wed Oct 21 23:37:42 2020) [sssd[be[LDAP]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [userPrincipalName] (Wed Oct 21 23:37:42 2020) [sssd[be[LDAP]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [cn] (Wed Oct 21 23:37:42 2020) [sssd[be[LDAP]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [memberOf] (Wed Oct 21 23:37:42 2020) [sssd[be[LDAP]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [whenChanged] (Wed Oct 21 23:37:42 2020) [sssd[be[LDAP]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [uSNChanged] (Wed Oct 21 23:37:42 2020) [sssd[be[LDAP]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowLastChange] (Wed Oct 21 23:37:42 2020) [sssd[be[LDAP]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowMin] (Wed Oct 21 23:37:42 2020) [sssd[be[LDAP]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowMax] (Wed Oct 21 23:37:42 2020) [sssd[be[LDAP]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowWarning] (Wed Oct 21 23:37:42 2020) [sssd[be[LDAP]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowInactive] (Wed Oct 21 23:37:42 2020) [sssd[be[LDAP]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowExpire] (Wed Oct 21 23:37:42 2020) [sssd[be[LDAP]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowFlag] (Wed Oct 21 23:37:42 2020) [sssd[be[LDAP]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [krbLastPwdChange] (Wed Oct 21 23:37:42 2020) [sssd[be[LDAP]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [krbPasswordExpiration] (Wed Oct 21 23:37:42 2020) [sssd[be[LDAP]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [pwdAttribute] (Wed Oct 21 23:37:42 2020) [sssd[be[LDAP]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [authorizedService] (Wed Oct 21 23:37:42 2020) [sssd[be[LDAP]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [accountExpires] (Wed Oct 21 23:37:42 2020) [sssd[be[LDAP]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [userAccountControl] (Wed Oct 21 23:37:42 2020) [sssd[be[LDAP]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [nsAccountLock] (Wed Oct 21 23:37:42 2020) [sssd[be[LDAP]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [host] (Wed Oct 21 23:37:42 2020) [sssd[be[LDAP]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [rhost] (Wed Oct 21 23:37:42 2020) [sssd[be[LDAP]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [loginDisabled] (Wed Oct 21 23:37:42 2020) [sssd[be[LDAP]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [loginExpirationTime] (Wed Oct 21 23:37:42 2020) [sssd[be[LDAP]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [loginAllowedTimeMap] (Wed Oct 21 23:37:42 2020) [sssd[be[LDAP]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sshPublicKey] (Wed Oct 21 23:37:42 2020) [sssd[be[LDAP]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [userCertificate;binary] (Wed Oct 21 23:37:42 2020) [sssd[be[LDAP]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [mail] (Wed Oct 21 23:37:42 2020) [sssd[be[LDAP]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 18 (Wed Oct 21 23:37:42 2020) [sssd[be[LDAP]]] [sdap_op_add] (0x2000): New operation 18 timeout 6 (Wed Oct 21 23:37:42 2020) [sssd[be[LDAP]]] [sdap_process_result] (0x2000): Trace: sh[0x562321c0f030], connected[1], ops[0x562321d75590], ldap[0x562321bf7400] (Wed Oct 21 23:37:42 2020) [sssd[be[LDAP]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_REFERENCE] (Wed Oct 21 23:37:42 2020) [sssd[be[LDAP]]] [sdap_get_generic_ext_add_references] (0x1000): Additional References: ldaps://ForestDnsZones.aadds.com/DC=ForestDnsZones,DC=aadds,DC=com (Wed Oct 21 23:37:42 2020) [sssd[be[LDAP]]] [sdap_process_result] (0x2000): Trace: sh[0x562321c0f030], connected[1], ops[0x562321d75590], ldap[0x562321bf7400] (Wed Oct 21 23:37:42 2020) [sssd[be[LDAP]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_REFERENCE] (Wed Oct 21 23:37:42 2020) [sssd[be[LDAP]]] [sdap_get_generic_ext_add_references] (0x1000): Additional References: ldaps://DomainDnsZones.aadds.com/DC=DomainDnsZones,DC=aadds,DC=com (Wed Oct 21 23:37:42 2020) [sssd[be[LDAP]]] [sdap_process_result] (0x2000): Trace: sh[0x562321c0f030], connected[1], ops[0x562321d75590], ldap[0x562321bf7400] (Wed Oct 21 23:37:42 2020) [sssd[be[LDAP]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_REFERENCE] (Wed Oct 21 23:37:42 2020) [sssd[be[LDAP]]] [sdap_get_generic_ext_add_references] (0x1000): Additional References: ldaps://aadds.com/CN=Configuration,DC=aadds,DC=com (Wed Oct 21 23:37:42 2020) [sssd[be[LDAP]]] [sdap_process_result] (0x2000): Trace: sh[0x562321c0f030], connected[1], ops[0x562321d75590], ldap[0x562321bf7400] (Wed Oct 21 23:37:42 2020) [sssd[be[LDAP]]] [sdap_process_result] (0x2000): Trace: end of ldap_result list (Wed Oct 21 23:37:42 2020) [sssd[be[LDAP]]] [sdap_process_result] (0x2000): Trace: sh[0x562321c0f030], connected[1], ops[0x562321d75590], ldap[0x562321bf7400] (Wed Oct 21 23:37:42 2020) [sssd[be[LDAP]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_REFERENCE] (Wed Oct 21 23:37:42 2020) [sssd[be[LDAP]]] [sdap_get_generic_ext_add_references] (0x1000): Additional References: ldaps://aadds.com/CN=Schema,CN=Configuration,DC=aadds,DC=com (Wed Oct 21 23:37:42 2020) [sssd[be[LDAP]]] [sdap_process_result] (0x2000): Trace: sh[0x562321c0f030], connected[1], ops[0x562321d75590], ldap[0x562321bf7400] (Wed Oct 21 23:37:42 2020) [sssd[be[LDAP]]] [sdap_process_result] (0x2000): Trace: end of ldap_result list (Wed Oct 21 23:37:42 2020) [sssd[be[LDAP]]] [sdap_process_result] (0x2000): Trace: sh[0x562321c0f030], connected[1], ops[0x562321d75590], ldap[0x562321bf7400] (Wed Oct 21 23:37:42 2020) [sssd[be[LDAP]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT] (Wed Oct 21 23:37:42 2020) [sssd[be[LDAP]]] [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no errmsg set (Wed Oct 21 23:37:42 2020) [sssd[be[LDAP]]] [sdap_op_destructor] (0x2000): Operation 18 finished (Wed Oct 21 23:37:42 2020) [sssd[be[LDAP]]] [generic_ext_search_handler] (0x4000): Request included referrals which were ignored. (Wed Oct 21 23:37:42 2020) [sssd[be[LDAP]]] [generic_ext_search_handler] (0x4000): Ref: ldaps:// ForestDnsZones.aadds.com/DC=ForestDnsZones,DC=aadds,DC=com (Wed Oct 21 23:37:42 2020) [sssd[be[LDAP]]] [generic_ext_search_handler] (0x4000): Ref: ldaps:// DomainDnsZones.aadds.com/DC=DomainDnsZones,DC=aadds,DC=com (Wed Oct 21 23:37:42 2020) [sssd[be[LDAP]]] [generic_ext_search_handler] (0x4000): Ref: ldaps://aadds.com/CN=Configuration,DC=aadds,DC=com (Wed Oct 21 23:37:42 2020) [sssd[be[LDAP]]] [generic_ext_search_handler] (0x4000): Ref: ldaps:// aadds.com/CN=Schema,CN=Configuration,DC=aadds,DC=com (Wed Oct 21 23:37:42 2020) [sssd[be[LDAP]]] [sdap_search_user_process] (0x0400): Search for users, returned 0 results. (Wed Oct 21 23:37:42 2020) [sssd[be[LDAP]]] [sdap_search_user_process] (0x2000): Retrieved total 0 users (Wed Oct 21 23:37:42 2020) [sssd[be[LDAP]]] [sdap_id_op_done] (0x4000): releasing operation connection (Wed Oct 21 23:37:42 2020) [sssd[be[LDAP]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x562321d71d00 (Wed Oct 21 23:37:42 2020) [sssd[be[LDAP]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x562321d71dd0 (Wed Oct 21 23:37:42 2020) [sssd[be[LDAP]]] [ldb] (0x4000): Running timer event 0x562321d71d00 "ltdb_callback" (Wed Oct 21 23:37:42 2020) [sssd[be[LDAP]]] [ldb] (0x4000): Destroying timer event 0x562321d71dd0 "ltdb_timeout" (Wed Oct 21 23:37:42 2020) [sssd[be[LDAP]]] [ldb] (0x4000): Destroying timer event 0x562321d71d00 "ltdb_callback" (Wed Oct 21 23:37:42 2020) [sssd[be[LDAP]]] [sysdb_search_by_name] (0x0400): No such entry (Wed Oct 21 23:37:42 2020) [sssd[be[LDAP]]] [sysdb_cache_search_groups] (0x2000): Search groups with filter: (&(objectCategory=group)(ghost= tory.blue(a)aadds.com)) (Wed Oct 21 23:37:42 2020) [sssd[be[LDAP]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x562321d711a0 (Wed Oct 21 23:37:42 2020) [sssd[be[LDAP]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x562321c1c0e0 (Wed Oct 21 23:37:42 2020) [sssd[be[LDAP]]] [ldb] (0x4000): Running timer event 0x562321d711a0 "ltdb_callback" (Wed Oct 21 23:37:42 2020) [sssd[be[LDAP]]] [ldb] (0x4000): Destroying timer event 0x562321c1c0e0 "ltdb_timeout" (Wed Oct 21 23:37:42 2020) [sssd[be[LDAP]]] [ldb] (0x4000): Destroying timer event 0x562321d711a0 "ltdb_callback" (Wed Oct 21 23:37:42 2020) [sssd[be[LDAP]]] [sysdb_cache_search_groups] (0x2000): No such entry (Wed Oct 21 23:37:42 2020) [sssd[be[LDAP]]] [sysdb_delete_user] (0x0400): Error: 2 (No such file or directory) (Wed Oct 21 23:37:42 2020) [sssd[be[LDAP]]] [dp_req_done] (0x0400): DP Request [Account #8]: Request handler finished [0]: Success (Wed Oct 21 23:37:42 2020) [sssd[be[LDAP]]] [_dp_req_recv] (0x0400): DP Request [Account #8]: Receiving request data. (Wed Oct 21 23:37:42 2020) [sssd[be[LDAP]]] [dp_req_reply_list_success] (0x0400): DP Request [Account #8]: Finished. Success. (Wed Oct 21 23:37:42 2020) [sssd[be[LDAP]]] [dp_req_reply_std] (0x1000): DP Request [Account #8]: Returning [Success]: 0,0,Success (Wed Oct 21 23:37:42 2020) [sssd[be[LDAP]]] [dp_table_value_destructor] (0x0400): Removing [0:1:0x0001:1:U:LDAP:name=tory.blue@aadds.com] from reply table (Wed Oct 21 23:37:42 2020) [sssd[be[LDAP]]] [dp_req_destructor] (0x0400): DP Request [Account #8]: Request removed. (Wed Oct 21 23:37:42 2020) [sssd[be[LDAP]]] [dp_req_destructor] (0x0400): Number of active DP request: 0 (Wed Oct 21 23:37:42 2020) [sssd[be[LDAP]]] [sdap_process_result] (0x2000): Trace: sh[0x562321c0f030], connected[1], ops[(nil)], ldap[0x562321bf7400] (Wed Oct 21 23:37:42 2020) [sssd[be[LDAP]]] [sdap_process_result] (0x2000): Trace: end of ldap_result list

2 2

keyring quota exhaustion from sssd-based SSH connections...
by Spike White 20 Oct '20

20 Oct '20

Sssd experts, We have a problem with two RHEL7 servers, where one particular account is logged into a great many times, fairly frequently. Can be as much as 2-3 concurrent sessions, but generally it’s just a bunch of sequential logins. All from that one account. We have just converted this user authentication to sssd (AD back-end) from a non-Kerberos-based user authentication. After an hour or so, the account can no longer log in. It reports an error from pam_sss.so. It says this in /var/log/secure: Oct 15 13:53:36 esrmfgstg01 sshd[19126]: pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.186.154.11 user=svc_npesrsnonprd Oct 15 13:53:36 esrmfgstg01 sshd[19126]: pam_sss(sshd:auth): received for user svc_npesrsnonprd: 4 (System error) Oct 15 13:53:36 esrmfgstg01 sshd[19126]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.186.154.11 user=svc_npesrsnonprd Oct 15 13:53:36 esrmfgstg01 sshd[19125]: pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.186.154.11 user=svc_npesrsnonprd Oct 15 13:53:36 esrmfgstg01 sshd[19125]: pam_sss(sshd:auth): received for user svc_npesrsnonprd: 4 (System error) In /var/log/sssd/sssd_pam.log file we see: (Thu Oct 15 13:53:36 2020) [sssd[pam]] [pam_dp_process_reply] (0x0200): received: [4 (System error)][amer.dell.com] In /var/log/sssd/sssd_amer.dell.com.log, we see: (Thu Oct 15 13:53:36 2020) [sssd[be[amer.dell.com]]] [read_pipe_handler] (0x0400): EOF received, client finished (Thu Oct 15 13:53:36 2020) [sssd[be[amer.dell.com]]] [krb5_auth_done] (0x0040): The krb5_child process returned an error. Please inspect the krb5_child.log file or the journal for more information And finally, in /var/log/sssd/krb5_child.log, we see: (Thu Oct 15 13:53:36 2020) [[sssd[krb5_child[19139]]]] [create_ccache] (0x4000): Initializing ccache of type [KEYRING] (Thu Oct 15 13:53:36 2020) [[sssd[krb5_child[19139]]]] [create_ccache] (0x4000): CC supports switch (Thu Oct 15 13:53:36 2020) [[sssd[krb5_child[19139]]]] [create_ccache] (0x4000): Match not found (Thu Oct 15 13:53:36 2020) [[sssd[krb5_child[19139]]]] [create_ccache] (0x4000): krb5_cc_cache_match failed (Thu Oct 15 13:53:36 2020) [[sssd[krb5_child[19139]]]] [create_ccache] (0x0020): 1016: [122][Disk quota exceeded] (Thu Oct 15 13:53:36 2020) [[sssd[krb5_child[19139]]]] [map_krb5_error] (0x0020): 1817: [122][Disk quota exceeded] (Thu Oct 15 13:53:36 2020) [[sssd[krb5_child[19139]]]] [k5c_send_data] (0x0200): Received error code 1432158209 (Thu Oct 15 13:53:36 2020) [[sssd[krb5_child[19139]]]] [pack_response_packet] (0x2000): response packet size: [4] (Thu Oct 15 13:53:36 2020) [[sssd[krb5_child[19139]]]] [k5c_send_data] (0x4000): Response sent. (Thu Oct 15 13:53:36 2020) [[sssd[krb5_child[19139]]]] [main] (0x0400): krb5_child completed successfully So we think the problem is that all the keyrings are consumed, or this user has exceeded its quota of keyrings. Faster than Kerberos garbage collects them. In googling, we see a similar problem but it’s specific to GNOME. https://bugzilla.redhat.com/show_bug.cgi?id=1230750 Our problem does not involve GNOME, just raw SSH connections. We bumped up */proc/sys/kernel/keys/maxkeys *(from default of 200 to 1000) and it seemed to help. Just wondering what is the correct fix? And if this is the correct fix, some guidance as to best value for maxkeys. BTW, even when we specify : default_ccache_name = FILE:/tmp/krb5cc_%{uid} in /etc/kr5.conf, sssd’s krb5_child.log seems to want to use KEYRING. What’s up with that? Spike

2 3

query sssd - original homedir after override_homedir
by schmidt.steffen＠gmx.de 17 Oct '20

17 Oct '20

Hey, Background: so I came across the problem that snaps don't allow home directories outside /home (c.f. https://bugs.launchpad.net/snappy/+bug/1620771 ). So I use override_homedir in sssd.conf to fix this (I have to say almost since I still can't start the snaps in $HOME (/home/$USER) but any other directory, even $HOME/Desktop). However, there is another layer of complication in my scenario: I don't have one file server but two that serve the home directories. Therefore, I use a autofs script to get the correct user mounts (auto.home.sh). fs1 /fs1/home/$USER ------+ |------ client sssd.conf: override_homedir = /home/%u fs2 /fs2/home/$USER ------+ auto.home.sh: script to choose correct mountpoint for $USER Problem: I would like to get the original home directory (e.g. /fs1/home/$USER) on the client. getent passwd only gets me /home/$USER (overriden by the parameter override_homedir in sssd.conf). So my hacky solution is right now to use ldbsearch: declare -r DOMAIN=example.com declare -r LDBDB= /var/lib/sss/db/cache_bc.frontend.ldb ldbsearch -H $LDBDB '($USER@$DOMAIN)' homeDirectory Another possibilty would be to use ldapsearch directly but I would like to first query the sss cache. Is there a better way to solve this problem? Thanks Steffen

3 3

Advantages of signed SASL bindings vs unsigned SASL bindings....
by Spike White 14 Oct '20

14 Oct '20

All, Still working with our AD team, trying to implement Microsoft's AD edict to only allow LDAP SASL bindings with a security strength factor of 2 or greater. https://bugzilla.redhat.com/show_bug.cgi?id=1793709 So I realize (now) that sssd's default GSSAPI SASL binding does not do signing. Whereas, the GSS-SPNEGO authentication mechanism does. Both authentication mechanisms claim a SSF of 256. So both are accepted by AD DCs enforcing MS' stricter policy. (We have verified this by hard-coding sssd clients to AD DCs thus configured). Even with the new hotfix that Microsoft released in July, the AD DCs still report event 2889 (insecure LDAP binding or unsigned LDAP binding) for GSSAPI SASL bindings. They do not report event 2889 for GSS-SPNEGO SASL bindings. I believe our older sssd clients (RHEL 6) cannot do gss-spnego auth mech. Only our newer RHEL7 and RHEL8 clients can do gss-spnego. So while we can satisfy MS' stricter requirement of SASL bindings with SSF >= 2, the AD admins will still see events 2889 in their DC logs. Certainly for our older clients. I don't fully understand this claim of SSF == 256 for GSSAPI. SSF == 0 is supposed to be no protection, SSF = 1 is supposed to be basic integrity checking only, >1 – Supports authentication, integrity and confidentiality. https://ldapwiki.com/wiki/Security%20Strength%20Factor I thought signing was what gave you integrity checking. To prevent man-in-the middle attacks. If so, how can GSSAPI claim SSF == 256, since it's not doing signing? Otherwise, if you can get integrity checking without signing and our GSSAPI bindings are strongly encrypted (they are), how could a man in the middle insert their own code into the packet? I..e, how important is signing really, if we're strongly encrypted? Just trying to gauge if it's worth the work effort to convert all our new'ish sssd client to gss-spnego, or leave them at (default) gssapi. Spike PS Best would be if MS had broken out insecure LDAP binding and unsigned SASL bindings into 2 different events. What the AD team *really* wants to eradicate is simple LDAP bindings (i.e., user name/password supplied in clear text). However, it's hard to distinguish between that and our (sssd-initiated) GSSAPI SASL bindings -- AD team is just looking for event 2889 in their logs.

4 7

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

sssd-users October 2020