You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@directory.apache.org by Ca...@ibs-ag.com on 2011/10/11 21:11:13 UTC
ApacheDS Password policy issues
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 ?
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.
#!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
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
Re: ApacheDS Password policy issues
Posted by Kiran Ayyagari <ka...@apache.org>.
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 Ca...@ibs-ag.com.
Hi, yes I definitely have that extra control set because the class was refactored.
2.00-M3 class name in wrapper.conf
org.apache.directory.shared.ldap.extras.controls.ppolicy.PasswordPolicyFactory
2.00-M4 class name in wrapper.conf
org.apache.directory.shared.ldap.extras.controls.ppolicy_impl.PasswordPolicyFactory
I know there's a lot in the message but is my logic / approach correct? It seems like it should be working but I'm at a loss.
-----Original Message-----
From: ayyagarikiran@gmail.com [mailto:ayyagarikiran@gmail.com] On Behalf Of Kiran Ayyagari
Sent: Thursday, November 10, 2011 11:00 AM
To: users@directory.apache.org
Subject: Re: ApacheDS Password policy issues
make sure that the system property EXT_CTRLS is set before starting the server (use System.setProperty() if running in embedded mode)
EXT_CTRLS="-Dextra.controls=org.apache.directory.shared.ldap.extras.controls.ppolicy_impl.PasswordPolicyFactory"
for a list of other properties and additional control factories take a look at this script [1]
[1] http://svn.apache.org/repos/asf/directory/apacheds/trunk/service/apacheds.sh
On Thu, Nov 10, 2011 at 10:23 AM, <Ca...@ibs-ag.com> wrote:
> Hi, my fault for the delay responding.. I'm running 2.0.0-M4-SNAPSHOT off the trunk.
>
> I'm trying to capture response controls in 2 cases and I cannot get either to work.
>
> a.) When I update the userPassword attribute and policy requirements
> are not met
> b.) When the user logs in and policy threshold is exceeded. Expiry, history, lockout, etc.
>
> In both cases either the response controls are null or the response control returned has no data. Details below.
>
> I have created password request and response control classes that
> implement javax.naming.ldap.Control The interface method getId() returns "1.3.6.1.4.1.42.2.27.8.5.1" which is a static member named OID.
> The policy response class extends the request class.
>
> I have a ControlFactory Class which implements javax.naming.ldap.ControlFactory and is added to my environment like this.
>
> env.put(LdapContext.CONTROL_FACTORIES,"com.my.MyControlFactory");
>
> The interface method below in my control factory only tests for data.
>
> public Control getControlInstance(Control ctl) {
> Control result = null;
> if (ctl.getID().equals(ControlPasswordPolicyResponse.OID)) {
> if (ctl.getEncodedValue() == null) {
> System.out.println("No data in response
> control");
> }
> }
> return result;
> }
>
> For example, when I try and update a password (that's in the history)
> the following exception is thrown but the response controls are null
>
> javax.naming.directory.InvalidAttributeValueException: [LDAP: error
> code 19 - CONSTRAINT_VIOLATION: failed for MessageType :
> MODIFY_REQUEST Message ID : 2
> Modify Request
> Object : 'uid=1320256180937,ou=users,ou=int,o=cpro'
> Modification[0]
> Operation : replace
> Modification
> userPassword: '0x31 0x32 0x33 0x34 0x35 0x36 '
> org.apache.directory.shared.ldap.model.message.ModifyRequestImpl@b6209
> aee ManageDsaITImpl Control
> Type OID : '2.16.840.1.113730.3.4.2'
> Criticality : 'false'
> '
> : invalid reuse of password present in password history]; remaining name 'uid=1320256180937,ou=users,ou=int,o=cpro'
>
> Again if the supplied password is too short, I get the exception but
> the response controls are null
>
> javax.naming.directory.InvalidAttributeValueException: [LDAP: error
> code 19 - CONSTRAINT_VIOLATION: failed for MessageType :
> MODIFY_REQUEST Message ID : 2
> Modify Request
> Object : 'uid=1320878789594,ou=users,ou=ext,o=cpro'
> Modification[0]
> Operation : replace
> Modification
> userPassword: '0x31 '
> org.apache.directory.shared.ldap.model.message.ModifyRequestImpl@67f20
> 66a ManageDsaITImpl Control
> Type OID : '2.16.840.1.113730.3.4.2'
> Criticality : 'false'
> '
> : Password should have a minmum of 3 characters]; remaining name 'uid=1320878789594,ou=users,ou=ext,o=cpro'
>
> The OID in these exceptions is a Netscape V3 control
> http://www.alvestrand.no/objectid/2.16.840.1.113730.3.4.html
>
>
> Finally when the policy is set to expire after 30 seconds
> (ads-pwdmaxage=30) and the user's password is older than this, a response Control is returned, but is getEncodedData() is null. This same thing happens when policy conditions are met and the login is successful.
>
> Thanks for your help. Carlo
>
>
>
> -----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, <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.
>>
>>
>>
>> 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@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>.
make sure that the system property EXT_CTRLS is set before starting the server
(use System.setProperty() if running in embedded mode)
EXT_CTRLS="-Dextra.controls=org.apache.directory.shared.ldap.extras.controls.ppolicy_impl.PasswordPolicyFactory"
for a list of other properties and additional control factories take a
look at this script [1]
[1] http://svn.apache.org/repos/asf/directory/apacheds/trunk/service/apacheds.sh
On Thu, Nov 10, 2011 at 10:23 AM, <Ca...@ibs-ag.com> wrote:
> Hi, my fault for the delay responding.. I'm running 2.0.0-M4-SNAPSHOT off the trunk.
>
> I'm trying to capture response controls in 2 cases and I cannot get either to work.
>
> a.) When I update the userPassword attribute and policy requirements are not met
> b.) When the user logs in and policy threshold is exceeded. Expiry, history, lockout, etc.
>
> In both cases either the response controls are null or the response control returned has no data. Details below.
>
> I have created password request and response control classes that implement javax.naming.ldap.Control
> The interface method getId() returns "1.3.6.1.4.1.42.2.27.8.5.1" which is a static member named OID.
> The policy response class extends the request class.
>
> I have a ControlFactory Class which implements javax.naming.ldap.ControlFactory and is added to my environment like this.
>
> env.put(LdapContext.CONTROL_FACTORIES,"com.my.MyControlFactory");
>
> The interface method below in my control factory only tests for data.
>
> public Control getControlInstance(Control ctl) {
> Control result = null;
> if (ctl.getID().equals(ControlPasswordPolicyResponse.OID)) {
> if (ctl.getEncodedValue() == null) {
> System.out.println("No data in response control");
> }
> }
> return result;
> }
>
> For example, when I try and update a password (that's in the history) the following exception is thrown but the response controls are null
>
> javax.naming.directory.InvalidAttributeValueException: [LDAP: error code 19 - CONSTRAINT_VIOLATION: failed for MessageType : MODIFY_REQUEST
> Message ID : 2
> Modify Request
> Object : 'uid=1320256180937,ou=users,ou=int,o=cpro'
> Modification[0]
> Operation : replace
> Modification
> userPassword: '0x31 0x32 0x33 0x34 0x35 0x36 '
> org.apache.directory.shared.ldap.model.message.ModifyRequestImpl@b6209aee ManageDsaITImpl Control
> Type OID : '2.16.840.1.113730.3.4.2'
> Criticality : 'false'
> '
> : invalid reuse of password present in password history]; remaining name 'uid=1320256180937,ou=users,ou=int,o=cpro'
>
> Again if the supplied password is too short, I get the exception but the response controls are null
>
> javax.naming.directory.InvalidAttributeValueException: [LDAP: error code 19 - CONSTRAINT_VIOLATION: failed for MessageType : MODIFY_REQUEST
> Message ID : 2
> Modify Request
> Object : 'uid=1320878789594,ou=users,ou=ext,o=cpro'
> Modification[0]
> Operation : replace
> Modification
> userPassword: '0x31 '
> org.apache.directory.shared.ldap.model.message.ModifyRequestImpl@67f2066a ManageDsaITImpl Control
> Type OID : '2.16.840.1.113730.3.4.2'
> Criticality : 'false'
> '
> : Password should have a minmum of 3 characters]; remaining name 'uid=1320878789594,ou=users,ou=ext,o=cpro'
>
> The OID in these exceptions is a Netscape V3 control
> http://www.alvestrand.no/objectid/2.16.840.1.113730.3.4.html
>
>
> Finally when the policy is set to expire after 30 seconds (ads-pwdmaxage=30) and the user's password is older than this, a response
> Control is returned, but is getEncodedData() is null. This same thing happens when policy conditions are met and the login is successful.
>
> Thanks for your help. Carlo
>
>
>
> -----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, <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.
>>
>>
>>
>> 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
RE: ApacheDS Password policy issues
Posted by Ca...@ibs-ag.com.
Hi, my fault for the delay responding.. I'm running 2.0.0-M4-SNAPSHOT off the trunk.
I'm trying to capture response controls in 2 cases and I cannot get either to work.
a.) When I update the userPassword attribute and policy requirements are not met
b.) When the user logs in and policy threshold is exceeded. Expiry, history, lockout, etc.
In both cases either the response controls are null or the response control returned has no data. Details below.
I have created password request and response control classes that implement javax.naming.ldap.Control
The interface method getId() returns "1.3.6.1.4.1.42.2.27.8.5.1" which is a static member named OID.
The policy response class extends the request class.
I have a ControlFactory Class which implements javax.naming.ldap.ControlFactory and is added to my environment like this.
env.put(LdapContext.CONTROL_FACTORIES,"com.my.MyControlFactory");
The interface method below in my control factory only tests for data.
public Control getControlInstance(Control ctl) {
Control result = null;
if (ctl.getID().equals(ControlPasswordPolicyResponse.OID)) {
if (ctl.getEncodedValue() == null) {
System.out.println("No data in response control");
}
}
return result;
}
For example, when I try and update a password (that's in the history) the following exception is thrown but the response controls are null
javax.naming.directory.InvalidAttributeValueException: [LDAP: error code 19 - CONSTRAINT_VIOLATION: failed for MessageType : MODIFY_REQUEST
Message ID : 2
Modify Request
Object : 'uid=1320256180937,ou=users,ou=int,o=cpro'
Modification[0]
Operation : replace
Modification
userPassword: '0x31 0x32 0x33 0x34 0x35 0x36 '
org.apache.directory.shared.ldap.model.message.ModifyRequestImpl@b6209aee ManageDsaITImpl Control
Type OID : '2.16.840.1.113730.3.4.2'
Criticality : 'false'
'
: invalid reuse of password present in password history]; remaining name 'uid=1320256180937,ou=users,ou=int,o=cpro'
Again if the supplied password is too short, I get the exception but the response controls are null
javax.naming.directory.InvalidAttributeValueException: [LDAP: error code 19 - CONSTRAINT_VIOLATION: failed for MessageType : MODIFY_REQUEST
Message ID : 2
Modify Request
Object : 'uid=1320878789594,ou=users,ou=ext,o=cpro'
Modification[0]
Operation : replace
Modification
userPassword: '0x31 '
org.apache.directory.shared.ldap.model.message.ModifyRequestImpl@67f2066a ManageDsaITImpl Control
Type OID : '2.16.840.1.113730.3.4.2'
Criticality : 'false'
'
: Password should have a minmum of 3 characters]; remaining name 'uid=1320878789594,ou=users,ou=ext,o=cpro'
The OID in these exceptions is a Netscape V3 control
http://www.alvestrand.no/objectid/2.16.840.1.113730.3.4.html
Finally when the policy is set to expire after 30 seconds (ads-pwdmaxage=30) and the user's password is older than this, a response
Control is returned, but is getEncodedData() is null. This same thing happens when policy conditions are met and the login is successful.
Thanks for your help. Carlo
-----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, <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.
>
>
>
> 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
Re: ApacheDS Password policy issues
Posted by Kiran Ayyagari <ka...@apache.org>.
On Thu, Oct 13, 2011 at 5:45 PM, <Ca...@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, <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.
>>
>>
>>
>> 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
RE: ApacheDS Password policy issues
Posted by Ca...@ibs-ag.com.
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!!
-----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, <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.
>
>
>
> 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
Re: ApacheDS Password policy issues
Posted by Kiran Ayyagari <ka...@apache.org>.
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.
>
>
>
> 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@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