none
Enabling SSL on Active Directory Doman Controller / LDAPS:636. Will LDAP 389 still work as usual or will everything need to have certs? RRS feed

  • Question

  • Hi everyone,

    Recently, I wanted to enable SSL on our 2008 R2 AD domain and I've been scratching my head and thinking about possible consequences. We are a 2008 R2 Domain / network with many non-Microsoft servers (Linux) running different portal applications and database services (PostgreSQL). And they are all using our AD to authenticate!

    NOW....

    I know that there are 2 or more ways to do Certification Authority setup:

    1. Enable CA (Default Enterprise root CA) on one of our Domain Controllers and AD will automatically replicate the change to other DC's on the domain. Which will enable LDPAS on port 636. Ok, great! 

    2. Second option, implement Certificate Authority on a member server on the domain network and keep the CA Infrastructure separate from the DC machines itself. Ok.

    We have decided to use the first option and add the Active Directory Certificate Services role on one of our 2008 R2 Domain Controllers. 

    If we do so, could someone PLEASE answer some of the questions I have here:

    1. After CA is configured on our AD domain controller, we should be able to use SSL over port 636. But, what will happen to the Default communication over LDAP port 389? Will it still be available or will everything need (be required) to go over LDAPS/636?

    2. Will all of our domain workstations / Windows 10 clients require a Certificate to be issued in order to communicate to AD? Or will they continue to communicate over LDAP : 389 as before? 

    In other words; if SSL is enabled on AD, and 636 is functional on all of our DC's, what will happen to the existing LDAP on 389? Will it continue to work just like it is, or will it stop working?

    We have many NON-Microsoft clients and servers running different  types of applications and databases which currently authenticate via our Active Directory. I don't want to end up in a situation where we have to issue Certificates to all of these non-Microsoft machines on the network in case our AD quits working via LDAP 389! 

    Any thoughts would be greatly appreciated.

    Thanks,

    Nic


    _nick_damas


    • Edited by Nick_damas Tuesday, April 11, 2017 7:00 PM
    Tuesday, April 11, 2017 6:45 PM

All replies

  • Hello, 

    Here is one one important point which you may consider before making any change.

    1. Enable CA (Default Enterprise root CA) on one of our Domain Controllers and AD will automatically replicate the change to other DC's on the domain. Which will enable LDPAS on port 636. Ok, great! 

    --> First of all, AD replicates only directory services database (Again depends on configuration). Enabling Ent CA on DC is not a good choice and AD will not replicate this info to any other DCs. I would suggest following this article -- https://social.technet.microsoft.com/wiki/contents/articles/2980.ldap-over-ssl-ldaps-certificate.aspx

    ============================

    1. After CA is configured on our AD domain controller, we should be able to use SSL over port 636. But, what will happen to the Default communication over LDAP port 389? Will it still be available or will everything need (be required) to go over LDAPS/636?

    --> 389 will not be disabled. 

    2. Will all of our domain workstations / Windows 10 clients require a Certificate to be issued in order to communicate to AD? Or will they continue to communicate over LDAP : 389 as before? 

    --> 389 will not be disabled. A lot of services use LDAP Port TCP 389 for LDAP communication (Like - Core Group Policy Engine GPSvc.dll). As per RFCs, theses services are not configured yet to use 636. 

    • Proposed as answer by TheDSGuy Sunday, September 6, 2020 5:43 AM
    Sunday, September 6, 2020 5:43 AM