SSSD won't start - Failed to unlock db

mshuter

New Member

Reaction score: 1
Messages: 7

For some reason SSSD 1.11.7_19 won't start on my development VM running FreeBSD 12.0-RELEASE r341666 GENERIC amd64

Code:
root@dev:/ # service sssd start
Starting sssd.
/usr/local/etc/rc.d/sssd: WARNING: failed to start sssd
Here is my /usr/local/etc/sssd/sssd.conf (comments omitted):
Code:
[sssd]
config_file_version = 2
services = nss, pam
domains = lab.local

[nss]

[pam]

[domain/lab.local]
id_provider = ldap
auth_provider = ldap
access_provider = ldap
chpass_provider = ldap
ldap_schema = rfc2307
ldap_uri = ldaps://ds.lab.local
ldap_search_base = dc=lab,dc=local
I'm getting the following in /var/log/sssd.log.

Code:
(Tue Aug 13 18:21:56 2019) [sssd] [ldb] (0x0010): Failed to unlock db: ../ldb_tdb/ldb_tdb.c:147: Reusing ldb opend by pid 769 in process 770
/ Protocol error
When I start sssd with the -d7 flag, I get this additional info in /var/log/sssd.log.

Code:
(Wed Aug 14 10:25:36:273804 2019) [sssd] [check_file] (0x0400): lstat for [/var/run/nscd/socket] failed: [2][No such file or directory].
(Wed Aug 14 10:25:36:289627 2019) [sssd] [ldb] (0x0400): server_sort:Unable to register control with rootdse!
(Wed Aug 14 10:25:36:295324 2019) [sssd] [confdb_get_domain_internal] (0x0400): No enumeration for [lab.local]!
(Wed Aug 14 10:25:36:295369 2019) [sssd] [confdb_get_domain_internal] (0x1000): pwd_expiration_warning is -1
(Wed Aug 14 10:25:36:295422 2019) [sssd] [server_setup] (0x0040): Becoming a daemon.
(Wed Aug 14 10:25:36:297006 2019) [sssd] [ldb] (0x0400): server_sort:Unable to register control with rootdse!
(Wed Aug 14 10:25:36 2019) [sssd] [server_setup] (0x0400): CONFDB: /var/db/sss/config.ldb
(Wed Aug 14 10:25:36 2019) [sssd] [ldb] (0x0010): Failed to unlock db: ../ldb_tdb/ldb_tdb.c:147: Reusing ldb opend by pid 765 in process 766
 / Protocol error
(Wed Aug 14 10:25:36 2019) [sssd] [confdb_get_param] (0x0020): Failed to get [krb5_rcache_dir] from [config/sssd], error [5] (Input/output error)
(Wed Aug 14 10:25:36 2019) [sssd] [confdb_get_string] (0x0020): Failed to get [krb5_rcache_dir] from [config/sssd], error [5] (Input/output error)
Can anyone tell me what this means? The PIDs referenced don't exist when I do ps -auxw | grep <pid>. FWIW, LDAP is working fine:

Code:
root@dev:~ # ldapsearch -D "cn=admin,dc=lab,dc=local" -W
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base <dc=lab,dc=local> (default) with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# lab.local
dn: dc=lab,dc=local
dc: lab
description: ...
objectClass: dcObject
objectClass: organization
o: ...

# people, lab.local
dn: ou=people,dc=lab,dc=local
ou: people
description: All people in organisation
objectClass: organizationalUnit

...
# search result
search: 2
result: 0 Success

# numResponses: 10
# numEntries: 9
root@dev:~ #
TIA.
 

SirDice

Administrator
Staff member
Administrator
Moderator

Reaction score: 8,050
Messages: 31,632

In this case:
Code:
cd /usr/ports/security/sssd/files
fetch -o patch-src_monitor_monitor.c "https://bugs.freebsd.org/bugzilla/attachment.cgi?id=205782"
Then build the port.
 
OP
OP
M

mshuter

New Member

Reaction score: 1
Messages: 7

Thank you very much for your help so far. The patch seems to have worked, the SSSD is at least starting now. Unfortunately I'm still getting "UNIX authentication refused" when I attempt to ssh in with an LDAP account. All of the following files are identical to a jail I have running SSSD 1.11.7_14 which authenticates LDAP accounts over ssh successfully. Are there any other configuration differences that might cause one to work and the other to fail? These are all I have in my build notes.


/usr/local/etc/sssd/sssd.conf
/etc/nsswitch.conf
/usr/local/etc/openldap/ldap.conf
/usr/local/share/certs/cacert.pem
/etc/pam.d/sshd
/etc/rc.conf (sshd_enable and flags)
 

SirDice

Administrator
Staff member
Administrator
Moderator

Reaction score: 8,050
Messages: 31,632

I've only dealt with SSSD on RHEL (we use it to authenticate with ADS). But things should be fairly similar. In your config you're using ldaps://, is that also set in ldap.conf? Perhaps your SSL/TLS isn't working correctly. Another thing, does your LDAP allow anonymous queries? You may need to set up an LDAP bind account in order for SSSD to access the LDAP directories.
 
OP
OP
M

mshuter

New Member

Reaction score: 1
Messages: 7

I've only dealt with SSSD on RHEL (we use it to authenticate with ADS). But things should be fairly similar. In your config you're using ldaps://, is that also set in ldap.conf? Perhaps your SSL/TLS isn't working correctly. Another thing, does your LDAP allow anonymous queries? You may need to set up an LDAP bind account in order for SSSD to access the LDAP directories.
I am currently using LDAPS with anonymous bind disabled. You've given me some good ideas - I'll try temporarily rolling back SSL and allowing anonymous binds and see if that changes things. Now that I think about it, when developing the configuration in a jail, I did testing with anonymous binds first, so it may have cached my test account's authentication and therefore just kept working after I enabled SSL. Will let you know how it turns out.
Is there a way to make a secure SSSD bind account (i.e., without just putting the username and password in sssd.conf?)
 
OP
OP
M

mshuter

New Member

Reaction score: 1
Messages: 7

If you get SSSD to work, would you share your notes ?
I do intend to share my notes... this has been a struggle for me to find reliable procedures for FreeBSD with SSSD. Most of what's out there is either dealing with SSSD on RHEL or authenticating FreeBSD to AD or LDAP directly. A lot of reading between the lines. They're similar, but just different enough that I think others might like to learn from my struggles.
 
OP
OP
M

mshuter

New Member

Reaction score: 1
Messages: 7

OK, it looks like I can get authentication to work either by specifying a bind account and password in sssd.conf (bad) or by enabling anonymous bind (worse). Does SSSD not attempt to use the logging in users' credentials to bind? I would think that would be more secure.
 
Top