Hi, my sssd is service is crashing on CentOS 8 it looks like something is changing the file permissions on /var/lib/sss/db/config.ldb
$ systemctl status sssd.service
● sssd.service - System Security Services Daemon Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled; vendor preset: enabled) Active: failed (Result: exit-code) since Mon 2020-01-13 16:30:16 CST; 15h ago Process: 874 ExecStart=/usr/sbin/sssd -i ${DEBUG_LOGGER} (code=exited, status=1/FAILURE) Main PID: 874 (code=exited, status=1/FAILURE)
Jan 13 16:30:16 sp20client.ad.siu.edu sssd[874]: (Mon Jan 13 16:30:16:876393 2020) [sssd[nss]] [ldb] (0x0020): Unable to open tdb '/var/lib/sss/db/config.ldb': Permission denied Jan 13 16:30:16 sp20client.ad.siu.edu sssd[874]: (Mon Jan 13 16:30:16:876628 2020) [sssd[nss]] [ldb] (0x0020): Failed to connect to '/var/lib/sss/db/config.ldb' with backend 'tdb': Unable to > Jan 13 16:30:16 sp20client.ad.siu.edu sssd[874]: (Mon Jan 13 16:30:16:876641 2020) [sssd[nss]] [confdb_init] (0x0010): Unable to open config database [/var/lib/sss/db/config.ldb] Jan 13 16:30:16 sp20client.ad.siu.edu sssd[874]: (Mon Jan 13 16:30:16:876654 2020) [sssd[nss]] [server_setup] (0x0010): The confdb initialization failed Jan 13 16:30:16 sp20client.ad.siu.edu sssd[874]: Exiting the SSSD. Could not restart critical service [nss]. Jan 13 16:30:16 sp20client.ad.siu.edu sssd[be[ad.siu.edu]][943]: Shutting down Jan 13 16:30:16 sp20client.ad.siu.edu sssd[be[implicit_files]][942]: Shutting down Jan 13 16:30:16 sp20client.ad.siu.edu systemd[1]: sssd.service: Main process exited, code=exited, status=1/FAILURE Jan 13 16:30:16 sp20client.ad.siu.edu systemd[1]: sssd.service: Failed with result 'exit-code'. Jan 13 16:30:16 sp20client.ad.siu.edu systemd[1]: Failed to start System Security Services Daemon.
something is changing the file permissions of file /var/lib/sss/db/config.ldb to:
$ ls -la /var/lib/sss/db/config.ldb -rw-------. 1 1767801122 1767800513 1286144 Jan 13 16:30 /var/lib/sss/db/config.ldb $
$ id 1767801122 id: ‘1767801122’: no such user $ getent passwd 1767801122 $ echo $? 2 $
$ systemctl restart sssd $ ls -lan /var/lib/sss/db/config.ldb -rw-------. 1 0 0 1286144 Jan 14 08:00 /var/lib/sss/db/config.ldb $ ls -la /var/lib/sss/db/config.ldb -rw-------. 1 root root 1286144 Jan 14 08:00 /var/lib/sss/db/config.ldb $
I've joined this machine to an Active Directory Domain using packages: realmd_prereq_packages: - realmd - sssd - adcli - oddjob - oddjob-mkhomedir - samba-common - samba-common-tools - krb5-workstation
realm join -vvvv --computer-ou="ou=Computers,dc=sample,dc=college,dc=edu" --user-principal=nfs/sp20client.sample.college.edu@AD.SIU.EDU --os-name=CentOS --user=account SAMPLE.COLLEGE.EDU
Things have been odd with the sssd authentication in other ways as well. One time when I tried to su root it wasn't working until I rebooted CentOS 8.
Here is my sssd.conf: [sssd] domains = sample.college.edu config_file_version = 2 services = nss, pam #default_domain_suffix = SAMPLE.COLLEGE.EDU
[domain/sample.college.edu] ad_domain = sample.college.edu krb5_realm = SAMPLE.COLLEGE.EDU 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
# The following pulls ldap uid,gid from AD #ldap_id_mapping = False
# The following uses xxxxxxx@sample.college.edu for login name if default_domain_suffix is not set. #use_fully_qualified_names = True # The following allows xxxxxxx to login with default_domain_suffix is not set. use_fully_qualified_names = False
fallback_homedir = /home/%u@%d access_provider = ad
subdomain_inherit = ignore_group_members, ldap_purge_cache_timeout ignore_group_members = True
krb5_lifetime = 7h krb5_renewable_lifetime = 7d krb5_renew_interval = 60s
dyndns_update = true dyndns_refresh_interval = 60 dyndns_update_ptr = true dyndns_ttl = 60
debug_level = 9 dyndns_iface = enp0s3 #dyndns_auth = none dyndns_server = 131.x.x.x
ad_hostname = sp20client.sample.college.edu
On Tue, Jan 14, 2020 at 02:23:39PM -0000, Michael Barkdoll wrote:
Hi, my sssd is service is crashing on CentOS 8 it looks like something is changing the file permissions on /var/lib/sss/db/config.ldb
$ systemctl status sssd.service
● sssd.service - System Security Services Daemon Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled; vendor preset: enabled) Active: failed (Result: exit-code) since Mon 2020-01-13 16:30:16 CST; 15h ago Process: 874 ExecStart=/usr/sbin/sssd -i ${DEBUG_LOGGER} (code=exited, status=1/FAILURE) Main PID: 874 (code=exited, status=1/FAILURE)
Jan 13 16:30:16 sp20client.ad.siu.edu sssd[874]: (Mon Jan 13 16:30:16:876393 2020) [sssd[nss]] [ldb] (0x0020): Unable to open tdb '/var/lib/sss/db/config.ldb': Permission denied Jan 13 16:30:16 sp20client.ad.siu.edu sssd[874]: (Mon Jan 13 16:30:16:876628 2020) [sssd[nss]] [ldb] (0x0020): Failed to connect to '/var/lib/sss/db/config.ldb' with backend 'tdb': Unable to > Jan 13 16:30:16 sp20client.ad.siu.edu sssd[874]: (Mon Jan 13 16:30:16:876641 2020) [sssd[nss]] [confdb_init] (0x0010): Unable to open config database [/var/lib/sss/db/config.ldb] Jan 13 16:30:16 sp20client.ad.siu.edu sssd[874]: (Mon Jan 13 16:30:16:876654 2020) [sssd[nss]] [server_setup] (0x0010): The confdb initialization failed Jan 13 16:30:16 sp20client.ad.siu.edu sssd[874]: Exiting the SSSD. Could not restart critical service [nss]. Jan 13 16:30:16 sp20client.ad.siu.edu sssd[be[ad.siu.edu]][943]: Shutting down Jan 13 16:30:16 sp20client.ad.siu.edu sssd[be[implicit_files]][942]: Shutting down Jan 13 16:30:16 sp20client.ad.siu.edu systemd[1]: sssd.service: Main process exited, code=exited, status=1/FAILURE Jan 13 16:30:16 sp20client.ad.siu.edu systemd[1]: sssd.service: Failed with result 'exit-code'. Jan 13 16:30:16 sp20client.ad.siu.edu systemd[1]: Failed to start System Security Services Daemon.
something is changing the file permissions of file /var/lib/sss/db/config.ldb to:
$ ls -la /var/lib/sss/db/config.ldb -rw-------. 1 1767801122 1767800513 1286144 Jan 13 16:30 /var/lib/sss/db/config.ldb $
$ id 1767801122 id: ‘1767801122’: no such user $ getent passwd 1767801122
Hi,
this is most probably the UID of an AD user, so as long as SSSD is not running it cannot be resolved.
$ echo $? 2 $
$ systemctl restart sssd $ ls -lan /var/lib/sss/db/config.ldb -rw-------. 1 0 0 1286144 Jan 14 08:00 /var/lib/sss/db/config.ldb $ ls -la /var/lib/sss/db/config.ldb -rw-------. 1 root root 1286144 Jan 14 08:00 /var/lib/sss/db/config.ldb $
I've joined this machine to an Active Directory Domain using packages: realmd_prereq_packages:
- realmd
- sssd
- adcli
- oddjob
- oddjob-mkhomedir
- samba-common
- samba-common-tools
- krb5-workstation
realm join -vvvv --computer-ou="ou=Computers,dc=sample,dc=college,dc=edu" --user-principal=nfs/sp20client.sample.college.edu@AD.SIU.EDU --os-name=CentOS --user=account SAMPLE.COLLEGE.EDU
Things have been odd with the sssd authentication in other ways as well. One time when I tried to su root it wasn't working until I rebooted CentOS 8.
Do you have the PAM related log message from the journal from this attempt?
Here is my sssd.conf: [sssd] domains = sample.college.edu config_file_version = 2 services = nss, pam #default_domain_suffix = SAMPLE.COLLEGE.EDU
[domain/sample.college.edu] ad_domain = sample.college.edu krb5_realm = SAMPLE.COLLEGE.EDU 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
# The following pulls ldap uid,gid from AD #ldap_id_mapping = False
# The following uses xxxxxxx@sample.college.edu for login name if default_domain_suffix is not set. #use_fully_qualified_names = True # The following allows xxxxxxx to login with default_domain_suffix is not set. use_fully_qualified_names = False
jfyi, we recommend to use 'domain_resolution_order' instead of 'default_domain_suffix' with recent versions of SSSD, see man sssd.conf for details.
bye, Sumit
fallback_homedir = /home/%u@%d access_provider = ad
subdomain_inherit = ignore_group_members, ldap_purge_cache_timeout ignore_group_members = True
krb5_lifetime = 7h krb5_renewable_lifetime = 7d krb5_renew_interval = 60s
dyndns_update = true dyndns_refresh_interval = 60 dyndns_update_ptr = true dyndns_ttl = 60
debug_level = 9 dyndns_iface = enp0s3 #dyndns_auth = none dyndns_server = 131.x.x.x
ad_hostname = sp20client.sample.college.edu _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.o...
Yes, I was just about to post an update. Someone did indeed create an AD user account named: root@sample.college.edu
If I can't get the other user to agree to remove root@sample.college.edu AD user object, then I think I'd be required to make users login as useraccount@sample.college.edu due to this file permission change issue and other issues that would likely occur. However, your default_domain_suffic seems to be here to save the day.
Would something like the following first attempt to resolve local user accounts prior to AD?
default_domain_suffix = LOCAL, SAMPLE.COLLEGE.EDU
I put the following like in the domain section to allow short domain names. [domain/sample.college.edu] use_fully_qualified_names = False
I'm trying it now and it currently appears to work. There currently is no conflict between local user root and domain user root, but last time it took a day or two for the error to pop up. Do you think this config is safe?
Sorry, I meant that I'm using: domain_resolution_order = LOCAL, AD.SIU.EDU
not: default_domain_suffix = LOCAL, SAMPLE.COLLEGE.EDU
On Tue, Jan 14, 2020 at 05:01:20PM -0000, Michael Barkdoll wrote:
Yes, I was just about to post an update. Someone did indeed create an AD user account named: root@sample.college.edu
If I can't get the other user to agree to remove root@sample.college.edu AD user object, then I think I'd be required to make users login as useraccount@sample.college.edu due to this file permission change issue and other issues that would likely occur. However, your default_domain_suffic seems to be here to save the day.
Would something like the following first attempt to resolve local user accounts prior to AD?
default_domain_suffix = LOCAL, SAMPLE.COLLEGE.EDU
Hi,
the domain used for users from /etc/passwd is called 'implicit_files' and as you said in your other email the option is called 'domain_resolution_order'.
If this does not help you can modify the order in /etc/nsswitch.conf as well so that 'files' is listed before 'sss'.
HTH
bye, Sumit
I put the following like in the domain section to allow short domain names. [domain/sample.college.edu] use_fully_qualified_names = False
I'm trying it now and it currently appears to work. There currently is no conflict between local user root and domain user root, but last time it took a day or two for the error to pop up. Do you think this config is safe? _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.o...
sssd-users@lists.fedorahosted.org
-
Michael Barkdoll -
Sumit Bose