Unable to open tdb '/var/lib/sss/db/config.ldb': Permission denied

[Michael Barkdoll]

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(a)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(a)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

[Sumit Bose]

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(a)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(a)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(a)lists.fedorahosted.org
>  To unsubscribe send an email to sssd-users-leave(a)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/[e-mail]...

[Michael Barkdoll]

Yes, I was just about to post an update.  Someone did indeed create an AD user account
named:
root(a)sample.college.edu

If I can't get the other user to agree to remove root(a)sample.college.edu AD user
object, then I think I'd be required to make users login as
useraccount(a)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?

[Michael Barkdoll]

Sorry, I meant that I'm using:
domain_resolution_order = LOCAL, AD.SIU.EDU

not:
default_domain_suffix = LOCAL, SAMPLE.COLLEGE.EDU

[Sumit Bose]

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(a)sample.college.edu
>  
>  If I can't get the other user to agree to remove root(a)sample.college.edu AD user
> object, then I think I'd be required to make users login as
> useraccount(a)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(a)lists.fedorahosted.org
>  To unsubscribe send an email to sssd-users-leave(a)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/[e-mail]...