July 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 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

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_be core dumping when ‘realm permit’ command run under puppet control…
by Spike White 25 Sep '19

25 Sep '19

All, This is a strange one. When we exec this command under puppet control: /usr/sbin/realm permit -R AMER.COMPANY.COM processehcprofiler(a)AMER.COMPANY.COM Then sssd_be core dumps (segfault). When we run that ‘realm permit’ command natively on the command line, it executes flawlessly. No core dump. Naturally, our first thought was that it’s something different in the environment. So we dumped the environment under which puppet exec resource runs. Yes, quite minimal. LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:mi=01;05;37;41:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arc=01;31:*.arj=01;31:*.taz=01;31:*.lha=01;31:*.lz4=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.tzo=01;31:*.t7z=01;31:*.zip=01;31:*.z=01;31:*.dz=01;31:*.gz=01;31:*.lrz=01;31:*.lz=01;31:*.lzo=01;31:*.xz=01;31:*.zst=01;31:*.tzst=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01;31:*.rar=01;31:*.alz=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.cab=01;31:*.wim=01;31:*.swm=01;31:*.dwm=01;31:*.esd=01;31:*.jpg=01;35:*.jpeg=01;35:*.mjpg=01;35:*.mjpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.webm=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=01;36:*.au=01;36:*.flac=01;36:*.m4a=01;36:*.mid=01;36:*.midi=01;36:*.mka=01;36:*.mp3=01;36:*.mpc=01;36:*.ogg=01;36:*.ra=01;36:*.wav=01;36:*.oga=01;36:*.opus=01;36:*.spx=01;36:*.xspf=01;36: LD_LIBRARY_PATH= LANG=en_US.UTF-8 HISTCONTROL=ignoredups HOSTNAME=austgcore25.us.company.com S_COLORS=auto PWD=/root APT_LISTCHANGES_FRONTEND=none DEBIAN_FRONTEND=noninteractive APT_LISTBUGS_FRONTEND=none MAIL=/var/spool/mail/root SHELL=/bin/bash TERM=xterm SHLVL=2 MANPATH=:/opt/puppetlabs/puppet/share/man PATH=/bin:/usr/bin:/sbin:/usr/sbin HISTSIZE=1000 LESSOPEN=||/usr/bin/lesspipe.sh %s _=/bin/env But when we create a bash session with no environment, then add this puppet-supplied environment and run the above realm permit– all is still well. We can reproduce this easily in puppet. Just delete our breadcrumb file (so that puppet re-executes this ‘realm permit’ command). And execute another puppet agent run. Doing this, we obtained a core dump from sssd_be. And it points to some code in ad_id.c: [root@austgcore25 tmp]# gdb -c core-sssd_be.15405.austgcore25.us.company.com.1563210863 GNU gdb (GDB) Red Hat Enterprise Linux 8.2-5.el8 Copyright (C) 2018 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html > This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word". [New LWP 15405] Reading symbols from /usr/libexec/sssd/sssd_be...Reading symbols from /usr/lib/debug/usr/libexec/sssd/sssd_be-2.0.0-43.el8.x86_64.debug...done. done. warning: Ignoring non-absolute filename: <linux-vdso.so.1> Missing separate debuginfo for linux-vdso.so.1 Try: dnf --enablerepo='*debug*' install /usr/lib/debug/.build-id/06/44254f9cbaa826db070a796046026adba58266 warning: .dynamic section for "/usr/lib64/libndr-nbt.so.0.0.1" is not at the expected address (wrong library or version mismatch?) [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Core was generated by `/usr/libexec/sssd/sssd_be --domain AMER.COMPANY.COM --uid 0 --gid 0 --logger=files'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x00007f79444f53c0 in ad_get_account_domain_search (req=req@entry=0x5557b6fd45b0) at src/providers/ad/ad_id.c:1276 1276 state->filter = sdap_combine_filters(state, state->base_filter, (gdb) This is in RHEL8. What we suspect is that the shell in which puppet executes this ‘realm permit’ is not supplying something that this executable needs. If we know what it is, we can preface our puppet exec resource code snippet with the missing piece. Spike PS This ‘realm permit’ does seem to perform the correct actions eventually. It adds the expected user to the simple_allow_users line of the appropriate AD domain in /etc/sssd/sssd.conf file. But because it segfaults and then has to start up again, it takes a very long time to complete the puppet run. (There’s about 20 – 30 users + groups allowed; it has to segfault on each of them).

