LDAP not authenticating users for login

We have a linux server environment with mostly Centos 6.9. I am trying to test a Rocky Linux installation for future server deployments. Unfortunately, I have not been able to get a Rocky server to allow logins via ldap.

I tried to do my due diligence and search for other posts. “Rocky Linux fails when tries to authenticate users using SSSD service” is another post on here and doesn’t quite fit my environment. I use standard ldap not Active Directory. Also I tried the suggestions and it didn’t work.

I am using openldap and sssd with oddjob-mkhomedir. Here is my config with my server information obscured.

[ /etc/openldap/ldap.conf ]
URI     ldap://my.ldapserver.net/
TLS_CACERT      /etc/openldap/cacerts/ldap1.pem
TLS_CACERTDIR /etc/openldap/cacerts

[ /etc/sssd/sssd.conf ]
config_file_version = 2
services = nss, pam,autofs
domains = default

homedir_substring = /home


id_provider = ldap
autofs_provider = ldap
auth_provider = ldap
chpass_provider = ldap
ldap_uri = ldap://my.ldapserver.net/
ldap_search_base = dc=MYDOMAIN,dc=NET
ldap_user_search_base = ou=Users,dc=MYDOMAIN,dc=NET?one?accesstype=websvr
ldap_id_use_start_tls = True
ldap_tls_cacertdir = /etc/openldap/cacerts
ldap_tls_cacert = /etc/openldap/cacerts/ldap1.pem
cache_credentials = True
ldap_tls_reqcert = allow
debug_level = 4

I can run the command id testuser and I will receive a response from the ldap server. I ensured that the user didn’t exist locally.

According to my understanding, I have bound it to the login with
authselect select sssd with-mkhomedir --force

Unfortunately, I don’t know enough about ldap authentication to diagnose this. Logging has not given any information except the usual failed login entries. Any help is appreciated. Thanks in advance!

You need to clarify which is the server and which is the client; better to give exact o/s versions of each and exact package versions. Have you tested logging in to the client as a local user and then using ldapsearch (e.g. with debug level) to contact the server. There’s logging for ‘sssd’ in /var/log

