Learn more about these different git repos.
Other Git URLs
my sssd.conf is
[sssd] debug_level = 2 # domains = xx-domain, local domains = xx-domain config_file_version = 2 services = nss, pam, ifp, ssh, pac default_domain_suffix = XX-DOMAIN # Number of times services should attempt to reconnect in the # event of a crash or restart before they give up reconnection_retries = 3 # If a back end is particularly slow you can raise this timeout here sbus_timeout = 30 [nss] debug_level = 2 filter_users = root filter_groups = root enum_cache_timeout = 30 user_attributes = +loginShell, +unixHomeDirectory, +gcos, +uidNumber, +gidNumber fallback_homedir = /home/%u default_shell = /bin/bash # ignore_group_members = false [pam] debug_level = 2 offline_credentials_expiration = 3 pam_id_timeout = 30 [ifp] debug_level = 2 # user_attributes = +loginShell, +unixHomeDirectory, +gcos, +uidNumber, +gidNumber [ssh] debug_level = 10 # [be] # debug_level = 2 # timeout = 30 [pac] debug_level = 10 # allowed_uids = xxxxx_admin # [domain/local] # debug_level = 2 # ad_domain = local # id_provider = local # use_fully_qualified_names = true # fallback_homedir = /home/%u # default_shell = /bin/bash [domain/xx-domain] debug_level = 5 ad_domain = xx-domain ad_site = gk ad_server = ad01.xx-domain, ad02.xx.gk-domain, .. up to 10 server id_provider = ad auth_provider = krb5 auth_provider = ad chpass_provider = ad access_provider = ad ad_enable_gc = true ad_gpo_access_control = false krb5_realm = XX-DOMAIN krb5_server = XX-DOMAIN realmd_tags = manages-system joined-with-sssd and puppet cache_credentials = true krb5_store_password_if_offline = true krb5_keytab=/etc/krb5.keytab enumerate = true # subdomain_inherit = ignore_group_members, ldap_purge_cache_timeout # ignore_group_members = true ## ldap_uri = ldap://ldap.xx.xx-software.com:389 ## ldap_search_base = OU=Benutzer,o=XX-DOMAIN ldap_purge_cache_timeout = 0 ldap_id_mapping = true ldap_schema = ad # ldap_schema = 2256 ## ldap_schema = rfc2307bis # ldap_schema = rfc2307 # ldap_group_name = uniqueMember ldap_use_tokengroups = false # ldap_group_search_base = ou=Benutzer,o=XX-DOMAIN use_fully_qualified_names = true ## use_fully_qualified_names = false ad_gpo_access_control = disabled krb5_auth_timeout = 30 dns_resolver_timeout = 30 subdomains_provider = none subdomain_enumerate = none subdomain_inherit = false dyndns_update = false dyndns_update_ptr = false ldap_user_ssh_public_key = xx-SSHPublicKeys fallback_homedir = /home/%u default_shell = /bin/bash # enumerate = true entry_cache_timeout = 30 enum_cache_timeout = 30 ldap_enumeration_refresh_timeout = 30
my packages are root@ubuntu-test02:~# dpkg -l | grep -i sss ii libnss-sss:amd64 1.16.1-1ubuntu1 amd64 Nss library for the System Security Services Daemon ii libpam-sss:amd64 1.16.1-1ubuntu1 amd64 Pam module for the System Security Services Daemon ii libsss-certmap0 1.16.1-1ubuntu1 amd64 Certificate mapping library for SSSD ii libsss-idmap0 1.16.1-1ubuntu1 amd64 ID mapping library for SSSD ii libsss-nss-idmap0 1.16.1-1ubuntu1 amd64 SID based lookups library for SSSD ii libsss-simpleifp0 1.16.1-1ubuntu1 amd64 SSSD D-Bus responder helper library ii libsss-sudo 1.16.1-1ubuntu1 amd64 Communicator library for sudo ii libwbclient-sssd 1.16.1-1ubuntu1 amd64 SSSD libwbclient implementation ii python3-sss 1.16.1-1ubuntu1 amd64 Python3 module for the System Security Services Daemon ii sssd 1.16.1-1ubuntu1 amd64 System Security Services Daemon -- metapackage ii sssd-ad 1.16.1-1ubuntu1 amd64 System Security Services Daemon -- Active Directory back end ii sssd-ad-common 1.16.1-1ubuntu1 amd64 System Security Services Daemon -- PAC responder ii sssd-common 1.16.1-1ubuntu1 amd64 System Security Services Daemon -- common files ii sssd-dbus 1.16.1-1ubuntu1 amd64 System Security Services Daemon -- D-Bus responder ii sssd-ipa 1.16.1-1ubuntu1 amd64 System Security Services Daemon -- IPA back end ii sssd-krb5 1.16.1-1ubuntu1 amd64 System Security Services Daemon -- Kerberos back end ii sssd-krb5-common 1.16.1-1ubuntu1 amd64 System Security Services Daemon -- Kerberos helpers ii sssd-ldap 1.16.1-1ubuntu1 amd64 System Security Services Daemon -- LDAP back end ii sssd-proxy 1.16.1-1ubuntu1 amd64 System Security Services Daemon -- proxy back end ii sssd-tools 1.16.1-1ubuntu1 amd64 System Security Services Daemon -- tools
nsswitch passwd: compat sss group: compat sss shadow: compat sss gshadow: files
hosts: files dns networks: files
protocols: db files services: db files sss ethers: db files rpc: db files
netgroup: nis sss sudoers: files sss
so now to Problem, the identical installation on debian9.5 works, but slow. on Ubuntu18 i have the Effekt that most group are fetched to the cache but wen i call them with getent group grpname i get no answer.
when i call ldbsearch -H /var/lib/sss/db/cache_xx-domain.ldb | grep -i prj_xxx_fw i got the group as i call it via ldap from the ad
unfortunately the ad schema has version 87 of Microsoft Windows [Version 10.0.14393], how far is the support of sssd to this schema.
In the Description of sssd i read Active Directory 2008r2 and rfc2307, but i got the best group resolution with schema = ad, and ver 1.16.3 behave identical.
Afaik the attributes used by SSSD's AD schema didn't change in version 87 which is used by Windows 2016.
With AD you should always use id_provider=ad and ldap_schema=ad, you can even drop the latter because it is set by default when using id_provider=ad.
Is the group lookup more reliable if you disable enumeration?
Additionally it might be worth to check if replacing 'compat' with 'files' in nsswitch.conf helps.
Also, unrelated to the issue, but please don't use auth_provider=krb5 but auth_provider=ad.
first of all, that good news about the schema.
I changed the config of sssd.conf and nsswitch.
passwd: files sss group: files sss shadow: files sss gshadow: files
but the problem is unchanged
root@ubuntu-test02:/var/log/sssd# getent group service_admins no answer
root@ubuntu-test02:/var/log/sssd# ldbsearch -H /var/lib/sss/db/cache_xx-domain.ldb | grep dn:\ name=service_admins@xx-domain asq: Unable to register control with rootdse! dn: name=service_admins@xx-domain,cn=groups,cn=xx-domain,cn=sysdb the group is in the cache
root@ubuntu-test02:/var/log/sssd# grep -i service_admins sssd_xx-domain.log (Tue Oct 16 17:41:52 2018) [sssd[be[gk-domain]]] [sysdb_create_ts_entry] (0x0040): ldb_add failed: Entry already exists[Entry name=service_admins@xx-domain,cn=groups,cn=xx-domain,cn=sysdb already exists] root@ubuntu-test02:/var/log/sssd# and also log entries are here
I also enabled the PAC Responder, in the hope of get group membeschips deliverd in such krb tickets of users, but so far i does not help. and the process sssd_be is mostly running full speed 100% cpu time.
oh and the identical configuration on debian9.5 is much slower, but findes more groups with getent group
oh and enumerate true/false has an speed impact on the debian systems, but not on the ubuntu systems.
Do you still see the 'ldb_add failed' error if you stop SSSD, remove everything from /var/lib/sss/db/ and start SSSD again?
yes very often. I reset several times on serveral ubuntu systems the cache with sss_cache -g group or -E for all and also by deleting /var/lib/sss/db and /var/lib/sss/mc and restarting sssd. but it always ends up in this problem. This beviour is identical with sssd ver 1.16.1 and 1.16.3 on ubuntu. In general it is different on debian 9.5 with sssd vers 1.15.0. The debian version is much slower but more functional.
Ok, in this case I think we need the whole domain log file with debug_level=9 which contains the debug data after a restart of SSSD where the files in /var/lib/sss/db were removed.
The 'ldb_add failed' messages indicates that SSSD tries to add an entry to the timestamp cache twice and only the full logs can tell why this happens.
i made a new run with empty cache dirs and debug level 9 of domain nss and sssd section
<img alt="sssd-debug-level9.tar" src="/SSSD/sssd/issue/raw/files/d2b47d17b7d0cd2b848df98fa5febedeb80cd830e42a80f3a6fe4528eea5b966-sssd-debug-level9.tar" />
The error is
[nss_get_grent] (0x0040): Incomplete group object for service_admins@XX-domain[0]! Skipping
Can you check the cache entry for service_admins if the gidNumber attribute is set and what the value of this attribute and of the isPosix attribute is?
user entries have the correct uidNumber and isPosix: TRUE, but all groups i have seen has like the group service_admins
dn: name=service_admins@xx-domain,cn=groups,cn=xx-domain,cn=sysdb createTimestamp: 1539953836 gidNumber: 0 name: service_admins@xx-domain objectCategory: group .... and no entry isPosix
i got a group which works with getent group
dn: name=APP_DEP_xxx@xx-domain,cn=groups,cn=xx-domain,cn=sysdb createTimestamp: 1539954255 gidNumber: 761840762 name: APP_DEP_xxx@xx-domain objectCategory: group objectSIDString: S-1-5-21-1343024091-746137067-842925246-40762 uniqueID: 38d9b1ac-0dc0-4bc7-836c-35b4da7359cd originalDN: CN=APP_DEP_xxx,OU=Applications,OU=Groups,OU=B enutzer,DC=XX-DOMAIN nameAlias: app_dep_esaxxx@xx-domain isPosix: TRUE originalModifyTimestamp: 20181019130740.0Z entryUSN: 94483882 orig_member: CN=DEP_xxxx,OU=Departments,OU=Groups,OU=Be nutzer,DC=XX-DOMAIN lastUpdate: 1539954537 dataExpireTimestamp: 1539959937 distinguishedName: name=APP_DEP_xxx@xx-domain,cn=groups,c n=gk-domain,cn=sysdb
As you can see the working group has 'isPosix: TRUE' and a non-zero gidNumber set.
Can you check after restarting SSSD with an empty cache if 'name=service_admins@xx-domain,cn=groups,cn=xx-domain,cn=sysdb' looks the same if you call ldbsearch directly after the restart before any other command is send?
with enumerate = false, nothing happens
with enumerate = true
sssd_be produces have single cpu load between 90% and 100%
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 2296 root 20 0 547900 183720 50680 R 100.0 4.5 0:26.95 sssd_be
and after 5 at least five min i get first groups, all with gidNumber: 0 and no isPosix: entry
and so in group service_admins as i all others
Ok, if with 'enumerate = false' the group isn't shown either the issue might be already present here. Since it is easier to parse the log I'd like to ask you set set 'enumerate = false' and 'debug_level = 9' in the [nss] and [domain/...] sections of sssd.conf. Then restart SSSD, call 'getent group service_admins' and attach the nss and domain logs covering this request.
i did exactly that short step.
<img alt="sssd_nss.log.xz" src="/SSSD/sssd/issue/raw/files/75209f990fbe8863d80913ab1589ce49ab15bc7f5a0e4b555a6c34f9190e6a5c-sssd_nss.log.xz" /><img alt="sssd_xx-domain.log.xz" src="/SSSD/sssd/issue/raw/files/e7d7e2af6818022720c0a029d6d07e216edcc73bd3256fdf1bb2cca8772a5f51-sssd_xx-domain.log.xz" />
Although 'ldap_id_mapping = true' SSSD uses a search filter which expects that the gidNumber LDAP attribute is set for the group.
I think this can be worked around by removing 'subdomains_provider = none'. If you are only interested in the xx-domain you can add 'ad_enabled_domains = xx-domain' instead.
Please let me know if this workaround helps and the group is returned?
great, that works!!! i retested that also on debian9
that speeds up the enum call, so now i have fast logon on
debian 9.5 with sssd 1.15.0 and ubuntu server 18.04 with 1.16.1 both have identical config now
but on debian9 the ssh key auth ( key in ad ) works fine
but not on ubuntu i can run successful sss_ssh_authorized_keys user before first logon try with key and after no more.
do you have an idea why ubuntu ( sssd 1.16.1 ) have a problem with ssh key
so that is a great step forward!!!
it was a replication issue with gc.
with ad_enable_gc = false it works
I was about to suggest the same. There is already a ticket for this issue https://pagure.io/SSSD/sssd/issue/2474.
The original issue basically a configuration issue. If you disable the subdomain_provider you have to set the domain SID of your domain manually with the ldap_idmap_default_domain_sid option so that the id-mapping can be initialized properly, see man sssd-ad for details.
However I would recommend the solutions from above to use the subdomain provider and if you do not want to use all domains from the AD forest enable only the the domains you are interested in.
Do you think this ticket can be closed?
the gc part has two ways to solve 1. define all posix/sssd needed attrs as replicated to gc in the schema definition 2. set ad_enable_gc = false
And yes you can close the ticket, done well!! great tanks.
Metadata Update from @eichhorn: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)
SSSD is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in SSSD's github repository.
This issue has been cloned to Github and is available here: - https://github.com/SSSD/sssd/issues/4847
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Login to comment on this ticket.