|
LDAP SASL Authentication using DIGEST MD5 Failing |
|
Subject: LDAP SASL Authentication using DIGEST MD5 Failing
Author: mehta.vikrant
In response to: When and Why DIGEST-MD5 Authentication Does Not Work?
Posted on: 11/15/2012 06:34:14 AM
Hi,
I am new to LDAP with MD5 authentication. I need a client authentication using LDAP with MD5 algorithm. Below is the configuration im using, also tried with combination of usernames mentioned in earlier posts. I am encrypting password from JSP with MD5 algorithm and passing the same to LDAP for authentication. I still get authentication failed with below trace.
User ID :----->USR23210 User Password :----->d18bb9bc4b85449f9cdbe076aacd4a2b provider_url :----->ldap://10.1.20.27 security_authentication :----->DIGEST-MD5 security_principal_default_password :----->notrequired security_principal_search :----->OU=EMPLOYEES,OU=BANK LTD,OU=ADUSERS,DC=bankltd,DC=com security_principal_default_password :----->notrequired security_attribute_for_user :----->sAMAccountName
-> 10.1.20.27:389
0000: 30 18 02 01 01 60 13 02 01 03 04 00 A3 0C 04 0A 0....`.......... 0010: 44 49 47 45 53 54 2D 4D 44 35 DIGEST-MD5
<- 10.1.20.27:389
0000: 30 84 00 00 01 04 02 01 01 61 84 00 00 00 FB 0A 0........a...... 0010: 01 0E 04 00 04 00 87 82 00 F0 71 6F 70 3D 22 61 ..........qop="a 0020: 75 74 68 2C 61 75 74 68 2D 69 6E 74 2C 61 75 74 uth,auth-int,aut 0030: 68 2D 63 6F 6E 66 22 2C 63 69 70 68 65 72 3D 22 h-conf",cipher=" 0040: 33 64 65 73 2C 64 65 73 2C 72 63 34 2D 34 30 2C 3des,des,rc4-40, 0050: 72 63 34 2C 72 63 34 2D 35 36 22 2C 61 6C 67 6F rc4,rc4-56",algo 0060: 72 69 74 68 6D 3D 6D 64 35 2D 73 65 73 73 2C 6E rithm=md5-sess,n 0070: 6F 6E 63 65 3D 22 2B 55 70 67 72 61 64 65 64 2B once="+Upgraded+ 0080: 76 31 65 33 33 30 61 38 64 35 66 39 64 38 38 34 v1e330a8d5f9d884 0090: 65 35 63 35 63 37 34 64 33 35 35 63 63 32 63 64 e5c5c74d355cc2cd 00A0: 30 31 33 63 64 31 39 66 65 37 64 31 65 33 63 64 013cd19fe7d1e3cd 00B0: 34 37 38 38 62 63 36 37 63 34 31 38 61 66 62 33 4788bc67c418afb3 00C0: 38 38 61 35 66 35 33 66 32 65 64 61 65 38 30 32 88a5f53f2edae802 00D0: 64 31 63 34 38 66 32 64 61 66 35 36 34 36 32 31 d1c48f2daf564621 00E0: 35 35 22 2C 63 68 61 72 73 65 74 3D 75 74 66 2D 55",charset=utf- 00F0: 38 2C 72 65 61 6C 6D 3D 22 69 63 69 63 69 62 61 8,realm="bankltd 0100: 6E 6B 6C 74 64 2E 63 6F 6D 22 .com"
-> 10.1.20.27:389
0000: 30 82 01 8D 02 01 02 60 82 01 86 02 01 03 04 00 0......`........ 0010: A3 82 01 7D 04 0A 44 49 47 45 53 54 2D 4D 44 35 ......DIGEST-MD5 0020: 04 82 01 6D 63 68 61 72 73 65 74 3D 75 74 66 2D ...mcharset=utf- 0030: 38 2C 75 73 65 72 6E 61 6D 65 3D 22 42 41 4E 32 8,username="USR2 0040: 33 32 31 30 40 69 63 69 63 69 62 61 6E 6B 6C 74 3210@bankltd.com 0050: 64 2E 63 6F 6D 22 2C 72 65 61 6C 6D 3D 22 69 63 ",realm="iciciba 0060: 69 63 69 62 61 6E 6B 6C 74 64 2E 63 6F 6D 22 2C nkltd.com", 0070: 6E 6F 6E 63 65 3D 22 2B 55 70 67 72 61 64 65 64 nonce="+Upgraded 0080: 2B 76 31 65 33 33 30 61 38 64 35 66 39 64 38 38 +v1e330a8d5f9d88 0090: 34 65 35 63 35 63 37 34 64 33 35 35 63 63 32 63 4e5c5c74d355cc2c 00A0: 64 30 31 33 63 64 31 39 66 65 37 64 31 65 33 63 d013cd19fe7d1e3c 00B0: 64 34 37 38 38 62 63 36 37 63 34 31 38 61 66 62 d4788bc67c418afb 00C0: 33 38 38 61 35 66 35 33 66 32 65 64 61 65 38 30 388a5f53f2edae80 00D0: 32 64 31 63 34 38 66 32 64 61 66 35 36 34 36 32 2d1c48f2daf56462 00E0: 31 35 35 22 2C 6E 63 3D 30 30 30 30 30 30 30 31 155",nc=00000001 00F0: 2C 63 6E 6F 6E 63 65 3D 22 2B 54 7A 6C 6B 75 51 ,cnonce="+TzlkuQ 0100: 33 53 65 63 6D 73 6A 30 41 35 75 52 31 72 46 77 3Secmsj0A5uR1rFw 0110: 6A 53 47 6C 51 4A 7A 69 2F 6F 58 6F 36 70 31 5A jSGlQJzi/oXo6p1Z 0120: 66 22 2C 64 69 67 65 73 74 2D 75 72 69 3D 22 6C f",digest-uri="l 0130: 64 61 70 2F 31 30 2E 30 2E 33 2E 32 37 22 2C 6D dap/10.1.20.27",m 0140: 61 78 62 75 66 3D 36 35 35 33 36 2C 72 65 73 70 axbuf=65536,resp 0150: 6F 6E 73 65 3D 66 61 63 39 35 62 34 35 65 33 62 onse=fac95b45e3b 0160: 33 36 30 65 33 62 38 39 37 33 66 61 39 32 35 35 360e3b8973fa9255 0170: 31 38 36 61 32 2C 71 6F 70 3D 61 75 74 68 2D 63 186a2,qop=auth-c 0180: 6F 6E 66 2C 63 69 70 68 65 72 3D 22 33 64 65 73 onf,cipher="3des 0190: 22 "
<- 10.1.20.27:389
0000: 30 84 00 00 00 65 02 01 02 61 84 00 00 00 5C 0A 0....e...a....\. 0010: 01 31 04 00 04 55 38 30 30 39 30 33 30 43 3A 20 .1...U8009030C: 0020: 4C 64 61 70 45 72 72 3A 20 44 53 49 44 2D 30 43 LdapErr: DSID-0C 0030: 30 39 30 34 33 45 2C 20 63 6F 6D 6D 65 6E 74 3A 09043E, comment: 0040: 20 41 63 63 65 70 74 53 65 63 75 72 69 74 79 43 AcceptSecurityC 0050: 6F 6E 74 65 78 74 20 65 72 72 6F 72 2C 20 64 61 ontext error, da 0060: 74 61 20 30 2C 20 76 65 63 65 00 ta 0, vece.
LDAP: error code 49 - 8009030C: LdapErr: DSID-0C09043E, comment: AcceptSecurityContext error, data 0, vece
Any help would be greatly appreciated.
>
> On 06/30/2006 07:03:52 PM SteveHB wrote:
The Digest-MD5 mechanism is described in RFC 2831. In Digest-MD5, the LDAP server sends data that includes various authentication options that it is willing to support plus a special token to the LDAP client. The client responds by sending an encrypted response that indicates the authentication options that it has selected. The response is encrypted in such a way that proves that the client knows its password. The LDAP server then verifies the client's response.
As it can be seen, the major advantages of DIGEST-MD5 are: 1) prevent user password being sent across the Internet via clear text; 2) provide message integrity and confidentiality protection, after authentication
Apparently, the disadvantages are not trivial: Digest authentication requires that the authenticating agent (usually the server) store some data derived from the user's password in certain forms to be able to retrieve the value of:
H({ username-value,":", realm-value, ":", passwd }).
without directly exposing the user's password. This is the source of why DIGEST-MD5 does not work for a lot of cases. (discussed later)
The following example shows how a client performs authentication using Digest-MD5 to an LDAP server.
/**
*
* SaslDigestMD5JndiClient.java
* Sample code to explore how and when DIGEST-MD5 authentication works.
*
*/
import java.util.Hashtable;
import javax.naming.directory.*;
import javax.naming.*;
public class SaslDigestMD5JndiClient
{
public static void main (String[] args)
{
String bind_dn = "testuser";
String bind_password = "secret";
String init_url = "ldap://myserver.mydomain.com:389";
Hashtable env = new Hashtable();
env.put(Context.INITIAL_CONTEXT_FACTORY,"com.sun.jndi.ldap.LdapCtxFactory");
env.put(Context.PROVIDER_URL, init_url);
// Set the authentication mechanism to be DIGEST-MD5
env.put(Context.SECURITY_AUTHENTICATION, "DIGEST-MD5");
env.put(Context.SECURITY_PRINCIPAL, bind_dn);
env.put(Context.SECURITY_CREDENTIALS, bind_password);
/*
* other environment properties are:
* javax.security.sasl.qop:
* specifies list of qops: "auth", "auth-int", "auth-conf"
* auth -- authentication only;
* auth-int -- authentication & subsequent message's integrity check
* auth-conf -- authentication & subsequent message's
* confidentiality enforcement
* default is "auth"
* env.put("javax.security.sasl.qop", "auth");
* javax.security.sasl.strength
* specifies low/medium/high strength of encryption;
* default is all available ciphers [high,medium,low];
* high means des3 or rc4 (128); medium des or rc4-56; low is rc4-40.
* env.put("javax.security.sasl.strength","high");
* javax.security.sasl.maxbuf
* specifies max receive buf size; default is 65536
* javax.security.sasl.sendmaxbuffer
* specifies max send buf size; default is 65536
*/
DirContext ctx = null;
try {
// Create the initial directory context
ctx = new InitialDirContext(env);
} catch (Exception e) {
System.err.println("Authentication failed: " + e);
}
try{
// Create the search controls
SearchControls searchCtls = new SearchControls();
//Specify the attributes to return
String returnedAtts[]={"sn","givenName","mail"};
searchCtls.setReturningAttributes(returnedAtts);
//Specify the search scope
searchCtls.setSearchScope(SearchControls.SUBTREE_SCOPE);
//specify the LDAP search filter
String searchFilter = "(&(objectClass=user)(mail=*))";
//Specify the Base for the search
String searchBase = "dc=mydomain,dc=com";
// Search for objects using the filter
NamingEnumeration results = ctx.search(searchBase,searchFilter,searchCtls);
//Loop through the search results
while (results.hasMoreElements()) {
SearchResult sr = (SearchResult)results.next();
System.out.println("dn: " + sr.getName());
Attributes attrs = sr.getAttributes();
System.out.println("attributes: " + attrs);
}
ctx.close();
} catch (NamingException e) {
System.err.println("Searching failed: " + e);
}
}
}
The above code has been testet against SunONE and Active Directory, testing scenarios will be discussed in very details but the failed outputs are very much the same like:
javax.naming.AuthenticationException: [LDAP: error code 49 - 8009030C: LdapErr: DSID-0C09043E, comment: AcceptSecurityContext error, data 0, vece at com.sun.jndi.ldap.LdapCtx.mapErrorCode(LdapCtx.java:2988) at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2934) at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2735) at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2649) at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:290) at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:175) at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:193) at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:136) at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:66) at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:662) at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:243) at javax.naming.InitialContext.init(InitialContext.java:219) at javax.naming.InitialContext.<init>(InitialContext.java:195) at javax.naming.directory.InitialDirContext.<init>(InitialDirContext.java:80)
References:
|
|
|
|