sssd-users September 2019

sssd-users@lists.fedorahosted.org

18 participants
21 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

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

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

Enumerate users from external group from AD trust
by Bolke de Bruin 29 Nov '19

29 Nov '19

Hello, I have sssd 1.13.00 working against FreeIPA 4.2 domain. This domain has a trust relationship with a active directory domain. One of the systems we are using requires to enumerate all users in groups by (unfortunate) design (Apache Ranger). This is done by using “getent group”. During this enumeration the full user list for a group that has a nested external member group* is not always returned so we thought to add “getent group mygroup” in order to get more details. Unfortunately this does not seem to work consistently: sometimes this gives information sometimes it does not: [root@master centos]# getent group ad_users ad_users:*:1950000004: [root@master centos]# id bolke(a)ad.local UID=1796201107(bolke(a)ad.local) GID=1796201107(bolke(a)ad.local) groepen=1796201107(bolke(a)ad.local),1796200513(domain users@ad.local),1796201108(test@ad.local) [root@master centos]# getent group ad_users ad_users:*:1950000004:bolke@ad.local <mailto:bolke@ad.local> If I clear the cache (sss_cache -E) the entry is gone again: [root@master centos]# getent group ad_users ad_users:*:1950000004: My question is how do I get sssd to enumerate *all users* in a group consistently? Thanks! Bolke * https://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/trust-gro…

3 15

Group disappears from users / no group name gets resolved
by Jamal Mahmoud 19 Nov '19

19 Nov '19

We've been experiencing an intermittent issue relating to SSSD v1.15.2, we are running CentOS7.4 on our workstations. We use SSSD to communicate with our Active Directory to pull users for auth. The majority of users have a certain group set as their primary group and some departments have it as an additional group. Most of the time this group works fine on all workstations but sometimes we will run into an issue where a user can no longer access the privileges attained from the group. For users who have it set as primary, the id command returns a gid without the name and for users who have it as an additional group, it doesn't appear at all. I've managed to capture output from sssd services and there are a few interesting lines that I thought I should share with you as I don't understand what they mean. I should add that when this error occurs, restarting the sssd.service usually works, if not, sss_cache -E works, and if that doesn't work, removing the workstation from the realm, de leting the sssd db and rejoining seems to be the final trick that works. Regarding the logs, the symptoms I noted are below: 1. getent group *mygroup* returns nothing 2. id user returns a gid without a resolved group name (if it is a primary group) 3. I had to leave the realm, delete the db and rejoin to get sssd to work properly again. in sssd_nss.log i found this entry: (Wed Aug 21 16:22:45 2019) [sssd[nss]] [nss_get_grent] (0x0040): Incomplete group object for group(a)domain.com[0]! Skipping and in the sssd_domain.com.log: (Wed Aug 21 16:22:43 2019) [sssd[be[domain.com]]] [sdap_nested_group_split_members] (0x4000): [CN=USER,OU=IT Privileged accounts,DC=domain,DC=com] is unknown object (Wed Aug 21 16:22:43 2019) [sssd[be[domain.com]]] [sdap_nested_group_process_send] (0x0400): More members were missing than the deref threshold (Wed Aug 21 16:22:43 2019) [sssd[be[domain.com]]] [sdap_nested_group_process_send] (0x2000): Looking up 11/224 members of group [CN=GROUP,OU=Security,OU=Groups,OU=Place St,OU=Offices,DC=domain,DC=com] (Wed Aug 21 16:22:43 2019) [sssd[be[domain.com]]] [sdap_nested_group_process_send] (0x2000): Dereferencing members of group [CN=GROUP,OU=Security,OU=Groups,OU=Place St,OU=Offices,DC=domain,DC=com] (Wed Aug 21 16:22:43 2019) [sssd[be[domain.com]]] [sdap_deref_search_send] (0x2000): Server supports ASQ (Wed Aug 21 16:22:43 2019) [sssd[be[domain.com]]] [sdap_asq_search_send] (0x0400): Dereferencing entry [CN=GROUP,OU=Security,OU=Groups,OU=Place St,OU=Offices,DC=domain,DC=com] using ASQ (Wed Aug 21 16:22:43 2019) [sssd[be[domain.com]]] [sdap_print_server] (0x2000): Searching XXX.XXX.XXX.XXX:389 (Wed Aug 21 16:22:43 2019) [sssd[be[domain.com]]] [sdap_get_generic_ext_send] (0x0400): WARNING: Disabling paging because scope is set to base. (Wed Aug 21 16:22:43 2019) [sssd[be[domain.com]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [no filter][CN=GROUP,OU=Security,OU=Groups,OU=Place St,OU=Offices,DC=domain,DC=com]. I've redacted the entries but I'm sure you can get the jist of whats happening here hopefully. If there is anything else you need, please do not hesitate to ask! If these logs don't point to anything could you maybe provide some advice on what to look for when parsing? Thanks, Jamal

