LinuxQuestions.org
Help answer threads with 0 replies.
Go Back   LinuxQuestions.org > Forums > Enterprise Linux Forums > Linux - Enterprise
User Name
Password
Linux - Enterprise This forum is for all items relating to using Linux in the Enterprise.

Notices

Reply
 
LinkBack Search this Thread
Old 06-26-2012, 02:06 PM   #1
TomL
LQ Newbie
 
Registered: Dec 2006
Posts: 5

Rep: Reputation: 0
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
 
Old 06-26-2012, 03:03 PM   #2
sgallagh
LQ Newbie
 
Registered: Mar 2011
Posts: 26

Rep: Reputation: 12
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.
 
Old 06-26-2012, 04:21 PM   #3
TomL
LQ Newbie
 
Registered: Dec 2006
Posts: 5

Original Poster
Rep: Reputation: 0
Quote:
Originally Posted by sgallagh View Post
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].
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.

Quote:
Originally Posted by sgallagh View Post
[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).
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.

Quote:
Originally Posted by sgallagh View Post
[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.
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
 
Old 06-27-2012, 06:09 AM   #4
sgallagh
LQ Newbie
 
Registered: Mar 2011
Posts: 26

Rep: Reputation: 12
Quote:
Originally Posted by TomL View Post
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).
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.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
LDAP/SSSD with password policy overlays: possible to completely lock out accounts? btmiller Linux - Server 4 03-26-2013 06:45 AM
CentOS 5.6 DC with LDAP Backend - Cant populate LDAP Totenkopf Linux - Server 4 05-28-2012 10:40 PM
rhel6 sssd ldap for authentication and local files for userNumber (unix uid). mwd Linux - Enterprise 1 08-22-2011 07:14 AM
ldap on Centos joshua777 Linux - Networking 1 10-11-2010 04:33 AM
Compare LDAP password with php crypt password coolamit78 Linux - Networking 1 01-30-2006 05:35 AM


All times are GMT -5. The time now is 08:44 AM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration