sssd performance on large domains
by zfnoctis＠gmail.com
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.
1 year, 10 months
ID Views for IPA ID Views for AD users inconsistent resolution
by Louis Abel
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 years, 4 months
sssd with samba
by Edouard Guigné
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
3 years
Enumerate users from external group from AD trust
by Bolke de Bruin
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(a)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-g...
4 years
SSSD strangeness
by simonc99＠hotmail.com
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 years, 1 month
sssd sudo using Microsoft Active Directory
by Bruno Monteiro
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(a)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!
4 years, 5 months
id / getent not finding AD users
by Thomas Beaudry
Hi Guys,
i have 2 Ubuntu 16.04 servers that have their users run by AD. The sssd.conf and output of "realm list" is identical for both servers. However, one of them can't seem to find the AD users, so ssh fails. I tried doing id <user> and getent passwd <user> and it doesn't find them.
Do you know what the issue might be?
Thanks,
Thomas
Here is my sssd.conf:
# cat /etc/sssd/sssd.conf
[autofs]
debug_level=1
[krb5]
debug_level=1
[nss]
filter_groups = root
filter_users = root
reconnection_retries = 3
[pam]
reconnection_retries = 3
debug_level=1
[sssd]
domains = MYDOMAIN.ca
config_file_version = 2
services = nss, pam, ssh, autofs
debug_level=1
[domain/MYDOMAIN.ca]
ad_domain = MYDOMAIN.ca
krb5_realm = MYDOMAIN.CA
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
override_homedir = /NAS/home/%u
fallback_homedir = /home/%u
access_provider = simple
debug_level=1
ignore_group_members=True
simple_allow_groups = perform_hpc
and output of realm list:
# realm list
MYDOMAIN.ca
type: kerberos
realm-name: MYDOMAIN.CA
domain-name: MYDOMAIN?.ca
configured: kerberos-member
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
login-formats: %U
login-policy: allow-permitted-logins
permitted-logins:
permitted-groups:
4 years, 5 months
Use local posix group with ad-users to allow login access
by Mads Boye
Hi everyone.
So I am banging my head against the wall and need some help.
What i try to achive is having a local posix group, which contains active directory users.
Now i would like to use this posix group to allow the users to access the server with e.g. ssh. How do I setup this?
Normally I use the allow_simple_groups for my AD user group who can login, but hte documentation says that local groups are not evaluated.
I have tried with /etc/security/access.conf
The OS I am using is Ubuntu 18.04
Is what I am trying to achive possible with sssd?
Please let me know if additional information is needed.
4 years, 5 months
Have 'realm join' overwrite host credentials if AD machine object already exists....
by Spike White
All,
We have a certain end condition that's troubling. I'm guessing we can
just throw a flag to realm join, or put a setting in /etc/realmd.conf to
fix. Let me explain.
Here's the usual situation. New fresh build. We join the AD domain as so:
realm join -v --automatic-id-mapping=no
--computer-ou="OU=Servers,OU=UNIX,DC=$SUPPORTREGION,DC=COMPANY,DC=COM"
--user-principal="host/`hostname --fqdn`@$JOINDOMAIN" $JOINDOMAIN
Fresh build -- this works fine. This creates the machine object in AD, in
our specific OU. Sets the hosts credentials in that machine object, saves
these host credentials in /etc/krb5.keytab file.
Life is good.
When we re-image a server, hopefully we remember to do a 'realm leave
<DOMAIN>' prior to re-imaging. That goes out, destroys the AD machine
object in our OU, possibly other cleanups.
Then we re-image. realm join (as above) finds no AD object, it does the
usual. Life is good.
Here's the end condition that isn't good. If we re-image and we've
forgotten to 'realm leave <DOMAIN>', then a pre-existing AD object exists
already in our OU. By the desired name.
In that case, when we re-image the above 'realm join' invocation does not
overwrite the host creds in this pre-existing machine object. And does not
create an /etc/krb5.keytab file.
Because it does not create an /etc/krb5.keytab file the 'realm join' does
not fully successfully complete.
We have experience with a previous (3rd party) AD integration product. In
that product, if you have a pre-existing AD object, it informs you an AD
object has been found, existing configuration will be overwritten. Then it
updates the host creds in that pre-existing machine object and it lays down
a keytab file with the host creds.
That is, if it finds a pre-existing AD machine object it soldiers on anyway.
We'd like to tweak our realm join to do that behavior. If pre-existing AD
machine object detects, overwrite the host creds in that machine object and
create /etc/krb5.keytab file with those same host creds. I.e., soldier on.
What flag do we throw to realm join to do that? Or what setting in
/etc/realmd.conf do we set?
This is on RHEL7 (sssd version 1.16.2-13) and RHEL8 (sssd version 2.0.0-23).
Spike
4 years, 5 months
Announcing SSSD 2.2.0
by Jakub Hrozek
SSSD 2.2.0
===========
The SSSD team is proud to announce the release of version 1.16.4 of the
System Security Services Daemon. The tarball can be downloaded from:
https://releases.pagure.org/SSSD/sssd/
RPM packages will be made available for Fedora shortly.
Feedback
————----
Please provide comments, bugs and other feedback via the sssd-devel or
sssd-users mailing lists:
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Highlights
----------
This release removes or deprecates functionality from SSSD, therefore the SSSD
team decided it was time to bump the major version number. The sssd-1-16
branch will be still supported (most probably even as a LTM branch) so that
users who rely on any of the removed features can either migrate or ask for
the features to be readded.
Except for the removed features, this release contains a reworked internal IPC
and a new default storage back end for the KCM responder.
Platform support removal
^^^^^^^^^^^^^^^^^^^^^^^^
* Starting with SSSD 2.0, upstream no longer supports RHEL-6 and its derivatives.
Users of RHEL-6 are encouraged to stick with the sssd-1-16 branch.
Removed features
^^^^^^^^^^^^^^^^
* The Python API for managing users and groups in local domains
(``id_provider=local``) was removed completely. The interface
had been packaged as module called ``pysss.local``
* The LDAP provider had a special-case branch for evaluating group
memberships with the RFC2307bis schema when group nesting was
explicitly disabled. This codepath was adding needless additional
complexity for little performance gain and was rarely used.
* The ``ldap_groups_use_matching_rule_in_chain`` and
``ldap_initgroups_use_matching_rule_in_chain`` options and the code that
evaluated them was removed. Neither of these options provided
a significant performance benefit and the code implementing
these options was complex and rarely used.
Deprecated features
^^^^^^^^^^^^^^^^^^^
* The local provider (``id_provider=local``) and the command line
tools to manage users and groups in the local domains, such as
``sss_useradd`` is not built by default anymore. There is a configure-time
switch ``--enable-local-domain`` you can use to re-enable the local
domain support. However, upstream would like to remove the local
domain completely in a future release.
* The ``sssd_secrets`` responder is not packaged by default. The responder
was meant to provide a REST API to access user secrets as well as
a proxy to Custodia servers, but as Custodia development all but
stopped and the local secrets handling so far didn't gain traction,
we decided to not enable this code by default. This also means that the
default SSSD configuration no longer requires libcurl and http-parser.
Changed default settings
^^^^^^^^^^^^^^^^^^^^^^^^
* The ``ldap_sudo_include_regexp`` option changed its default value
from ``true`` to ``false``. This means that wild cards in the ``sudoHost``
LDAP attribute are no longer supported by default. The reason we
changed the default was that the wildcard was costly to evaluate
on the LDAP server side and at the same time rarely used.
New features
^^^^^^^^^^^^
* The KCM responder has a new back end to store credential caches
in a local database. This new back end is enabled by default and
actually uses the same storage as the ``sssd-secrets`` responder had used,
so the switch from sssd-secrets to this new back end should be
completely seamless. The ``sssd-secrets`` socket is no longer required for
KCM to operate.
* The list of PAM services which are allowed to authenticate using a
Smart Card is now configurable using a new option
``pam_p11_allowed_services``.
Packaging Changes
-----------------
* The ``sss_useradd``, ``sss_userdel``, ``sss_usermod``, ``sss_groupadd``,
``sss_groupdel``, ``sss_groupshow`` and ``sss_groupmod`` binaries and their
manual pages are no longer packaged by default unless
``--enable-local-provider`` is selected.
* The sssd_secrets responder is no longer packaged by default unless
``--enable-secrets-responder`` is selected.
* The new internal IPC mechanism uses several private libraries that
need to be packaged - ``libsss_sbus.so``, ``libsss_sbus_sync.so``, ``libsss_iface.so``,
``libsss_iface_sync.so``, ``libifp_iface.so`` and ``libifp_iface_sync.so``
* The new KCM ccache back end relies on a private library
``libsss_secrets.so`` that must be packaged in case either the KCM responder
or the secrets responder are enabled.
Documentation Changes
---------------------
* The ``ldap_groups_use_matching_rule_in_chain`` and
``ldap_initgroups_use_matching_rule_in_chain`` options were removed.
* The ``ldap_sudo_include_regexp`` option changed its default value
from ``true`` to ``false``.
Known issues
------------
* https://pagure.io/SSSD/sssd/issue/3807 - The sbus codegen script relies
on "python" which might not be available on all distributions
* There is a script that autogenerates code for the internal SSSD IPC.
The script happens to call "python" which is not available on all
distributions. Patching the ``sbus_generate.sh`` file to call e.g.
python3 explicitly works around the issue
Tickets Fixed
-------------
* `3717 <https://pagure.io/SSSD/sssd/issue/3717>`_ - Don't package sssd-secrets by default
* `3685 <https://pagure.io/SSSD/sssd/issue/3685>`_ - KCM: Default to a new back end that would write to the secrets database directly
* `3530 <https://pagure.io/SSSD/sssd/issue/3530>`_ - Remove CONFDB_DOMAIN_LEGACY_PASS
* `3515 <https://pagure.io/SSSD/sssd/issue/3515>`_ - Disable host wildcards in sudoHost attribute (ldap_sudo_include_regexp=false)
* `3494 <https://pagure.io/SSSD/sssd/issue/3494>`_ - Remove the special-case for RFC2307bis with zero nesting level
* `3493 <https://pagure.io/SSSD/sssd/issue/3493>`_ - Remove the pysss.local interface
* `3492 <https://pagure.io/SSSD/sssd/issue/3492>`_ - Remove support for ldap_groups_use_matching_rule_in_chain and ldap_initgroups_use_matching_rule_in_chain
* `3304 <https://pagure.io/SSSD/sssd/issue/3304>`_ - Only build the local provider conditionally
* `2926 <https://pagure.io/SSSD/sssd/issue/2926>`_ - Make list of local PAM services allowed for Smartcard authentication configurable
Detailed Changelog
------------------
* Amit Kumar (1):
* providers: disable ldap_sudo_include_regexp by default
* Fabiano Fidêncio (19):
* man/sss_ssh_knownhostsproxy: fix typo pubkeys -> pubkey
* providers: drop ldap_{init,}groups_use_matching_rule_in_chain support
* ldap: remove parallel requests from rfc2307bis
* tests: adapt common_dom to files_provider
* tests: adapt test_sysdb_views to files provider
* tests: adapt sysdb-tests to files_provider
* tests: adapt sysdb_ssh tests to files provider
* tests: adapt auth-tests to files provider
* tests: adapt tests_fqnames to files provider
* sysdb: sanitize the dn on cleanup_dn_filter
* sysdb: pass subfilter and ts_subfilter to sysdb_search_*_by_timestamp()
* tests: adapt test_ldap_id_cleanup to files provider
* tests: remove LOCAL_SYSDB_FILE reference from test_sysdb_certmap
* tests: remove LOCAL_SYSDB_FILE reference from test_sysdb_domain_resolution_order_
* tests: remove LOCAL_SYSDB_FILE reference from test_sysdb_subdomains
* tests: remove LOCAL_SYSDB_FILE reference from common_dom
* local: build local provider conditionally
* pysss: fix typo in comment
* pysss: remove pysss.local
* Jakub Hrozek (55):
* Updating the version to track 1.16.4 development
* src/tests/python-test.py is GPLv3+
* src/tests/intg/util.py is licensed under GPLv3+
* src/tests/intg/test_ts_cache.py is licensed under GPLv3+
* src/tests/intg/test_sudo.py is licensed under GPLv3+
* src/tests/intg/test_sssctl.py is licensed under GPLv3+
* src/tests/intg/test_ssh_pubkey.py is licensed under GPLv3+
* src/tests/intg/test_session_recording.py is licensed under GPLv3+
* src/tests/intg/test_secrets.py is licensed under GPLv3+
* src/tests/intg/test_pysss_nss_idmap.py is licensed under GPLv3+
* src/tests/intg/test_pam_responder.py is licensed under GPLv3+
* src/tests/intg/test_pac_responder.py is licensed under GPLv3+
* src/tests/intg/test_netgroup.py is licensed under GPLv3+
* src/tests/intg/test_memory_cache.py is licensed under GPLv3+
* src/tests/intg/test_local_domain.py is licensed under GPLv3+
* src/tests/intg/test_ldap.py is licensed under GPLv3+
* src/tests/intg/test_kcm.py is licensed under GPLv3+
* src/tests/intg/test_infopipe.py is licensed under GPLv3+
* src/tests/intg/test_files_provider.py is licensed under GPLv3+
* src/tests/intg/test_files_ops.py is licensed under GPLv3+
* src/tests/intg/test_enumeration.py is licensed under GPLv3+
* src/tests/intg/sssd_passwd.py is licensed under GPLv3+
* src/tests/intg/sssd_nss.py is licensed under GPLv3+
* src/tests/intg/sssd_netgroup.py is licensed under GPLv3+
* src/tests/intg/sssd_ldb.py is licensed under GPLv3+
* src/tests/intg/sssd_id.py is licensed under GPLv3+
* src/tests/intg/sssd_group.py is licensed under GPLv3+
* src/tests/intg/secrets.py is licensed under GPLv3+
* src/tests/intg/ldap_local_override_test.py is licensed under GPLv3+
* src/tests/intg/ldap_ent.py is licensed under GPLv3+
* src/tests/intg/krb5utils.py is licensed under GPLv3+
* src/tests/intg/kdc.py is licensed under GPLv3+
* src/tests/intg/files_ops.py is licensed under GPLv3+
* src/tests/intg/ent_test.py is licensed under GPLv3+
* src/tests/intg/ent.py is licensed under GPLv3+
* src/tests/intg/ds_openldap.py is licensed under GPLv3+
* src/tests/intg/ds.py is licensed under GPLv3+
* src/config/setup.py.in is licensed under GPLv3+
* src/config/SSSDConfig/ipachangeconf.py is licensed under GPLv3+
* Explicitly add GPLv3+ license blob to several files
* Updating the version before the 2.0 release
* TESTS: the sys package was used but not imported
* TESTS: Remove tests database in teardown
* TESTS: Properly set argv[0] when starting the secrets responder
* KCM: Move a confusing DEBUG message
* KCM: Fix a typo
* UTIL: Add libsss_secrets
* SECRETS: Use libsss_secrets
* KCM; Hide the secret URL as implementation detail instead of exposing it in the JSON-marshalling API
* UTIL: libsss_secrets: Add an update function
* KCM: Add a new back end that uses libsss_secrets directly
* TESTS: Get rid of KCM_PEER_UID
* TESTS: Add tests for the KCM libsss_secrets back end
* KCM: Change the default ccache storage from the secrets responder to libsecrets
* BUILD: Do not build the secrets responder by default
* Lukas Slebodnik (6):
* krb5_locator: Make debug function internal
* krb5_locator: Simplify usage of macro PLUGIN_DEBUG
* krb5_locator: Fix typo in debug message
* krb5_locator: Fix formatting of the variable port
* krb5_locator: Use format string checking for debug function
* PAM: Allow to configure pam services for Smartcards
* Pavel Březina (21):
* include stdarg.h directly in debug.h
* pam_add_response: fix talloc context
* sss_ptr_hash: add sss_ptr_get_value to make it useful in delete callbacks
* sss_ptr_list: add linked list of talloc pointers
* sbus: move sbus code to standalone library
* sbus: add sbus sssd error codes
* sbus: add new implementation
* sbus: build new sbus implementation
* sbus: disable generating old api
* sbus: fix indirect includes in sssd
* sbus: add sss_iface library
* sbus: convert monitor
* sbus: convert backend
* sbus: convert responders
* sbus: convert proxy provider
* sbus: convert infopipe
* sbus: convert sssctl
* sbus: remove old implementation
* sbus: add new internal libraries to specfile
* sbus: make tests run
* tests: disable parse_inp_call_dp, parse_inp_call_attach in responder-get-domains-tests
* amitkuma (1):
* confdb: Remove CONFDB_DOMAIN_LEGACY_PASS
4 years, 5 months
