Brock, Not sure about that. The only thing I can think of is you may have the ads-pwdsafemodify set TRUE. We looked at this feature a couple years ago and I don't think it was implemented then but it may be now in M19. If that's the case, you could try setting it FALSE (and restarting). The studio's UI might not have the ability to provide the existing password while changing. I don't know. If you post the full stack trace of the exception it may offer better clues. Thanks
-----Original Message----- From: brock samson [mailto:[email protected]] Sent: Friday, March 06, 2015 12:19 AM To: [email protected] Subject: RE: pwdMustChange not working Carlo, thank you for such detailed description. i never mentioned in my initial post that i already had pwdPolicySubentry placed as a user's attribute, though its value is pointing to ads-pwdId=default,ou=passwordPolicies,ads-interceptorId=authenticationInterceptor,ou=interceptors,adsdirectoryServiceId=default,ou=config, which is the ootb password policy. the part that i did not perform was having the admin change that user's password which results in pwdReset attribute being set. yet when i signed in as an admin (uid=admin,ou=system) to apache studio and then proceeded to change a user's (uid=bob,ou=users,o=mycompany) passwod, i got the following error: LdapNoPermissionException: trying to update password attribute without the supplying the old password. do you know what i am doing wrong? should an admin be forced to enter an old password? if that is the case, how do i make apache studio do that? thanks. > From: [email protected] > To: [email protected] > Subject: RE: pwdMustChange not working > Date: Thu, 5 Mar 2015 19:04:58 +0000 > > Hi, we've been that feature for quite some time to force a user to change > their password after it's been reset by an admin. > > Make sure the user(s) you want this to affect have the pwdPolicySubEntry > attribute set on their entry with the DN of the password policy entry. > > For example > > dn: uid=jsmith,ou=users,ou=int,o=company > uid: jsmith > cn: jsmith > ... > pwdPolicySubEntry: > ads-pwdId=internalUsers,ou=passwordPolicies,ads-interceptorId=authenticationInterceptor,ou=interceptors,adsdirectoryServiceId=default,ou= > config > > Then on the policy entry itself, the attribute ads-pwdmustchange must be set > TRUE. > And he policy must be enabled, ads-enabled=TRUE > > If you've made changes to the policy, restart the server. > > Then if an admin, using the bind credentials (uid=admin,ou=system) sets the > password for jsmith, the pwdReset attribute is added to their user entry. > The next time jsmith binds with their credentials, you get a signal that the > password must change in the bind response. > Here's some pseudo code: > > BindRequest bindRequest = new BindRequestImpl(); > bindRequest.setDn(dn); > bindRequest.setCredentials(strPassword); > > LdapApiService codec = > LdapApiServiceFactory.getSingleton(); > PasswordPolicyDecorator pwCtrl = new > PasswordPolicyDecorator(codec,new PasswordPolicyImpl()); > > bindRequest.addControl(pwCtrl); > BindResponse bindResponse = > connection.bind(bindRequest); > PasswordPolicyResponse pw = null; > PasswordPolicy pwPolicy = > ((PasswordPolicyDecorator)ctrl).getDecorated(); > > if (pwPolicy.hasResponse()) > { > pw = pwPolicy.getResponse(); > // process password response. > > if (PasswordPolicyErrorEnum.CHANGE_AFTER_RESET == > ctrl.getPasswordPolicyError()) > { > // this will be true when the pwdRest attr is > present on the user. > // call your change password code here > } > > > } > > After the jsmith user changes their password (with their credentials) the > pwdReset attribute is removed from their entry. > > > Hope this helps. > > > -----Original Message----- > From: brock samson [mailto:[email protected]] > Sent: Thursday, March 05, 2015 12:39 PM > To: [email protected] > Subject: pwdMustChange not working > > i am running apacheds2-M19, and changing pwdMustChange password policy > attribute's value from FALSE to TRUE does not have any effect. after server > restart and using the typical LdapNetworkConnection.bind() function, and > response is marked with SUCCESS. also, despite very good description of > pretty much every password policy attribute on your doc site, there is > absolutely nothing written about this particular attribute. >
