MongoDB-AD Integration made easy with Centrify

Showing results for 
Search instead for 
Do you mean 
Reply
Centrify Guru I
Posts: 2,430
Registered: ‎07-26-2012
#1 of 5 27,648
Accepted Solution

MongoDB-AD Integration made easy with Centrify

[ Edited ]

Business Problems: Using MongoDB with AD leveraging Centrify

http://centrifying.blogspot.com/2014/10/business-problems-centrify-and-mongodb.html

 

MongoDB is becoming increasingly popular alternative to other database offerings.  What's really refreshing about it is that they do provide several mechanisms for authentication.  This means flexibility!


As of this writing, MongoDB offers the following authentication mechanisms:
Reference: http://docs.mongodb.org/manual/tutorial/enable-authentication/
  • X.509 certificates
  • LDAP with AD or OpenLDAP leveraging SASL
  • Kerberos

What's the business problem here?

However, 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
A second post covers Kerberos integration.

How can Centrify accelerate and secure MongoDB deployments?

  • By providing THE most robust and thoroughly tested  way of integrating with AD
  • Faster results - time to market these capabilities
  • Enhancing security by implementing privileged user management.
This post covers the SASL implementation and a subsequent post will cover Kerberos.
 

Basics:  What is SASL?

As per Wikipedia:  "SASL is a framework for authentication and data security  in Internet protocols"

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:
Integration - MongoDB SASL.jpg

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: http://docs.mongodb.org/manual/tutorial/install-mongodb-enterprise-on-red-hat-or-centos   (use CentOS to follow along)

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
cyrus-sasl-plain-2.1.23-13.el6_3.1.x86_64
 
Notes:
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
$ cat /etc/sysconfig/saslauthd | grep MECH
MECH=pam
# Options sent to the saslauthd. If the MECH is other than "pam" uncomment the next line.
$ cat /etc/sysconfig/saslauthd | grep SOCKETDIR

SOCKETDIR=/var/run/saslauthd
 
 
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)
$ saslauthd -a pam -d
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 piggibacking on the sshd config since I already know it works with AD users.
 
$ cp /etc/pam.d/sshd /etc/pam.d/mongod
 $ cp /etc/pam.d/sshd /etc/pam.d/other
 
Configure MongoDB

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

Set the following parameters in the /etc/mongodb.conf file:
auth=true
setParameter=saslauthdPath=/var/run/saslauthd/mux
setParameter=authenticationMechanisms=PLAIN,MONGODB-CR

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")
admin
> use $external
switched to db $external
> db.createUser(
... {user:"cosmo.kramer",
... roles:[{role:"read",db:"reporting"}]
... }
... )
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
... ...    }
... ... )
1
 
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.

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.
Acces Manager - Highlight of PAM rights.jpg
Step 11:  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:

 

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.

 

Videos

Want to learn more about practical Centrify examples? Check out my blog at http://centrifying.blogspot.com
Follow Centrify:
Posts: 961
Topics: 3
Kudos: 256
Blog Posts: 6
Ideas: 0
Solutions: 126
Registered: ‎07-06-2010
#2 of 5 27,643

Re: MongoDB-AD Integration made easy with Centrify

Execellent write-up Robertson!! 

 

Great to see MongoDB providing out of the box PAM support via SASLAUTH and GSSAPI support.

Felderi Santiago
VP of Enterprise Solutions
Centrify Corporation
Found my response helpful? Click the Kudos button!
Follow Centrify:
Centrify Guru I
Posts: 2,430
Registered: ‎07-26-2012
#3 of 5 27,639

Re: MongoDB-AD Integration made easy with Centrify

[ Edited ]

Hahaha!!! you wrote it, I just tested it in the contoso lab.  It's all you.  I'm trying to do the video but too many mistakes, it's hard to do in one take.  Time to get a break.  

Kerberos and videos coming soon!!

 

Shout out to @Alex from MongoDB.

Want to learn more about practical Centrify examples? Check out my blog at http://centrifying.blogspot.com
Follow Centrify:
Centrify Guru I
Posts: 2,430
Registered: ‎07-26-2012
#4 of 5 27,595

