Labs: Using Couchbase's upcoming LDAP functionality with AD leveraging Centrify’s LDAP Proxy

Background

Couchbase is including LDAP support in the upcoming March release and we wanted to preview how to leverage your existing Centrify assets to help with this scenario.  The instructions below are for testing purposes only.
This capability will provide the ability to use LDAP users (From AD or other LDAP directories) to be provisioned as Full or Read-only administrators of the web console.

About this configuration

In this configuration  Couchbase is using saslauthd to connect to LDAP.  By leveraging the Centrify LDAP Proxy, this configuration can benefit from the robust capabilities of the Centrify agent (AD sites and services awareness, performance, caching, etc).

What’s required?

• Couchbase Server 3.5.x:  http://latestbuilds.hq.couchbase.com/couchbase-server/sherlock/1415/couchbase-server-enterprise-3.5.0-1415-centos6.x86_64.rpm
• Centrify Agent + LDAP Proxy:  http://www.centrify.com/products/server-suite/active-directory-bridge/
• Cyrus-SASL (saslauthd):  http://linux.die.net/man/8/saslauthd

Instructions (All steps on CentOS 6.x)

Step 1 – Install the Centrify Agent and join AD

1. With a privileged user, install the Centrify agent.
   rpm –Uvh centrifydc-<version>  (e.g. centrifydc-5.2.2-rhel3-x86_64.rpm)
2.  Check if all is OK to join Active Directory
   adcheck <your domain>  (e.g. adcheck corp.contoso.com)
   Make sure you fix any issues (e.g. DNS, DC connectivity, etc)
3. Join active directory (you’ll need an account that can join computers in AD)
   adjoin –z Model –c “ou=Servers,ou=UNIX” –u jerry.seinfeld -V corp.contoso.comJoins the corp.contoso.com in Centrify zone mode (Model) mode, and places the computer on the /UNIX/Servers OU and uses jerrry.seinfeld's  account for the corp.contoso.com domain.

Step 2 – Install, configure, start and test the Centrify LDAP Proxy

1. Install the Centrify LDAP Proxyrpm – Uvh centrify-ldapproxy-<version>  (e.g. centrifydc-ldapproxy-5.2.2-rhel3-x86_64.rpm)
2. Elevate and start the proxy manually or configure a startup script.  For example
   dzdo /usr/share/centrifydc/libexec/slapd  -f /etc/centrifydc/openldap/ldapproxy.slapd.conf -h ldap://cen1.corp.contoso.com
   This makes the LDAP proxy to start reading the indicated startup file and listens to the hostname cen1.corp.contoso.com
3. To test that the LDAP proxy is responding to queries, use ldapsearch:$ /usr/share/centrifydc/bin/ldapsearch -h cen1.corp.contoso.com -x -b "ou=staff,dc=corp,dc=contoso,dc=com" "(cn=George Constanza)"
4. Your search should yield results.

Step 3 – Install and Configure and Test saslauthd for LDAP

1. Install cyrus-sasl (saslauthd)$ dzdo yum install cyrus-sasl
2. Configure SASL for LDAP

• a.       Edit the /etc/sysconfig/saslauthd and make sure the MECH parameter is set to LDAPMECH = ldap
• b.      Configure the LDAP parameters for SASL the config file should be on /etc/saslauthd.conf. You need to add the ldap_server parameter (the system running the Centrify LDAP proxy) as well as your search base and the attribute that corresponds to the user name.  With Centrify you can use the AD name (samAccountName) or the uid contained in the PosixAccount class.  In my test scenario:
  ldap_servers: ldap://cen1.corp.contoso.comldap_search_base: ou=Staff,dc=corp,dc=contoso,dc=com=ldap_filter: (samAccountName=%u)
  
  Note that in a production environment you’ll use multiple proxies for HA and secure LDAP (ldaps://) and most likely your Couchbase configuration will be clustered.  Use the same availability controls for the Authentication that you are using for the cluster.
• c.       Start the saslauthd service (or set it to start automatically with chkconfig)$ dzdo service saslauthd start

1. Test saslauthd for LDAPUse the testsaslauth script to test LDAP authentication:/usr/sbin/testsaslauthd -u george.constanza -p <cleartextpw> -f /var/run/saslauthd/mux
2. If everything is well set up, the output should be:  0: OK "Success."

Steps 1 to 3 - Potential misconfigurations:

• Firewall ports are not open for LDAP
• The Proxy is not started or hasn't started with the appropriate protocol or hostname.
• The configuration of saslauthd is incorrect (look at /etc/sysconfig/saslauthd OR /etc/saslauthd.conf)
• Your LDAP filters are not correct.

Step 4 – Install Couchbase and Perform Initial Setup

Official instructions here: http://docs.couchbase.com/admin/admin/Install/rhel-installing.html

1. Obtain the new bits that support LDAP: wget http://latestbuilds.hq.couchbase.com/couchbase-server/sherlock/1415/couchbase-server-enterprise-3.5.0-1415-centos6.x86_64.rpm
2. Add the following lines to the /etc/rc.localfor i in /sys/kernel/mm/*transparent_hugepage/enabled; doecho never > $i; donefor i in /sys/kernel/mm/*transparent_hugepage/defrag; doecho never > $i; done 
3. Save and reboot the server.
4. Install couchbase$ dzdo rpm --install couchbase-server-version.rpm
5. Provided that your firewall ports are open, you can go to a browser and navigate to the Couchbase admin page:  http://your-hostname:8091
6. Follow the steps to complete the initial configuration (hostname, cluster, sample apps, Administrative user, etc)

Note: In my environment I performed a reboot.  Keep in mind that if you ran the Centrify LDAP proxy manually, you need to launch it again and restart saslauthd before the next step.

Step 4 – Set up Couchbase for LDAP and test settings

1.  Log in to the couchbase administrative interface with your administrator account.
2. Navigate to Settings > LDAP Auth Setup
3. Under Setup, check the Enable Checkbox and press Save.
4. Add a Full or Read-Only administrator
   (I used the AD username, since my LDAP filter uses samAccountName).  E.g. George.Constanza
5. To test the user, use the Validate box.
   
6. Sign out of the Console.  Attempt login with the newly assigned Admin.   If your admin is Full, they’ll get access to all the settings, if they are read-only, they’ll get the settings grayed out.

Summary

Setup was fairly simple using the Centrify LDAP proxy.  The benefits are tangible because the underlying adclient agent serves as a way not to have to maintain multiple LDAP entries and for additional performance gains.  Keep in mind, this was a "quick-and-dirty" setup, in reality you would have to account for LDAPS and HA.

As far as Couchbase goes, I was very impressed with how simple it was to set up and things just worked. They have been adding security features incrementally, and we are hoping that we can see them leverage PAM, Kerberos, PKI and to be able to leverage NSS UNIX users/groups for at least administrative interfaces; this will enable Centrify users to expose AD capabilities and accelerate the security posture of the platform.  We are keeping our eyes and ears locked on these newer technologies.

Quick Video Playlist (11 minutes total)

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:

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

Principals are OK.

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

[cosmo.kramer@cen3 ~]

$ 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

TGT successful.

$ 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

TGS successful

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

Output of 1 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 ad a readable password.

Video

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:
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?

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 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: 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:

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 for the socket.

$ 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)
$ 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     pam_centrifydc.so
auth       requisite      pam_centrifydc.so deny
account    sufficient     pam_centrifydc.so
account    requisite      pam_centrifydc.so deny
session    required       pam_centrifydc.so homedir
password   sufficient     pam_centrifydc.so try_first_pass
password   requisite      pam_centrifydc.so 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=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"}]})

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:

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.

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: