Can't authenticate against a 389DS server. I suspect it's a SSSD problem on the client side


I’m running a 389DS LDAPS server (with self-signed certificates) on a Fedora 30 remote machine called “miservidor.midominio.local”. There I have a typical directory containing user and group entries.

I can retrieve directory data from another Fedora 30 machine (the client’s one) without any problem. For instance, executing this command (“usu1ldap” is the name of an user located inside a “usuarios” organizationalunit)…:

LDAPTLS_REQCERT=never ldapsearch -H ldaps://miservidor.midominio.local -b “dc=midominio,dc=local” uid=usu1ldap

…I get:


But I want to use “usu1ldap” to login in client machine. So I’ve configured /etc/sssd/sssd.conf file in client machine like this…:


…I’ve executed sudo authselect select sssd to configure NSS/PAM accordingly and finally I’ve restarted sssd service.

However, something doesn’t work: getent passwd doesn’t show “usu1ldap” user and, obviously, id usu1ldap retrieves “unknown user”.

What am I doing wrong? I’m a bit desperated…I’ve tried to grasp sssd’s log files but without any clue.
Thanks a lot for your patience.

NOTE: Notice that in sssd.conf file I’ve had to put in ldap_default_bind_dn and ldap_default_authtok lines the name and password of directory’s manager user respectively because my 389DS server by default doesn’t allow anonymous queries and I don’t know how to change this (yet).


The client on which you are trying to configure sssd is running Fedora 30?

1 Like

Yes, both machines are Fedora 30

Note, that domain .local is reserved for mDNS and using it for other tasks may result in unexpected issues.

grep -v -e "^#" -e "^$" /etc/nsswitch.conf
getent hosts miservidor.midominio.local
nslookup miservidor.midominio.local
ping -c 3 miservidor.midominio.local

Thanks, I didn’t think about it. But it’s not that problem.
I’ve changed “.local” domain by “.net” domain in all places ("/etc/hostname" and “/etc/hosts” files in server, “dse.ldif” file from configuration 389DS, in “sssd.conf” file in client and obviously in the distinguished name of all ldap entries. No luck: the same behaviour.
In fact, note that the ldap connection between client and server through the network works flawessly: I can do the ldapsearch shown above in client and I get the ldap entry correctly. What it doesn’t work (I suspect) it’s the fetching of that ldap entry by sssd service because getent passwd doesn’t list it. But I don’t know if it’s a problem of a lacking option in “sssd.conf” file or it’s a bad configuration done by authselect (I don’t think so, but…). I’m really stuck.

1 Like

You can post the configs, so someone might point to the problem.

Hello again.
Thanks for the interest.
I’ve installed “sssd-tools” in client machine to troubleshoot (which need “libsss_simpleifp” package as dependency). Specifically, I’ve run the sudo sssctl user-checks usu1ldap command and I’ve seen this:


So it seems clear it’s an issue related to NSS or PAM topic. The content of my “/etc/sssd/sssd.conf” file is shown in first post.

Thanks a lot

1 Like

The “/etc/nsswitch.conf” file’s content after running sudo authselect select sssd with-mkhomedir with-sudo is


The “/etc/pam.d/system-auth” file’s content after that command is:


Well, running the sudo sssctl user-checks usu1ldap command I’ve seen the following line appears in journal:

Maybe it’s a clue

Well, I’ve solved the issue: I forgot adding the services=nss,pam line in “/etc/sssd/sssd.conf” file (below [sssd] section. That was all. Oh my… I thought systemd could care of this (see but it seems it doesn’t.
Thanks to all of you for your interest.


Well, in fact it does: you only have to do what is explained in “How to test section” in above link. That is, you should only execute

systemctl enable sssd-nss.socket sssd-pam.socket*
systemctl start sssd-nss.socket sssd-pam.socket*

And that’s all: now services= line is optional.
My fault was not realizing these sockets were not activated by default


This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.