directory-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kiran Ayyagari <kayyag...@apache.org>
Subject Re: ApacheDS Password policy issues
Date Thu, 13 Oct 2011 22:14:16 GMT
On Thu, Oct 13, 2011 at 5:45 PM,  <Carlo.Accorsi@ibs-ag.com> wrote:
> Thank you so much. I won't be able to test all you fixed until Monday but I'll let you
know.
>
> I meant to get back to you about the ads-pwcheckquality. When I have it set to 2,  I
get exceptions for length. (ok, thanks)
> We set the userPassword attribute using the code snip below.
>
> String strPassword = "foo";
> MessageDigest oMsgDigest = MessageDigest.getInstance("SHA");
> oMsgDigest.update(strPassword.getBytes());
>  byte[] b = oMsgDigest.digest();
> String strResult = "{SHA}"+getEncodeBase64(b);
>
> When we try and do this (with ads-pwcheckquality=2)
> javax.naming.directory.InvalidAttributeValueException is thrown .." cannot verify the
quality of the non-cleartext passwords"
>
> OK fine. I'd be happy to  just set the clear text value but how does it know the pw
algorithm to store it with? Or does it not matter anymore? Thanks!!
>
there is an interceptor enabled by default for hashing the passwords
using hash method 'SSHA', so clear text passwords will be checked
for ppolicy conformance and hashed before storing into server
>
> -----Original Message-----
> From: ayyagarikiran@gmail.com [mailto:ayyagarikiran@gmail.com] On Behalf Of Kiran Ayyagari
> Sent: Thursday, October 13, 2011 4:17 PM
> To: users@directory.apache.org
> Subject: Re: ApacheDS Password policy issues
>
> On Tue, Oct 11, 2011 at 3:11 PM,  <Carlo.Accorsi@ibs-ag.com> wrote:
>> Hi, I've been working with the password policy functionality this week and have encountered
a few issues I'm hoping you can help clarify.
>>
>> These attributes are on the policy itself unless otherwise specified.
>>
>>
>> 1.       ads-pwdminlength (minimum # of chars require for a password) having a
non-zero value accepts passwords that are any length.
>>
>> a.       I didn't test ads-pwdmaxlength but might check that while you're there.
>>
>>
>>
>> 2.       The value ads-pwmaxage is supposed to be how long a password is valid
(in seconds).
>>
>> a.       Setting this to a non-zero value causes a pwdChangedTime
>> attribute to be set on the user when their password changes (ok)
>>
>> b.      However it never enforces the expiry
>>
>>                                                      
       i.
>> The ads-pwdgraceauthnlimit ( # of grace logins after expiration)
>> doesn't seem to have any effect
>>
>>                                                      
     ii.
>> Also setting  ads-pwdexpirewarning above and below  the max age
>> doesn't seem to matter either
>>
>> c.       If it did expire, how is this indicated on the user object ?
>>
>>
> have fixed this issue. Server indicates the user about expiry by sending the ppolicy
response control after setting the value for timeBeforeExpiration property to the time left
before the password expires.
> Note that this only happens if the user sent a request with ppolicy control (OID - 1.3.6.1.4.1.42.2.27.8.5.1)
>>
>> 3.       When ads-pwdmaxfailure (number of times failed bind is permitted) is
set to 5 , it allows 11 login failures before locking the account.
>>
>> a.       Each login failure creates an additional pwdFailureTime
>> attribute for the user (ok)
>>
>> b.      pwdAccountLockedTime attribute is created after the 11th
>> failed bind. (Also what we want, but after 5 failures)
>>
>> c.       This might be some caching issue because I think once it took 13 failed
attempts before it locked.
>>
>>
> this is a bit strange, do you have some custom caching mechanism in place? OR some custom
authenticator implementation that doesn't inherit the AbstractAuthenticator?
>>
>> 4.       When ads-pwdinhistory (# of old passwords kept so they're not reused)
is set to 5 .
>>
>> a.       Users initially have no pwdHistory attribute (ok)
>>
>> b.      Each of the first 5 password changes happens successfully.
>> Each time adding new pwdHistory attribute to the user. (ok)
>>
>> c.       On the 6th  change, the exception below occurs. It's like it needs to
reuse the first pwdHistory attribute but cannot.
>>
>>
> have fixed this issue, please verify with the latest trunk and let us know.
>> #!RESULT ERROR
>> #!CONNECTION ldap://localhost:10389
>> #!DATE 2011-10-11T14:32:58.205
>> #!ERROR [LDAP: error code 20 - ATTRIBUTE_OR_VALUE_EXISTS: failed for
>> MessageType : MODIFY_REQUEST Message ID : 29     Modify Request
>> Object : 'uid=1286309809116,ou=users,ou=int,o=cpro'
>> Modification[0]                 Operation :  replace
>> Modification     userPassword: '0x7B 0x53 0x48 0x41 0x7D 0x79 0x59
>> 0x53 0x75 0x30 0x42 0x53 0x75 0x78 0x32 0x49 ...'
>> org.apache.directory.shared.ldap.model.message.ModifyRequestImpl@3d1ac
>> ad9: ERR_54 Cannot add a value which is already present : '0x32 0x30
>> 0x31 0x31 0x31 0x30 0x31 0x31 0x31 0x38 0x33 0x32 0x30 0x34 0x5A 0x23
>> ...']
>> dn: uid=1286309809117,ou=users,ou=int,o=cpro
>> changetype: modify
>> replace: userPassword
>>
>> userPassword:: e1NIQX15VVN1MEJTdXgySTZWUEJaSGFCNmhmMUxkaTA9
>>
>>
>>
>>
>> I'll keep testing and thank you in advance!!
>> Carlo Accorsi
>>
>>
>>
>>
>
>
>
> --
> Kiran Ayyagari
>



-- 
Kiran Ayyagari

Mime
View raw message