Friday, October 24, 2014

Business Problems: Using MongoDB with AD leveraging Centrify

About MongoDB

MongoDB is becoming increasingly popular alternative to other database offerings.  What's really refreshing about it is that unlike some other established database leaders (Ahem.... big O) they do provide several mechanisms for authentication.  This means flexibility!

As of this writing, MongoDB offers the following authentication mechanisms:
  • X.509 certificates
  • LDAP with AD or OpenLDAP leveraging SASL
  • Kerberos

What's the business problem here?

Typically the folks dealing with apps and databases are not experts on authentication.  This means cognitive, cooperation and coordination issues and obviously time-to-production challenges.
In addition, if your Linux/UNIX infrastructure does not implement a robust set of access control technologies, each additional node adds to the problem.

This post covers
  • SASL (plain) integration leveraging PAM
  • Limiting Access using Centrify Access components

How Centrify can accelerate and secure MongoDB deployments?

  • By providing THE most robust and thoroughly tested way of integrating non-Windows platforms (Unix/Linux/OS X) to Active Directory.
    • No need to worry about setting up multiple LDAP servers (Centrify is sites and services aware)
    • In the SASL use case, no need to worry about plaintext communications since ultimately Centrify uses Kerberos.
    • In the GSSAPI/Kerberos, Centrify maintains the environment for you and provides tools for ease of management.
  • Faster results - time to market these capabilities
  • Enhancing security by implementing privileged user management.

Basics:  What is SASL?

As per Wikipedia:  "Simple Authentication and Security Layer (SASL) is a framework for authentication and data security in Internet protocols. It decouples authentication mechanisms from application protocols, in theory allowing any authentication mechanism supported by SASL to be used in any application protocol that uses SASL."

The key here is that MongoDB supports SASL and SASL can use PAM.  Since Centrify makes PAM work with AD out of the Box, implementation is very simple:

Implementation  (on CentOS)

Note:  You will need the Enterprise Edition of MongoDB to get this going.  For instructions of how to set up, go here:   (use CentOS to follow along) - I will be elevating with dzdo:

Test and Configure SASLAUTHD

Step 1:  Make SASL(saslauthd)  is in your system and working and they cyrus-sasl-plain is installed
$ cat /etc/redhat-release
CentOS release 6.5 (Final)
$  adinfo -v
adinfo (CentrifyDC 5.2.0-218)
$ service saslauthd status
saslauthd is stopped
$  rpm -qa | grep cyrus-sasl-plain

If the cyrus-sasl-plain package is not present, use yum or other utilities to add it.
The saslauthd is stopped, this means that the service is not set to start automatically.

Step 2:  Make sure that SASL is configured to work with PAM and identify the path for the socket.
$ cat /etc/sysconfig/saslauthd | grep MECH
# Options sent to the saslauthd. If the MECH is other than "pam" uncomment the next line.
$ cat /etc/sysconfig/saslauthd | grep SOCKETDIR

Step 3: Test SASL by determining your valid AD users and testing interactively
# to determine who can log in to your computer from AD
$ adquery user
cosmo.kramer:x:1149240408:1149240408:Cosmo Kramer:/home/cosmo.kramer:/bin/bash
george:x:1149240406:1149240406:George Constanza:/home/george:/bin/bash

Step 4: To start saslauthd interactively  (with PAM support and verbose)
$ dzdo saslauthd -a pam -d
saslauthd[4022] :main            : num_procs  : 5
saslauthd[4022] :main            : mech_option: NULL
saslauthd[4022] :main            : run_path   : /var/run/saslauthd
saslauthd[4022] :main            : auth_mech  : pam
saslauthd[4022] :ipc_init        : using accept lock file: /var/run/saslauthd/mux.accept

Step 5: In another terminal or SSH session, test SASL with PAM using testsaslauthd

$ testsaslauthd -u cosmo.kramer -p <kramer's password> -s login -f /var/run/saslauthd/mux
0: OK "Success."

This means that SASL with PAM is working as expected.

Step 6: Now you can make SASL start automatically if needed
$ dzdo chkconfig saslauthd on

$ chkconfig  | grep saslauthd
saslauthd       0:off   1:off   2:on    3:on    4:on    5:on    6:off

Create a PAM configuration file for mongod
Step 7: Because we've configured SASL to use PAM, now we need a configuration file that has the system or centrify entries.  In my example, I'm piggybacking on the sshd config since I already know it works with AD users.  We also want to make sure that the "other" PAM config file is leveraging the Centrify PAM modules as well

$ cp /etc/pam.d/sshd /etc/pam.d/mongod
$ cp /etc/pam.d/sshd /etc/pam.d/other

Ultimately, for both auth, account, password and session, these files include password-auth (in CentOS), which basically has the Centrify PAM directives - here's an excerpt of password-auth:

cat /etc/pam.d/password-auth
# lines inserted by Centrify Direct Control (CentrifyDC 5.2.0-218)
auth       sufficient
auth       requisite deny
account    sufficient
account    requisite deny
session    required homedir
password   sufficient try_first_pass
password   requisite deny

This is what makes the magic happen.  The video below covers steps 1 thru 7.

Configure MongoDB

Step 8: Configure MongoDB Security for SASL and restart it.

Set the following parameters in the /etc/mongodb.conf file:

Auth has to be set to true and the parameter saslauthdPath has to be set to the socket in /var/run/saslauthd/mux  - Make sure the folder and file have the correct permissions.  Finally, the authenticationMechanisms havs to include Plain (for SASL).

To restart MongoDB with service, use:

$ service mongod restart

Test SASL/PAM authentication with MongoDB

To test, you'll need an externally identified user.  We will use the same user we used to test SASL

Step 9:  Create an externally identified user in MongoDB

$ mongo
MongoDB shell version: 2.6.5
connecting to: test
> db.getSiblingDB("admin")
> use $external
switched to db $external
> db.createUser({user:"cosmo.kramer",

The output should be:

Successfully added user: {
        "user" : "cosmo.kramer",
        "roles" : [
                        "role" : "read",
                        "db" : "reporting"

Step 10: Test SASL authentication inside MongoDB

$ mongo
MongoDB shell version: 2.6.5
connecting to: test
> db.getSiblingDB("$external").auth({mechanism: "PLAIN",user:'cosmo.kramer',pwd:'<kramer's password>',digestPassword: false})

The output should be:


The output of 1 means Success.  This is a very simple process for using the PLAIN method, but what's the issue here?  The password is in plaintext, even in our testing it was visible.  We will improve on this by using Kerberos, but first, let's add some access controls by leveraging the authorization components of Centrify.

The video below covers steps 8-10

Limiting access to MongoDB using PAM granular access controls leveraging Centrify

You may want to add an additional layer of security, for example, in a shared system, you may want to grant a super-set of users access to the box, but limit who can log in to MongoDB via SASL with PAM.  For this, you have the ability to create a role with the PAM mongod access right.

Step 10:  Create the MongoDB PAM Access right

  1. In Access Manager, navigate to Zone > Authorization > UNIX Rights Definitions > PAM Access
  2. Right Click and Select Add PAM Right, and set it up like this:
    Name: MongoDB
    Application: mongodb

At this point, if you have any role with the MongoDB database profile, you can add this PAM access right to make sure that they have access to MongoDB;  other users with just the ssh right, will be able to log into the box, but won't be able to log into MongoDB.

The video below showcases how to leverage PAM Access rights as an additional security layer for MongoDB with Centrify:

No comments:

Post a Comment