I'm reviewing Active Directory telemetry from a domain-joined Windows workstation and noticed that Kerberos traffic goes to one endpoint while LDAP searches go to another. In this case, the LDAP destination does not appear to be a domain controller. I understand that Kerberos handles authentication and ticket issuance, while LDAP is used for directory queries, and that a Kerberos ticket can potentially authenticate to an LDAP service on a different host. How normal is this in a Windows environment? What legitimate services might cause LDAP connections to a non-domain-controller server, such as an LDAP proxy, application, DFS namespace server, virtualization platform, or network appliance? Could different DNS service records explain the behavior? Also, what is the best way to identify the client process that initiated the connection, and how trustworthy is endpoint attribution in identity-monitoring telemetry?
4 Answers
The non-DC host may be running an application that speaks LDAP or proxies requests to directory servers. DFS namespace infrastructure is one common example, but enterprise software, virtualization management systems, and security or networking appliances can do similar things. Identify the host owner, inspect its listening sockets and service configuration, and compare the connection with DNS SRV lookups using tools such as nslookup.
Kerberos and LDAP discovery are separate operations. A client can use DNS SRV records such as _kerberos and _ldap to locate each service, and those records may resolve to different hosts in the same site. Kerberos may remain associated with the KDC that issued the ticket, while a later LDAP lookup uses a fresh DNS result or a Global Catalog selection. So different endpoints are not automatically suspicious.
To find the originating process on the workstation, correlate the event timestamp with endpoint network telemetry, process trees, Windows Security events, Sysmon, firewall connection logs, or packet captures. Look for the process that opened the LDAP port rather than assuming the workstation's general authentication activity caused it. Also validate the destination through DNS, reverse DNS, certificates, and the host's installed services before treating the attribution as definitive.
Telemetry can report the communicating endpoints accurately while still lacking enough context to identify why the connection was made. Confirm the port, protocol, DNS answer, and process locally whenever the destination is unexpected.
First check the destination port and the service actually listening there. Port 3268 or 3269 usually indicates a Global Catalog lookup, and the Global Catalog server does not have to be the same domain controller that issued the Kerberos ticket. Port 389 or 636 could be a normal LDAP/LDAPS service, an LDAP proxy, or an application exposing directory functionality. DFS namespace servers, virtualization platforms, and some network appliances can also perform or receive LDAP-related operations.
If the reported LDAP destination is not a domain controller at all, verify whether it actually accepted the connection. A stale DNS or service record, an old address, or a load balancer can make the telemetry look stranger than the underlying activity.