Hello Helen (@hbuelow ),
If one cannot investigate further the firewall problems between the Windows 2019 server and the DC then it is perhaps worth investigating how the Windows 2008 R2 server manages to work.
Here are three ideas, although none of them may be suitable in your environment:
- Don't use ContextOptions.SecureSocketLayer and TCP port 636 (just normal LDAP and port 389); now make a new Network Monitor capture and run your code/script. Most of the connection will still be encrypted (by SASL), but the authentication mechanism should be visible in the trace.
- Follow the instructions in Event Tracing in LDAP Applications to capture ETW (Event Tracing for Windows) data for the connection (this way of capturing data can see the raw LDAP protocol without encryption, so you can continue to use the ContextOptions.SecureSocketLayer option).
- Just use ETW to trace the Microsoft-Windows-LDAP-Client provider. Without the registry modification of option 2, this will collect less information but it might still be enough to understand how the Windows 2008 R2 system is authenticating.
The "klist purge" might have not had the desired effect because explicit credentials are used in the LDAP bind. There are two "messages" to the local Kerberos client that "purge" its cache: KerbPurgeTicketCacheMessage and KerbPurgeTicketCacheExMessage. "klist purge" probably uses the first message, but the second message might be necessary in this case.