Event 2889: Insecure LDAP

[Charles F Sullivan]

In attempting to track down third party stuff that uses AD and makes LDAP connections which are considered insecure, I enable verbose logging of the Directory Services event log and look for 2889 events ("The following client performed a SASL (Negotiate/Kerberos/NTLM/Digest) LDAP bind without requesting signing..."). LDAP signing requirements are set to None in the DC GPO.

We have vCenter servers and Macs that are joined to AD and have regularly gotten flagged with these events (apparently with false positives) on our Windows 2012 R2 DCs. I have just recently replaced most of these DCs with Windows 2019 DCs and we do not see any 2889 events at all after enabling the verbose logging.

The only question I have is whether anyone can explain why none of these events show up on the Windows 2019 DCs. I've read plenty about the issue and how it affects Macs and vCenter with the apparent false positives, but I am not able to find anything that says it only affects earlier versions of DCs.

--

Charlie Sullivan

Principal Windows Systems Administrator

[Kurt Buff]

On the 2019 DCs, did you set
"HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics" to '2'?

Kurt

> --
> You received this message because you are subscribed to the Google Groups "ntsysadmin" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to ntsysadmin+...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/CAEuHzz%3D3ozvUayhXvbvwXdfUgD5kqzb0VEyWYS8CYaJbR-6gRw%40mail.gmail.com.

[Kurt Buff]

Hit send by accident, before message was complete

New-ItemProperty -Path
'HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics' -Name "16
LDAP Interface Events" -Value 2 -PropertyType DWORD -Force

Is the PowerShell command to set that up.

Kurt

On Wed, Jul 27, 2022 at 9:37 AM 'Charles F Sullivan' via ntsysadmin
<ntsys...@googlegroups.com> wrote:
>

[Charles F Sullivan]

Hi Kurt -

Yes, I mentioned that I enabled verbose logging on the Directory Service log and that is how I did it.

I set it to 2 on all DCs, new and old. I then check at least a few days later. The old DCs will have hundreds of the 2889 events, the new DCs none.

To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/CADy1Ce4zbEzYRi2hcooy_B8K2QJMN%2BjODZz1op4D7mUZHa%2BC%3Dw%40mail.gmail.com.

[Kurt Buff]

Ah.

Perhaps a manual query to LDAP and examine the event log?

And of course you've verified that the DCs are actually listening on 389?

Kurt

On Wed, Jul 27, 2022 at 9:59 AM 'Charles F Sullivan' via ntsysadmin

> To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/CAEuHzzkOpqOR56N_cDe9P9jYZzVMx3o%2BEAaxHKBq3KcaO2Hweg%40mail.gmail.com.

[Charles F Sullivan]

The DCs are listening on 389 or I would be having bigger problems. They are listening on 636 as well because we have some apps using LDAPs.

Your reply is very helpful because you got me thinking to try a couple of things on one of the Windows 2019 DCs:

I ran netstat and could see established LDAP connections. The very first one I checked happens to be a Mac. I had seen successful connections from Macs in the security logs for Kerberos connections, but this proves Macs are able to make LDAP connections specifically.

I used LDP to make a simple bind to one of the Windows 2019 DCs and it did in fact generate one of the 2889 warnings.

So at this point I feel that there is nothing to worry about since I know the Macs are able to use AD as needed. I still don't know why I'm not seeing the 2889 warnings from the Macs (or vCenter or a few other third party apps using insecure LDAP). For now it really doesn't matter because we are not requiring LDAP signing.

Thanks for the help!

To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/CADy1Ce6-RYKbf2p%2BSb_vUYB2KQ0w1GceNWDCrtujWA755a0xnA%40mail.gmail.com.

[Kurt Buff]

We don't have Macs, so I can't help you there.

I attempted to implement LDAP signing around the first of the year,
and it broke things that I didn't know were using it - even though I
had that audit in place.

I've had to postpone a retry until I get some other things done.

I feel your pain...

Kurt

On Thu, Jul 28, 2022 at 7:47 AM 'Charles F Sullivan' via ntsysadmin

> To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/CAEuHzzk7qMo_it767c7DRpZ4YBELD%3Dve%2BHmV5YeQTYrd3F5hpA%40mail.gmail.com.