directory-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ezsra McDonald <ezsra.mcdon...@gmail.com>
Subject Re: ADS returns password expired when wrong password provided
Date Mon, 04 Apr 2016 14:06:47 GMT
Thanks for your response.

We are running ADS M20. I assume it is functioning the same as M21?

--Ezsra

On Sat, Apr 2, 2016 at 12:42 PM, Emmanuel Lécharny <elecharny@gmail.com>
wrote:

> Le 31/03/16 20:21, Ezsra McDonald a écrit :
> > We have ApacheDS configured to expire passwords after a fixed amount of
> > time. If a user lets their password expire and that user attempts to
> > authenticate with an *invalid* password, ADS will respond with an error
> > code related to their password being expired rather than a response
> stating
> > their password entry was invalid.
>
> First of all, which version of ApacheDS are you using ?
>
> Now, with the latest version (2.0.0-M21), when you try to bind with a
> correct or incorrect password when the correct password has expired, you
> get this response :
>
>
> Correct Password, expired :
> ---------------------------
> MessageType : BIND_RESPONSE
> Message ID : 2
>     BindResponse
>         Ldap Result
>             Result code : (INVALID_CREDENTIALS) invalidCredentials
>             Matched Dn : ''
>             Diagnostic message : 'INVALID_CREDENTIALS: Bind failed:
> password expired'
>
> Incorrect Password, expired :
> -----------------------------
> MessageType : BIND_RESPONSE
> Message ID : 2
>     BindResponse
>         Ldap Result
>             Result code : (INVALID_CREDENTIALS) invalidCredentials
>             Matched Dn : ''
>             Diagnostic message : 'INVALID_CREDENTIALS: Bind failed:
> ERR_229 Cannot authenticate user cn=userExpireWarningToo,ou=system'
>
>
> The diagnostic message is different, but it's hard to use it. You still
> can determinate in which case you are, if you add the PasswordPolicy
> control to your BindRequest, because then you will get back the reason
> why the bind was rejected :
>
>
>
> Correct Password, expired, with PasswordPolicy control :
> --------------------------------------------------------
> MessageType : BIND_RESPONSE
> Message ID : 2
>     BindResponse
>         Ldap Result
>             Result code : (INVALID_CREDENTIALS) invalidCredentials
>             Matched Dn : ''
>             Diagnostic message : 'INVALID_CREDENTIALS: Bind failed:
> password expired'
>     PasswordPolicy[criticality:false] PasswordPolicyResponse
> [timeBeforeExpiration=-1, graceAuthNRemaining=-1,
> ppolicyError=PASSWORD_EXPIRED]
>
>
> Incorrect Password, expired, with PasswordPolicy control :
> ----------------------------------------------------------
> MessageType : BIND_RESPONSE
> Message ID : 2
>     BindResponse
>         Ldap Result
>             Result code : (INVALID_CREDENTIALS) invalidCredentials
>             Matched Dn : ''
>             Diagnostic message : 'INVALID_CREDENTIALS: Bind failed:
> ERR_229 Cannot authenticate user cn=userExpireWarningToo,ou=system'
>
>
> As you can see, in the second case, you will get no PasswordPolicy
> response control in the result.
>
> >
> > This is not the desired behavior for a couple of reasons. First, it is
> > confusing our users because they assume that if our SSO portal tells them
> > their password has expired, that they did enter the correct existing
> > password. So when they get sent to our password change screen, they will
> > enter the invalid existing password that they used initially, thinking it
> > was correct.
> It's up to you to send the PasswordPolicy control and return a message
> to the user based on the response you get.
>
> >
> > The other issue is a matter of security. It is possible for anyone to
> > determine if an account is expired just by entering the correct username.
>
> If the password has expired, it's not anymore usable, so it's safe,
> unless your user has picked a password that he/she use somewhere else.
> there is a bit of education to push here...
> Regardless, for an attacker, knowing that an account has expired if of
> little interest.
>
> Or Am I wrong ?
>
> >
> > Are there any suggestions on how to configure ADS to first verify the
> > password is valid before responding with an account expired code.
>
> No, but we can change the result we return. My perception is that the
> base response should not tell the user that the password has expired,
> unless the PasswordPolicy control is explicitely sent. It will be up to
> the user to determinate if he wasn't able to login because his password
> has expired or because he tried with the wrong password.
>
> wdyt ?
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message