November 2019 - sssd-users - Fedora mailing-lists

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

Is there an RFC or detailed design document describing SSSD's ID Mapping algorithm?
by Jeff Thornsen 23 Jan '20

23 Jan '20

The reason I ask is because I use a bunch of storage appliances that offer Secure-NFS (NETAPP, EMC UNITY, etc.), but they only support NIS, IDMU, RFC2307, and RFC2307bis style Identity Mapping, all of which require manual assignment of UID/GID numbers to objects in LDAP, which is untenable for large environments. Microsoft even removed Unix Attribute editor from their LDAP GUI for the RFC2307 attributes in Windows Server 2016 to push people away from using rfc2307. I would like to be able to provide a link to an RFC or design document describing the SSSD ID Mapping algorithm so that these 3rd party vendors can incorporate an identical identity mapping algorithm into their products, so that I can use their Secure-NFS product in conjunction with sssd and have the uid and gid numbers match up with the other Linux hosts in our environment.

5 6

Can SSSD sort the autofs map
by Oguzhan Eris 09 Dec '19

09 Dec '19

Hi everyone. First off, thanks to everyone who's ever worked on SSSD. It's easily in my top 5 favorite FOSS projects out there. I am not sure if this is the right way to ask for an enhancement, or whether I should file an issue on GitHub, but I am running into an issue that's described in this Red Hat page https://access.redhat.com/solutions/3673501 (login required) Basically for an automount map where I need nested top level paths: /mnt/foo /mnt/foo/bar each defined by their own map objects. SSSD does not handle this (neither does LDAP directly from autofs) because the return map from LDAP is unsorted, and if the maps are provided to autofs ordered as: /mnt/foo/bar /mnt/foo the /mnt/foo map masks the previous /mnt/foo/bar map and you'll only get the entries from /mnt/foo Using file based mount maps, one can easily sort the top level maps, and get around this issue. Would it be possible to have SSSD return the maps from LDAP query in a sorted way? There is an LDAP control that most LDAP servers support to return a sorted output, ( https://ldapwiki.com/wiki/Server%20Side%20Sort%20Control ) but with so many clients and a large list, this might be better left to the client to do instead. I'm happy to help out if someone can point me in the right direction in the code. Thanks again

5 11

How to have a dynamic ldap_default_bind_dn value in sssd.conf?
by Oscar Torrente 06 Dec '19

06 Dec '19

Hello. I'm using a LDAP server for authentication/identification of users. I've set its ACIs so that every user just can access to its own data But now I have a problem in sssd clients: I should put the correct ldap_default_bind_dn value to make the request, a value which should be dynamic as it's typed on gdm/login/ssh/whatever. How can I do that? I don't want to write the admin's cn (and password!) in client's sssd.conf files! Thanks!! P.S: I've asked the same topic in https://serverfault.com/questions/993030/how-to-have-a-dynamic-ldap-default… but sadly there's no answer....

3 4

Fedora 30 and 31 instant fail at gdm login greeter PIN prompt
by Zynda, Bradley V. (GSFC-423.0)[ADNET SYSTEMS INC] 05 Dec '19

05 Dec '19

Hello, pam.d/system-auth auth [success=done authinfo_unavail=ignore ignore=ignore default=die] pam_sss.so try_cert_auth pam.d/smartcard-auth auth [default=1 ignore=ignore success=ok] pam_succeed_if.so uid >= 1000 quiet auth sufficient pam_sss.so ignore_authinfo_unavail require_cert_auth auth required pam_deny.so account required pam_unix.so account sufficient pam_localuser.so account sufficient pam_succeed_if.so uid < 1000 quiet account [default=bad success=ok user_unknown=ignore] pam_sss.so account required pam_permit.so session optional pam_keyinit.so revoke session required pam_limits.so -session optional pam_systemd.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so session optional pam_sss.so etc/sssd/sssd.conf [sssd] services = nss, pam domains = files [nss] [pam] pam_cert_auth = True pam_cert_db_path = /etc/sssd/pki/<cert>.pem debug_level = 4 [domain/files] id_provider = files [certmap/files/<user>] matchrule = <EKU>msScLogin<SUBJECT>^.*,UID=<user>,.*$ gdm.d/greeter-login enable-smartcard-authentication=true enable-fingerprint-authentication=false enable-password-authentication=false Reboot and get Card PIN user prompt gdm-login-greeter -> add username and click next Get Prompted for PIN but after a second it just fails and goes back to asking for username. Has anyone run into this behaviour, suggestions, fix? Seems to be a reoccurring issue I have seen in +F28, +CentOS7 and +RHEL7 basically anything with obsolete coolkey pkcs11 authconfig. Thanks, Brad

2 12

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

Debian10 and self-signed cert
by Todor Petkov 28 Nov '19

28 Nov '19

Hello, I am trying to configure sssd authentication on Debian 10.2, sssd 1.16.3, against 389-ds with self-signed certificate. In /etc/sssd/sssd.conf I have the line "ldap_tls_reqcert = never" line, but when I start sssd manually on the command line, it says " [sss_ldap_init_sys_connect_done] (0x0020): ldap_install_tls failed: [Connect error] [Key usage violation in certificate has been detected.]" Can someone give me a hint how to teach sssd to ignore the certificate? Regards,

3 4

logins fail after socket activated responders implemented.
by Lawrence Kearney 21 Nov '19

21 Nov '19

SSSD team, A curious issue after walking through the implementation of the socket activated responders. System is a new RHEL 7.7 host with SSSD v1.16.4-21 using the AD providers. Essentially user resolution (NSS), user login (PAM) and sssctl (IFP) worked when specifying the responders in the SSSD.conf file. [root@darkvixen241 ~]# id msteele uid=1727401116(msteele) gid=1727401151(primary_unix_g) groups=1727401151(primary_unix_g),1727402106(darkvixen_hpc_admin_g),1727401607(darkvixen_hpc_g),1727402101(darkvixen100_g),1727401603(darkvixen101_g),1727401604(darkvixen102_g),1727401174(darkvixen240_g),1727401175(darkvixen241_g),1727401145(marketing_g),1727402105(bioinf_lab_g),1727400513(domain users) [root@darkvixen241 ~]# sssctl user-checks msteele user: msteele action: acct service: system-auth SSSD nss user lookup result: - user name: msteele - user id: 1727401116 - group id: 1727401151 - gecos: Ming Steele - home directory: /home/dvc.darkvixen.com/msteele - shell: /bin/bash SSSD InfoPipe user lookup result: - name: msteele - uidNumber: 1727401116 - gidNumber: 1727400513 - gecos: Ming Steele - homeDirectory: /home/msteele - loginShell: /bin/bash testing pam_acct_mgmt pam_acct_mgmt: Success PAM Environment: - no env - After implementing the desired socket activated responders I cannot login as users via SSH, but can su as them from a root session. User resolution and sssctl still work. [root@darkvixen241 ~]# systemctl list-units -a -t socket | grep sssd- sssd-autofs.socket loaded active listening SSSD AutoFS Service responder socket sssd-kcm.socket loaded active listening SSSD Kerberos Cache Manager responder socket sssd-nss.socket loaded active running SSSD NSS Service responder socket sssd-pac.socket loaded active listening SSSD PAC Service responder socket sssd-pam-priv.socket loaded active listening SSSD PAM Service responder private socket sssd-pam.socket loaded active listening SSSD PAM Service responder socket sssd-secrets.socket loaded active listening SSSD Secrets Service responder socket sssd-ssh.socket loaded active listening SSSD SSH Service responder socket sssd-sudo.socket loaded active listening SSSD Sudo Service responder socket [root@darkvixen241 ~]# id msteele uid=1727401116(msteele) gid=1727401151(primary_unix_g) groups=1727401151(primary_unix_g),1727402106(darkvixen_hpc_admin_g),1727401607(darkvixen_hpc_g),1727402101(darkvixen100_g),1727401603(darkvixen101_g),1727401604(darkvixen102_g),1727401174(darkvixen240_g),1727401175(darkvixen241_g),1727401145(marketing_g),1727402105(bioinf_lab_g),1727400513(domain users) [root@darkvixen241 ~]# sssctl user-checks msteele user: msteele action: acct service: system-auth SSSD nss user lookup result: - user name: msteele - user id: 1727401116 - group id: 1727401151 - gecos: Ming Steele - home directory: /home/dvc.darkvixen.com/msteele - shell: /bin/bash SSSD InfoPipe user lookup result: - name: msteele - uidNumber: 1727401116 - gidNumber: 1727400513 - gecos: Ming Steele - homeDirectory: /home/msteele - loginShell: /bin/bash testing pam_acct_mgmt pam_acct_mgmt: Authentication service cannot retrieve authentication info PAM Environment: - no env - My sssd.conf is provided below: [sssd] config_file_version = 2 # services = nss,pam,pac,ssh,autofs,sudo domains = dvc.darkvixen.com [nss] filter_users = root,bin,daemon,adm,lp,sync,shutdown,halt,mail,operator,games,ftp,nobody,systemd-network,dbus,polkitd,sshd,postfix,chrony,sssd,apache,rpc,rpcuser,nfsnobody filter_groups = root,bin,daemon,sys,adm,tty,disk,lp,mem,kmem,wheel,cdrom,mail,man,dialout,floppy,games,tape,video,ftp,lock,audio,nobody,users,utmp,utempter,input,systemd-journal,systemd-network,dbus,polkitd,ssh_keys,sshd,postdrop,postfix,chrony,printadmin,cgred,sssd,apache,rpc,rpcuser,nfsnobody [pam] pam_account_expired_message = "Account expired, please contact help desk." pam_account_locked_message = "Account locked, please contact help desk." pam_verbosity = 3 [pac] [ssh] [autofs] [sudo] [ifp] [domain/dvc.darkvixen.com] id_provider = ad access_provider = ad cache_credentials = true override_homedir = /home/%d/%u override_shell = /bin/bash override_gid = 1727401151 ad_access_filter = DOM:DVC.DARKVIXEN.COM: (|(memberOf=CN=DARKVIXEN241_G,OU=LDAP,OU=SVS,DC=dvc,DC=darkvixen,DC=com)(memberOf=CN=DARKVIXEN_HPC_ADMIN_G,OU=CLUSTERS,OU=SVS,DC=dvc,DC=darkvixen,DC=com)) Nothing remarkable shows up in the logs after issuing "sssctl debug-level 7" and curiously there are no sssd_pam or sssd_pac log files created. Any assistance would be appreciated, -- lawrence -- Lawrence Kearney w: www.lawrencekearney.com l: www.linkedin.com/in/lawrencekearney

3 11

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 issues on upgrade to EL 8.1
by John Beranek 18 Nov '19

18 Nov '19

So, I've started testing upgrading EL 8.0 to 8.1, in my case with Oracle Linux 8. I spotted 2 issues during/after upgrade, both seem related to sssd. The first is that during the upgrade, sssd is updated and therefore restarted, but sssd fails to restart successfully. Nov 15 22:33:31 devzitsol8 systemd[1]: Stopping System Security Services Daemon... Nov 15 22:33:31 devzitsol8 sssd[nss][11571]: Shutting down Nov 15 22:33:31 devzitsol8 sssd[autofs][11574]: Shutting down Nov 15 22:33:31 devzitsol8 sssd[be[AD]][11570]: Shutting down Nov 15 22:33:31 devzitsol8 sssd[sudo][11573]: Shutting down Nov 15 22:33:31 devzitsol8 sssd[pam][11572]: Shutting down Nov 15 22:33:31 devzitsol8 sssd[be[implicit_files]][11569]: Shutting down Nov 15 22:33:31 devzitsol8 systemd[1]: Stopped System Security Services Daemon. Nov 15 22:33:31 devzitsol8 systemd[1]: Starting System Security Services Daemon... Nov 15 22:33:31 devzitsol8 sssd[33205]: Starting up Nov 15 22:33:31 devzitsol8 sssd[be[AD]][33207]: Starting up Nov 15 22:33:31 devzitsol8 sssd[be[implicit_files]][33206]: Starting up Nov 15 22:33:31 devzitsol8 sssd[be[AD]][33208]: Starting up Nov 15 22:33:33 devzitsol8 sssd[be[AD]][33209]: Starting up Nov 15 22:33:36 devzitsol8 sssd[nss][33211]: Starting up Nov 15 22:33:36 devzitsol8 sssd[autofs][33214]: Starting up Nov 15 22:33:36 devzitsol8 sssd[sudo][33213]: Starting up Nov 15 22:33:36 devzitsol8 sssd[pam][33212]: Starting up Nov 15 22:33:36 devzitsol8 sssd[nss][33215]: Starting up Nov 15 22:33:36 devzitsol8 sssd[autofs][33216]: Starting up Nov 15 22:33:36 devzitsol8 sssd[sudo][33217]: Starting up Nov 15 22:33:36 devzitsol8 sssd[pam][33218]: Starting up Nov 15 22:33:37 devzitsol8 sssd[be[AD]][33219]: Starting up Nov 15 22:33:37 devzitsol8 sssd[33205]: Exiting the SSSD. Could not restart critical service [AD]. Nov 15 22:33:37 devzitsol8 sssd[be[implicit_files]][33206]: Shutting down Nov 15 22:33:37 devzitsol8 systemd[1]: sssd.service: Main process exited, code=exited, status=1/FAILURE Nov 15 22:33:37 devzitsol8 systemd[1]: sssd.service: Failed with result 'exit-code'. Nov 15 22:33:37 devzitsol8 systemd[1]: Failed to start System Security Services Daemon. This appears to be due to this: (Fri Nov 15 22:33:37 2019) [sssd[be[AD]]] [be_res_get_opts] (0x0100): Lookup order: ipv4_first (Fri Nov 15 22:33:37 2019) [sssd[be[AD]]] [recreate_ares_channel] (0x0100): Initializing new c-ares channel (Fri Nov 15 22:33:37 2019) [sssd[be[AD]]] [sss_names_init_from_args] (0x0100): Using re [(((?P<domain>[^\\]+)\\(?P<name>.+$))|((?P<name>[^@]+)@(?P<domain>.+$))|(^(?P<name>[^@\\]+)$))]. (Fri Nov 15 22:33:37 2019) [sssd[be[AD]]] [sss_fqnames_init] (0x0100): Using fq format [%1$s@%2$s]. (Fri Nov 15 22:33:37 2019) [sssd[be[AD]]] [sbus_signal_handler] (0x0020): We do not listen to this signal! (Fri Nov 15 22:33:37 2019) [sssd[be[AD]]] [sbus_signal_handler] (0x0020): We do not listen to this signal! (Fri Nov 15 22:33:37 2019) [sssd[be[AD]]] [dp_load_configuration] (0x0100): Using [ad] provider for [id] (Fri Nov 15 22:33:37 2019) [sssd[be[AD]]] [dp_load_configuration] (0x0100): Using [ad] provider for [auth] (Fri Nov 15 22:33:37 2019) [sssd[be[AD]]] [dp_load_configuration] (0x0100): Using [ad] provider for [access] (Fri Nov 15 22:33:37 2019) [sssd[be[AD]]] [dp_load_configuration] (0x0100): Using [ad] provider for [chpass] (Fri Nov 15 22:33:37 2019) [sssd[be[AD]]] [dp_load_configuration] (0x0100): Using [ad] provider for [sudo] (Fri Nov 15 22:33:37 2019) [sssd[be[AD]]] [dp_load_configuration] (0x0100): Using [ad] provider for [autofs] (Fri Nov 15 22:33:37 2019) [sssd[be[AD]]] [dp_load_configuration] (0x0100): Using [ad] provider for [selinux] (Fri Nov 15 22:33:37 2019) [sssd[be[AD]]] [dp_load_configuration] (0x0100): Using [ad] provider for [hostid] (Fri Nov 15 22:33:37 2019) [sssd[be[AD]]] [dp_load_configuration] (0x0100): Using [ad] provider for [subdomains] (Fri Nov 15 22:33:37 2019) [sssd[be[AD]]] [dp_load_configuration] (0x0100): Using [ad] provider for [session] (Fri Nov 15 22:33:37 2019) [sssd[be[AD]]] [dp_module_open_lib] (0x0010): Unable to load module [ad] with path [/usr/lib64/sssd/libsss_ad.so]: libwbclient.so.0: cannot open shared object file: No such file or directory (Fri Nov 15 22:33:37 2019) [sssd[be[AD]]] [dp_load_module] (0x0020): Unable to create DP module. (Fri Nov 15 22:33:37 2019) [sssd[be[AD]]] [dp_target_init] (0x0010): Unable to load module ad (Fri Nov 15 22:33:37 2019) [sssd[be[AD]]] [dp_load_targets] (0x0020): Unable to load target [id] [80]: Accessing a corrupted shared library. (Fri Nov 15 22:33:37 2019) [sssd[be[AD]]] [dp_init_done] (0x0020): Unable to initialize DP targets [1432158209]: Internal Error After the 8.1 update completed though, I could happily start sssd. The second issue is more subtle, and comes due to our use of the autofs provider, using Active Directory for the map location. On bootup autofs takes a long time to start, which means that autofs-provided mounts are unavailable when the system first boots. This looks a lot like this Fedora bug: https://bugzilla.redhat.com/show_bug.cgi?id=1648521 Nov 16 10:27:46 devzitsol8 oddjob-mkhomedir[1513]: error creating /nethome: Permission denied Nov 16 10:29:04 devzitsol8 automount[1124]: lookup_read_master: lookup(sss): getautomntent_r: Invalid argument Nov 16 10:29:04 devzitsol8 automount[1124]: lookup(file): failed to read included master map auto.master Nov 16 10:29:04 devzitsol8 automount[1124]: lookup(file): failed to read included master map auto.master Nov 16 10:29:04 devzitsol8 automount[1124]: mounted indirect on /misc with timeout 300, freq 75 seconds Nov 16 10:29:04 devzitsol8 automount[1124]: mounted indirect on /net with timeout 300, freq 75 seconds Nov 16 10:29:04 devzitsol8 automount[1124]: mounted indirect on /nethome with timeout 300, freq 75 seconds Nov 16 10:29:04 devzitsol8 systemd[1]: Started Automounts filesystems on demand. Nov 16 10:29:04 devzitsol8 systemd[1]: Reached target Multi-User System. Nov 16 10:29:04 devzitsol8 systemd[1]: Starting Update UTMP about System Runlevel Changes... Nov 16 10:29:04 devzitsol8 systemd[1]: Started Update UTMP about System Runlevel Changes. Nov 16 10:29:04 devzitsol8 systemd[1]: Startup finished in 1.207s (kernel) + 5.624s (initrd) + 1min 37.318s (userspace) = 1min 44.150s. Nov 16 10:30:18 devzitsol8 systemd[1503]: Starting Mark boot as successful... Happy to provide more logs if it helps diagnose these issues. Cheers, John -- John Beranek To generalise is to be an idiot. http://redux.org.uk/ -- William Blake

1 0

how to say name of daemon? "S-S-S-D" or "TRIPLE-S-D"?
by Spike White 15 Nov '19

15 Nov '19

All, S-S-S-D does not seem to roll off the tongue. When I say that, co-workers think I'm discussing solid-state drives (SSD). When I call it triple-S-D, someone invariably corrects me. Which is correct? Are both pronunciations correct? Spike

7 6

managing authorization without AD/LDAP
by JOULAUD François 13 Nov '19

13 Nov '19

Hello, I have a use case of ssh authentication to some server which for various reasons (one of them being network isolation) cannot access to Directory. With ssh I can use ssh certificates to do the authentication part "offline" without the need for the server to access any centralized service. But I still need LDAP connexion to get directory information (numeric uid, groups, etc.) I would like a mechanic which allows to transmit this information along with the connexion initiation. For example the ssh certificate could have some extension options like uid(a)example.com=1234 and groups(a)example.com=wheel,admin,mygroup and this certificate would create the corresponding entries in SSSD in passwd and groups databases which would be valid for the duration of the certificate. Do anyone knows of such a setup or have any pointer to similar ideas ? Do you think it would be possible for SSSD to be extended to support this use case ? Would it be easy to implement ? (a bunch of AuthorizedKeyCommand shell scripts interacting with SSSD D-Bus interface would suit me) François

1 0

GID numbers showing up rather than group names using groups command.
by Abhisheyk Deb 12 Nov '19

12 Nov '19

Hi, This issue might have been already fixed. And my configuration might not be right. So we have a Active directory domain which has two domain controllers, and a linux system which is joined to that domain. For some users, when we use the groups <username> command, we are getting all the proper information, but for some users, groups command gives error like "cannot find name for group ID XXXXXXXX" The /etc/sssd/sssd.conf file is as follows: [sssd] domains = ad.example.com config_file_version = 2 services = nss, pam [pam] offline_credentials_expiration = 1 [domain/ad.example.com] ad_domain = ad.example.com krb5_realm = ad.example.com 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 access_provider = ad override_homedir = /user/%u account_cache_expiration = 1 entry_cache_timeout = 180 Can somebody help me with this issue? Thank you Abhishek Deb

1 0

Any way to get sssd to ignore gidNumber (Posix attribute) when auto_private_group set to true?
by Spike White 06 Nov '19

06 Nov '19

All, We're replacing a commercial product that ignores whatever GID is used in gidNumber posix attribute, when auto_private_groups is set to true. However, we find in sssd that even when we set auto_private_groups = True, that in additional to all the supplemental groups defined by memberOf, it also appends as the supplemental group the group whose GID is in gidNumber. Is that any way to disable this? To have sssd list only "memberOf" groups as supplemental groups when auto_private_groups == True? Spike White

2 2

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

sssd PKINIT smartcard auth on RHEL7?
by James Ralston 04 Nov '19

04 Nov '19

I am struggling to get smartcard authentication working on RHEL7, using sssd-1.16.4-21.el7 and krb5 PKINIT against Microsoft Active Directory KDCs. Has anyone actually gotten this working? If so, what behavior differences do you see from various login mechanisms (gdm, login, et. al.)? Because I see *no* visual differences in any login mechanism. gdm, login, et. al. prompt for a username/password, exactly as before. Both after I enter the username, and after I enter the PIN (at the "password" prompt), there is a delay while sssd pokes at the card. I can also tell this from watching the light on the card reader blink. But then the login fails. I mean, these documents: https://docs.pagure.org/SSSD.sssd/design_pages/smartcard_authentication_pki… https://docs.pagure.org/SSSD.sssd/design_pages/smartcard_multiple_certifica… …make it sound like the gdm login screen should prompt me to insert a smartcard, or least differentiate *somehow* that smartcard authentication is in play. Both features claim to be implemented in sssd-1.16.4-21.el7. But I see nothing that indicates these features are working. If it's really the case that we have to train our users to type their username into the "username" prompt and enter their smartcard PIN into the "password" prompt, we can do that, but that doesn't seem to be how it's supposed to work based on the above documents. And that's going to seem completely horrible to users in contrast to how Windows works, where you walk up, insert your smartcard, and the login screen identifies you and then prompts for your PIN. I mean, I get it that /usr/bin/login running on a virtual console can't engage in a nifty interactive dialog like Windows does. But is really the case that gdm is that dumb with smartcards as well? Or am I misunderstanding how gdm+sssd+smartcard+PKINIT is supposed to work? I can supply (somewhat redacted) configuration files if need be, but I have everything set correctly that I know to set: * krb5.conf is configured correctly; I can kinit using the smartcard+PIN. * We use pam_sss.so in all of (password-auth, system-auth, smartcard-auth), so no matter how a program enters the PAM stack, it should get pam_sss.so and PKINIT. * I touched /var/lib/sss/pubconf/pam_preauth_available into existence and restarted sssd. * I set enable-smartcard-authentication to true in dconf (for org.gnome.login-screen). * I set "pam_cert_auth = true" in the [domain/example.org] section of /etc/sssd/sssd.conf. * I extracted the correct certificate from my smartcard (the one that krb5.conf is configured to find) and added it to my userCertificate attribute in Active Directory. * I even populated /etc/pki/nssdb with all of the same certificates that update-ca-trust maintains, even though I'm not sure that's necessary, as I think krb5 pkinit.so should handle that. * I increased various sssd timeouts to work around this bug in sssd that was derailing the nss responder: #4103 slow smartcard interactions break sssd when PKINIT is configured https://pagure.io/SSSD/sssd/issue/4103 I'm open to suggestions for anything that I missed.

4 13

Re: sssd - ssh and ticket renewal
by Sumit Bose 04 Nov '19

04 Nov '19

On Mon, Nov 04, 2019 at 04:01:20PM +0000, Jay McCanta wrote: > I've been working with SSSD for a good while and I could have sworn I knew how to get this working, but.... > > Login on workstations via GDM and my Kerberos tickets get renewed automatically. As I type this, I realize that I do lock/unlock my screen at least once a day. My tickets never seem to expire on my workstation. > From my workstation, I ssh to a server with sssd enabled authentication (Ubuntu bionic on both ends). I use a different account on the remote server and am asked for a password. Ssh is configured to use PAM and has it's own password authentication disabled. (PasswordAuthentication no; UsePAM yes; ChallengeResponseAuthentication yes). Home folders are kerberized NFS and upon initial login, all is well. However the ticket for this session never renews on its own. sudo will refresh the ticket. It's about the only other thing we have sssd enable for besides ssh. Without any sudo activity, the Kerberos ticket expires and we lose access to home folders. Current workaround is a user cron job that tries to refresh the key every hour. I have to sudo on this server several times a day so my tickets were being renewed. CO-workers don't have sudo access and they are the ones losing their tickets. > > Is my assumption that one should be able to ssh to a server and have that server refresh tickets (like on a workstation) a valid one? If so, where should I concentrate my efforts to get this working? Hi, please have a look at the krb5_renew_interval option explained in the sssd-krb5 man page. HTH bye, Sumit > > Thanks to all in this group. > > [cid:image001.jpg@01D592E5.F6CEED20]<https://f5.com/> > Jay McCanta | Principal Systems Administrator > D +1 (206) 272-7998 M +1-206-434-1080 > > > _______________________________________________ > sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org > To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.…

2 1

sssd - ssh and ticket renewal
by Jay McCanta 04 Nov '19

04 Nov '19

I've been working with SSSD for a good while and I could have sworn I knew how to get this working, but.... Login on workstations via GDM and my Kerberos tickets get renewed automatically. As I type this, I realize that I do lock/unlock my screen at least once a day. My tickets never seem to expire on my workstation. From my workstation, I ssh to a server with sssd enabled authentication (Ubuntu bionic on both ends). I use a different account on the remote server and am asked for a password. Ssh is configured to use PAM and has it's own password authentication disabled. (PasswordAuthentication no; UsePAM yes; ChallengeResponseAuthentication yes). Home folders are kerberized NFS and upon initial login, all is well. However the ticket for this session never renews on its own. sudo will refresh the ticket. It's about the only other thing we have sssd enable for besides ssh. Without any sudo activity, the Kerberos ticket expires and we lose access to home folders. Current workaround is a user cron job that tries to refresh the key every hour. I have to sudo on this server several times a day so my tickets were being renewed. CO-workers don't have sudo access and they are the ones losing their tickets. Is my assumption that one should be able to ssh to a server and have that server refresh tickets (like on a workstation) a valid one? If so, where should I concentrate my efforts to get this working? Thanks to all in this group. [cid:image001.jpg@01D592E5.F6CEED20]<https://f5.com/> Jay McCanta | Principal Systems Administrator D +1 (206) 272-7998 M +1-206-434-1080

1 0

smartcard mapping via msUPN SAN (OID 1.3.6.1.4.1.311.20.2.3)?
by James Ralston 01 Nov '19

01 Nov '19

I was reviewing the documentation for the "certificate mapping and matching rules for all providers" feature that landed in sssd 2.0: https://docs.pagure.org/SSSD.sssd/design_pages/certmaps_for_LDAP_AD_file.ht… However, I'm not sure how to use this feature to map certificates to AD users based on the msUPN SAN. For smartcards used with Microsoft Active Directory, the certificate with the "Microsoft Smartcardlogin" X509v3 Extended Key Usage object (EKU) will typically have additional X509v3 Subject Alternative Name objects: $ pkcs15-tool --read-certificate 01 | openssl x509 -noout -text | grep -A 1 'X509v3 Subject Alternative Name' Using reader with a card: SCM Microsystems Inc. SCR 3310 [CCID Interface] 00 00 X509v3 Subject Alternative Name: othername:<unsupported>, othername:<unsupported> The OpenSSL x509 tool doesn't parse the othername attributes, but we can use asn1parse to do so: $ pkcs15-tool --read-certificate 01 | openssl asn1parse Using reader with a card: SCM Microsystems Inc. SCR 3310 [CCID Interface] 00 00 0:d=0 hl=4 l=1296 cons: SEQUENCE 4:d=1 hl=4 l=1016 cons: SEQUENCE 8:d=2 hl=2 l= 3 cons: cont [ 0 ] … 874:d=5 hl=2 l= 3 prim: OBJECT :X509v3 Subject Alternative Name 879:d=5 hl=2 l= 81 prim: OCTET STRING [HEX DUMP]:DEADBEEFDEADBEEF… 962:d=4 hl=2 l= 27 cons: SEQUENCE Decoding the hex blob at offset 879 yields: $ pkcs15-tool --read-certificate 01 | openssl asn1parse -strparse 879 Using reader with a card: SCM Microsystems Inc. SCR 3310 [CCID Interface] 00 00 0:d=0 hl=2 l= 79 cons: SEQUENCE 2:d=1 hl=2 l= 36 cons: cont [ 0 ] 4:d=2 hl=2 l= 10 prim: OBJECT :Microsoft Universal Principal Name 16:d=2 hl=2 l= 22 cons: cont [ 0 ] 18:d=3 hl=2 l= 20 prim: UTF8STRING :123456789@example.org "Microsoft Universal Principal Name" is OID 1.3.6.1.4.1.311.20.2.3: $ grep -A 3 msUPN /usr/include/openssl/obj_mac.h #define SN_ms_upn "msUPN" #define LN_ms_upn "Microsoft Universal Principal Name" #define NID_ms_upn 649 #define OBJ_ms_upn 1L,3L,6L,1L,4L,1L,311L,20L,2L,3L From <http://oid-info.com/get/1.3.6.1.4.1.311.20.2.3>: { iso(1) identified-organization(3) dod(6) internet(1) private(4) enterprise(1) 311 20 2 3 } The value of this object will be set as the userPrincipalName attribute on the AD user object of the person to whom the smartcard was issued. And this is why Microsoft Windows smartcard login doesn't need the AD user object to have the user's certificate preloaded into the userCertificate attribute. Interestingly enough, for pkinit.so's pkinit_cert_match option, the <SAN> component-rule is also matching against the msUPN object. You can see this if you build pkinit.so with debugging and execute "kinit" with "pkinit_cert_match = <SAN>.*@.*": $ kinit … pkinit_cert_matching: Processing rule '<SAN>.*@.*' parse_rule_component: found keyword '<SAN>' parse_rule_component: found value '.*@.*' parse_rule_component: returning 0 parse_rule_set: After parse_rule_component, remaining 0, rule '' parse_rule_set: returning 0 crypto_retrieve_X509_sans: looking for SANs in cert = … crypto_retrieve_X509_sans: found 2 subject alt name extension(s) crypto_retrieve_X509_sans: unrecognized othername oid in SAN crypto_retrieve_X509_key_usage: returning eku 0x60000000 crypto_retrieve_X509_key_usage: returning ku 0x80000000 … check_all_certs: matching rule relation is NONE with 1 components check_all_certs: subject: … regexp_match: checking SAN rule '.*@.*' with value 123456789(a)example.org regexp_match: the result is a match component_match: returning match = 1 <SAN> component-rule Looking at the source, crypto_retrieve_X509_sans() is targeting SAN values of GEN_OTHERNAME and GEN_DNS; all other SAN objects are skipped. And for GEN_OTHERNAME, it is targeting only specific OIDs (thus the "unrecognized othername oid in SAN" line). But one of the OIDs targeted is msUPN. So… how can I configure sssd to perform the same matching on the msUPN SAN that Windows and pkinit.so perform? From looking at sss-certmap(5), my first attempt would be something like this: [certmap/example.org/msupn] matchrule = &&<SAN:1.3.6.1.4.1.311.20.2.3>.* maprule = (userPrincipalName={subject_pkinit_principal}) First, I suspect I don't need to use <SAN:dotted-decimal-oid> form, but I don't know which <SAN:foo> match is the one I actually want, because the man page doesn't clarify which <SAN:foo> matches correspond to specific OIDs. Is it <SAN:pkinit>? The same problem for the maprule: I'm not sure if {subject_pkinit_principal} is the correct maprule to use. "The SAN used by pkinit" sounds correct, though. Thanks in advance for any tips…

2 5

Ability to auth sudo against a different back end using sssd.
by Erinn Looney-Triggs 01 Nov '19

01 Nov '19

Folks I am in the process of working through this but I thought I would throw it out just in case there were other thoughts or I was chasing down the wrong lane. We have a requirement for sudo to use a different password than the user password where I work. Now in RHEL 7 we implemented this requirement by modifying the pam stack for sudo to use the pam_krb5 module like the following: auth required pam_env.so auth requisite pam_succeed_if.so uid >= 500 quiet auth sufficient pam_krb5.so try_first_pass no_user_check auth required pam_deny.so account sufficient pam_localuser.so account sufficient pam_succeed_if.so uid < 500 quiet account [default=bad success=ok user_unknown=ignore] pam_krb5.so account required pam_permit.so password requisite pam_cracklib.so try_first_pass retry=3 type= password sufficient pam_krb5.so try_first_pass use_authtok password required pam_deny.so session optional pam_keyinit.so revoke session required pam_limits.so Now pam_krb5 is configured to auth against a username/sudo principal in /etc/krb5.conf like the following (the mappings is the important part): [appdefaults] pam = { debug = false forwardable = true renew_lifetime = 24h ticket_lifetime = 24h krb4_convert = false mappings = ^(.*)$ $1/sudo } pam_krb5 has for better or worse gone the way of the dodo in RHEL 8 and so I am looking to implement something similar using sssd. Our systems are already joined to an AD, and it appears to me for the moment that the 'application domain' using pam_sss might be the right approach here. I understand that it is best tested with LDAP, but well, here we go. So thus far I have: [application/appdom] inherit_from = ad.example.com and the /etc/pam.d/sudo has the following inserted: auth sufficient pam_sss.so forward_pass domains=appdom Great it seems to work. Now I need to remap the name to username/sudo and auth it against kerb. I don't even know if this is possible at this point, but again I thought I would write it up and ask just in case someone knew. Thanks, -Erinn

3 7

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

sssd-users November 2019