Testing LDAP Authentication and Authorization on Percona Operator for MongoDB

Testing LDAP Authentication and Authorization on Percona Operator for MongoDB

As of Percona Operator for MongoDB 1.12.0, the documentation now has instructions on how to configure LDAP Authentication and Authorization. It already contains an example of how to configure the operator if OpenLDAP is your LDAP server. Here is another example of setting it up but using Samba as your LDAP server.

To simplify the installation and configuration, I will use Ubuntu Jammy 22.04 LTS since the distribution repository contains the packages to install Samba and Kubernetes.

This is the current configuration of the test server:

OS: Ubuntu Jammy 22.04 LTS
Hostname: samba.percona.local
IP Address: 192.168.0.101

Setting up Samba

Let’s install the necessary packages to install Samba as PDC and troubleshooting tools:

Disable smbd, winbind, and systemd-resolved services because we will need to reconfigure samba as a PDC and DNS resolver. Also remove current samba configuration, /etc/samba/smb.conf.

Delete the symlink on /etc/resolv.conf and replace the content with “nameserver 127.0.0.1” to use the samba’s DNS service:

Create a domain environment with the following settings:

Realm: PERCONA.LOCAL
Domain: PERCONA
Administrator Password: PerconaLDAPTest2022

Edit /etc/samba/smb.conf and set DNS forwarder to 8.8.8.8 to resolve other zones. We will also disable mandatory TLS authentication since Percona Operator does not support LDAP with TLS at the time of writing this article.

Symlink krb5.conf configuration.

Unmask samba-ad-dc service and start it. Ensure it will start at boot time.

Check if the Samba services are up and running

Adding users and groups

Now that Samba is up and running, we can now perform user and group management. We will create Samba users and groups and assign users to groups with samba-tool.

Use samba-tool again to view the details of the users and groups:

Searching with ldapsearch

Troubleshooting LDAP starts with being able to use the ldapsearch tool to specify the credentials and filters. Once you are successful with authentication and searching, it’s easier to plug the same or similar parameters used in ldapsearch in the configuration of the Percona operator. Here are some examples of useful ldapsearch commands:

1. Logging in as “CN=Dev User01,CN=Users,DC=percona,DC=local”. If authenticated, return the DN, First Name, Last Name, email and sAMAccountName for that record.

Essentially, without mapping,you will need to supply the username as the full DN to login to MongoDB. Eg. mongo -u “CN=Dev User01,CN=Users,DC=percona,DC=local”

2. Logging in as “CN=Search User01,CN=Users,DC=percona,DC=local” and looking for users in “DC=percona,dc=local” where sAMAccountName is “dbauser01”. If there’s a match, it will return the DN, First Name, Last Name, mail and sAMAccountName for that record.

With mapping, you can now authenticate by specifying sAMAaccountName or mail depending on how mapping is defined. Eg. mongo -u dbauser01 or mongo -u “[email protected]”

3. Logging in as “CN=Search User01,CN=Users,DC=percona,DC=local”, looking for groups in “DC=percona,dc=local” where “CN=Dev User01,CN=Users,DC=percona,DC=local” is a member. If there’s a match, it will return the DN and common name of the group.

This type of search is important to enumerate the groups of that user for we can define the privileges of that user based on its group membership.

Kubernetes installation and configuration

Now that authenticating to LDAP and search filters are working, we are ready to test this in the Percona Operator. Since this is just for testing, we might as well use the same server to deploy Kubernetes. In this example, we will use Microk8s.

Once installed, check system pods when all are running before we continue to the next step:

Deploying the Percona Operator for MongoDB

Now that Kubernetes is running, we can download the Percona Operator for MongoDB. Let’s download version 1.13.0 with git:

Then let’s go to the deploy directory and apply bundle.yaml to install the Percona operator:

Check if the operator is up and running:

Now that it is running we need to apply cr.yaml to create the MongoDB instances and services. We will just use minimal deployment in cr-minimal.yaml which is provided in the deploy directory.

Wait until all pods are created:

Setting up roles on the Percona Operator

Now that MongoDB pods are running, let’s add the groups for role-based mapping. We need to add this configuration from the primary config server which will be used by mongos and replicaset for authorization when logging in.

First, let’s get the username and password of the admin user:

Next, let’s connect to the primary config server:

From the console, we can create two roles “CN=dbadmins,CN=Users,DC=percona,DC=local” and “CN=developers,CN=Users,DC=percona,DC=local” with their corresponding privileges:

Note that the role names defined here correspond to the Samba groups I created with samba-tool. Also, you will need to add the same roles in the replicaset endpoint if you want your LDAP users to have these privileges when connecting to the replicaset directly.

Finally, exit the mongo console by typing exit and pressing Enter. Do the same to exit the pod as well.

Applying the LDAP configuration to the replicaset, mongos, and config servers

Now, we can add the LDAP configuration to the config server. Our first test configuration is to supply the full DN when logging in so the configuration will be:

Next, apply the configuration to the config servers:

Additionally, if you want to log in to the replica set with LDAP, you can apply the same configuration as well:

As for mongos, you will still need to omit the settings for authorization because this will come from the config server:

Then apply the configuration for mongos:

One-by-one the pods will be recreated. Wait until all of them are recreated:

Now you can test authentication in one of the endpoints:

As you can see above, the user,”CN=Dba User01,CN=Users,DC=percona,DC=local” has assumed the role as root. You can test other endpoints using these commands.

Using userToDNMapping to simplify usernames

Obviously, you may not want the users to authenticate with the full DN. Perhaps, you want the users to specify just the first CN. You can use match and substitution mapping for this:

You will need to delete the old configuration and apply the new ones:

With userToDNMapping, match and substitution you can now just specify the first CN. Once all of the pods are restarted, try logging in with a shorter username:

Perhaps, it still seems awkward to have usernames with spaces and you would like to login based on other attributes such as sAMAccountName or mail. You can use an additional LDAP query in userToDBMapping to search for the record based on these properties. Once the record is found it will extract the user’s DN for authentication. For the example below, we will use sAMAccountName as input for the username:

Again, we will need to delete the old configuration and apply new ones:

Once the pods are recreated, we can now authenticate with regular usernames.

Summary

I hope this article gets you up to speed on setting up LDAP authentication and authorization with Percona Operator for MongoDB.