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.4, 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.4 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.
1) 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
2) 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'
3) Test SASL configuration by verifying that user “alex” can log in from this machine using the “mongodb” servicename:
$ testsaslauthd -u alex -p
4) Start MongoDB Enterprise with LDAP authentication enabled, by adjusting the config file:
$ sudo nano /etc/mongod.conf
auth=true
setParameter=saslauthdPath=/var/run/saslauthd/mux
setParameter=authenticationMechanisms=PLAIN
$ sudo service mongod restart
5) Try to authenticate as the user “alex” in MongoDB Enterprise:
$ mongo
> db.getSiblingDB("$external").auth(
{
mechanism: "PLAIN",
user: "alex",
pwd: "xxx",
digestPassword: false
}
)
1
>
The return value of “1” means success.
Setting up MongoDB Enterprise with Kerberos authentication using Quest Authentication Services
1) Create a user in Active Directory with SPN for the mongodb service:
$ sudo /opt/quest/bin/vastool -u ldap_admin service create mongodb/
Password for ldap_admin@MONGOTEST.COM:
The “ldap_admin” is user who is a member of the “Domain Admins” group in AD. This command will create automatically the “lin-client-mongodb” user in AD with the associated SPN “mongodb/lin-client.mongotest.com@MONGOTEST.COM”. The service keytab file will be exported to the “/etc/opt/quest/vas/mongodb.keytab” file.
2) Configure the MIT Kerberos (the /etc/krb5.conf file) using vastool:
$ sudo /opt/quest/bin/vastool -k /etc/opt/quest/vas/mongodb.keytab kinit
mongodb/
$ sudo mv /etc/krb5.conf /etc/krb5.conf.orig
$ sudo /opt/quest/bin/vastool configure mit
3 Start MongoDB with Kerberos authentication enabled, by adjusting the config file. You also need to make sure that mongod listens on the interface associated with the FQDN. For this exercise, you can just configure mongod to listen on all interfaces:
$ sudo nano /etc/mongod.conf
# Listen to local interface only. Comment out to listen on all
interfaces.
#bind_ip=127.0.0.1
auth=true
setParameter=authenticationMechanisms=GSSAPI
$ sudo service mongod stop$ sudo env KRB5_KTNAME=/etc/opt/quest/vas/mongodb.keytab mongod -f
/etc/mongod.conf
3) Try to authenticate as the user “alex@MONGOTEST.COM” in MongoDB Enterprise:
$ kinit alex@MONGOTEST.COM
Password for alex@MONGOTEST.COM:
$ mongo --host lin-client.mongotest.com
> db.getSiblingDB("$external").auth(
{
mechanism: "GSSAPI",
user: "alex@MONGOTEST.COM",
}
)
1
>
The return value of “1” indicates success. It is important to provide the --host parameter to the mongo shell so that it generates a correct Kerberos ticket request.
Summary and More Information
MongoDB Enterprise offers different options for authentication, including Kerberos and LDAP external authentication. Organizations deploying Quest Authentication Services can now integrate their MongoDB Enterprise systems into the existing security infrastructure without additional operational overhead.
Further information is available in our MongoDB Enterprise security documentation and MongoDB Enterprise user and role management tutorials.
To download MongoDB Enterprise, click below:
About Alex Komyagin
Alex is a member of the all-star MongoDB Technical Services team. He is always happy to help customers to meet their goals against all odds. Prior to MongoDB, Alex led a team of engineers for an embedded software project. Also he is a very nice person.