Windows 10: Security Advisory ADV190023 effect on non-domain appliances using LDAP queries against...

In preparation for Security Advisory ADV190023, I have enabled diagnostic logging on some of our domain controllers. We provide hosted messaging services to our customers, and each customer has their own dedicated domain controllers for their Exchange environments.

I increased the AD Diagnostic Event logging (16 LDAP Interface Events) on a few of the domain controllers and have discovered that both our e-mail gateway appliances and an archiving appliance are making unsecure LDAP queries.

Microsoft suggests to either use an AD-integrated Enterprise CA to generate server certificates, or purchase a public CA certificate, in order to enable SSL capabilities on the domain controllers, but based on the following set of circumstances, I do not believe I can employ either solution:

1. The appliances are not on the customer's domains. They would have no access to the root CA if I was to enable an Enterprise CA in each domain.


2. The appliances connect to the customer's domain controllers via IP addresses. They do not have the ability to perform DNS lookups in the private domains of each customer in order to resolve a FQDN to an IP address.

3. All customers are using a unique internal domain (.local domain). We can not get a public CA for a .local domain. And even if we could, the appliances would still need to resolve the FQDN of the server for the certificate to be used for SSL.

:)

 

Security Advisory ADV190023 | Microsoft Guidance for Enabling LDAP Channel Binding and LDAP Signing

I've been reviewing ADV190023 (which seems to indicate that insecure LDAP binds will no longer be permitted in Active Directory after January 2020). I made the changes to the Windows Registry on my Domain Controllers to get detailed logging information about
applications/computers performing either simple LDAP binds or unsigned SASL binds.

I found that the vast majority of the Event log entries were for OSX computers which were bound to AD and performing unsigned SASL binds. These generated Event ID 2889 in the Directory Service log. By my reading of the Security Advisory, unsigned SASL binds
will no longer be permitted after January 2020 so I worked on making the MAC OSX machines use SSL when communicating to AD.

I made the suggested registry changes on a Test Domain Controller - those changes supposedly will not allow simple LDAP binds or unsigned SASL binds. I tried the test which was specified with LDS and a simple bind and that failed with a "requires a higher
level of security" message, which is what was expected.

However, even after configuring a MAC OSX computer to use SSL (I verified that it is using port 636 Tcp to "talk" to the DC) I am getting Event ID 2889 in the Directory Service log indicating that the MAC is still using an unsigned SASL bind. The bind/login
process works (I am able to successfully authenticate as an AD user on the MAC over SSL) but the continued error in the Event log bothers me.

key points:

1. If I make the "don't allow insecure LDAP binds" changes on the DC and don't make any changes on the MAC, I am still able to bind/authenticate to AD from the MAC. The Security Advisory seems to indicate that this should fail, but my tests don't agree. Event
ID 2889 is generated in the Directory Service Event Log.

2. If I force the MAC to use SSL to talk to AD (after making the "don't allow insecure LDAP binds" change on the DC) I am able to bind/authenticate to AD from the MAC and I still get the 2889 entry in the DS Event Log. There doesn't seem to be any change
in behavior from the Windows side.

Am I mis-reading the Security Advisory? Or is there some other change (other than the three registry changes outlined in the Security Advisory) that need to happen on the DC? I would like this to be a non-issue when Microsoft pushes this change out in January.

 

KB4103727 and Server 2016 LDAP queries

Since I have installed KB4103727 on Server 2016 Datacenter all Ldap queries fail from our Xerox printers using a normal domain user account. Once I remove the patch the LDAP queries succeed again normally.

 

LDAP SSL

Hello all,

My company is new to active directory and because of audits we have every year, we are trying to make things secured. That said, I setup an Enterprise CA server, created a certificates from a domain controller template and issued the certificates to the
domain controllers.

I tested LDAP SSL using the ldp.exe tool and everything appears fine using port 636 SSL and 3269 SSL. However, I would like to know whether sensitive traffic is encrypted. I do know that i cant block port 389 from the clients side because it is used for
the AD authentication. Does anyone know any way to test whether traffic goes through LDAP SSL when needed, and can i block the port 3268 used for Global Catalogs since now the domain controllers have a certificate? Also can anyone mention the cases when traffic
goes through LDAP SSL?

Thanks a lot for your time and sorry if my questions sounds kind of stupid.