directory-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <>
Subject RE: ApacheDS differentiating Authentication Exceptions
Date Thu, 10 Nov 2011 18:10:42 GMT
Hi Thanks for the suggestion.. I looked at .reconnect(Control[])  but my LdapContext  both
cases I mention is null.  

This is how I'm attempting to log in a user

	Hashtable env=new Hashtable();
	env.put(Context.SECURITY_PRINCIPAL,strDn); // user trying to login (DN here)
	env.put(Context.SECURITY_CREDENTIALS,strPass); // incorrect password
	env.put(Context.SECURITY_AUTHENTICATION, "simple");
	env.put(LdapContext.CONTROL_FACTORIES, "");	
	LdapContext ctx = new InitialLdapContext(env,ctrls);

When the authentication exception is thrown,  ctx is null so there are no response controls
to be had.
Is there a more accepted way to validate users? I don't allow anonymous binds. Thanks. 

-----Original Message-----
From: Daniel Fisher [] 
Sent: Thursday, November 10, 2011 11:32 AM
Subject: Re: ApacheDS differentiating Authentication Exceptions

Try performing your bind with LdapContext#reconnect instead, the response controls should
be available to you then.
(At least that works with OpenLDAP.)

--Daniel Fisher

On Thu, Nov 10, 2011 at 10:55 AM, <> wrote:

> Hi, Another question around failed login attempts.
> We bind like this. With the env containing the user, pass and all 
> other props.
> LdapContext ctx = new InitialLdapContext(env,ctrls);
> When the user supplies either an incorrect password or the account is 
> locked, a javax.naming.AuthenticationException is thrown.
> And the resulting ctx is null, so there are no Response Controls 
> available in these cases.
> In both failure modes the stack traces are identical except for the 
> value of ex.getMessage().
> [LDAP: error code 49 - INVALID_CREDENTIALS: Bind failed: ERR_229 
> Cannot authenticate user uid=xyz,o=corp]
> [LDAP: error code 49 - INVALID_CREDENTIALS: Bind failed: account was 
> permanently locked]
> Other than comparing the strings above, is there another way to 
> determine which event occurred?
> We're running 2.0.0-M4-SNAPSHOT from the trunk.
> Thank you.

View raw message