Adding Active Directory OAUTH Provider

Many organizations use Microsoft Active Directory to control a user’s ability to login to various environments and as a way to provide RBAC (role-based access controls) through Groups.

OCP works with many authentication providers such as Github, Gitlab, HTPASSWD, Google, OpenID, as well as LDAP. Active Directory is based on LDAP so it will be used to allow users to login to the OCP cluster.

In this demonstration, I will describe the users and groups that are setup in Active Directory and the roles that each of these users will have in my demo environment. Secondly, I will walk you through the information gathering that you will need to do to define the OU (Organizational Unit) structure and LDAP settings. Next, I will show a quick example on how to troubleshoot issues with logging into OCP using the Active Directory/LDAP provider. Lastly, you will see how group membership can be used to provide role-bindings to allow users to have various levels of access to the cluster and to specific projects/namespaces.

This information is based on the documentation from:

https://docs.openshift.com/container-platform/4.6/authentication/identity_providers/configuring-ldap-identity-provider.html

Here is some general information about my setup

Domain: calligan.local

Fact Finding

To gather the OU structure, either ask your Windows administrator or (if you have login access to the domain controller), you the adsiedit utility.

1. Open up the adsiedit utility. You can either type adsiedit.msc at the run prompt or go under the “Windows Administrative Tools” menu.

2. Right-click on “ADSI Edit” in the left-pane and select “Connect To”. Use the default naming since we are logging in directly to the domain controller.

On the connection settings window, you have the LDAP connection string (Path) which is LDAP://ad-test.calligan.local. This will be used when adding the identity provider to OCP.

3. Click-on default naming context from the left-pane and expand DC=calligan,DC=local.

Under here, we see OU=Accts. This is where all users are located. Eventhough there are different business units and/or geographical regions, we want to allow all user accounts to be able to login to the OCP cluster for this example. Our search string would include everything under OU=Accts. To get the full path to the OU=Accts, right-click on OU=Accts and go to “Properties”.

Under properties, search for distinguishedName

The distinguishedName is “OU=Accts,DC=calligan,DC=local”. This will be used later.

The information we will need to create the Active Directory OAUTH provider is as follows

LDAP URL String: This is the path we gathered earlier with the distinguishedName at the end followed by the search that we will do (based on sAMAccountName).
For example, LDAP://ad-test.calligan.local/OU=Accts,DC=calligan,DC=local?sAMAccountName

Bind DN: This is the username@domain or either a service account (preferable) or a domain administrator account.
administrator@calligan.local

Bind PW: Your password

Email: Can leave empty

ID: sAMAccountName
Name: displayName
preferredUserName: sAMAccountName

CAFile: To gather this, run the following command:

openssl s_client -connect <ldapservername:636> -showcerts

Grab the contents of the cert and copy to your buffer (CTRL-C). Create a file on your desktop (IE: adca.crt).

Adding Active Directory/LDAP Identity Provider

1. Login to the OCP web console and go to Administration –> Cluster Settings –> Global Configuration –> Oauth

2. On the bottom of this screen will be an “Add” button. Choose LDAP.

3. Fill-in the information we gathered earlier.

For name, this can be anyname you want to use. I used the default (ldap)

Browse to the adca.crt file you saved and then click “Add”

4. Wait a few minutes and then logout of your cluster. Go back to the Openshift web console login page. You should now see your new identity provider.

If you are having problems logging into your cluster, take a look at the logs in the openshift-authentication project.

There are 2 pods running in this namespace. One of these pods will show if there is any problem with the connection between the cluster and the AD server. If you receive an invalid username/password, no error will show here. Only problems with certs, binding credentials, search strings, etc will appear in these logs.

Group Sync/Role-Bindings

As you may recall, the keith user is supposed to be a cluster admin. developer-a and developer-b are admins on each of their projects (admin_project[a,b]).

We will need to create an LDAPSyncConfig in order to map groups and users together. We will then use the group membership to attach to specific role-bindings.

More information on the LdapSyncConfig can be found here.

https://docs.openshift.com/container-platform/4.6/authentication/ldap-syncing.html#ldap-syncing-config-activedir_ldap-syncing-groups

Here is the information we will need to provide in the LdapSyncConfig

bindDN: This is the username@domain or either a service account (preferable) or a domain administrator account.
administrator@calligan.local

Bind PW: Your password

Groups you want to sync (groupUIDNameMapping):

This is the full DN name of the groups you want to sync seperated by a colon and the group name that they are to be called on the OCP cluster.

groupsQuery/baseDN: The OU of the groups. In this example, it is “ou=groups,DC=calligan,DC=local”. If you don’t know this, use adsiedit as we did earlier.

usersQuery/baseDN: The OU of the users. In this example, it is “ou=Accts,DC=calligan,DC=local”.

Sample LDAPSync File

1. Copy this LdapSync file to your bastion/jumpserver. I called mine LdapSync.yaml.
2. Since this bastion/jumpserver will need to trust the CA or self-signed cert of active directory, you may need to copy the adca.crt file we used earlier to the /etc/pki/ca-trust/source/anchors directory and run “update-ca-trust extract” command.
3. To sync up each group, run the following commands
   
   export KUBECONFIG=<PATH TO KUBECONFIG>
   
   oc adm groups sync –sync-config=LdapSync.yaml “CN=OCP_Cluster_Admin,OU=Groups,DC=calligan,DC=local” –confirm
   
   oc adm groups sync –sync-config=LdapSync.yaml “CN=Admin_Project_A,OU=Groups,DC=calligan,DC=local” –confirm
   
   oc adm groups sync –sync-config=LdapSync.yaml “CN=Admin_Project_B,OU=Groups,DC=calligan,DC=local” –confirm

4. Run the “oc get groups” command to see the groups that were created and a list of members.

5. Now, let’s add the cluster admin role binding for the OCP_Cluster_Admins group.

oc adm policy add-cluster-role-to-group cluster-admin OCP_Cluster_Admins

6. Let’s login to the cluster as the keith user to confirm that he can see all projects. Ignore the cert issue.

6. Next, let’s add the role mapping to allow developer-a admin access to project-a.

oc adm policy add-role-to-group admin Admin_Project_A -n project-a

Let’s make sure that developer-a can only see project-a

7. Lastly, let’s add the role mapping to allow developer-b admin access to project-b.

oc adm policy add-role-to-group admin Admin_Project_B -n project-b

Let’s make sure that developer-b can only see project-b

I hope you have found this helpful.