4 9

[AD] Filter out disabled users
by Hinrikus Wolf 19 Sep '19

19 Sep '19

Hi, we are currently running a Samba AD DC Server with sssd on clients. Now we want to run sssd also on our mail server with postfix + dovecot. Postfix and dovecot get their users from NSS i.e. from sssd. In our Domain there are several disabled users (via User Account Control Bit). Any of these users are listed in NSS. Unfortunately, they can receive emails, because they are existing in the user database of NSS. But they cannot login to read mails or even answer. We would like to filter out disables users from NSS s.t. postfix will not accept emails for disabled users. We searched in man 5 sssd-ad but did not find a config option for this use case. Do you have any idea what we could do to achieve the desired behaviour? Thanks a lot. Best regards Rikus

5 13

[AD] User discovery/enumeration issue due to domain settings
by Christian Lamparter 06 Aug '19

06 Aug '19

Hello Folks, I'm currently setting up sssd (Debian 1.16.3) on Debian Buster 10.0 and I ran into a problem that I was able to trace down to the domain permission/security settings that placed the users into a special OU that machine accounts can't read. First a bit of background: Currently, there's a way to use winbind + friends in order to join and auth users on the domain. But due to limitations (unreliable no home directories, gid/uid mapping issues, etc.), I want to give sssd a try and I tested this with both of the current Debian sssd version 1.16.3 and 2.2.0-4 (from unstable / sid / rolling release). I successfully used the "realm" utility to discover and setup the sssd.conf === # realm discover -v DOMAIN (named changed) * Resolving: _ldap._tcp.domain * Performing LDAP DSE lookup on: 1x.y.z.1 * Performing LDAP DSE lookup on: 1z.a.b.c * Performing LDAP DSE lookup on: 1d.e.f.g * Successfully discovered: domain domain type: kerberos realm-name: DOMAIN domain-name: domain configured: no server-software: active-directory client-software: sssd required-package: sssd-tools required-package: sssd required-package: libnss-sss required-package: libpam-sss required-package: adcli required-package: samba-common-bin # realm join -v -U me@DOMAIN domain * Resolving: _ldap._tcp.domain * Performing LDAP DSE lookup on: 1x.y.z.1 * Performing LDAP DSE lookup on: 1z.a.b.c * Performing LDAP DSE lookup on: 1d.e.f.g * Successfully discovered: domain Password for me@DOMAIN: ******* * Unconditionally checking packages * Resolving required packages [...] * Generated 120 character computer password * Using keytab: FILE:/etc/krb5.keytab * Found computer account for COMPUTER * Set computer password * Retrieved kvno '14' for computer account in directory: ... * Modifying computer account: userAccountControl * Modifying computer account: operatingSystemVersion, operatingSystemServicePack * Modifying computer account: userPrincipalName * Cleared old entries from keytab: FILE:/etc/krb5.keytab * Discovered which keytab salt to use * Added the entries to the keytab: ... * /usr/sbin/update-rc.d sssd enable * /usr/sbin/service sssd restart * Successfully enrolled machine in realm === /etc/sssd/sssd.conf [sssd] domains = domain config_file_version = 2 services = nss, pam, ifp # added ifp [domain/domain] ad_domain = domain krb5_realm = DOMAIN realmd_tags = manages-system joined-with-adcli cache_credentials = True 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@%d access_provider = ad === klist shows a valid ticket and everything seemed to be working. But when I was trying to login (yes, I made sure that my time is synced and I made sure /etc/nssswitch.conf was correct) with my "me@domain" login it never worked. I tried also id me@domain and sssctl (had to add ifp, seems like realm doesn't add) but it wasn't working for my login. After trying a lot of different combinations with different id, auth_providers and ldap I discovered that the AD Server is setup in such a way (probably due to DSVGO) that the Domain-PC Accounts are not allowed to read from the OU where all the staff users are placed. And indeed, when I copied the exact search query from the sssd_domain log with debug-level 7 and instructed ldapsearch to use GSSAPI with the Domain-PC ticket I always got a "not found". However, when I used simple bind with "me@domain" + password auth I got the request worked. So, I wonder if it is possible to extend sssd in such a way that id lookups could be performed with the provided either a provided user secret instead of the machine secret? Regards, Christian

