Step 1 – Configure Directory Service Authentication in DSM
These are the Directory Service settings that I configured so that DSM and its databases could authenticate against my OpenLDAP. A few things which are slightly different to those of you who might be more familiar with Active Directory is that the full Distinguished Name (DN) of the admin appears in the Username field. This is expected for OpenLDAP. The Bind Username needs to be the full DN. My engineering team informed me that Active Directory has an optimisation where, if you pass the userPrincipalName, it will try to log in using the userPrincipalName attribute, and not require the full DN. This optimisation is not in OpenLDAP. Just something to be aware of.
However, once you specify the Bind DN (using the full DN) and set the User Search Attribute, other users can log in using their short user IDs. This means that users should be able to use their uid when accessing the PostgresSQL database.
Step 2: Deploy a database with Directory Service Auth
The next step is to create a PostgreSQL database with Directory Service Authentication enabled. This step could also be done after the database has been provisioned, although enabling or disabling Directory Services on a database will require the database to restart. The option to enable Directory Service Authentication is found in the Basic section in the Database Create workflow, as highlighted below.
Once the database is deployed, this option should show Enabled in the Summary view of the database.
You can also check if the Directory Service Authentication has been added by checking the database itself. Query the pg_hba.conf settings by connecting to the database as an admin (default, pgadmin) and running the psql command table pg_hba_file_rules; This should show entries in the rules which now have an LDAP auth_method, along with a number of options which reflect the Directory Service configuration shown in step 1.
Step 3: Give OpenLDAP user database permissions
The third and final step is to grant the user permissions to access the database. To do this, you will first need connect to the database as an admin (default, pgadmin) and run the commands as shown in the official DSM 2.2 documentation. To begin, let’s verify the uid of the OpenLDAP user that I plan to grant access to. The uid is the User Search Attribute that has been configured in the Directory Service. I can use the ldapsearch command as follows to do that. I am running this via a shell session to my OpenLDAP server (running Debian):
$ sudo ldapsearch -cxWD "cn=admin,dc=rainpole,dc=com" \ -H ldaps://openldap.rainpole.com:636 -LLL -x -b "dc=rainpole, dc=com" \ uid=ops@tenant1 uid Enter LDAP Password: ******** dn: uid=ops@tenant1,ou=users,dc=rainpole,dc=com uid: ops@tenant1
The uid ops@tenant1 is valid. You could omit the “uid=ops@tenant1” part of the previous command if you wanted to get a list of all users IDs (uids). Now that the uid is confirmed, connect to the database as an admin using the connection string found on the DSM UI for this database. Then run the following commands to grant user ops@tenant1access to the database.
cjh-pg-01=# CREATE ROLE "ops@tenant1" login; CREATE ROLE cjh-pg-01=# GRANT ALL PRIVILEGES ON DATABASE "cjh-pg-01" TO "ops@tenant1"; GRANT cjh-pg-01=# GRANT ALL ON SCHEMA public TO "ops@tenant1"; GRANT cjh-pg-01=# \q
Now to test if our user can access the database. Run the following command:
$ psql postgresql://@cjh-pg-01.rainpole.com:5432/cjh-pg-01 -U ops@tenant1 Password for user ops@tenant1: ******* psql (15.10 (Debian 15.10-0+deb12u1), server 14.15 (VMware Postgres 14.15.0)) SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, compression: off) Type "help" for help. cjh-pg-01=>
Success! Our OpenLDAP user (ops@tenant1) has been able to successfully login to the database. Repeat step 3 for any other users that you wish to grant access to the database.