-
Notifications
You must be signed in to change notification settings - Fork 13
LDAP over SSL
Some AD objects can be modified without running an ldaps connection. Things like passwords however, cannot.
This is a guide to getting ldaps running on a *nix machine.
Check that you have LDAP and OpenSSL support by performing creating a php webpage like:
<?php phpinfo(); ?>
And then viewing it on your server. Look for a table with the heading 'openssl' and a row in that table where it says: "OpenSSL support enabled"
If not, check your distribution specific documentation on how to install OpenSSL.
There are two types of setup you can have here. The first is a Certificate Authority (CA) that is configured as an Enterprise CA on your local domain or as simply a request to a Third Party CA. The second type of CA is a Standalone CA on your local domain.
The request methods are very similar but without precise command line arguments you'll find one or other won't work correctly.
We'll try to document both methods here as best we can. Much of this information has been compiled through trial, error and testing on both development and live Domain Controllers
This guide is for using Enterprise or Third Party Certificate Authorities
LDAP over SSL is not enabled by default on domain controllers, you must configure this by installing Certificate Services.
If you follow this guide from Microsoft you should be able to get SSL enabled.
In my own installation I came across a few stumbling blocks that may or may not affect you. If you use an external CA for your SSL certificate, rather than an self-signed one you probably won't get this problem!
After generating the .req request file running the recommended certreq -new request.inf request.req and then using the Certification Authority console, and attempt to submit the request - no go. Lo and behold, Microsoft KB 910249 came and bit me.
Certificate Request Processor
The request contains no certificate template information. 0×80094801 (-2146875391) Denied by Policy Module 0×80094801, the request does not contain a certificate template extension or the Certificate Template request attribute.
Microsoft's resolution: Generate the request some other way.
Stuff that.
Here's the solution I found after 5 minutes with Google
certreq -submit -attrib "CertificateTemplate: DomainController" request.req
The key is the extra attribute we add to force use of the template. The certificate is issued.
However I still had a problem with a DNS error message. In the end I actually used the IIS based certificate manager at http(s)://<IP of server>/certsrv and issued the certificate that way, then back the Microsoft guide.
This guide is for running Standalone Certificate Authorities, they cannot follow the same processes as Enterprise level CAs and will result in errors when trying to accept the certificates to the domain controller
This is based on the information from the Microsoft TechNet Article: Advanced Certificate Enrollment and Management
Firstly from your domain controller, run the following .vbs script
This will create the following files
- DC_Name.asn
- DC_Name-req.bat
- DC_Name-vfy.bat
- DC_Name.b64
- DC_Name.bin
- DC_Name.inf
The only two files we are interested in are the .inf and .asn files.
Now from the command line prompt call the following (replacing request.inf with the actual names of your files)
certreq -new request.inf request.req
This will create a file called request.req
We then copy the request.req and the .asn files over to the CA. This is where things get more complicated.
Again from the command line we need to run
certreq -attrib "CertificateTemplate:DomainController" request.req
This will give us a request ID, this is important, make a note of it.
certutil -setextension <RequestID> 2.5.29.17 1 @<dcname>.asn
What Microsoft also doesn’t tell you here, is that if you are using Windows Server 2008, this command will not work unless you have loaded the command prompt with elevated priviledges (UAC). The subject alternative name, which is identified by the object identifier 2.5.29.17, is set with the attributes that are defined in the .asn file. The fourth parameter that is set to “1” marks the extension as critical.
The TechNet Processing Domain Controller Certificates article mentions how to validate the certificate request is good, however we are assuming these tests come back as positive so next we need to issue and retrieve the certificate.
From the CA now run
certutil –resubmit <RequestID>
and then finally
CERTREQ -retrieve <RequestID> <dcname>.cer <dcname>.p7b
You will now have a .cer and a .p7b file which you can copy back to the domain controller.
To install the certificate, from the command line on the domain controller
CERTREQ -ACCEPT <dcname>.p7b
Microsoft tells you to restart the Domain Controller. In our experience this was not necessary and SSL over LDAP was available immediately
Apparently you are supposed to now export the CA certificate, and for some installations you may need to do this, and install it on your web server. I have not had to do this in any of my tests. In my tests, after installing the certificate on the domain controller I was able to connect over LDAPS immediately.
Do a phpinfo() and check where the HOME variable points to in the Apache environment. Create a symbolic link or copy ldap.conf to this location.
If you get a connect error may be because your local OpenSSL installation doesn't recognise the certificate (or its authority) provided by the server. This can be circumvented by adding the following line to ldap.conf on your server or similar:
Change TLS_REQCERT allow to TLS_REQCERT never
Before trying the TLS_REQCERT allow to TLS_REQCERT never, you should set the ca cert from your DC in ldap.conf. You do this by adding TLS_CACERT /path/to/cert to ldap.conf. TLS_REQCERT never could make you vulnerable to man in the middle attacks. The cert will need to be readable by Apache.
Apache must be able to read ldap.conf, you cannot skip this step.
This is probably the most generic error. Use the console to check to make sure you can actually get a connection. There's no point chasing problems in PHP if you can't do it from the console.
ldapsearch -H "ldaps://dc01.mydomain.local" -b "" -s base -Omaxssf=0
The ldapsearch should spit back a whole bunch of stuff. If it doesn't, you need to troubleshoot the error message it gives you. Optionally add -d7 (debug level) to the command line above.
From the domain controller itself you can test if LDAP over SSL works
- Start the Active Directory Administration Tool (Ldp.exe).
- On the Connection menu, click Connect.
- Type the name of the domain controller to which you want to connect.
- Type 636 as the port number.
- Click OK
RootDSE information should print in the right pane, indicating a successful connection.