The config I posted is the LDAP client. The LDAP server has been in production for years with about 200 Linux boxes authenticating properly to LDAP. I using SSSD (2.6.2-4.el8_6) and openldap-clients (2.4.46-18.el8). Logging into the client as a local user works just fine. ldapsearch (From the client) responds with the proper information, listing my: ou, ObjectClasses, cn, accesstype(s), etc. I have sssd debug_level set to 10 and there is absolutely no logging pertaining to a failure in any of the logs under /var/log/sssd/*

OK, that’s very clear now, so I think you’re saying everything works perfectly except for ‘sssd’ on the Rocky 8.6 client? The bit where it says “[domain/default]”, is that correct? Regarding the AuthSelect, did you check what it actually did, state before and after?

Yes, I believe that could be the case: That ldap is working but sssd is not allowing login.
The part where it says [domain\default] is the same config I pulled from another CentOS 6 server(ldap client) on our network. Then I made sure the certificates were placed properly. I didn’t take note of what the AuthSelect state was before but here is it currently.

[root@ldaptestj ~]# authselect current
Profile ID: sssd
Enabled features:
- with-mkhomedir

It’s a bit strange it’s no logging anything, I assume you rebooted the client after making the changes. Have you checked for any ‘sssd’ entries in journalctl?

Yes, I have rebooted the client since the last changes. As for journalctl, here are the only entries after I restarted the client and initiated a login that failed.

-- The unit systemd-hostnamed.service has successfully entered the 'dead' state.
Jun 27 16:29:37 ldaptestj sshd[2004]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=[IP REMOVED] user=testuser
Jun 27 16:29:39 ldaptestj sshd[2004]: Failed password for testuser from [IP REMOVED] port 60158 ssh2
[root@ldaptestj ~]#
[root@ldaptestj ~]#
[root@ldaptestj ~]# uptime
 16:29:54 up 1 min,  1 user,  load average: 0.06, 0.03, 0.01
[root@ldaptestj ~]#

Which seems odd because both getent passwd testuser and sssctl user-checks testuser return values from the ldap server.

Have you tested with ldapsearch?
If you have rsyslog enabled then you would have logs in /var/log/sssd

sssd_autofs.log                      sssd_default.log-20220605            sssd.log-20220529.gz                 sssd_pam.log
sssd_autofs.log-20220529.gz          sssd_implicit_files.log              sssd.log-20220605                    sssd_pam.log-20220529.gz
sssd_autofs.log-20220605             sssd_implicit_files.log-20220529.gz  sssd_nss.log                         sssd_pam.log-20220605
sssd_default.log                     sssd_implicit_files.log-20220605     sssd_nss.log-20220529.gz             
sssd_default.log-20220529.gz         sssd.log                             sssd_nss.log-20220605

You can trying upping the debug level to 9

Yes, I have tested with ldapsearch. I can search and get attributes from the ldap server. And if I bind it to an account I am able to receive the hashed “userPassword” attribute.

As for the logs, I do have the sssd logging enabled. I changed the debug level to 9 and gave it a reboot this morning. I then zeroed the logs and tried to login with the ldap account. I initiated a login 3 times and failed authentication each time. Here are the results, AFTER the failed login attempts.

-rw-------. 1 root root 0 Jun 28 09:04 sssd_autofs.log
-rw-------. 1 root root 0 Jun 28 09:10 sssd_default.log
-rw-------. 1 root root 0 Jun 28 09:04 sssd_ifp.log
-rw-------. 1 root root 0 Jun 28 09:04 sssd_implicit_files.log
-rw-------. 1 root root 0 Jun 28 09:05 sssd_kcm.log
-rw-------. 1 root root 0 Jun 28 09:04 sssd.log
-rw-------. 1 root root 0 Jun 28 09:05 sssd_nss.log
-rw-------. 1 root root 0 Jun 28 09:05 sssd_pam.log

I am not sure why I am not getting any logs pertaining to failed logs for sssd . Here are the commands I am running to set the debug level. If there is another way to set the debug level, I am more than willing to try.

[root@ldaptestj /]# sudo systemctl stop sssd
[root@ldaptestj /]# sudo sssd --debug-level=9
[root@ldaptestj /]# sudo systemctl start sssd

Note that these entries say ‘sshd’ which is not the same as ‘sssd’.

Yes, I realize that. This is just a journatctl output. There is no sssd entries in journalctl.

Can you try this command as root on the Rocky 8.6 client

systemctl status sssd.service

and post the full output. You will need to tell ‘systemctl’ not to wrap text etc

Here you go

[root@ldaptestj ~]#
[root@ldaptestj ~]# systemctl status sssd.service
● sssd.service - System Security Services Daemon
   Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled; vendor preset: enabled)
   Active: active (running) since Tue 2022-06-28 10:05:00 CDT; 1 day 7h ago
 Main PID: 3613 (sssd)
    Tasks: 0 (limit: 23048)
   Memory: 26.6M
   CGroup: /system.slice/sssd.service
           ‣ 3613 sssd --debug-level=9

Jun 28 10:04:59 ldaptestj sssd_be[3624]: Starting up
Jun 28 10:04:59 ldaptestj sssd_autofs[3628]: Starting up
Jun 28 10:04:59 ldaptestj sssd_pam[3627]: Starting up
Jun 28 10:04:59 ldaptestj sssd_nss[3626]: Starting up
Jun 28 10:05:00 ldaptestj systemd[1]: Started System Security Services Daemon.
Jun 28 10:05:00 ldaptestj sssd_autofs[3628]: Shutting down (status = 0)
Jun 28 10:05:00 ldaptestj sssd_pam[3627]: Shutting down (status = 0)
Jun 28 10:05:00 ldaptestj sssd_nss[3626]: Shutting down (status = 0)
Jun 28 10:05:00 ldaptestj sssd_be[3625]: Shutting down (status = 0)
Jun 28 10:05:00 ldaptestj sssd_be[3624]: Shutting down (status = 0)
[root@ldaptestj ~]#

The 6.9 was released in 2017. The last version of CentOS 6, the 6.10, was released 2018 and died 2020.
Many fear for vulnerabilities even where they don’t exist, while we know that 6.9 had many. It is high time to get something new.

Myself, I did replace CentOS 6 openldar server with CentOS 8 and 389ds in summer 2020, before CentOS 6 was dead. (Obviously, the CentOS Linux 8 had to be replaced last year.) Most of my systems do run CentOS 7 and its sssd/openldap client was/is ok with both server versions. However, I don’t authenticate to openldap. I did, when clients were still CentOS 6, but already back then I did deploy Kerberos for authentication. Hence, if there is a bullet with openldap, I’ve (accidentally) dodged it years ago.

I do recall that at some point update (but was it for 6 or 7?) the openldap did start to require TLS for authentication. In other words, that the auth_provider connection is much more strict than the id_provider. This would explain why you do get account info even though authentication fails.

These commands look like they:

  1. Stop the currently running sssd process
  2. Start sssd process with some options
  3. Start sssd process with whatever options the service does use

That does not sound quite right. The Chapter 12. Troubleshooting authentication with SSSD in IdM Red Hat Enterprise Linux 8 | Red Hat Customer Portal shows that persistent debug levels are set in sssd.conf and if you want to affect currently running sssd process, then you do it with sssctl:

sudo systemctl restart sssd  # Ensure that service uses persistent config
sudo sssctl debug-level 9    # Change debug-level on the fly

One last point, more prominent with RHEL 9: support for old, weak ciphers (e.g. SHA-1) are being removed. Could that affect the certificates?
With ldapsearch, can you get the hashed password of your account from LDAP? Can you authenticate ldapsearch to server with the TLS “on” (however one does that)?

From the original post

Can you better clarify what you mean by “logins”? Do you mean you are using the GDM graphical user interface, and what error does it give?
From the post above

It’s showing your service started the sub tasks and then stopped them, and it says you have “zero” tasks running, which looks wrong.
In default Rocky 8.6, when logged in locally, you should see three tasks running.

Thank you very much for the useful response. I do recognize that Centos 6 needs to be updated. This is part of that project.

As for the ‘sssd --debug-level=9’ command, I confirmed that this morning, for some reason it does not manipulate the debug level for the current session. But your command with sssctl was able to resolve that.

Unfortunately, I believe we are running into compatibility issues with the old openldap server and the newer sssd and openldap utilities. I have confirmed there is an ssl error in the logs. At this point I will be transitioning to a new openldap SERVER for requests so the versions match.

Thank you everyone for your detailed responses and insight.

OK, but you didn’t answer the post form Jun 30.

When you say a “new openldap server”, I’m guessing this won’t be on Rocky, as it was deprecated?

More details about config and certificates

No, I plan on creating a new Rocky Linux server to by my new LDAP Server.

It is true that package ‘openldap-servers’ is deprecated. However, Rocky 8 still has it in its ‘powertools’ repository.

The powertools repo is based on RHEL 8’s CodeReady Linux Builder repo.
The Chapter 3. The CodeReady Linux Builder repository Red Hat Enterprise Linux 8 | Red Hat Customer Portal writes:

Packages included in the CodeReady Linux Builder repository are unsupported.

That is, no bug fixes are promised for those packages.

The migration from openldap to 389ds server was, IMHO, relatively easy. If one has to set up a new server anyway, then one might as well consider between an unsupported package and a leap to supported LDAP server implementation.

Forgive my ignorance. I have done some research and it looks like going 389ds would be preferable. Thanks again for steering me in a direction I didn’t even know to go.