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 ]
BASE dc=MYDOMAIN,dc=NET
URI ldap://my.ldapserver.net/
TLS_CACERT /etc/openldap/cacerts/ldap1.pem
TLS_CACERTDIR /etc/openldap/cacerts
TLS_REQCERT allow
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.
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.
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 ~]#
[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:
Stop the currently running sssd process
Start sssd process with some options
Start sssd process with whatever options the service does use
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)?
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.
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.