2 4

Re: Could not convert objectSID ... to a UNIX ID
by Gordon Messmer 01 Aug '19

01 Aug '19

On Tuesday, July 30, 2019 22:35 PDT, Sumit Bose <sbose(a)redhat.com> wrote: > > the version of SSSD you are using should automatically pick a new range > if the RID is too large. Can you send your sssd.conf for a start to > better understand your setup and see what might preventing SSSD from > picking a new range? The configuration file is generated by "realm join". Are there any specific patterns you'd like to see from the logs that might provide more information? [sssd] domains = business.com config_file_version = 2 services = nss, pam [domain/business.com] debug = 6 ad_domain = business.com krb5_realm = BUSINESS.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 = False fallback_homedir = /home/business/%u access_provider = ad

2 1

Could not convert objectSID ... to a UNIX ID
by Gordon Messmer 31 Jul '19

31 Jul '19

I have what I think is an odd situation. One of the users I support is complaining that he is unable to log in to his domain-member Linux system. After enabling debug logging, I've found the error "Could not convert objectSID ... to a UNIX ID" in the logs. The RID is greater than 200000, so I believe I need to adjust the allowed range and delete the sssd cache, and then fix all of the files on the filesystem which are owned by domain users. The first odd part is that the user is actually able to log in to this system for a while, and is able to log in to other hosts that are also running sssd-1.16.2-13.el7_6.8.x86_64 on CentOS 7.6. If I can figure out why that is, I hope that leads us to a solution that isn't as intrusive as the one described above. Does anyone have a guess why this might only affect one host right now, and only after a few days of use? I'm not sure why our RIDs would be unusually large, unless it is because we have users that create short-lived VMs, join them to the domain, and then destroy them very frequently. What is the recommended practice for domains with large and rapidly incrementing RIDs? What are the implications of increasing the ID map range? At one point in troubleshooting, we saw this in the log. Does increasing the range come at a memory cost? (Fri Jul 26 14:31:52 2019) [sssd[be[business.com]]] [dp_module_run_constructor] (0x0010): Module [ad] constructor failed [12]: Cannot allocate memory (Tue Jul 30 06:12:32 2019) [sssd[be[business.com]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(sAMAccountName=newish_user)(objectclass=user)(objectSID=*))][DC=business,DC=com]. (Tue Jul 30 06:12:32 2019) [sssd[be[business.com]]] [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no errmsg set (Tue Jul 30 06:12:32 2019) [sssd[be[business.com]]] [sdap_save_user] (0x0400): Save user (Tue Jul 30 06:12:32 2019) [sssd[be[business.com]]] [sdap_get_primary_name] (0x0400): Processing object newish_user (Tue Jul 30 06:12:32 2019) [sssd[be[business.com]]] [sdap_save_user] (0x0400): Processing user newish_user(a)business.com (Tue Jul 30 06:12:32 2019) [sssd[be[business.com]]] [sdap_idmap_sid_to_unix] (0x0080): Could not convert objectSID [S-1-5-21-xxxx-xxxx-xxxx-257746] to a UNIX ID (Tue Jul 30 06:12:32 2019) [sssd[be[business.com]]] [sdap_save_user] (0x0020): Failed to save user [newish_user(a)business.com]

2 1

How to automate realm join command?
by Zdravko Zdravkov 30 Jul '19

30 Jul '19

Hi all. I'm looking for the best way to automate the realm join command. Ideally I'd achieve that in kickstart or at first login. I've been considering some kind of shell script, but it seems that it will work only when password is in plain text, which I want to to avoid if possible. Thanks for any suggestions

