RANCHER CONFIG FOR AD
PRE-REQUISITES
Rancher allows several auth mechanisms to be used to authenticate users of the cluster. One of the more tricky to set up options is the Microsoft Active Directory auth provider, due to some opaque options.
Firstly, you’ll need a low-privilege account in your Active Directory (AD) that can list users and groups, and not much else. This is the account that Rancher will utilise to perform the account lookups and verification.
Once that’s in place, navigate to the Active Directory setup screen in your Rancher admin UI, while logged in as an admin-level user. This can be found under ‘Security → Authentication → Active Directory’.
Rancher AD config screen
You’ll be presented with a number of options. The trick is to get each section aligned with what your AD setup requires, and that can take patience, guesswork and luck, if you haven’t been explicitly given all the settings you’ll need.
SERVER SETTINGS
First, you’re asked to fill in the LDAP server or host. Enter the hostname in the field provided, and add a port of 389 for unencrypted or 636 for TLS (also referred to as ldaps). If you are sure that your ldap is encrypted, tick the “Use TLS” box as well as making the port 636.
Rancher AD server details config screen
The connection timeout can usually be left as-is, only fiddle with that under exceptional circumstances, beyond the scope of this article.
BIND ACCOUNT
The next piece of information to provide is the service account username that the bind to ldap will be made as. This takes the form of username@domain.tld. You can also provide it in the NetBIOS format of domain\username. But don’t do that.
Next, enter the corresponding password in the password field provided.
The default login domain should be left empty, unless you specify the NetBIOS style login information above. But don’t do that.
The user and group search base should look something like DC=x,DC=y,DC=z if your login domain is x.y.z. This can be narrowed down by restricting the base search further by including a specific user group.
SCHEMA CUSTOMISATION
The trickier part starts now. You can Customize the schema by supplying user and group search, class and other bits of arcana that seem far too complex. Stick to defaults to start off with or unless you have explicit information that you should change these. Most AD setups have not been changed here on the server side, so the common options should work.
I’ll quickly list the most common options for them below:
USERS
Object class: “Person”
Login attribute: “userPrincipalName”
Username Attribute: “name”
Search Attribute: “sAMAccountName”
Status Attribute: “userAccountControl”
Disabled BitMask: 2
GROUPS
Object Class: “group”
Name Attribute: “name”
Search Attribute: “sAMAccountName”
NB: Leave out the quotes above, they are there to show you exactly what should be entered for each field.
Rancher AD customize schema config screen
TEST ACCOUNT
Lastly, add a user and password in the section provided at the end to test the connection with. If all goes well, you should see a successful bind and the AD setup saved.
The account Used to test Active Directory will inherit all global permissions, as well as the project and cluster rolebindings of the local rancher user.
Rancher AD account test
AUTHENTICATE RANCHER WITH AD
Last part is to click the “Authenticate with Active Directory”. If you are successful you will be greeted with a new screen summarising the integration details.
You will now be able to grant authenticated AD users access rights to global, cluster, project or namespace level objects allowing granular control to your Rancher Kubernetes environments
Rancher AD setup complete summary screen
