#3857 usage of ms ad with schema version 87 and sssd 1.16.1 on Ubuntu 18.04.1 LTS (GNU/Linux 4.15.0-36-generic x86_64)
Closed: Fixed 12 days ago by eichhorn. Opened a month ago by eichhorn.

my sssd.conf is

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

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

debug_level = 2
offline_credentials_expiration = 3
pam_id_timeout = 30

debug_level = 2
# user_attributes = +loginShell, +unixHomeDirectory, +gcos, +uidNumber, +gidNumber 

debug_level = 10

# [be]
# debug_level = 2
# timeout = 30

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

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

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

hosts: files dns
networks: files

protocols: db files
services: db files sss
ethers: db files
rpc: db files

netgroup: nis sss
sudoers: files sss

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


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

record 8942

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

record 4170

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
nameAlias: app_dep_esaxxx@xx-domain
isPosix: TRUE
originalModifyTimestamp: 20181019130740.0Z
entryUSN: 94483882
orig_member: CN=DEP_xxxx,OU=Departments,OU=Groups,OU=Be
lastUpdate: 1539954537
dataExpireTimestamp: 1539959937
distinguishedName: name=APP_DEP_xxx@xx-domain,cn=groups,c

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%

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.


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.

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)

12 days ago

Login to comment on this ticket.

Attachments 2
Attached a month ago View Comment
Attached 14 days ago View Comment