Re: MongoDB-AD Integration made easy with Centrify

[ Edited ]

Labs: MongoDB-AD Integration with Centrify - The Kerberos Remix

Background

In the previous post, we discussed how with Centrify, MongoDB authentication can be streamlined and we discussed SASL Auth integration.  We also discussed how to leverage the authorization capabilities of Centrify to limit access to MongoDB via PAM with SASL.

However, SASL is a simple option and can be greatly enhanced by using a different option.

Advantages of using AD Kerberos with Centrify

Centrify automatically creates and maintains the Kerberos environment of a UNIX, Linux or Mac OS X environment, no need to deal with /etc/krb5.conf files, machine keytabs or incompatibilities because Centrify's shared objects are optimized to work with AD regardless of the complexity of the AD environment (one-way trusts, cross-forest trusts, etc).

The key benefit here is time to production.  When App Developers or DBAs don't have to worry about standing up an environment (such an MIT Kerberos realm), maintaining and understanding Kerberos, it's easier to focus on the tasks around MongoDB.  Active Directory is your Kerberos infrastructure and Centrify is the enabler.

From a business perspective consistency is preserved by eliminating duplication of capabilities and processes.
From a security perspective, the access model remains the same and no additional attestation mechanisms need to be created.
From the user's perspective they are more productive because we can eliminate an additional authentication prompt (remember how bad it looked when we saw the plaintext passwords on the screen?)

Another benefit is the utilities like adkeytab that allow for the provisioning and maintenance of service accounts and kerberos key tables in your systems.  MongoDB uses the GSSAPI interfaces to provide Kerberos authentication.

Moderation note:  This post requires that you understand the basics of Active Directory and Kerberos.  If any of these terms: domain controller, kdc, service principal name, user principal name, TGT, TGS, DNS, etc, are foreign to you, please do some background study.

Basics:  What is GSSAPI?

Wikipedia:  "The Generic Security Service Application Program Interface (GSSAPI, also GSS-API) is an application programming interface for programs to access security services.."


The key here is that MongoDB supports Kerberos via the GSSAPI interfaces, Since Centrify makes Kerberos work effortlessly , the implementation is relatively simple:
Integration - MongoDB GSSAPI.jpg
MongoDB will start with GSSAPI authentication enabled and will use the key table file (keytab file) of an AD service account that has a UPN set to mongodb/<fqdn of system>@DOMAIN and an SPN set to mongodb/<fqdn of system>.  This will allow for it to request a ticket-granting-ticket or a service ticket depending on the call.

 

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: http://docs.mongodb.org/manual/tutorial/install-mongodb-enterprise-on-red-hat-or-centos   (use CentOS to follow along) - I will be elevating with dzdo:

Use adkeytab to create the service account and key table file for MongoDB

Adkeytab has been discussed previously here.  Remember that when you use it, the service account's password is randomized;  this eliminates the risk of several people knowing the credentials of a shared account, however, makes the burden around protecting the keytab file.  Make sure you have protocols around this.  If you're using separation of duties, the UNIX admin may not have the rights to create a service account in AD, so you have to work in cooperation with the AD team. 
Note:  Remember that the Centrify Kerberos tools are in the /usr/share/centrifydc/kerberos/bin directory.

Step 1:  Understand the adkeytab parameters:

  • this is a new account  (the -n option is required)
  • credentials are required to create the new account (-u <ad user that can create>) 
    e.g. jerry.seinfeld  (the AD admin in my environment)
  • a key table file will be created (-K /path/to/file)
    e.g. /etc/mongodb.keytab
  • An OU for service accounts in AD will be used (-c "dn of ou")
    e.g. "ou=Service Accounts"
  • A UPN will be specified (-U service/principal@REALM)
    e.g. mongodb/cen3.corp.contoso.com@CORP.CONTOSO.COM
  • A SPN will be specified (-P service/principal)
    e.g. mongodb/cen3.corp.contoso.com
  • The UserName (samAccountName) will be different than the cn (-S name)
    e.g. mongodb.service  (note:  the limit here is 20 chars)
  • The final parameter is the cn
    e.g. mongodb

