- LDAP
- Active Directory
- VMware
LDAP binding and AD
AD experts out there, you will be able to shed light on LDAP channel binding, LDAP signing, and Kerberos authentication. I have been reading the link below and states that the March 2020 update will enable LDAP signing on the Active Directory server by default. My understanding is that any device which use LDAP is going to be broken,
We have windows 2012 AD domain controllers and Windows 10 PCs, All the PC are part of the AD in this case they use Kerberos authentication so we do not need to worry about LDAP signing unless we use any non-AD device for LDAP query then we have to make sure that they use SSL/TLS, am I connect?
https://support.microsoft.com/en-us/help/4520412/2020-ldap-channel-binding-and-ldap-signing-requirement-for-window
My next question,
Where and when do this LDAP channel binding and LDAP signing come into account in AD?
We have windows 2012 AD domain controllers and Windows 10 PCs, All the PC are part of the AD in this case they use Kerberos authentication so we do not need to worry about LDAP signing unless we use any non-AD device for LDAP query then we have to make sure that they use SSL/TLS, am I connect?
https://support.microsoft.com/en-us/help/4520412/2020-ldap-channel-binding-and-ldap-signing-requirement-for-window
My next question,
Where and when do this LDAP channel binding and LDAP signing come into account in AD?
LDAP bindings which are simple or unsecured will fail following the March 2020 patches.
The first thing you need to do is download the LDAP query Powershell script from Github. Read this article for a link to the script repository.
Once you have that, you will need to follow the instructions to temporarily set the diagnostic logging level to 3 for all domain controllers.
You will let your domain controllers run like this for at least 24 hours and then run the script on each domain controller in an elevated Powershell process. The script will output a list of any process using simple or unsecured LDAP.
The first thing you need to do is download the LDAP query Powershell script from Github. Read this article for a link to the script repository.
Once you have that, you will need to follow the instructions to temporarily set the diagnostic logging level to 3 for all domain controllers.
You will let your domain controllers run like this for at least 24 hours and then run the script on each domain controller in an elevated Powershell process. The script will output a list of any process using simple or unsecured LDAP.
I have done all and identified the devices which use LDAP. I have not seen any desktop with that event.
My confusion about the desktop. Is the desktop use LDAP for any AD queries?
My confusion about the desktop. Is the desktop use LDAP for any AD queries?
Domain-joined workstations do not use LDAP for Active Directory enumeration. They use native AD call for this work. LDAP is generally used by third-party tools to perform single-sign-on authentication with Active Directory.
For example, VMware uses LDAP to perform AD-integrated authentication.
For example, VMware uses LDAP to perform AD-integrated authentication.
And you do need to allow the Domain Controllers to collect LDAP messages for at least 24 hours to generally ensure there are no affected LDAP connections in your environment.
Thanks for the reply. We ran the script and found a few devices which use LDAP. I have a question about the March 2020 security updates. My assumption is the update will enable only LDAPs the devices will break if we do not configure for LDAPs.
Do we have to do anything on the domain controllers other than applying March 2020 patches? That is, enforcing the LDAP signing policy via GP.
Do we have to do anything on the domain controllers other than applying March 2020 patches? That is, enforcing the LDAP signing policy via GP.
The only systems which should be answering LDAP queries in the average environment are your domain controllers.
It would be best to identify what devices or applications are performing LDAP queries and ensure these are doing so securely.
Your workstations should not be performing any LDAP queries inside or outside of the organization under normal circumstances. I they are doing so, that would be suspicious behavior unless you know you have a documented application performing these queries.
It would be best to identify what devices or applications are performing LDAP queries and ensure these are doing so securely.
Your workstations should not be performing any LDAP queries inside or outside of the organization under normal circumstances. I they are doing so, that would be suspicious behavior unless you know you have a documented application performing these queries.
Thanks Darrell
I found the devices and changed the configuration to use TLS. All good now. However I noticed an another article over the internet which says edit the registry to enforce the LDAP binding. This is where my confusion.
I configured the client to use TLS and did not make change on registry to enforce LDAP binding.
Does this means that my client can be vulnerable though they use TLS?
I found the devices and changed the configuration to use TLS. All good now. However I noticed an another article over the internet which says edit the registry to enforce the LDAP binding. This is where my confusion.
I configured the client to use TLS and did not make change on registry to enforce LDAP binding.
Does this means that my client can be vulnerable though they use TLS?
It would help to answer your question if you could post the relevant URLs you are looking at to this thread.
Hi Sara,
The March 2020 patches for LDAP essentially make this registry setting set to a value of "2" - making queries against AD will require a secure call.
What you are going to be more concerned with is third-party applications attempting to perform LDAP lookups using insecure methods. Once you install the patches, your systems will require any external application to use authenticated, encrypted LDAP calls. You should not need to implement this registry entry unless some system in your organization is performing LDAP lookups against a foreign Windows Active Directory infrastructure.
The March 2020 patches for LDAP essentially make this registry setting set to a value of "2" - making queries against AD will require a secure call.
What you are going to be more concerned with is third-party applications attempting to perform LDAP lookups using insecure methods. Once you install the patches, your systems will require any external application to use authenticated, encrypted LDAP calls. You should not need to implement this registry entry unless some system in your organization is performing LDAP lookups against a foreign Windows Active Directory infrastructure.
-
![]()
received a Solution
LDAP vs Kerberos -
![]()
wrote an Article
![]()
Fixing AD Subnets
-
![]()
created a Video
![]()
[Webinar] How Hackers Steal Your Credentials and Why Active Directory Must be Secure to Stop Them
-
Explore Cloud Class® ![]()
Certification: MCSE Microsoft Certified Systems Engineer - Identity with Windows Server 2016
Premium Content
You need an Expert Office subscription to comment.Start Free Trial