Active Directory provides a Public Key Infrastructure (PKI) capability with the Microsoft Certificate Authority. This is quite convenient to system administrators especially when combined with Group Policy since it allows for the automation of the Certificate lifecycle: issue, renew, revoke, supersede templates, etc.
We've discussed this before, but Centrified clients can also take advantage of Certificate auto-enrollment. This can happen automatically or manually using the adcert utility.
How it works?
The process works as follows:
When a system is joined to AD using Centrify, as part of the join the system will read the domain controller's SYSVOL for Group Policies. The system may download the trust chain (containing the trusted CAs or the local root CA) and any revocation information to the /var/centrify/net/certs folder.
If the auto-enrollment policy that applies to the system points to a usable template, the agent will attempt to enroll automatically when the GPO refresh interval starts. Note: there are different auto-enrollment GPOs depending on the version of Active Directory.
The agent will use the computer's credentials with the adcert utility and connect to the CA or Intermediate CA to obtain a certificate set for autoenrollment.
adcert will issue pkcs10 request for each template, if an issuing CA is found for the templates in question and the certificates, chain and private key (if defined exportable by the template) will be placed in the /var/centrify/net/certs folder with this format: [name of template].cert [name of template].key [name of template].chain
Once the certificate is in your system, you may be able to use it as is, or you may have to change the encoding using OpenSSL tools.
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).
With a
privileged user, install the Centrify agent. rpm –Uvh centrifydc-<version>
(e.g. centrifydc-5.2.2-rhel3-x86_64.rpm)
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)
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
Install
the Centrify LDAP Proxyrpm
– Uvh centrify-ldapproxy-<version> (e.g.
centrifydc-ldapproxy-5.2.2-rhel3-x86_64.rpm)
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
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)"
Your search should yield results.
Step 3 – Install and Configure and Test saslauthd 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
Test
saslauthd for LDAPUse the testsaslauth script to test LDAP authentication:/usr/sbin/testsaslauthd
-u george.constanza -p <cleartextpw> -f /var/run/saslauthd/mux
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
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
Provided
that your firewall ports are open, you can go to a browser and navigate to the
Couchbase admin page: http://your-hostname:8091
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
Log in
to the couchbase administrative interface with your administrator account.
Navigate
to Settings > LDAP Auth Setup
Under
Setup, check the Enable Checkbox and press Save.
Add a
Full or Read-Only administrator (I used the AD username, since my LDAP filter uses samAccountName). E.g. George.Constanza
To test
the user, use the Validate box.
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.