Step 2:  Run adkeytab in verbose mode  (elevated to be able to copy on /etc)

 

$ dzdo adkeytab -V -n -u jerry.seinfeld -K /etc/mongodb.keytab -U mongodb/cen3.corp.contoso.com@CORP.CONTOSO.COM -P mongodb/cen3.corp.contoso.com -c ou="Service Accounts" -S mongodb   mongodb

ADKeyTab version: CentrifyDC 5.2.0-218
Options
-------
use machine ccache: no
domain: corp.contoso.com
server: null
gc: null
user: jerry.seinfeld
container: ou=Service Accounts
account: mongodb
trust: no
des: no
jerry.seinfeld@CORP.CONTOSO.COM's password:
Attempting bind to corp.contoso.com site:CorpHQ server:dc1.corp.contoso.com: ccache:MEMORY:0x5666c0
Bind successful to server dc1.corp.contoso.com
Attempting bind to GC domain:corp.contoso.com site:CorpHQ gcserver:dc1.corp.contoso.com ccache:MEMORY:0x5666c0
Bound to GC server:dc1.corp.contoso.com domain:CORP.CONTOSO.COM
Searching for AD Object: filter = (samAccountName=mongodb.service), root = DC=corp,DC=contoso,DC=com
Searching for AD Object: filter = (samAccountName=mongodb.service$), root = DC=corp,DC=contoso,DC=com
AD Object not found.
Building Container DN from OU=SERVICE ACCOUNTS
Account 'CN=mongodb,OU=SERVICE ACCOUNTS,DC=corp,DC=contoso,DC=com' does not exist
Search for account in GC: filter = (samAccountName=mongodb.service), root = DC=CORP,DC=CONTOSO,DC=COM
SAM name 'mongodb.service' not found in GC
Problem to create account; try again with no password required
Searching for AD Object: filter = (samAccountName=mongodb.service), root = DC=corp,DC=contoso,DC=com
AD Object found: CN=mongodb,OU=Service Accounts,DC=corp,DC=contoso,DC=com
Key Version = 1
Adding managed account keys to configuration file: mongodb
Changing account 'mongodb' password with user 'jerry.seinfeld@CORP.CONTOSO.COM' credentials.
Searching for AD Object: filter = (samAccountName=mongodb.service), root = DC=corp,DC=contoso,DC=com
AD Object found: CN=mongodb,OU=Service Accounts,DC=corp,DC=contoso,DC=com
Key Version = 2
Success: New Account: mongodb

 

 

Step 2:  Verify the AD user account attributes and make sure you can get a TGT and a TGS with the keytab  (elevating to read from /etc)

 

$ adquery user -PS mongodb
userPrincipalName:mongodb/cen3.corp.contoso.com@CORP.CONTOSO.COM
serverPrincipalName:mongodb/cen3.corp.contoso.com

 

$ dzdo /usr/share/centrifydc/kerberos/bin/kinit -kt /etc/mongodb.keytab mongodb/cen3.corp.contoso.com@CORP.CONTOSO.COM


$ dzdo /usr/share/centrifydc/kerberos/bin/klist                                                               Ticket cache: FILE:/tmp/krb5cc_1149240408
Default principal: mongodb/cen3.corp.contoso.com@CORP.CONTOSO.COM

Valid starting     Expires            Service principal

10/25/14 14:19:40  10/26/14 00:19:40  krbtgt/CORP.CONTOSO.COM@CORP.CONTOSO.COM

        renew until 10/26/14 14:19:40
 
$ dzdo /usr/share/centrifydc/kerberos/bin/kinit -kt /etc/mongodb.keytab -S mongodb/cen3.corp.contoso.com@CORP.CONTOSO.COM mongodb
 
$ dzdo /usr/share/centrifydc/kerberos/bin/klist

Ticket cache: FILE:/tmp/krb5cc_1149240408
Default principal: mongodb@CORP.CONTOSO.COM

Valid starting     Expires            Service principal
10/25/14 14:20:00  10/26/14 00:20:00  mongodb/cen3.corp.contoso.com@CORP.CONTOSO.COM
renew until 10/26/14 14:20:00

 

