Both Active Directory (AD) and OpenLDAP play important roles in the enterprise. In fact, within the same company you’ll find the UNIX group using OpenLDAP and the LAN and Windows administrators using AD. However, most people are unable to fully access the AD schema via OpenLDAP. In this article we will consider how to configure Active Directory Authentication with LDAP over Proxy with Transport Layer Security/SSL.
OpenLDAP and AD can peacefully coexist— the key is finding the best way to allow LDAP operations to cross the boundaries between AD and OpenLDAP deployments. One way to make this happen is to configure Active Directory Authentication with LDAP over TLS/SSL. Our main goal is to integrate our LDAP with Active Directory. We will include some schema into main configuration file and add required parameters.
Before we get started
Before moving on, let’s define terminology. First, an LDAP server is actually what is known as a Directory Service Agent (DSA). Second, a DSA manages either part or all of a Directory Information Tree (DIT). Several DSAs may be deployed to manage an entire DIT as well as to allow for replication and high availability. The portion of the DIT that a DSA manages is known either as a partition or database. We will use the term database.
Make sure OpenLDAP is up and running
The OpenLDAP server process is named slapd, which stands for “stand-alone LDAP daemon.” It provides almost all of the OpenLDAP server functionality, including the ability to accept connections from LDAP clients, process queries and updates, and implement the ACLs that restrict access to confidential information within the directory.
Let's consider that you have already installed and configured OpenLDAP.
According to the configuration above, slapd manages a database for the directory tree dc=example,dc=com.
Please make sure that slapd service is running.
service slapd status
Now, we will test that our entries (from the same sample configuration provided in this article) loaded properly by using ldapsearch command.
ldapsearch -LLL -x -h localhost -b 'dc=example,dc=com'
The -x option specifies that ldapsearch should use simple authentication instead of Simple Authentication and Security Layer (SASL). With simple authentication, the LDAP client sends the credentials in plaintext. Even if you use LDAP over SSL (LDAPS) or LDAP StartTLS, you'are still using simple authentication, but the tunnel being used for communication is encrypted (and far more secure).
Back to the ldapsearch command. It performs a query to find all entries below the root of the tree. As expected, ldapsearch returns all the entries that we originally imported via ldapadd as in the provided example.
Integration with Active Directory
We have easily viewed entries from OpenLDAP by using simple ldapsearch command on our local client, but what about viewing entries that are managed under Active Directory? For that to happen, you need to direct OpenLDAP to Active Directory.
Please make sure that all required modules are included in slapd.conf file:
include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/nis.schema
Next step is to enable openLDAP proxy as Active Directory, please navigate to the end of the slapd.conf and add following lines:
database ldap subordinate rebind-as-user yes uri "ldaps://ad-dc.example.com" suffix "DC=corp,DC=ad,DC=com" chase-referrals yes idassert-bind bindmethod=simple binddn="CN=ad-username,DC=corp,DC=ad,DC=com" credentials="password" tls_cacert=/etc/openldap/certs/certificate_file
database ldap - defined a new back end by using slapd-ldap, which will be our proxy service.
subordinate - without this keyword, slapd searches only the database specified by the search base (e.g., if dc=example,dc=com were the specified search base, then cn=users,dc=example,dc=com would never be examined because it’s a different slapd database).
rebind-as-user - This option tells slapd to bind to the remote Directory Service Agent with the credentials supplied by the client. Please note the the credentials must be valid in AD.
URI - This specifies the remote LDAP server, which in this case is the AD domain controller.
chase-referrals - This option specifies that slapd will chase any referrals automatically.
idassert-bind - This parameter is used to bind to the remote server and optionally authorize another identity.
bindmethod - This statement is used to define what method is used by the proxy to bind to the remote server with the given administrative identity.
In this case we use simple since it is strongly recommended that TLS be used in together with simple bind. Simple bind requires additional parameters:
binddn="CN=ad-username,DC=corp,DC=ad,DC=com" is used to specify a bind DN;
credentials="password" is used to specify the bind credentials;
tls_cacert - Transport Layer Security Certificate Authority certificate defines the path and file name of the certificate that allows the client to verify the LDAP Server certificate. This file can be obtained from the X.509 certificate supplier or in case of self-signed - copied from the LDAP server.
Ok, so now the clients will be authorized as "CN=ad-username,DC=corp,DC=ad,DC=com" even if they actually connected anonymously to the proxy.
Now, restart slapd service and run ldapsearch again
ldapsearch -v -H "ldaps://ad-dc.example.com:636/" -b "DC=corp,DC=ad,DC=com" -s sub -D "CN=ad-username,DC=corp,DC=ad,DC=com" -w "password"
If command fails, please make sure that:
1. You are able to reach ldaps://ad-dc.example.com:636
2. Bind with the credentials supplied by the client (Active Directory side)
You should now be able to attach Active Directory to any part of your OpenLDAP directory. You can authenticate your AD users in LDAP applications that use OpenLDAP or even provide access to multiple ADs in your network if they aren’t all part of a larger forest already.