win_user: Does not allow modification of domain users

[dagwieers]

ISSUE TYPE

• Feature Idea

COMPONENT NAME

win_user

ANSIBLE VERSION

v2.3

SUMMARY

I wanted to replace the following task:

- win_command: net localgroup Administrators sqlsvc /add
  register: net_localgroup
  changed_when: net_localgroup.rc == 0 and 'The command completed successfully.' in net_localgroup.stdout
  failed_when: net_localgroup.rc != 0 and 'The specified account name is already a member of the group.' not in net_localgroup.stderr

with a win_user task:

- win_user:
    name: sqlsvc
    groups: 
    - Administrators
    groups_action: add
    password: '{{ some_password }}'
    password_never_expires: yes
    state: present

This works for a computer in AD domain and will add the domain-user to the local group Administrators (in AD). However, win_user fails to do the same, instead it creates a local user in local group Administrators.

If you provide the user with AD domain (e.g. DOMAIN\sqlsvc) it fails with the error that the user does not exist. Exception calling "SetInfo" with "0" argument(s): "The specified username is invalid."

PS There is also another issue with the fact that the password: parameters seems to be mandatory. Which is reported in #20369

[ansibot]

cc @nitzmahone
click here for bot help

[ebarrere]

+1! I would love this functionality.

[nwchandler]

I need this for work. I'll take a swing at updating the module and share when ready.

[nwchandler]

I've been doing some testing using Ansible 2.3.0.0 today, along with Windows 2012 R2 Standard. When I run a win_user task such as below against a domain controller, it creates the domain user and seems to assign groups as I would expect:

- name: Ensure user1 is present
        win_user:
          name: user1
          state: present
          fullname: User 1
          password: <redacted>
          password_expired: yes
          groups:
            - Domain Users   # If you don't include this, you do need to include groups_action: add
            - Remote Desktop Users
            - Administrators

I DO see the 'Exception calling "SetInfo ...' error when I specify DOMAIN\username, however since I'm pointing at a domain controller, I think it would be fair to omit the DOMAIN prefix from the name. I wanted to see if this is consistent with your findings (e.g., you can get the user created if you omit the domain)... Otherwise, I may have misunderstood the issue.

[nitzmahone]

I don't know for sure, but I don't think that's a safe way to manage domain users. You're basically hacking the SAM database on the domain controller because it happens to have the same format as a local SAM database on a non-DC. I don't know if those users are properly created in the directory, or how you'd set AD-specific values like the target OU, etc.

A proper domain user management module will need to use the documented APIs for this (eg, ADSI or things built on top of it) and expose the necessary properties that a domain admin will expect.

[nwchandler]

That's all certainly fair, @nitzmahone . There are some things missing that a domain admin would likely expect, as you allude to. I was, for some reason, under the impression this didn't create users or assign groups at all on domain controllers, though, which is why I was looking for clarity on symptoms others had seen.

Based on your second paragraph, am I correct in thinking you would prefer a separate module entirely for domain user management?

[nitzmahone]

Like I said, the fact that the existing stuff works to create a user on a domain controller is both an accident and probably incomplete. I don't know enough about the AD guts to know if it will properly create the user object in AD just because you created it in the DC's SAM database (eg, will the user propagate to another DC correctly?)

As for the separate module thing, I'm definitely leaning that way. There's a whole suite of modules necessary for AD management, so I was kinda hoping to share some infrastructure and UI "look and feel" across them, rather than growing organically, but that of course makes it a much bigger project (which is why we still don't have anything).

[nwchandler]

I have created PR #24075 for anyone who is interested in reviewing.

[andrewsaraceni]

Related to @dagwieers' initial note, both win_user and the upcoming win_domain_user as per #24075 still do not account for the scenario of adding domain users to local computer groups. This is actually something we do quite often, e.g. add a domain user to the local Administrators group on a standard (i.e. non-DC) target system as a one-off.

Would it makes sense to have either of these modules handle this scenario, or perhaps build out the functionality of win_group to accomplish this? Happy to submit a PR.

[jhawkesworth]

@andrewsaraceni rather than making big modules that have lots of options, I think the best thing to do is create small modules that do one thing well. So in this case I'd suggest creating a win_group_member module that just ensured the specified users were in the specified groups.

[andrewsaraceni]

Thanks @jhawkesworth, I may give this a go sometime soon.

[ansibot]

cc @angstwad @cchurch
click here for bot help

[jborean93]

Closing as there is now a new module in 2.4 that can manage domain users and groups.