MD5 authentication against Active Directory with ruby ldap

Ruby
1

Here is the code:

require ‘ldap’
require ‘base64’
require ‘digest/md5’

pass = “{MD5}” + Base64.encode64(Digest::MD5.digest(“secret”) ).chomp

pass=‘secret’

conn = LDAP::Conn.new( ‘dc.domain.com’, 389 )
conn.set_option( LDAP::LDAP_OPT_PROTOCOL_VERSION, 3 )
conn.bind(‘[email protected]’,pass)

The problem is it doesn’t work with MD5 hashed password but it works
with the plain text password (‘secret’). I really appreciate it if
somebody can help me out.

James

2

On 8/22/07, James Y. [email protected] wrote:

pass=‘secret’

James

Posted via http://www.ruby-forum.com/.

This makes sense. LDAP directories store password hashes instead of
passwords to make it impossible for anyone who has access to the
directory’s
datastore (like a programmer, a sysadmin, a backup admin, or a hacker)
to
get enough information to be able to bind.

If you could actually bind using a password hash, then the hashes stored
in
the directory itself would in effect be plaintext, which defeats the
whole
purpose.

3

Thanks Francis, but I am still confused. what you mean we have to use
password in plain text to bind with Active Directory? Because the
password would be saved in a configuration file, which is vulnerable.
I’d like to save the hashed password in the configuration to bind with
AD. I just changed the group policy on AD to allow “store passwords
using reversible encryption” But it still takes the plain text binding
and gives the error to the MD5 hashed password.

Francis C. wrote:

On 8/22/07, James Y. [email protected] wrote:

pass=‘secret’

James

Posted via http://www.ruby-forum.com/.

This makes sense. LDAP directories store password hashes instead of
passwords to make it impossible for anyone who has access to the
directory’s
datastore (like a programmer, a sysadmin, a backup admin, or a hacker)
to
get enough information to be able to bind.

If you could actually bind using a password hash, then the hashes stored
in
the directory itself would in effect be plaintext, which defeats the
whole
purpose.

4

It is still confusing to me. I wonder if it is true that a plaintext
password would be transfered over the network in the case that we use
the plaintext password to bind with AD. If this is correct, there is no
security. I guess there should be an efficient way to work it out.

James

Francis C. wrote:

On 8/22/07, James Y. [email protected] wrote:

Thanks Francis, but I am still confused. what you mean we have to use
password in plain text to bind with Active Directory? Because the
password would be saved in a configuration file, which is vulnerable.
I’d like to save the hashed password in the configuration to bind with
AD. I just changed the group policy on AD to allow “store passwords
using reversible encryption” But it still takes the plain text binding
and gives the error to the MD5 hashed password.

If you saved a password-hash in a configuration file, and it were
possible
to bind with the password-hash, then the hash is in effect plaintext.
You’re
not adding any security by using a hash in that circumstance. This is a
difficult problem. If you’re trying to enable an automatic login without
any
kind of authentication transaction involving a challenge, then somewhere
along the way you will have a sensitive resource that you have to
protect as
best you can.

5

On 8/22/07, James Y. [email protected] wrote:

Thanks Francis, but I am still confused. what you mean we have to use
password in plain text to bind with Active Directory? Because the
password would be saved in a configuration file, which is vulnerable.
I’d like to save the hashed password in the configuration to bind with
AD. I just changed the group policy on AD to allow “store passwords
using reversible encryption” But it still takes the plain text binding
and gives the error to the MD5 hashed password.

If you saved a password-hash in a configuration file, and it were
possible
to bind with the password-hash, then the hash is in effect plaintext.
You’re
not adding any security by using a hash in that circumstance. This is a
difficult problem. If you’re trying to enable an automatic login without
any
kind of authentication transaction involving a challenge, then somewhere
along the way you will have a sensitive resource that you have to
protect as
best you can.

6

On 8/22/07, James Y. [email protected] wrote:

It is still confusing to me. I wonder if it is true that a plaintext
password would be transfered over the network in the case that we use
the plaintext password to bind with AD. If this is correct, there is no
security. I guess there should be an efficient way to work it out.

Yes, the plaintext psw is transferred over the network, whether the
plaintext is some readable passphrase or an MD5 (or other) hash. Use
encryption for the network connection.

7

Thanks. next question is how to encrypt the network connection with AD
for binding process. Here is the result for ldapsearch.

ldapsearch -h AD -p 389 -x -b “” -s base -LLL supportedSASLMechanisms
dn:
supportedSASLMechanisms: GSSAPI
supportedSASLMechanisms: GSS-SPNEGO
supportedSASLMechanisms: EXTERNAL
supportedSASLMechanisms: DIGEST-MD5

Francis C. wrote:

On 8/22/07, James Y. [email protected] wrote:

It is still confusing to me. I wonder if it is true that a plaintext
password would be transfered over the network in the case that we use
the plaintext password to bind with AD. If this is correct, there is no
security. I guess there should be an efficient way to work it out.

Yes, the plaintext psw is transferred over the network, whether the
plaintext is some readable passphrase or an MD5 (or other) hash. Use
encryption for the network connection.

8

On 8/23/07, James Y. [email protected] wrote:

Thanks. next question is how to encrypt the network connection with AD
for binding process. Here is the result for ldapsearch.

Ask your A/D admin what encryption options are available on that A/D.
Sometimes there is no encryption because Windows domain logins use a
derivative of Kerberos which Microsoft advertises to be secure.

If you use ldapsearch, the man pages will tell you how to dial
encryption
into the client. For Ruby clients, Net::LDAP definitely supports TLS
encryption. I’m 99% sure that ruby/ldap does as well.