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.
>                                         
                                          

Reply via email to