5 19

SSSD strangeness
by simonc99＠hotmail.com 05 Nov '19

05 Nov '19

Hi All We've got SSSD 1.13.0 installed as part of a Centos 7.2.1511 installation. We've used realmd to join the host concerned to our 2008R2 AD system. This went really well, and consequently we've been using SSSD to provide login services and kerberos integration for our fairly large hadoop system. The authconfig that's implicitly run as part of realmd produces the following sssd.conf: [sssd] domains = <joined domain> config_file_version = 2 services = nss, pam [pam] debug_level = 0x0080 [nss] timeout = 20 force_timeout = 600 debug_level = 0x0080 [domain/<joined domain>] ad_domain = <joined domain> krb5_realm = <JOINED DOMAIN> realmd_tags = manages-system joined-with-samba cache_credentials = true id_provider = ad krb5_store_password_if_offline = True default_shell = /bin/bash ldap_id_mapping = True use_fully_qualified_names = False fallback_homedir = /home/%u@%d access_provider = simple simple_allow_groups = <AD group allowing logins> krb5_use_kdc_info = False entry_cache_timeout = 300 debug_level = 0x0080 ad_server = <active directory server> As I've said - this works really well. We did have some stability issues initially, but they've been fixed by defining the 'ad_server' rather than using autodiscovery. Logins work fine, kerberos TGTs are issued on login, and password changes are honoured correctly. However, in general day to day use, we have noticed a few anomalies, that we just can't track down. Firstly (this has happened a few times), a user will change their AD password (via a Windows PC). Subsequent logins - sometimes with specific client software - fail with pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=<remote PC name> user=<username> pam_sss(sshd:auth): received for user <username>: 17 (failure setting user credentials) So in this example, the person concerned has changed their AD password. Further attempts to access this system via SSH work fine. However, using SFTP doesn't work (the above is output into /var/log/secure). There are no local controls on sftp logins, and the user concerned was working fine (using both sftp and ssh) until they updated their password. There is no separate sftp daemon running, and it only affects one individual currently (but we have seen some very similar instances before) The second issue we have is around phantom groups in AD. Hadoop uses an id -Gn command to see group membership for authorisation. With some users - we've seen 6 currently - we see certain groups failing to be looked up: id -Gn <username> id: cannot find name for group ID xxxxyyyyy <group name> <group name> <group name> <group name> <etc...> The xxxxyyyyy indicates: xxxx = hashed realm name yyyyy = RID from group in AD We can't find any group with that number on the AD side! We can work around this by adding a local group (into /etc/group) for the GIDs affected. This means the id -Gn runs correctly, and the hadoop namenode can function correctly - but this is a workaround and we'd like to get to the bottom of the issue. Rather than flooding this post now with logfiles, just thought I'd see if this looked familiar to anyone. Happy to upload any logs, amend logging levels, etc. Many thanks Simon

4 7

AD user is granted access when it should be denied
by Emil Petersson 11 Oct '19

11 Oct '19

