Re: Password Policy Enforced for admin user
Bug created: https://issues.apache.org/jira/browse/DIRSERVER-2067 Will this bug be fixed in the next release?
Re: Password Policy Enforced for admin user
can you file a bug, I will take a look. thank you Bug created: https://issues.apache.org/jira/browse/DIRSERVER-2067
Re: Password Policy Enforced for admin user
David Paulsen dave.paulsen@... writes: Kiran Ayyagari kayyagari at ... writes: On Fri, May 29, 2015 at 2:13 AM, David Paulsen dave.paulsen at ... wrote: I'm running in to a strange issue. I have two separate servers running the official 2.0.0-M20 release. In one instance I can change the password to anything I want (including the same password) when I bind to the connection using the built in admin user (dn=uid=admin,ou=system). In another instance running the same version of the 2.0.0-M20 release, that exact same operation (again bound as admin user) results in the following error: invalid reuse of password present in password history you sure that this is happening during bind? this check is performed only while updating the password of a user (excluding admin user) It should never enforce the password policy for the admin user, correct? Any idea what could be causing it to enforce the policy in one M20 instance and not the other? Thanks! Hi Kiran... Right. It didn't happen during bind, it happened when I tried to update the password to the same value after binding as the dn=uid=admin,ou=system user. I found a way to recreate this problem. I believe the issue is that when bound to a connection using the uid=admin,ou=system user, it enforces the ads-pwdInHistory in the password policy of the uid I'm changing the password for. For example, if I'm changing the password for uid=147547,ou=8300,ou=DVHead,dc=kewilltransport,dc=com, and that uid has a pwdPolicySubentry=ads-pwdId=DVHead8300,ou=passwordPolicies,ads- interceptorId=authenticationInterceptor,ou=interceptors,ads- directoryServiceId=default,ou=config, it enforces the ads- pwdId=DVHead8300 policy's ads-pwdInHistory setting even with the admin user. My understanding is that since it's the admin user, it should not be enforcing any password policy rules. Steps: (1) Create a password policy where the ads-pwdInHistory is greater than 0 so it enforces not reusing passwords. (2) Create a uid and set it's pwdPolicySubentry to the above password policy. (3) Create a connection and bind to it using the uid=admin,ou=system user, and then modify password for the above uid. You will get this error: error: invalid reuse of password present in password history
Password Policy Enforced for admin user
I'm running in to a strange issue. I have two separate servers running the official 2.0.0-M20 release. In one instance I can change the password to anything I want (including the same password) when I bind to the connection using the built in admin user (dn=uid=admin,ou=system). In another instance running the same version of the 2.0.0-M20 release, that exact same operation (again bound as admin user) results in the following error: invalid reuse of password present in password history It should never enforce the password policy for the admin user, correct? Any idea what could be causing it to enforce the policy in one M20 instance and not the other? Thanks!
Re: When will 2.0.0-M20 be released?
David Paulsen dave.paulsen@... writes: Emmanuel Lécharny elecharny at ... writes: I would say end of march, may be earlier. But this is just an estimate. Great, thank you for the estimate. Do you have an updated date for the M20 release? We really need this soon so we can deploy ApacheDS in our next production release. Thank you!
Re: Getting Password Expired Instead of Invalid Credentials
David Paulsen dave.paulsen@... writes: https://issues.apache.org/jira/browse/DIRSERVER-2051 Many thanks ! No problem. Any chance of this getting in 2.0.0-M20? Any update on this defect? Will it get fixed in M20? Thanks!
Re: When will 2.0.0-M20 be released?
Emmanuel Lécharny elecharny@... writes: I would say end of march, may be earlier. But this is just an estimate. Great, thank you for the estimate.
Re: When will 2.0.0-M20 be released?
Can you please provide at least a rough estimate of when M20 will be released?
Re: Getting Password Expired Instead of Invalid Credentials
https://issues.apache.org/jira/browse/DIRSERVER-2051 Many thanks ! No problem. Any chance of this getting in 2.0.0-M20?
Re: Getting Password Expired Instead of Invalid Credentials
Ooops... You are so right ! Can you fill a JIRA ? I created a JIRA issue: https://issues.apache.org/jira/browse/DIRSERVER-2051
Getting Password Expired Instead of Invalid Credentials
First of all, I'm using the ApacheDS Trunk that I downloaded and built on 2/24/2014. When I log in with invalid credentials AND the password is expired, I would expect to get the invalid credentials error: LDAPException: Invalid Credentials (49) Invalid Credentials LDAPException: Server Message: INVALID_CREDENTIALS: Bind failed: ERR_229 Cannot authenticate user uid=admin,ou=DJPS1,ou=DVHead,dc=kewilltransport,dc=com Instead I get the password expired error: LDAPException: Invalid Credentials (49) Invalid Credentials LDAPException: Server Message: INVALID_CREDENTIALS: Bind failed: paasword expired I would think we should get the invalid credentials error in that case. Thanks!
When will 2.0.0-M20 be released?
Hello... There are two importing fixes added to M20 that I'm waiting for: DIRSERVER-1809 DIRSERVER-2050 We cannot go live with ApacheDS in our application until we get these fixes in an official ApacheDS release. So, I really need to know when M20 will be released. Could you give me any kind of date, even if it's a range? Thanks!
Re: Adding larrge number of password policies is slow
Kiran Ayyagari kayyagari@... writes: On Wed, Feb 11, 2015 at 12:59 AM, David Paulsen dave.paulsen@... wrote: If there is any way to make this perform better I would really appreciate it! Are there any options in the short term I have for making this perform? For example, can I configure the server to write changes to disk in batches (rather that for every change) while performing a mass import of data? Any other ideas? I am currently looking to improve this, please watch this thread for updates Thanks Kiran, will this change be in M20? Also, do you have any idea when M20 will be available? no definitive plan yet, but won't be long though OK, thanks. Will the performance improvements for adding/changing password policies be included in the M20 release as well?
Re: Adding larrge number of password policies is slow
If there is any way to make this perform better I would really appreciate it! Are there any options in the short term I have for making this perform? For example, can I configure the server to write changes to disk in batches (rather that for every change) while performing a mass import of data? Any other ideas? I am currently looking to improve this, please watch this thread for updates Thanks Kiran, will this change be in M20? Also, do you have any idea when M20 will be available?
Re: Adding larrge number of password policies is slow
Kiran Ayyagari kayyagari@... writes: On Thu, Feb 5, 2015 at 12:17 PM, Emmanuel Lécharny elecharny@...m wrote: Le 03/02/15 16:36, Kiran Ayyagari a écrit : On Tue, Feb 3, 2015 at 10:57 PM, David Paulsen dave.paulsen@... wrote: Hello... Our application is a hosted, multi-tenant application where we have 1000's organzations (ou's), with each having it's own password policy. I have a Java utility that adds all the policies to ApacheDS. Adding the first few hundred adds take 2-3 seconds each, which is OK. But as the number of policies increases, the time to add new policies steadily increases too. For example, adding the 5300th (yes we have that many!) takes about 15 seconds. Note that the time to add orgs (ou's) and users (uid's) stays pretty constant (200- 500ms) this is expected, cause the configuration is stored in a text file and each update on this partition results in re-writing the entire config file I wonder if there is not a way to tell the server to use the multi-file version of the config, which would make it much faster... no, instead we might have to think of completely moving to this new format If there is any way to make this perform better I would really appreciate it! Are there any options in the short term I have for making this perform? For example, can I configure the server to write changes to disk in batches (rather that for every change) while performing a mass import of data? Any other ideas?
Adding larrge number of password policies is slow
Hello... Our application is a hosted, multi-tenant application where we have 1000's organzations (ou's), with each having it's own password policy. I have a Java utility that adds all the policies to ApacheDS. Adding the first few hundred adds take 2-3 seconds each, which is OK. But as the number of policies increases, the time to add new policies steadily increases too. For example, adding the 5300th (yes we have that many!) takes about 15 seconds. Note that the time to add orgs (ou's) and users (uid's) stays pretty constant (200- 500ms) I am using 2.0.0.M19, and all the default settings on a Windows 7 box. Any ideas on increasing the performance for password policy adds? Thanks!
Re: Password Policy attribute pwdMinAge not working?
This is fantastic Kiran, thanks! I'm assuming this will be in the ApacheDS 2.0.0-M20 release, correct? I'm also assuming that if I want it before then I'll have to build my own version from the trunk, correct? Correct and correct. We are most certlainly try to cut an ApacheDS release soon anyway, so you won't have to wait too long for an official M20 Thank Kiran, do have a rough idea of when M20 will be released? If it's within the next few weeks I won't worry about building the trunk.
Re: Password Policy attribute pwdMinAge not working?
We are most certlainly try to cut an ApacheDS release soon anyway, so you won't have to wait too long for an official M20 Any rough idea of when M20 will be released?
Re: Password Policy attribute pwdMinAge not working?
Is there any way around requiring a restart of the server to have password policy settings take effect? This would be a major issue for us. not yet, I have been sitting on this idea for far too long, but the effort stopped midway. Is there a way to formally request the enhancement to not require a there was one filed a while ago https://issues.apache.org/jira/browse/DIRSERVER-1809 restart, or is it already on your radar and you'll get to it when you can? We are very eager to get this capability added. Thanks Kiran, is there anything I can do to expedite this? We really need it. In the enhancement it suggests adding a method that would refresh the running policies in memory could be an easier interim solution - could that be done sooner?
Re: Password Policy attribute pwdMinAge not working?
Kiran Ayyagari kayyagari@... writes: On Wed, Jan 21, 2015 at 8:26 AM, David Paulsen dave.paulsen@... wrote: Thanks, Kiran. I was using the admin account to change the password. But, when I attempted to use the user account for which I'm changing the password (instead of the admin account), I get an INSUFFICIENT_ACCESS_RIGHTS error: LDAPException: Insufficient Access Rights (50) Insufficient Access Rights are there any ACIs affecting the below mentioned entry? LDAPException: Server Message: INSUFFICIENT_ACCESS_RIGHTS: failed for MessageType : MODIFY_REQUEST Message ID : 111 Modify Request Object : 'uid=jguinn,ou=8300,ou=DVHead,dc=kewilltransport,dc=com ' Modification[0] Operation : replace Modification userPassword: 0x48 0x69 0x54 0x68 0x65 0x72 0x65 0x32 org.apache.directory.api.ldap.model.message.ModifyRequestImpl at 8ede0d34: null LDAPException: Matched DN: Not that I know of. I did not specifically configure any ACIs for uid=jguinn,ou=8300,ou=DVHead,dc=kewilltransport,dc=com. Is there a way I can check for that? I would think that by default a user logged in to see if the parent/root entry has any ACI applied LDAP as themselves would be able to change their password, correct? yes Hi Kiran, it's working now. What happened is that in my password policy, I had changed ads-pwdallowuserchange=TRUE, but I hadn't restarted the LDAP server, and apparently password policy changes don't take effect until the server is restarted. Once I restarted, I could change the password when connected as the user I'm changing the password for. And, if I attempt to change the password before the pwdMinAge expires, I get a code = 19 password is too young to update error as expected. All good. Is there any way around requiring a restart of the server to have password policy settings take effect? This would be a major issue for us because we create/change password policy configurations often (we maintain password policies per customer). Thank you for your help!
Re: Password Policy attribute pwdMinAge not working?
Hi Kiran, it's working now. What happened is that in my password policy, I had changed ads-pwdallowuserchange=TRUE, but I hadn't restarted the LDAP server, and apparently password policy changes don't take effect until the server is restarted. ah! Once I restarted, I could change the password when connected as the user I'm changing the password for. And, if I attempt to change the password before the pwdMinAge expires, I get a code = 19 password is too young to update error as expected. All good. Is there any way around requiring a restart of the server to have password policy settings take effect? This would be a major issue for us not yet, I have been sitting on this idea for far too long, but the effort stopped midway because we create/change password policy configurations often (we maintain password policies per customer). Thank you for your help! Is there a way to formally request the enhancement to not require a restart, or is it already on your radar and you'll get to it when you can? We are very eager to get this capability added.
Re: Password Policy attribute pwdMinAge not working?
Kiran Ayyagari kayyagari@... writes: On Fri, Jan 16, 2015 at 4:16 AM, David Paulsen dave.paulsen@... wrote: I set the pwdMinAge in my Password Policy to 86400 (1 day in seconds) but it doesn't see to be working. I am able to change the password, and then change it again immediately after that. My understanding is that I should have to wait a day before I can change it again. Is that correct? you must have tried to change as admin, password policies are not applied when an admin user updates passwords, make sure you are not changing as an admin. I am using ApacheDS version 2.0.0-M19. Thanks! Thanks, Kiran. I was using the admin account to change the password. But, when I attempted to use the user account for which I'm changing the password (instead of the admin account), I get an INSUFFICIENT_ACCESS_RIGHTS error: LDAPException: Insufficient Access Rights (50) Insufficient Access Rights LDAPException: Server Message: INSUFFICIENT_ACCESS_RIGHTS: failed for MessageType : MODIFY_REQUEST Message ID : 111 Modify Request Object : 'uid=jguinn,ou=8300,ou=DVHead,dc=kewilltransport,dc=com ' Modification[0] Operation : replace Modification userPassword: 0x48 0x69 0x54 0x68 0x65 0x72 0x65 0x32 org.apache.directory.api.ldap.model.message.ModifyRequestImpl@8ede0d34: null LDAPException: Matched DN:
Re: Password Policy attribute pwdMinAge not working?
Thanks, Kiran. I was using the admin account to change the password. But, when I attempted to use the user account for which I'm changing the password (instead of the admin account), I get an INSUFFICIENT_ACCESS_RIGHTS error: LDAPException: Insufficient Access Rights (50) Insufficient Access Rights are there any ACIs affecting the below mentioned entry? LDAPException: Server Message: INSUFFICIENT_ACCESS_RIGHTS: failed for MessageType : MODIFY_REQUEST Message ID : 111 Modify Request Object : 'uid=jguinn,ou=8300,ou=DVHead,dc=kewilltransport,dc=com ' Modification[0] Operation : replace Modification userPassword: 0x48 0x69 0x54 0x68 0x65 0x72 0x65 0x32 org.apache.directory.api.ldap.model.message.ModifyRequestImpl at 8ede0d34: null LDAPException: Matched DN: Not that I know of. I did not specifically configure any ACIs for uid=jguinn,ou=8300,ou=DVHead,dc=kewilltransport,dc=com. Is there a way I can check for that? I would think that by default a user logged in to LDAP as themselves would be able to change their password, correct?
Password Policy attribute pwdMinAge not working?
I set the pwdMinAge in my Password Policy to 86400 (1 day in seconds) but it doesn't see to be working. I am able to change the password, and then change it again immediately after that. My understanding is that I should have to wait a day before I can change it again. Is that correct? I am using ApacheDS version 2.0.0-M19. Thanks!