4 3

System Error when su to user
by Sherman Lilly 30 Jul '19

30 Jul '19

I am getting an System Error message when I try to su to an user. I am using Ubuntu 18.04 and version 1.16.1-1ubuntu1.3 Jul 29 11:55:17 su[8658]: pam_sss(su:auth): authentication success; logname= uid=1000 euid=0 tty=/dev/pts/0 ruser=**** rhost= user=***** Jul 29 11:55:17 su[8658]: pam_sss(su:account): Access denied for user *****: 4 (System error) Jul 29 11:55:17 su[8658]: pam_acct_mgmt: System error Jul 29 11:55:17 su[8658]: FAILED su for ***** by *****

2 3

Max hostname len in adcli or realm join to AD?
by Spike White 22 Jul '19

22 Jul '19

All, In previous AD integration tools, the max host name length was customarily 15 chars. Because of ancient NETBIOS restrictions (16 char restrictions and netbios adds a '$' to the end of host name). That was like an AD 2003 restriction. With some slightly (well-documented) trickiness, in newer AD deployments those AD integration tools would allow up to an 18 char host name. I see in modern AD now, up to a 20 character name is tolerated (although recommendation is to retain the final '$'). So -- 19 char max. https://social.technet.microsoft.com/Forums/en-US/f2afb2ce-74fb-4434-932b-6… (However, that statement that 'common name' (max length 15) has to be unique in the OU is troubling. If you put all your Linux servers in the same OU, you're back to your 15 char limitation.) Apparently, in 2013 realm join and adcli allowed a15 char host name max. https://bugzilla.redhat.com/show_bug.cgi?id=1001667 Is that still true today, max 15 char host name in realm join / adcli? Spike

2 1

Replicate digest mapping from pam_pkcs11
by James Trater 15 Jul '19

15 Jul '19

Hello. Is it possible to replicate the digest mapping feature of pam_pkcs11 in sssd? We have built our infrastructure around the notion of mapping users to certificates based on the certificate digest. With the removal of pam_pkcs11 from recent distros (including RHEL 8) we are faced with either changing our mapping scheme (potentially a lot of work) or making this work in sssd. This is a snippet of what we do today: --- snip pam_pkcs11.conf --- # digest - elaborate certificate digest and map it into a file mapper digest { debug = false; module = internal; # module = /usr/$LIB/pam_pkcs11/digest_mapper.so; # algorithm used to evaluate certificate digest # Select one of: # "null","md2","md4","md5","sha","sha1","dss","dss1","ripemd160" algorithm = "sha1"; mapfile = file:///etc/pam_pkcs11/digest_mapping; # mapfile = "none"; } --- snip --- # snippet of digest_mapping file (the values have been obfuscated) [root@friday-vm]# grep jim digest_mapping 11:BC:53:F1:EF:24:B4:9C:47:ED:7D:EC:2B:82:CB:93:61:F8:88:4F -> jim

2 3

How to alleviate certain annoying messages in /var/log/messages?
by Spike White 09 Jul '19

09 Jul '19

