In the almost two years of Centrifying we have discussed Identity Consolidation with AD and Single Sign-on at length. 90% of organizations have Active Directory but sometimes over-complicate things when it comes to identity consolidation and SSO.
I had the chance to speak about this in a seminar and these two videos consolidate many entries that we've covered in this blog over the years.
Direct Integration
Name Service Switch, Pluggable Authentication Modules, GSSAPI, Kerberos and Proxies
OpenSSH SSO over an outgoing external non-transitive AD one-way trust
NSS and PAM using Oracle DB as an example (externally identified user)
The idea is to eliminate complexity and promote reuse by committing to Active Directory, let the Centrify DirectControl agent do the heavy-lifting for Direct Integration and use the SPNEGO plugins when needed.
For the full briefing, including marketing slideware go here.
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.
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.
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)
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.
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.
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.
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:
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
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:
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 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
In Access Manager, navigate to Zone > Authorization > UNIX Rights Definitions > PAM Access
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:
