You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@directory.apache.org by Kiran Ayyagari <ka...@apache.org> on 2011/10/11 21:23:41 UTC
Re: ApacheDS Password policy issues
On Tue, Oct 11, 2011 at 3:11 PM, <Ca...@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.
>
in both cases if the attribute is absent or if the value is negative
then no limits are enforced on the min/max length of the password
>
>
> 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 ?
>
>
>
> 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.
>
>
>
> 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.
>
>
and for all the above cases, will check and get back to you(we
currently have very limited number of test cases in this area),
thanks for reporting.
> #!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@3d1acad9: 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
Re: ApacheDS Password policy issues
Posted by Kiran Ayyagari <ka...@apache.org>.
On Wed, Oct 12, 2011 at 2:44 PM, <Ca...@ibs-ag.com> wrote:
>>
>> On Tue, Oct 11, 2011 at 3:11 PM, <Ca...@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.
>>>
>> in both cases if the attribute is absent or if the value is negative
>> then no limits are enforced on the min/max length of the password caccorsi - Regarding point #1, by non-zero I meant a positive number. I have 10 in my policy but I can set a password that has a length of 5 without error/exception.
>>>
> did you set the value of ads-pwdcheckquality to 0 or 1?
> caccorsi - ads-pwdcheckquality=1
>
this is the reason why the checks related to length are not enforced
(note that when the value is set to 0 or 1 none of the quality checks
are performed on userPassword attribute)
>>>
>>> 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 ?
>>>
>>>
>>>
>>> 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.
>>>
>>>
>>>
>>> 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.
>>>
>>>
>> and for all the above cases, will check and get back to you(we currently have very limited number of test cases in this area), thanks for reporting.
>>> #!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@3d1a
>>> c
>>> 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
>
--
Kiran Ayyagari
RE: ApacheDS Password policy issues
Posted by Ca...@ibs-ag.com.
>
> On Tue, Oct 11, 2011 at 3:11 PM, <Ca...@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.
>>
> in both cases if the attribute is absent or if the value is negative
> then no limits are enforced on the min/max length of the password caccorsi - Regarding point #1, by non-zero I meant a positive number. I have 10 in my policy but I can set a password that has a length of 5 without error/exception.
>>
did you set the value of ads-pwdcheckquality to 0 or 1?
caccorsi - ads-pwdcheckquality=1
>>
>> 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 ?
>>
>>
>>
>> 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.
>>
>>
>>
>> 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.
>>
>>
> and for all the above cases, will check and get back to you(we currently have very limited number of test cases in this area), thanks for reporting.
>> #!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@3d1a
>> c
>> 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
Re: ApacheDS Password policy issues
Posted by Kiran Ayyagari <ka...@apache.org>.
On Tue, Oct 11, 2011 at 4:38 PM, <Ca...@ibs-ag.com> wrote:
>
> On Tue, Oct 11, 2011 at 3:11 PM, <Ca...@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.
>>
> in both cases if the attribute is absent or if the value is negative then no limits are enforced on the min/max length of the password
> caccorsi - Regarding point #1, by non-zero I meant a positive number. I have 10 in my policy but I can set a password that has a length of 5 without error/exception.
>>
did you set the value of ads-pwdcheckquality to 0 or 1?
>>
>> 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 ?
>>
>>
>>
>> 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.
>>
>>
>>
>> 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.
>>
>>
> and for all the above cases, will check and get back to you(we currently have very limited number of test cases in this area), thanks for reporting.
>> #!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
RE: ApacheDS Password policy issues
Posted by Ca...@ibs-ag.com.
On Tue, Oct 11, 2011 at 3:11 PM, <Ca...@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.
>
in both cases if the attribute is absent or if the value is negative then no limits are enforced on the min/max length of the password
caccorsi - Regarding point #1, by non-zero I meant a positive number. I have 10 in my policy but I can set a password that has a length of 5 without error/exception.
>
>
> 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 ?
>
>
>
> 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.
>
>
>
> 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.
>
>
and for all the above cases, will check and get back to you(we currently have very limited number of test cases in this area), thanks for reporting.
> #!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