aem_user { ensure => password_changed } should first check if the password was already the desired password

[henrykuijpers]

I'm trying to create some configuration to be able to change passwords of certain system users. I.e. admin.

When I put the following script:
aem_user { "Change admin password": aem_username => 'admin', aem_password => 'adminx', ensure => password_changed, name => 'admin', path => '/home/users', old_password => 'adminx', new_password => 'admin' }
I can perfectly fine change the password of admin from 'admin' to 'adminx'.

However, when I run this script again, it will throw an error (401, unable to authenticate).

It seems to me that if the password is already the desired password ('adminx'), the state is already correct and therefore it shouldn't throw this error, but instead be OK and continue.

Or should I be calling another method to get my desired functionality?
Or my question/issue rephrased: How would you normally use this functionality in your scripts, to make sure that you're able to change passwords on your servers, without doing it manually?

[henrykuijpers]

I do see in the code that there are no checks to see if the user is already able to login with the new password.

WDYT, @cliffano ? Is this a bug, or a feature ?

[cliffano]

@henrykuijpers Sorry for the late reply, been working on lots of things lately.

The ensurable password_changed is meant to indicate that the user can login with old_password and then change it to new_password regardless whether they are the same or not. The limitation is that the endpoint that Adobe advised me to use for changing password in AEM 6.2 requires the user to login as itself, hence the need to specify user's current password in old_password attribute. Whereas in AEM 6.0 there was an endpoint that allows admin user to change the password of any user, but this endpoint no longer works with 6.2 .

So the difference with your use case scenario is that you want to ensure that a user's password is set to a certain value, which is different to password_changed ensurable.

Are you using this scenario in a Puppet master/agent with mutable environment setup?
If your goal is to set a user password at all cost, then the key is to find an endpoint that allows admin user to set a user's password.
The current endpoint for changing user password won't work for your use case because it will only work when the password is already what you want, but not when the password is different.
Put simply, if your user state can mutate, then the value of old_password and new_password will keep changing.

[cliffano]

@henrykuijpers Have you encountered any endpoint that allows admin user to set any user's password?

[henrykuijpers]

No, unfortunately I didn't come across any such endpoint.

Maybe it is possible to use impersonation here?
Or leverage this bundle: https://github.com/shinesolutions/aem-password-reset ?

[0Rick0]

Sorry to update on an old issue, but I'm running into this right now.

I did find these two endpoints using the AEM UI

• classic:

  POST /home/users/<user-path>.rw.html (e.g. /home/users/f/fumxeJQfwwMhAQPHPWio.rw.html)
  Content-Type: application/x-www-form-urlencoded; charset=UTF-8
  
  %3Astatus=browser&%3AcurrentPassword=<current-password>&rep%3Apassword=<new-password>&rep%3Apassword=<new-password>&_charset_=utf-8
  

• touch:

  POST /home/users/<user-path>.rw.userprops.html (e.g. /home/users/f/fumxeJQfwwMhAQPHPWio.rw.userprops.html)
  Content-Type: application/x-www-form-urlencoded
  
  rep%3Apassword=<new-password>&%3AcurrentPassword=<current-password>&_charset_=utf-8
  

These are called by using the set password button in either the classic or touch UI user manager.

Where new-password is the new password and user-path is the path to the user's node.
But most important current-password is the password of the currently signed in user, e.g. admin.

Would one of these endpoints be useful?