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:[email protected]]
Sent: Thursday, November 10, 2011 11:32 AM
To: [email protected]
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, <[email protected]> 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.
>
