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

[q2dg (Oscar Torrente)]

Hello.

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).

[alciregi (Alessio)]

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

[q2dg (Oscar Torrente)]

Yes, both machines are Fedora 30
Thanks!

[vgaetera (Vladislav Grigoryev)]

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

[q2dg (Oscar Torrente)]

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.

[vgaetera (Vladislav Grigoryev)]

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

[q2dg (Oscar Torrente)]

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

[q2dg (Oscar Torrente)]

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:

Thanks!

[q2dg (Oscar Torrente)]

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

Maybe it’s a clue

[q2dg (Oscar Torrente)]

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 https://docs.pagure.org/SSSD.sssd/design_pages/systemd_activatable_responders.html) but it seems it doesn’t.
Thanks to all of you for your interest.

[q2dg (Oscar Torrente)]

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