sssd experts, We have a “nuisance-level” problem with RHEL8 physical builds after AD-integrating via sssd. How do I stop certain annoying messages in /var/log/messages? This RHEL8 physical build properly creates an /etc/krb5.keytab file with the expected host entries. Here’s the snippet from kutil: [root@austgcore25 log]# cd /etc [root@austgcore25 etc]# ktutil ktutil: read_kt /etc/krb5.keytab ktutil: list -t -e -k slot KVNO Timestamp Principal ---- ---- ----------------- --------------------------------------------------- … 6 16 07/03/2019 21:31 host/AUSTGCORE25(a)AMER.EXAMPLE.COM (des-cbc-crc) (0xbf3d37462967e65e) 7 16 07/03/2019 21:31 host/AUSTGCORE25(a)AMER.EXAMPLE.COM (des-cbc-md5) (0xbf3d37462967e65e) 8 16 07/03/2019 21:31 host/AUSTGCORE25(a)AMER.EXAMPLE.COM (arcfour-hmac) (0xa21feefac524db9e82f3e38e73551c28) 9 16 07/03/2019 21:31 host/AUSTGCORE25(a)AMER.EXAMPLE.COM (aes128-cts-hmac-sha1-96) (0x196ff6a33ef6284bb432f97cf36e737c) 10 16 07/03/2019 21:31 host/AUSTGCORE25(a)AMER.EXAMPLE.COM (aes256-cts-hmac-sha1-96) (0xadd866228352701a94f5cd40d76ed886a7fe084b2f7a90981b16d19f14962e3b) … The AD integration seems to work fine. I can log in with my AD account no problem. Even after reboots. (cross domain authentication temporarily not working on this build, likely unrelated.) However, we continue to get the complaints in /var/log/messages: Jul 8 11:38:25 austgcore25 [sssd[ldap_child[1816]]][1816]: Failed to initialize credentials using keytab [MEMORY:/etc/krb5.keytab]: Client 'host/ AUSTGCORE25(a)AMER.EXAMPLE.COM' not found in Kerberos database. Unable to create GSSAPI-encrypted LDAP connection. Jul 8 11:38:26 austgcore25 [sssd[ldap_child[1817]]][1817]: Failed to initialize credentials using keytab [MEMORY:/etc/krb5.keytab]: Client 'host/ AUSTGCORE25(a)AMER.EXAMPLE.COM' not found in Kerberos database. Unable to create GSSAPI-encrypted LDAP connection. I notice it’s attempting to use MEMORY:/etc/krb5.keytab. How do I stop this annoying messages in /var/log/messages? We have multiple AD domains defined in our sssd.conf file for this cross-domain auth. (Usually, cross-domain auth works fine for us.) Spike

1 1

sssd sudo using Microsoft Active Directory
by Bruno Monteiro 02 Jul '19

02 Jul '19

Hello, Below my configuration and errors :) (I've adapted some strings for the sake of example - domain is not real) cat /etc/sssd/sssd.conf [sssd] services = nss, pam,ssh, sudo debug_level = 0x7FFF domains = LDAP_MY.COM [sudo] debug_level = 0x3ff0 [domain/LDAP_MY.COM] debug_level = 0x3ff0 access_provider = ldap id_provider = ldap sudo_provider = ldap ldap_uri = ldap://<IP> ldap_default_bind_dn = <user>@my.com ldap_default_authtok = <password> ldap_sudo_search_base = OU=SUDOers,DC=my,DC=com /etc/nsswitch.conf ... sudoers: sss files .... ldbsearch -H /var/lib/sss/db/cache_LDAP_MY.COM/ldb contains Microsoft AD records: # record 2 dn: name=r2,cn=sudorules,cn=custom,cn=LDAP_MY.COM,cn=sysdb cn: r2 dataExpireTimestamp: 1561891358 entryUSN: 245385 name: r2 objectClass: sudoRule originalDN: CN=r2,OU=SUDOers,DC=my,DC=com sudoCommand: ALL sudoHost: ALL sudoOption: !authenticate sudoUser: Admin(a)my.com distinguishedName: name=r2,cn=sudorules,cn=custom,cn=LDAP_MY.COM, cn=sysdb AD sudoRole is sudoRule in local SSSD DB cache. But getting this below when trying to test 'sudo -l' or 'sudo su' [sssd[sudo]] [sudosrv_fetch_rules] (0x0400): Returning 0 rules for [Admin@my.com@my.com] from /var/log/sssd/sssd_sudo.log Duplicate domain ? I can see the rules been updated in the SSSD cache file from Microsoft AD. But I cannot use them because maybe some misconfiguration ? setup for sudo logs: /etc/sudo.conf and put down the following lines: Debug sudo /var/log/sudo_debug all@debug Debug sudoers.so /var/log/sudo_debug all@debug from /var/log/sudo_debug I have this: ... user_in_group: user admin(a)my.com NOT in group sudo ... Thx a lot! Cheers!

3 3

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

sssd-users July 2019