| |
Scenarios Where DIGEST-MD5 Works or NOT Work -- Active Directory 2003 |
|
|
Subject: Scenarios Where DIGEST-MD5 Works or NOT Work -- Active Directory 2003
Author: SteveHB
In response to: Scenarios Where DIGEST-MD5 Works or NOT Work -- Active Directory 2000
Posted on: 07/27/2006 01:39:38 PM
Basic Settings
---------------
Server: AD 2003
Client: JNDI application
User: cn=testuser,cn=users,dc=mydomain,dc=com
Realm: MYREALM
Passwd: (password stored in hash format)
The following settings works
env.put(Context.SECURITY_AUTHENTICATION, "DIGEST-MD5");
env.put(Context.SECURITY_PRINCIPAL, "testuser");
The following settings dose NOT works
env.put(Context.SECURITY_AUTHENTICATION, "DIGEST-MD5");
env.put(Context.SECURITY_PRINCIPAL, "MYREAM\\testuser");
The following settings dose NOT works
env.put(Context.SECURITY_AUTHENTICATION, "DIGEST-MD5");
env.put(Context.SECURITY_PRINCIPAL, "testuser@mydomain.com");
: Microsoft has noticed the serious security risk to store password in reversible encryption as required by AD 2000. For this reason, AD 2003 comes with a 'better' solution -- Advanced Digest Mechanism, which stores user credentials as an MD5 hash . Advanced Digest authentication does not require that credentials are stored using reversible encryption. Instead, Advanced Digest authentication stores a few precalculated hashes in Active Directory, so user passwords cannot feasibly be discovered by anyone with access to the domain controller, including the domain administrator.
As an MD5 hash contains a user name, password, and the name of the realm, specified in RFC as H( { username-value, ":", realm-value, ":", passwd } ), if server stores this kind of hashed info rather than the reversible one, server has very limited flexibility to calculate client's hash for comparison. That's why the minor variation of usename, "MYREAM\\testuser" or "testuser@mydomain.com" would fail (remembering they are working for AD 2000). That sucks in terms of flexibility on client side.
>
> On 06/30/2006 08:21:28 PM SteveHB wrote:
Basic Settings
---------------
Server: AD 2000
Client: JNDI application
User: cn=testuser,cn=users,dc=mydomain,dc=com
Realm: MYREALM
Passwd: secret *[see note below]
The following settings works
env.put(Context.SECURITY_AUTHENTICATION, "DIGEST-MD5");
env.put(Context.SECURITY_PRINCIPAL, "testuser");
The following settings works
env.put(Context.SECURITY_AUTHENTICATION, "DIGEST-MD5");
env.put(Context.SECURITY_PRINCIPAL, "MYREAM\\testuser");
The following settings works
env.put(Context.SECURITY_AUTHENTICATION, "DIGEST-MD5");
env.put(Context.SECURITY_PRINCIPAL, "testuser@mydomain.com");
The following settings works
env.put(Context.SECURITY_AUTHENTICATION, "DIGEST-MD5");
env.put(Context.SECURITY_PRINCIPAL, "testuser@mydomain.com");
env.put("javax.security.sasl.qop", "auth-conf");
The following settings dose NOT work
env.put(Context.SECURITY_AUTHENTICATION, "DIGEST-MD5");
env.put(Context.SECURITY_PRINCIPAL,
"cn=testuser,cn=users,dc=mydomain,dc=com");
The following settings dose NOT work
env.put(Context.SECURITY_AUTHENTICATION, "DIGEST-MD5");
env.put(Context.SECURITY_PRINCIPAL, "u:testuser");
The following settings dose NOT work
env.put(Context.SECURITY_AUTHENTICATION, "DIGEST-MD5");
env.put(Context.SECURITY_PRINCIPAL,
"dn:cn=testuser,cn=users,dc=mydomain,dc=com");
Conclusions:
For DIGEST-MD5 to work on AD 2000, client's password must be stored using reversible encryption so that the authentication agent (AD) can retrieve the password in clear text and then calculate the hash H(). Compared to SunOne, AD 2000 is doing much better, but still faces the important security consequence.
Active Directory supports message integrity and confidentiality protection, as suggested in RFC 2831.
Active Directory does not support distinguished name.
Active Directory does not support the 'u:' or 'dn:' notation, as described in Sun.
References:
|
|
|
|
