microsoft.ad.user - having trouble updating user password

[iamperson347]

SUMMARY

I'm attempting to update a service account (standard ad user, not a gmsa, etc.), but I'm having trouble getting this module to work as a replacement for win_domain_user. Ideally, I would like to pass in the sam account name of the service account, and update the password.

• I have tried using the identity property exclusively (to initially find the object) but I receive an error that "name" is required.
• I have tried using the name property exclusively (to initially find the object) but I receive an error that account already exists. I'm assuming the module needs "path" in this case?
• I have tried using the identity and name property together, but this creates and issue where the module is trying to rename/move the ad user object.

The accounts will be in separate OU's, so I cannot hardcode the path. I do see an object_info module where I could query for the user object first, but it seems the ad.user module should be able to accomplish the task at hand (as it's a replacement for win_domain_user).

Do you have any suggestions on the use case above?

ISSUE TYPE

• Bug Report

COMPONENT NAME

microsoft.ad.user

ANSIBLE VERSION

ansible [core 2.12.10]
  config file = /etc/ansible/ansible.cfg
  configured module search path = ['/opt/ansible-venv/5.10.0-core-2.12.10/share/ansible/plugins/modules']
  ansible python module location = /opt/ansible-venv/5.10.0-core-2.12.10/lib/python3.8/site-packages/ansible
  ansible collection location = /opt/ansible-venv/5.10.0-core-2.12.10/share/ansible/collections
  executable location = /opt/ansible-venv/5.10.0-core-2.12.10/bin/ansible
  python version = 3.8.0 (default, Dec  9 2021, 17:53:27) [GCC 8.4.0]
  jinja version = 3.1.2
  libyaml = True

COLLECTION VERSION

Collection   Version
------------ -------
microsoft.ad 1.2.0

CONFIGURATION

COLLECTIONS_PATHS(/etc/ansible/ansible.cfg) = ['/opt/ansible-venv/5.10.0-core-2.12.10/share/ansible/collections']
DEFAULT_CALLBACK_PLUGIN_PATH(/etc/ansible/ansible.cfg) = ['/opt/ansible-venv/5.10.0-core-2.12.10/share/ansible/plugins/callback']
DEFAULT_FILTER_PLUGIN_PATH(/etc/ansible/ansible.cfg) = ['/opt/ansible-venv/5.10.0-core-2.12.10/share/ansible/plugins/filter']
DEFAULT_FORKS(/etc/ansible/ansible.cfg) = 20
DEFAULT_HOST_LIST(/etc/ansible/ansible.cfg) = ['/etc/ansible/inventory/running']
DEFAULT_LOG_PATH(/etc/ansible/ansible.cfg) = /var/log/ansible/ansible.log
DEFAULT_MODULE_PATH(/etc/ansible/ansible.cfg) = ['/opt/ansible-venv/5.10.0-core-2.12.10/share/ansible/plugins/modules']

OS / ENVIRONMENT

STEPS TO REPRODUCE

See summary above.

EXPECTED RESULTS

microsoft.ad.user can update user account passwords by passing in samaccountname similar to win_domain_user.

ACTUAL RESULTS

[jborean93]

The name value of microsoft.ad.user is slightly different from win_domain_user as the latter was slightly confusing as to how it worked with name acting as both the cn/name of the user account as well as having a fallback on the sAMAccountName and other values. It made supporting renaming/moving the object a lot harder to achieve whereas microsoft.ad.user follows a set standard used by all the modules in this collection.

A basic description is that name is always referring to the CN component of the user's distinguished name. An example of this:

- name: manages user CN=testing,{{ default_domain_user_container}}
  microsoft.ad.user:
    name: testing

- name: manages user CN=testing,OU=MyOU,DC=domain,DC=test
  microsoft.ad.user:
    name: testing
    path: OU=MyOU,DC=domain,DC=test

If identity is not used then it will either manage the user at the path set or create a new user if it does not. Unfortunately even if identity is set to refer to the user to manage, I believe it will try and move the user to the target path which if no path was specified will be the default user container. So:

- name: manages sAMAccountName userSAM and ensures it is at CN=testing,{{ default_domain_user_container}} 
  microsoft.ad.user:
    name: testing
    identity: userSAM

- name: manages sAMAccountName userSAM and ensures it is at CN=testing,OU=MyOU,DC=domain,DC=test
  microsoft.ad.user:
    name: testing
    identity: userSAM
    path: OU=MyOU,DC=domain,DC=test

I see two possible options:

1. Keep the existing behaviour and require the path be set correctly in this situation
2. Change the behaviour to only move if a path was explicitly set

I am leaning towards option 2 because it closely matches the behaviour of win_domain_user. I do need to try and consider whether it might have some unintended side effects I can't think off right now. Maybe supporting a difference between no value/null (do not move) and an empty string for path (move to the default path) might help?

[iamperson347]

Option 2 sounds great and it sounds like it might make the module a bit easier to use. However, as you mentioned, I'm not sure of downstream implications of a change like that.

[jborean93]

The PR #59 implements option 2. At this stage the collection is quite new and I believe it's the behaviour that more people would expect based on the few issues we've received so far.

[iamperson347]

@jborean93 I think the MR linked has improved the situation. However, since name has to be set (if state = present), it still appears to not be quite possible to simply select the user object by samaccount name (with something like the identity paramter) and update an attribute on it. If we try to specify samaccount name for both identity and name, it is possible the user object will still be renamed (if those values don't actually match in AD).

Looking forward to your thoughts - I can open a separate issue for a new suggestion.

[jborean93]

@iamperson347 might be best to open as a new issue. Briefly thinking about it I think it should be fine to do and I cannot think of any downsides to it.