You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[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
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.
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]
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
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.
[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
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?
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.
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?
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.
Cloned from Pagure issue: https://pagure.io/SSSD/sssd/issue/3857
my sssd.conf is
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.
Comments
Comment from sbose at 2018-10-16 12:31:49
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.
Comment from jhrozek at 2018-10-16 12:40:26
Also, unrelated to the issue, but please don't use auth_provider=krb5 but auth_provider=ad.
Comment from eichhorn at 2018-10-16 18:12:47
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]
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
Comment from eichhorn at 2018-10-16 18:15:28
oh and enumerate true/false has an speed impact on the debian systems, but not on the ubuntu systems.
Comment from sbose at 2018-10-19 12:01:30
Do you still see the 'ldb_add failed' error if you stop SSSD, remove everything from /var/lib/sss/db/ and start SSSD again?
Comment from eichhorn at 2018-10-19 13:33:58
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.
Comment from sbose at 2018-10-19 14:05:02
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.
Comment from eichhorn at 2018-10-19 15:25:10
i made a new run with empty cache dirs and debug level 9 of domain nss and sssd section
Comment from sbose at 2018-10-19 16:16:14
The error is
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?
Comment from eichhorn at 2018-10-22 12:35:20
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
Comment from eichhorn at 2018-10-22 12:52:06
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
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
Comment from sbose at 2018-10-25 16:33:09
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?
Comment from eichhorn at 2018-11-06 16:53:47
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
Comment from sbose at 2018-11-07 10:46:41
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.
Comment from eichhorn at 2018-11-07 11:34:55
i did exactly that short step.
Comment from sbose at 2018-11-07 12:39:03
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?
Comment from eichhorn at 2018-11-07 14:58:34
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!!!
Comment from eichhorn at 2018-11-08 13:50:29
it was a replication issue with gc.
with
ad_enable_gc = false
it works
Comment from sbose at 2018-11-08 17:20:57
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?
Comment from eichhorn at 2018-11-09 15:05:32
the gc part has two ways to solve
And yes you can close the ticket, done well!! great tanks.
Comment from eichhorn at 2018-11-09 15:05:58
Metadata Update from @eichhorn:
The text was updated successfully, but these errors were encountered: