What risks should I be aware of that we're facing by not using SSL
Requests by domain members will use SASL (see: LDAP Security Model section in this doc)
Requests not from a domain member or client able to use SALS can be intercepted. Internally, this may not be that big of a deal since you probably have a switched network, and good control of your physical infrastructure.
If I follow one of the million guides on the internet to enable SSL, will it interrupt current service? Or will I be able to do it and the client machines will some how be informed to use SSL automatically?
It should not interrupt current service. Some clients (like your Dell LOM) will need configuration to use the SSL port, if the are currently working, and you want to enable SSL. You shouldn't have to do anything on your Windows servers/workstations.
I have two DCs running a single domain as domain.local. Since it's an "internal" TLD, I'm guessing I'll need to set this up using an internal CA and not a third party?
You can do either, you can even use a self-signed certificate. Some clients won't like this a self signed certificate, but your Drac probably would be fine with a self-signed certificate.
Setting up an enterprise CA is relatively easy, but it should really be on a box/vm just for this purpose. Can you afford a spare Windows license?
You could also run an OpenSSL CA, you could run one from a USB flash drive pretty easily. If you are familiar with Linux, then setting up an Ubuntu box/vm/usb device running tinyca should only take a couple hours.
Based off the answer of #1, would you say it's safe to stay off of SSL? What would you feel is the ratio of benefit to effort involved in getting converted to ssl?
- If you don't trust your physical infrastructure, then you should probably enable SSL.
- If you have a very small number of servers, then it may not be worth the effort.
- You may be able to mitigate the risk using ipsec or some VPN to encrypt the LDAP.
- As Evan mentioned in a comment, the DRAC LOM, is basically providing physical access, so you should strongly consider setting up SSL to protect you from a MITM.
You are looking to get your DCs to support BIND via LDAPS. To do this, you will need to add a certificate to your domain controllers' Personal Certificate Store that meets the following requirements. This certificate could either be from a locally housed Certificate Authority or a Third-Party Authority.
- The LDAPS certificate is located in the Local Computer's Personal
certificate store (programmatically known as the computer's MY
certificate store).
- A private key that matches the certificate is present in the Local Computer's store and is correctly associated with the certificate.
- The private key must not have strong private key protection enabled.
- The Enhanced Key Usage extension includes the Server Authentication (1.3.6.1.5.5.7.3.1) object identifier (also known as OID).
- The Active Directory fully qualified domain name of the domain controller (for example, DC01.DOMAIN.COM) must appear in one of the following places: The Common Name (CN) in the Subject field. DNS entry in the Subject Alternative Name extension.
- The certificate was issued by a CA that the domain controller and the LDAPS clients trust. Trust is established by configuring the clients and the server to trust the root CA to which the issuing CA chains.
- You must use the Schannel cryptographic service provider (CSP) to
generate the key.
The above was taken from KB321051: How to enable LDAP over SSL with a third-party certification authority.
Additional information on how to setup a local CA for using LDAPS can be found at the following article: LDAP over SSL (LDAPS) Certificate
Once your DCs have the proper certificate installed, LDAPS communication should automatically be enabled. You can verify this with ldp.exe
as you were attempting to do.
Best Answer
The first thing you may want to do is check that your server is presenting it's certificates properly. You can do this by trying to connect to your server using OpenSSL. On a client machine with access, run:
This should return a nice print out of the server's certificate. The key here is checking the "Verify return code" printed at the end. You may get different codes, but generally speaking, you should get 0 for a valid certificate, and possibly 19 if you're self-signing.
If this fails, go back and check to ensure you have imported your server side certificates properly.
If you've passed this test, move on to testing your TLS connections from the client side.
On a client machine, run
This will force an LDAP lookup over an encrypted connection. If that's successful, you should get some user information back, and a check into the DS logs should yield the following:
If this fails, you'll want to ensure the certificates were properly imported on the client side.
When troubleshooting, some common areas I've found myself looking frequently are:
1.) On the clients, in some cases (which someone here may be able to better explain), you might try to require signing by editing ldap.conf and including the line
2.) If the authentication GUI is giving you problems, you might try just explicitly turning on TLS for LDAP with
I've had problems with the GUI before, so I tend to stick to using CLI commands.
3.) And a final thing you might try (again , just for testing), is calling
Update
If you're looking for more help in actually creating self sign certificates, try the following:
1.) Create your own, self-signed CA Certificate:
2.) Create a server certificate for the directory server
3.) Import both of these certificates into the directory server in the "Manage Certificates" section, selected under "Tasks"
4.) Enable TLS encryption
5.) Create an exportable certificate for clients and output it to a .pem file
6.) By means of your choosing - download the client certificate onto each client.
7.) Rehash the certificates by using the previously mentioned command