Authenticating To Ansible Tower Via Windows Active Directory

The Ansible automation platform has many awesome features, and one in particular is its ability to authenticate off of something other than itself. A common one I’m running into with customers is having Tower authenticate off of their Active Directory, so that’s what I’m going to tackle here. This assumes you have a functioning AD environment(though turning up a domain controller is still a very simple process(I haven’t stood up a DC since windows 2000 LOL)). Here’s Ansible’s documentation on it.

Demo Video

Active Directory Configuration

My AD server is windows server 2016 essentials and all of my screen shots are done from my laptop using Active Directory Explorer.

My AD domain is DEMO.local:

I stuck everything in the Users CN:

Notice in the above that I have two users:
– test1
– test2
I also have 4 groups defined:
– tower_admins
– tower_auditors
– tower_users
– tower_team_network

The groups will be mapped to various things in tower, which I’ll cover in just a bit.

Tower Configuration

So navigating to system -> authentication will present me with my external authentication options. From here I’m going to choose LDAP since AD is really just LDAP under the hood.

I’ve highlighted…highlit…multiple things here.
KEEP “LDAP USER DN TEMPLATE” and “LDAP DENY GROUP” BLANK. It tends to break things if you don’t need it.
For LDAP server I’m doing an unencrypted connection so I just use ldap:x.x.x.x:389; if it was to be secure I’d specify ldaps:x.x.x.x:636.
For LDAP BIND DN I’ve specified a user that has access to access the various users and groups(this is the account Tower uses to authenticate with the LDAP server).
I use MemberDNGroupType for my LDAP group type, though there is an AD option. If you have nested LDAP groups, be sure to set the option here.
The LDAP Require Group is an optional field. If this option is set, then only AD users that are members of this group are allowed to connect. This prevents random AD users from connecting.
If you don’t specify anything here, then any AD user can connect to the system, but they won’t have access to do anything(other than create a credential) by default. In my case I use the tower_users group.

Here’s my next set of options:

LDAP User Search is where in LDAP the system will look for users. I have them all in the users group as specified here, but I also use scope_subtree, which tells Tower to look here, but also look in other groups under this. I also specify the sAMAccountName object to be the username as shown in the following screenshot:

1
2
3
4
5

[
 "CN=Users,DC=DEMO,DC=local",
 "SCOPE_SUBTREE",
 "(sAMAccountName=%(user)s)"
]

Next will be the LDAP Group Search option, which tells tower where to look in the LDAP tree for the configured groups used for users.

1
2
3
4
5

[
 "CN=Users,DC=DEMO,DC=local",
 "SCOPE_SUBTREE",
 "(objectClass=group)"
]

Then we hit the LDAP User Attribute Map, which maps LDAP options to tower options.

1
2
3
4
5

{
 "first_name": "givenName",
 "last_name": "sn",
 "email": "mail"
}

The LDAP Group Type Parameters do a little more mapping.

1
2
3
4

{
 "member_attr": "member",
 "name_attr": "cn"
}

LDAP User Flags By Group is where I map my singleton roles roles for admins and auditors. The AD tower_admins group and tower_auditors group get mapped to system admins/auditors in tower.

1
2
3
4
5
6
7
8

{
 "is_superuser": [
  "CN=tower_admins,CN=Users,DC=DEMO,DC=local"
 ],
 "is_system_auditor": [
  "CN=tower_auditors,CN=Users,DC=DEMO,DC=local"
 ]
}

LDAP Organization Map maps groups to various levels as shown below. tower_admins become admins and every other group are users.

1
2
3
4
5
6
7
8
9
10
11

{
 "Default": {
  "remove_admins": true,
  "admins": "CN=tower_admins,CN=Users,DC=DEMO,DC=local",
  "users": [
   "CN=_tower_auditors,CN=Users,DC=DEMO,DC=local",
   "CN=tower_users,CN=Users,DC=DEMO,DC=local",
   "CN=tower_team_network,CN=Users,DC=DEMO,DC=local"
  ]
 }
}

Last is the LDAP Team Map. This is where various AD groups are mapped to teams within Ansible Tower. If the team doesn’t exist, then the first time a user authenticates, the teams will be created. After the groups exist it’s an admin’s job to go and add permissions for the various groups.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

{
 "LDAP Admins": {
  "remove": true,
  "organization": "Default",
  "users": "CN=tower_admins,CN=Users,DC=DEMO,DC=local"
 },
 "LDAP Auditors": {
  "remove": true,
  "organization": "Default",
  "users": "CN=tower_auditors,CN=Users,DC=DEMO,DC=local"
 },
 "LDAP Users": {
  "remove": true,
  "organization": "Default",
  "users": "CN=tower_users,CN=Users,DC=DEMO,DC=local"
 },
 "LDAP Network": {
  "remove": true,
  "organization": "Default",
  "users": "CN=tower_team_network,CN=Users,DC=DEMO,DC=local"
 }
}

So any AD user that is a member of the tower_team_network group is put into Tower’s “LDAP Network” team.

LDAP Order Of Operation

Check the link here on how multiple LDAP servers are utilized.
The TLDR is:

All of the usual rules apply: Django will attempt to authenticate a user with each backend in turn until one of them succeeds. When a particular backend successfully authenticates a user, that user will be linked to the backend for the duration of their session.

LDAP Troubleshooting On Tower

When things inevitably go wrong, here’s some troubleshooting options.
In tower, create this file(/etc/tower/conf.d/ldap.py) with the following option:

1

LOGGING['handlers']['tower_warnings']['level'] =  'DEBUG'

After that, restart the Tower services

1

ansible-tower-service restart

You can now do a tail on the /var/log/tower/tower.log log file to see LDAP specific messages.

You also want to use the LDAP search command(you will have to download the tool) to do some testing with the following command:

1

ldapsearch -x  -H ldap://192.168.51.6 -D "CN=Greg Sowell,CN=Users,DC=DEMO,DC=local" -b "dc=DEMO,dc=local" -w MyPassword

Jeremy turned me on to the fact that a convenient way to see what’s going on is to do a wireshark capture on the packets; it will give you indications on what’s happening in the auth process.

Big thanks to Jimmy for helping me suss the last bug out of my config. Turns out if any group that Tower is searching LDAP for isn’t found, then it will just fail with a very nondescript error(so double check all of your spellings).

Hope this helps and happy authenticating.