Alex Komyagin

1 result

MongoDB LDAP and Kerberos Authentication with Dell (Quest) Authentication Services

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.6, 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.6 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 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 $ sudo reboot $ hostname -f 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 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 ./ 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 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. 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 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' Test SASL configuration by verifying that user “alex” can log in from this machine using the “mongodb” servicename: $ testsaslauthd -u alex -p

January 27, 2015