Hashed password in LDAP - OKTA settings to authenticate Skip to main content
How satisfied are you with the Okta Help Center?
Thank you for your feedback!
How satisfied are you with the Okta Help Center?
Very Dissatisfied
Very satisfied
Enter content less than 200 characters.
Ask Search:
Niall McLoughlinNiall McLoughlin 

Hashed password in LDAP - OKTA settings to authenticate


New OKTA account, and I've setup the LDAP agent on my on premise LDAP. If the LDAP stores the password in the password attribute in clear text, I can authenticate with OKTA. If I use any option to hash the LDAP password, authentication no longer works, which is as I would expect. The bind to LDAP is done with the password in the clear, which won't match the hashed LDAP password.

So is the only option with the LDAP agent for the password to be stored in clear text in LDAP ? That isn't going to work.
Madhu Mahadevan - SEMadhu Mahadevan - SE (Okta, Inc.)
Okta submits the username+password to the LDAP Server via LDAP Agent.  It is upto the LDAP server (regardless of whatever hashing mechanism it uses to store the password) to validate the submitted credentials.  I suspect that there is something else at work here.  Certainly storing passwords in clear text would be a huge security risk and we would not recommend it in a production setting.
Niall McLoughlinNiall McLoughlin
Hi Madhu

I still haven't been able to resolve this. If use any form of hash on the password, the LDAP server should no longer know what the clear text password value is. A hash is one way only. It doesn't get "decrypted" back into a plain text string, so it isn't up to the LDAP server to validate the submitted credentials.

The only way I can see this working is if the LDAP agent can be configured with a set of hashing algoritms and the administrator picks the appropriate alg. for the ldap server that is persisting the credentials. The LDAP agent then recieves the credentials ( over SSL ) during the authentication request, and the agent hashes the plain text password it recieves before performing a BIND against the LDAP server.

However, that's not documented anywhere or in any of the configuration settings for the LDAP agent.
Organization AdminOrganization Admin
When you say you are using a form of Hashing is that you have a 3rd party system hashing the password prior to it getting to the LDAP server or are you saying that you are sending the clear text password to the LDAP server and then after it receives the password in clear text the LDAP server is hashing it?

The Okta agent attempts to do a simple bind to the LDAP server just as you would with any LDAP browswer. Then the LDAP server will Hash that value appropriate for the configuration of the LDAP server and compare the new password hash (attempted password) with the existing password hash (actual password) and respond appropriately based on what was sent to the LDAP server.

If you are hashing the password and then sending that hashed password to the LDAP server the password will be double hashed and you would have to know what that hash value is to be able to authenticate with the LDAP Agent.

If you are worried about the data going over your network in clear text then I would recomend looking into enabling LDAPS for the flavor of LDAP directory you are using.