Hi, I am running sssd-1.16.4-21.el7.x86_64 (from CR repo) on a CentOS 7 client. I authenticate to AD 2016, and control access to servers using GPO. For some reason, a completely unprivileged user in AD is allowed to login, and I'd like to understand why. Here's a sanitized sssd.conf: [sssd] domains = prd.domain.com config_file_version = 2 services = nss, pam, sudo full_name_format = %1$s default_domain_suffix = prd.domain.com [domain/prd.domain.com] debug_level = 9 ad_domain = prd.domain.com ad_site = XX1 ad_server = dc000.prd.domain.com, dc001.prd.domain.com krb5_realm = PRD.DOMAIN.COM realmd_tags = manages-system joined-with-samba cache_credentials = false id_provider = ad krb5_store_password_if_offline = True default_shell = /bin/bash ldap_id_mapping = true use_fully_qualified_names = True fallback_homedir = /home/%u access_provider = ad ldap_sudo_search_base = DC=domain,DC=com entry_cache_sudo_timeout = 10 enumerate = true dyndns_update = false ad_gpo_access_control = enforcing ldap_idmap_default_domain_sid = S-1-5-21-6607581186-1994368826-2594857426 ldap_idmap_default_domain = prd.domain.com ad_gpo_implicit_deny = true auto_private_groups = true ad_gpo_ignore_unreadable = true When I try to SSH to the client using my unprivileged user, I am getting the following output from the SSSD debug: [sysdb_gpo_get_gpo_result_setting] (0x0400): key [SeDenyRemoteInteractiveLogonRight] value [*S-1-5-32-546] [ad_gpo_access_check] (0x0400): RESULTANT POLICY: [ad_gpo_access_check] (0x0400): gpo_map_type: Remote Interactive [ad_gpo_access_check] (0x0400): allowed_size = 0 [ad_gpo_access_check] (0x0400): denied_size = 1 [ad_gpo_access_check] (0x0400): denied_sids[0] = S-1-5-32-546 ... snip ... [ad_gpo_access_check] (0x0400): CURRENT USER: [ad_gpo_access_check] (0x0400): user_sid = S-1-5-21-6607581186-1994368826-2594857426-2570 [ad_gpo_access_check] (0x0400): group_sids[0] = S-1-5-21-6607581186-1994368826-2594857426-513 [ad_gpo_access_check] (0x0400): group_sids[1] = S-1-5-11 [ad_gpo_access_check] (0x0400): POLICY DECISION: [ad_gpo_access_check] (0x0400): access_granted = 1 [ad_gpo_access_check] (0x0400): access_denied = 0 [ad_gpo_access_done] (0x0400): GPO-based access control successful. I'm trying to understand why this user is being granted access. I find it especially confusing as there is clearly one deny sid and no allow sids detected. The wanted behaviour is that the user should be denied access as long as I've not explicitly allowed it in AD. Thanks!

2 7

Question concerning SSH key attributes
by Lawrence Kearney 30 Sep '19

30 Sep '19

A question concerning the following SSSD directives: ldap_user_ssh_public_key = ldap_host_ssh_public_key = Both default to "sshPublicKey" values, but other than the obvious stated use cases (in the directive names and man file entries) I feel I'm missing something concerning the " ldap_host_ssh_public_key" directive. For example, using the default configuration, the SSSD pulls down the public key(s) stored for a user stored in the " sshPublicKey" attribute using the "/usr/bin/sss_ssh_authorizedkeys" utility. to facilitate access to a predetermined set of hosts. What is the use case for the " ldap_host_ssh_public_key" directive? Is it somehow used to store the public Key for a particular host (and why?) and does it have any relationship to the "/usr/bin/sss_ssh_knownhostsproxy" utility used to centralise (and distribute?) host keys? Any info would be most useful and as always, thank you! -- lawrence -- Lawrence Kearney

3 3

Allow me to introduce my situation….
by Spike White 27 Sep '19

27 Sep '19

All, In recent postings, there’s been some (quite correct!) inferences about my situation. Let me dispel any confusion, so you’re aware of my perspective. I work for a Fortune 500 company in their IT department. Our company and team has done Linux and UNIX AD integration using 2 ½ commercial products for over 12 years now. (that third product was used only in a very limited scope). Our team has oversight for about 30,000 Linux servers – 17K of them that are AD-integrated and 13K in the process of getting there. So, my team and our server support organization has a wealth of experience with the Linux client configurations of AD integration. We know our company incident procedures and that escalation process. Thus, I can say with confidence (for instance) that Linux sysadmins are engaged in the infrequent occurrence that AD integration is bulloxed on a particular Linux server. So, while we have a wealth of experience in AD/LDAP Linux and app integration, we are frankly newbies to sssd. I fully admit to my inexperience in sssd configuration and setup. However, I have been using it and evaluating it for almost a year. I have it working on RHEL7, RHEL8 and (just last week) RHEL6. I have gone through all anticipated test cases and – except for one totally obscure edge case -- sssd appears like it can do everything the commercial AD integration products can do. I say that – although I have two open sssd cases with our OS vendor. 1. One has been discussed already on this forum – “realm permit” segfaulting (but only on RHEL8). Our OS vendor has provided a work-around for this. 2. I believe the second bug is not a “bug” at all – but it’s due to my lack of understanding of AD and my inexperience with sssd. I’m currently working that with our OS vendor as well. Incidentally, if it appears that I’m singularly focused on AD – that’s because I am. That’s all my company uses for its back-end authentication mechanism. I’m also singularly focused on RHEL and RHEL-derived Linux servers, for similar reasons. Thus, when I suggest an RFE, I’m speaking from my perspective only and my company’s Linux perspective. I fully realize that other companies have different escalation policies, different authentication back-ends and different situations. I fully realize that any RFE I suggest would be half-baked (at best) – if accepted, it would surely be re-written to be more generic and useful for a larger target audience. Spike

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

sssd-users September 2019