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.INITIAL_CONTEXT_FACTORY,"com.sun.jndi.ldap.LdapCtxFactory";);
	env.put(Context.PROVIDER_URL,this.strBaseLdapUrl);
	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, "com.my.pwfactory");	
	
	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 [mailto:dfisher@vt.edu] 
Sent: Thursday, November 10, 2011 11:32 AM
To: users@directory.apache.org
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, <Carlo.Accorsi@ibs-ag.com> 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.
>