MongoDB LDAP and Kerberos Authentication with Dell (Quest) Authentication Services
By Alex Komyagin @MongoDB with the help of Kyle Robinson @Dell
January 2015, NYC
Overview
Dell (formerly Quest)
identity and access management software
helps to solve security and administration issues inherent in Unix-based systems. The Privileged Access Suite product consolidates and unifies Unix, Linux, and Mac OS X identities, giving users centralized authentication and single sign-on with Microsoft Active Directory.
Since version 2.6,
MongoDB Enterprise
supports authentication with Microsoft Active Directory Services using
LDAP
and
Kerberos
protocols. On Linux systems that are using Dell Privileged Access Suite it is now possible to integrate MongoDB into the existing infrastructure through the 3-step integration process described in this post.
Requirements
Existing Active Directory domain
Linux server
MongoDB Enterprise 2.6 or greater
Quest Authentication Services (QAS) version 4.1.0 or greater (part of the Privileged Access Suite distribution)
All further MongoDB commands in this paper are given for the latest stable release, MongoDB 2.6. The Linux OS used is RHEL6.5. The Quest Authentication Services version is 4.1.0.21267.
Setup procedure
Preparing a new MongoDB Linux server
I assume you already have QAS installed and configured on your production systems. For the purposes of this tutorial, I will cover the most basic steps needed to set everything up on a standalone Linux system:
1. Configure hostname and DNS resolution
For QAS and MongoDB Enterprise to function properly you must set a hostname on the system and make sure it’s configured to use the proper Active Directory-aware DNS server instance IP address. You can update the hostname using commands that resemble the following:
$ sudo nano /etc/sysconfig/network
HOSTNAME=lin-client.mongotest.com
$ sudo reboot
$ hostname -f
lin-client.mongotest.com
mongotest.com is the domain name configured in Active Directory.
Next, verify the DNS settings and add additional servers, if needed:
$ sudo nano /etc/resolv.conf
search mongotest.com
nameserver AA.BB.CC.DD
2. Install MongoDB Enterprise
The installation process is outlined in our
Documentation
. It’s recommended to turn SELinux off for this exercise, or you should
configure SELinux
to allow MongoDB to access the 27017 port:
$ sudo nano /etc/selinux/config
SELINUX=disabled
$ sudo reboot
Since MongoDB Enterprise grants user privileges through
role-based authorization
, there should be an
LDAP
and a
Kerberos
user created in the database:
$ sudo service mongod start
$ mongo
> db.getSiblingDB("$external").createUser(
{
user : "alex",
roles: [ { role: "root" , db : "admin"} ]
}
)
> db.getSiblingDB("$external").createUser(
{
user: "alex@MONGOTEST.COM",
roles: [ { role: "root", db: "admin" } ]
}
)
“alex” is a user listed in AD and who is a member of the “Domain Users” group and has “support” set as its Organizational Unit.
3. Install Quest Authentication Services
Basic installation of QAS is as simple as running a shell script:
$ tar -zxvf QAS_4_1_0_21267.tar.gz && cd QAS_4_1_0_21267
$ sudo ./install.sh
You will need a valid license file for QAS in order for the LDAP and Kerberos authentication to work.
Once the QAS package is installed, you will need to connect this machine to AD:
$ sudo /opt/quest/bin/vastool -u ldap_admin -s join
--autogen-posix-attrs -f mongotest.com
ldap_admin@MONGOTEST.COM's password:
Here “ldap_admin” is a user who is a member of the “Domain Admins” group in AD.
I’m using the --autoget-posix-attrs parameter to the “join” command to instruct QAS to automatically generate POSIX user attributes for AD users. Other options would be to specify those manually (unixHomeDirectory, uidNumber, gidNumber, loginShell) in AD or use a vastool command to update the user entry in AD from Unix:
$ sudo /opt/quest/bin/vastool -u ldap_admin create -ei
"alex:x:1001:100::/home/alex:/bin/sh" user alex
4. Verifying the installation
You can confirm that the Active Directory user is properly recognized by QAS using the following two commands:
$ sudo /opt/quest/bin/vastool isvas user alex
alex is a QAS user.
$ sudo /opt/quest/bin/vastool user checklogin alex
Password:
ALLOWED [user=alex] [service=login]
Access Rule = [No Allow or Deny rules exist!]
As it is evident from their output, user “alex” is a valid QAS user and his login is allowed from this machine.
Setting up MongoDB Enterprise with LDAP authentication using Quest Authentication Services
The QAS “vasd” daemon manages all communications with Active Directory, and MongoDB can use QAS
PAM
module to authenticate LDAP users.
Configure saslauthd, which is used by MongoDB as an interface between the database and the Linux PAM system.
a. Verify that “MECH=pam” is set in /etc/sysconfig/saslauthd:
$ grep ^MECH /etc/sysconfig/saslauthd
MECH=pam
On Debian-based systems (such as Ubuntu) the saslauthd configuration file is located at /etc/default/saslauthd.
b. Turn on the saslauthd service and ensure it is started upon reboot:
$ sudo service saslauthd start
Starting saslauthd: [ OK ]
$ sudo chkconfig saslauthd on
$ sudo chkconfig --list saslauthd
saslauthd 0:off 1:off 2:on 3:on 4:on 5:on 6:off
Configure PAM to recognize the mongodb service by creating an appropriate PAM service file. I will use the sshd service file as a template, since it should have already been preconfigured to work with QAS:
$ sudo cp -v /etc/pam.d/{sshd,mongodb}
`/etc/pam.d/sshd' -> `/etc/pam.d/mongodb'
Test SASL configuration by verifying that user “alex” can log in from this machine using the “mongodb” servicename:
$ testsaslauthd -u alex -p
January 27, 2015