Step 3: Secure the Keytab

 

Copy the keytab to /var/lib/mongo

$ dzdo mv /etc/mongodb.keytab /var/lib/mongo/mongodb.keytab 

 Change the owner of the keytab to mongod

$ dzdo chown mongod:mongod /var/lib/mongo/mongodb.keytab 

 
Set up a test user and configure MongoDB for GSSAPI authentication

Note:  If you don't know how to properly set up users in Mongo and you're following along from the SASL posting, just disable auth and create the user.  We will reenable it later.

Step 4:  Make sure that SASL is configured to work with PAM and identify the path for the socket.

$ mongo
> use $external
switched to db $external
> db.createUser({user: "j.peterman@CORP.CONTOSO.COM",roles: [ { role: "read", db: "reporting" }]})
Successfully added user: {
        "user" : "j.peterman@CORP.CONTOSO.COM",
        "roles" : [
                {
                        "role" : "read",
                        "db" : "reporting"
                }
        ]
}

 

The result should be success.  Keep in mind that the user's domain has to be in CAPS.

Step 5:  Set the KRB5_KTNAME environment variable for the keytab

vi /etc/sysconfig/mongod

 and add this line:

export KRB5_KTNAME=/var/lib/mongo/mongodb.keytab

 
Step 6:  Edit the mongodb.conf file to enable GSSAPI

Comment out the bind_ip directive. For Kerberos SSO to work, you must bind over the network.

Otherwise the appropriate will be localhost versus the actual hostname of the system

 

#bind_ip=127.0.0.1

 
Re-enable authentication.  Note that you can enable both SASL and GSSAPI

auth=true
setParameter=saslauthdPath=/var/run/saslauthd/mux
setParameter=authenticationMechanisms=PLAIN,MONGODB-CR,GSSAPI

 
Restart MongoDB and make sure there are no errors.

$ dzdo service mongod restart

 
Test GSSAPI/Kerberos authentication

Step 7:  Log in to the system with the externally identified user that was created with the full UPN, inspect the Kerberos TGT.

$ /usr/share/centrifydc/kerberos/bin/klist
Ticket cache: FILE:/tmp/krb5cc_1149240919
Default principal: j.peterman@CORP.CONTOSO.COM

Valid starting     Expires            Service principal
10/25/14 15:23:35  10/26/14 01:23:35  krbtgt/CORP.CONTOSO.COM@CORP.CONTOSO.COM
        renew until 11/01/14 15:23:35
10/25/14 15:25:13  10/26/14 01:23:35  mongodb/cen3.corp.contoso.com@CORP.CONTOSO.COM
        renew until 11/01/14 15:23:35

 
Notice that during login, Centrify will automatically kinit and enable your TGT.

Step 7:  Launch mongo with the system name and perform the testing.

$ mongo cen3.corp.contoso.com
MongoDB shell version: 2.6.5
> db.getSiblingDB("$external").auth({mechanism: "GSSAPI",user:'j.peterman@CORP.CONTOSO.COM',})
1

 


This proves that authentication with Kerberos/GSSAPI was succesful.

> db.getSiblingDB("$external").auth({mechanism: "PLAIN",user:'j.peterman',pwd:'<jp's password>',digestPassword: false})
1

 
Both GSSAPI and SASL Plain can be used simultaneously.  Kerberos is superior due to the fact that the user eliminates one prompt and a readable password.

 

In Summary, with Centrify:

- Faster and more secure delivery of your App/Database capabilities with MongoDB

- A robust access controls model leveraging AD

- No duplication of capabilities (technology, processes, knowledge)

Want to learn more about practical Centrify examples? Check out my blog at http://centrifying.blogspot.com
Follow Centrify:
Highlighted
Centrify Guru I
Posts: 2,430
Registered: ‎07-26-2012
#5 of 5 27,590

Re: MongoDB-AD Integration made easy with Centrify

[ Edited ]

Video playlist that contains all the steps above.

Want to learn more about practical Centrify examples? Check out my blog at http://centrifying.blogspot.com
Follow Centrify: