AD Authentication in Modules
A key requirement of the modules used inside this collection is being able to authenticate a user to the domain controller when managing a resource. This guide will cover the different options available for this scenario.
Note
This guide covers authentication to a domain controller when using a module on a Windows host. See LDAP Authentication for information on how authentication is done when using plugins running on Linux.
Implicit Authentication
The first and simplest option is to use the connection user’s existing credentials during authentication. This avoids having to specify a username and password in the module’s parameters, but it does require that the connection method used by Ansible supports credential delegation. For example using CredSSP authentication with the winrm
and psrp
connection plugin, or using Kerberos delegation. Other authentication options, like NTLM, do not support credential delegation and will not work with implicit authentication.
The only way to test out if implicit authentication is available is to run the module and see if it works. If it does not work then the error will most likely contain the message Failed to contact the AD server
.
Become
If implicit authentication is not available, the module can be run with become
that specifies the username and password to use for authentication.
- name: Use become with connection credentials
microsoft.ad.user:
name: MyUser
state: present
become: true
become_method: runas
become_flags: logon_type=new_credentials logon_flags=netcredentials_only
vars:
ansible_become_user: '{{ ansible_user }}'
ansible_become_pass: '{{ ansible_password }}'
The runas
method is used on Windows and the become_flags
will specify that the credentials should be used for network authentication only. The ansible_become_user
and ansible_become_pass
variables specify the username and password to use for authentication. It is important that both of these variables are set to a valid username and password or else the authentication will fail.
It is also possible to use the SYSTEM
account for become. This will have the module use the AD computer account for that host when authenticating with the target DC rather than an explicit username and password. The AD computer account must still have the required rights to perform the operation requested.
- name: Use machine account for authentication
microsoft.ad.user:
name: MyUser
state: present
become: true
become_method: runas
become_user: SYSTEM
Explicit Credentials
The final option is to specify the username and password as module options. This can be done in two ways; with the domain_username
and domain_password
options, or with the domain_credentials
option. An example of both methods is shown below.
- name: Use domain_username and domain_password
microsoft.ad.user:
name: MyUser
state: present
domain_username: '{{ ansible_user }}'
domain_password: '{{ ansible_password }}'
- name: Use domain_credentials
name: MyUser
state: present
domain_credentials:
- username: '{{ ansible_user }}'
password: '{{ ansible_password }}'
Note
The domain_credentials
option was added in version 1.6.0 of this collection.
The domain_credentials
option without the name
key, like in the above example, will be the credentials used for authentication with the default domain controller just like domain_username
and domain_password
. Using both options together is not supported and will result in an error.
The domain_credentials
option can also be used to specify server specific credentials. For example when attempting to lookup the identity of an AD object:
- name: Set member with lookup on different server
microsoft.ad.group:
name: MyGroup
state: present
members:
add:
- GroupOnDefaultDC
- name: GroupOnDefaultDC2
- name: GroupOnOtherDC
server: OtherDC
- name: GroupOnThirdDC
server: ThirdDC
domain_credentials:
- username: UserForDefaultDC
password: PasswordForDefaultDC
- name: OtherDC
username: UserForOtherDC
password: PasswordForOtherDC
In the case above there are three members being added to the group:
GroupOnDefaultDC
- Will be looked up on the default domain controller usingUserForDefaultDC
andPasswordForDefaultDC
GroupOnDefaultDC2
- Same as the above just specified as a dictionaryGroupOnOtherDC
- Will be looked up onOtherDC
usingUserForOtherDC
andPasswordForOtherDC
GroupOnThirdDC
- Will be looked up onThirdDC
using the implicit user authentication context
The value for server
must correspond to a name
entry in domain_credentials
. If the server is not specified in domain_credentials
, the module will default to using the domain_username/domain_password
or implicit user authentication.
Note
The default (no name
key) entry in domain_credentials
is only used for lookups without an explicit server set. The domain_username
and domain_password
credential will be used for all connections unless there is an explicit server entry in domain_credentials
.