Enabling Active Directory LDAPS

A start point of a set of posts about how to enable Active Directory LDAPS support, and using it as basis of a wide spread auhtentication mechanism integration.

One of the most straight-forward integration technologies available today, authentication is one of the biggest weaknesses around the Corporate environments. Within a huge talk about Cloud services, applications and outsourced services, here in Italy it mostly comes to a great chit-chat about heterogeneous platforms, applications and systems, all with their own authentication mechanisms. When talking about authentication failure, the most amazing example I have found relies in the “Minority Report” 2002 movie. If you seen the movie, you might remember how John Anderton have his eyes transplanted and uses his own to “badge” the access control of the Police Station and gets in, even after being classified as a criminal, chased by the police and even closed in prison (his wife actually is able to use the same trick to get in). Well this massive fail of authentication and access control to applications happens everyday in Corporate environments.

Albeit I will not be discussing in this post about a real integration issue, this is a first post of some that has some basics about Authentication integration and consolidation.

In real world different authentication mechanisms exists. On Linux you may want to use Kerberos or LDAP authentication for centralized management and accounting of different services, which of course is much more natural when speaking of Microsoft Active Directory. Several software and/or appliance makers allow the integration with standard authentication mechanisms, to allow centralized user, accounting and authorization management. At last, why should I have a checklist of systems to verify when enabling or disabling a user, when I can control everything from a single management point, which also gives me built-in reliability and availability? IT time is a cost for any Company, therefore reducing it to the lowest level is the best choice you might want to consider working on.

I will mostly used Active Directory as my start point because it is the broadest authentication system within Companies, in particular those in the SMB segment. Active Directory is also extremely versatile and prone to customization (even if this requires a bit more of hacking) and allows very diverse and distributed deployments. At its base we can find, for the most part, RFC-compliant protocols, which are Kerberos (v5) and LDAP.

Many applications or appliances, indeed, require a secure access to your Active Directory, or more precisely LDAPS connection. By default Mictosoft Windows starts your Domain Controllers without the SSL support for LDAP (Lightweight Directory Access Protocol), but be aware that LDAP does NOT contain user credentials. Those are managed by the Kerberos Distribution Center (KDC). In any case, LDAP can contain some sensitive data which, if sniffed or intercepted, might enlarge the surface of a possible attack, exposing your network infrastructure (for example, by enumerating the sites). When talking about security appliances, such as Watchguard, Stonesoft or Fortinet, access to your directory has to be secure.

Unless you have a really wide and complex Active Directory structure, typical of Enterprise environments and not likely of SMB companies, you shouldn't install a CA server within your Organization. It brings an incredible set of conditions to be met and consequences in the long-period, most importantly you can NOT move your CA root server from one machine to the other without deep knowledge and how to do it. If you plan to deploy a CA server you might want to consider a talk with an MCSE-grade System Administrator that had successfully deployed and recovered Certification Authority services.

This post (the introduction is finished) shows how to start Active Directory using common tools like OpenSSL on a Windows 2008R2 single Domain Controller environment, and will be shortly followed by a multi-DC environment too, since it's the most common case for me. The reason why I don't want to use an Internal CA infrastructure is the overall complexity of the system. Also the goal of this initial scenario includes the following secondary (and future described goals):

1. installation and configuration of the Watchguard Server Center with Active Directory authentication
2. certificate use and distribution for HTTPS content-filter policy

Creating and Installing Certificates on a Windows 2008R2 Domain Controller

So lets get started. What we need is:

- OpenSSL on either a Linux or Windows Box installed
- a Microsoft Windows Server 2008R2 Domain Controller correctly working

Build the CA key pair

The first thing you need to build is the CA key pair. This will be used to sign any certificate request in future, and to prove that given (issued) certificate is valid.

# openssl genrsa -des3 -out ca.key 4096
# openssl req -new -x509 -days 3650 -key ca.key -out ca.crt

Be aware that the days parameter is the maximum age of your certificate. Once the certificate expires, all issued certificates will be also expired. A security measure wants the certificate to be valid for a period of time no too long so it can not be brute-forced. In many SMB environments this value (~10 years) should be acceptable. In larger more complex environments you might want to consider the CA infrastructure alternative.

At the end of the above commands you will be asked for a passphrase. This should be really strong and stored safely, since it's used to access the Private Key and is vital for issuing new certificates. So give it a strong one and keep it safe.

When building the CA certificate you will also be asked for information about who or what (in our case the Company) it represents. For our example I used the following details:

Country Name (2 letter code) [XX]:IT
State or Province Name (full name) []:MI
Locality Name (eg, city) [Default City]:Milano
Organization Name (eg, company) [Default Company Ltd]:En3pY Labs
Organizational Unit Name (eg, section) []:IT
Common Name (eg, your name or your server's hostname) []:en3pylabs.domain
Email Address []:training@en3pylabs.com

You should now have two files in your working directory: ca-new.key and ca-new.crt. Also you might want to write down the expiration date in your IT documentation for future use and reminder.

Installing the certificate on the Domain Controller

Once your certificate is ready, you're required to install it on your Domain Controller. Copy (if you don't have it already) the .crt file on your DC, and then start the Microsoft Management Console:

1. Start > Run > mmc.exe
2. On the Management console click "File" > "Add or Remove Snap-ins"
3. in the dialog windows scroll to locate "Certificates" then click "Add >"
4. A new dialog box opens: choose "Computer Account" then click Next
5. Choose "Local Computer" then click "Finish"
6. Click "OK" to return to the MMC

In the MMC you should now see the Certificates (Local Computer) management snap-in. Explode the tree and locate the "Trusted Root Certification Authorities" item. Right click on it and in the context menu choose "All tasks" then "Import..." as figured in the picture below.

Once your certificate has been imported you should see it listed within the Root Certification Authority certificates.

Distributing the Root Certificate

In order to make all certificates issued by the newly created CA within your domain, you might want to distribute the root certificate to all computers in the domain. To accomplish this you can use the Group Policy Management Console (GPMC) and edit the default domain policy, adding the certificate to the domain Trusted Root CAs.

Therefore you need to:

1. Open the Group Policy Management Console (shortcut: "Start" > "Run" > "gpmc.msc")
2. Browse the tree until you get to the Group Policy Object named "Default Domain Policy" (picture 2)
3. Right click the Default Domain Policy and click Edit to open the Group Policy Editor
4. Browse to "Trusted Root Certification Authorities" like in picture 3
5. Import the root CA certificate the same way you did in previous step
6. Close the Group Policy Editor and the GPMC

Picture 2: Default Domain Policy object location:

Picture 3: Trusted Root Certification Authorities location in Group Policy editor

If on any computer of the domain you issue the command:

C:\Users\Administrator\Desktop> gpupdate /force

You should be able to see the Root CA certificate listed in the Computer's Certificates snap-in. All the certificates issued by your Root CA will now be recognized and considered valid by any computer within your domain.

Building your domain controller certificate

On your domain controller you need to build a Certificate Request (CSR) in order to issue a new certificate for that server. Albeit you can use OpenSSL for that purpose, the use of built-in OS tools is always preferred. We will indeed use the certreq tool built-in in Windows. To build the CSR we need to determine the subject of the certificate itself, as well as define the scope of the certificate, which is "Server Authentication". You need to build a .inf file where to define those details. We'll build a file named "request.inf" in our working directory (say Desktop) with the following content:

;----------------- request.inf -----------------
[Version]

Signature="$Windows NT$"

[NewRequest]
Subject = "CN=lab-dc.en3pylabs.domain,OU=IT,DC=lab-dc,DC=en3pylabs,DC=domain,O=En3pY Labs,L=Milan,S=Milan,C=IT"

KeySpec = 1
KeyLength = 1024
Exportable = TRUE
MachineKeySet = TRUE
SMIME = False
PrivateKeyArchive = FALSE
UserProtected = FALSE
UseExistingKeySet = FALSE
ProviderName = "Microsoft RSA SChannel Cryptographic Provider"
ProviderType = 12
RequestType = PKCS10
KeyUsage = 0xa0

[EnhancedKeyUsageExtension]
OID=1.3.6.1.5.5.7.3.1

The above "Subject" have to contain the domain controller Fully Qualified Domain Name and further information about the issued certificate, similar to the information you gave in the root certificate creation. Once the file is ready and saved issue the CSR creation:

C:\Users\Administrator\Desktop\> certreq -new request.inf dc.csr

Get the dc.csr (Domain Controller) file on the box where you  have OpenSSL ready and then issue the certificate using your CA. The command line to build a new certificate from the CSR file is:

# openssl x509 -req -days 3650 -in dc.csr -CA ca.crt -CAkey ca.key -set_serial 01 -out dc.crt

You may now take back the dc.crt on your DC desktop and accept it:

C:\Users\Administrator\Desktop\> certreq -accept dc.crt

Within my enviornment the command, once issued, imported automatically the certificate into the system.

Once rebooted the server had LDAPS port 636/tcp listening and the directory was accessible via LDAP over SSL. If your system is out of the domain, you might want to install the CA certificate on it so it can automatically trust the domain controller's own certificate.

Disclaimers & Credits

This documentation is provided as-is and it is your own responsibility to apply this solution in a working environment. The documentation has been written as it was tested in a lab environment based on Microsoft Windows 2008R2 server trial edition. Proof concept of this article has been read on this blog by Peter Borissow. Rest of work has been done on Fedora Linux, OpenSSL, GIMP. For any further information feel free to contact me.