I'm analyzing Active Directory telemetry from a domain-joined Windows workstation. The workstation obtains or uses Kerberos tickets through one endpoint, but later sends LDAP queries to a different endpoint. 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 searches. Since Kerberos can authenticate a client to an LDAP service elsewhere, I'm trying to determine how normal this pattern is.
What are the common legitimate explanations for Kerberos and LDAP using different machines? Could the LDAP destination be an application server, LDAP proxy, DFS namespace server, Global Catalog, virtual IP, or another appliance? Also, what ports, DNS records, and client-side process data should I check to identify the service and determine which application initiated the connection?
4 Answers
A non-domain-controller LDAP destination may be a legitimate application or appliance that queries AD. Examples include DFS namespace servers, virtualization platforms, network-management and security appliances, identity products, and other software with an LDAP client. If the host accepted the connection, identify what is listening on that port and review its service configuration. If it did not respond, stale DNS or service records could be pointing clients at an old or incorrect address.
DFS namespace servers are one possible explanation: they don't have to be domain controllers and may contact AD over LDAP to obtain namespace or referral information. To identify the client-side origin, correlate the network event with endpoint process telemetry, including the process ID, executable path, parent process, service account, and timing. Packet captures and DNS logs can help confirm whether the connection followed an SRV lookup or was opened directly by an application.
Check the destination port. Port 3268 usually indicates a Global Catalog search, which can be handled by a different domain controller from the one that issued the Kerberos ticket. Port 389 is standard LDAP, while 636 is LDAPS. A virtual IP or LDAP proxy can also sit in front of directory servers, although Kerberos is generally harder to load-balance because of service principal name requirements.
The two connections can be selected independently. Windows uses DNS SRV records to locate services such as Kerberos and LDAP, and those records can resolve to different hosts. Clients may also perform separate lookups at different times, so different endpoints—especially within the same AD site—aren't automatically suspicious. Check the relevant _kerberos and _ldap SRV records with an SRV lookup tool and verify that they point to the expected systems.
That makes sense. I’ll correlate the destination port with the DNS records and determine whether the endpoint is a Global Catalog, proxy, or virtual service address.