Specifying LDAP password format for SSSD in CentOS 6.2
 

I'm trying to configure up some CentOS 6.2 systems to use our TLS enabled LDAP servers. I have gotten LDAP authentication set up and users can login on the console and via SSH with no issues.

My problem is that when they change their password, it is being stored as SSHA on the LDAP server. I realize this is because the LDAP server is configured for a default password format of SSHA, but, due to some legacy systems, I can't have the user passwords stored in that format (though I do want other, non-user passwords in SSHA format).

In CentOS 5.x, I could specify the format to use in /etc/pam_ldap.conf (pam_password=md5), but I don't see any way to do this with SSSD. In looking at the source, it appears to only support the LDAP EXOP update. That appears to mean that the LDAP server hashes the password, not the client (and thus the password is being hashed in SSHA).

Am I missing a config option somewhere? So far, I've had to set FORCELEGACY=yes in /etc/sysconfig/authconfig which is essentially disabling SSSD and using the old pam_ldap module. While this is OK for now, at some point, I suspect the legacy will go away and I'll be forced to use SSSD.
I guess the hope is that the legacy systems go away before FORCELEGACY does :)
Thanks
Tom

You are asking the wrong question. The reason SSSD doesn't support setting the password directly is because this is an extremely dangerous security vulnerability[1]. You should never be writing the password directly into LDAP from a client, and the LDAP server should never be configured to allow you to do this.

Also, there's only one reason that it would matter which format the password was hashed in the LDAP server, and that's if you're doing password checks via the NSS 'shadow' map. Basically, it means that your clients must be doing a 'getent shadow <username>' and then locally hashing the entered password and comparing it to the one you got from the server. This is *also* a security vulnerability[2].

The safe way to perform an LDAP authentication (and the way that SSSD does it), is to connect to the LDAP server and bind as the user that is trying to log in. The LDAP server itself will then compare the password internally, without letting the client ever see the hash. If it compares correctly, the bind will succeed. If not, it will return failure. This requires no special knowledge of the hash format on the client, and is therefore backwards-compatible.

Older clients such as CentOS 5.x can be configured this way with pam_ldap. Newer clients do this by default because it is much more secure.


[1] If the SSSD or pam_ldap client has privilege to modify the password directly, then your LDAP server has no ability to enforce complexity requirements or other policies. Furthermore, it means that the client may have the ability to change other users' passwords (depending on the ACIs set on the LDAP server).

[2] Allowing your clients to view the password hashes makes it much easier for an attacker to gain access to the system. They need only collect the hashes and then perform an offline dictionary attack until they find a user with a weak password. With authentication set up as I described above, the LDAP server will disconnect the attacker after a certain number of failed attempts, limiting their ability to find a weakness through brute force.

Welcome to old versions of Solaris :( Yes, they use shadow maps and compare the hash locally, this is probably a hold-over from the days of local accounts and NIS. Getting them to even talk with an LDAP server was an exercise in frustration! Other/newer systems bind to the LDAP server, but older Solaris can only deal with crypt and md5 hashes passwords. Thus the need to make sure that users don't shoot themselves in the foot by changing their password on a newer system and having it be in SSHA format. It's not worth the effort to invest time in ancient Solaris systems, I'm just waiting for them to die.

We don't have other password policies enforced at the LDAP server so that's not an issue. Writing (or accessing in any way) other user's passwords is denied by ACIs.

Via LDAP ACIs, a user can only write their password once they have bound to the directory (thus, they already know their own password). They can not read their password value, nor that of any other users (it's a write/auth only ACI, no read perms).

So, my take away is that there is no hidden configuration that I missed and that disabling SSSD and using FORCELEGACY is my option.
Thanks,
Tom

Well, this cannot be fully true. If the password hashes can be displayed through the shadow map, then it means that at least one user (the one root on the system binds as with nss_ldap) has the ability to read all the hashes (so they are available for authentication with pam_unix).

This means that anyone with root access to any of your machines has trivial access to the password hashes of all of your users. I should note that any system set up this way is likely in violation of compliance laws (such as Sarbanes–Oxley in the USA) which govern how personal information such as passwords must be stored and made available.