Summary: A detailed breakdown of what happens on the network when a Windows client authenticates against Active Directory, covering DNS discovery, DC location, and the full Kerberos ticket exchange — including the ports, protocols, and packet flows involved.
When a Windows client logs into a domain, it doesn't simply send a username and password to a server. Behind the scenes, a carefully orchestrated sequence of network exchanges takes place — starting with DNS lookups to find a Domain Controller, followed by a Kerberos ticket exchange that grants access without ever transmitting the user's password in clear text.
Understanding this flow is essential for network engineers designing firewall rules, VLANs, and WAN connectivity for AD-joined environments, as well as for troubleshooting authentication failures at the network layer.
Active Directory uses Kerberos v5 as its primary authentication protocol. NTLM is used as a fallback when Kerberos is unavailable (e.g. authenticating by IP address rather than hostname, or connecting to legacy systems).
cifs/fileserver.corp.local). The KDC uses SPNs to issue the correct service ticket.Before authentication can begin, the client must find a Domain Controller. This is done via DNS SRV record lookups.
Client DNS Server
│ │
│── DNS SRV query ─────────────────▶│
│ _ldap._tcp.dc._msdcs.corp.local │
│ │
│◀─ SRV records (list of DCs) ──────│
│ e.g. dc01.corp.local:389 │
│ dc02.corp.local:389 │
The client then sends an LDAP ping (a UDP CLDAP request on port 389) to the returned DCs to find the most responsive one in the same site.
Client Domain Controller (dc01)
│ │
│── CLDAP Ping (UDP 389) ──────────▶│
│◀─ DC Locator Response ────────────│
│ (confirms site, DC name, etc.) │
Once a DC is located, the client begins the Kerberos exchange to obtain a Ticket Granting Ticket (TGT).
Client KDC (Domain Controller)
│ │
│── AS-REQ (TCP/UDP 88) ───────────▶│
│ Username + encrypted timestamp │
│ (pre-auth using user's password │
│ hash as key) │
│ │
│◀─ AS-REP ─────────────────────────│
│ TGT (encrypted with krbtgt key) │
│ + Session Key (encrypted with │
│ user's password hash) │
Summary: Password Sent on the Wire — The user's password is never transmitted. Instead, it is used locally to encrypt a timestamp, which the KDC verifies. This is the core security strength of Kerberos.
When the client needs to access a resource (e.g. log on to the workstation, access a file share), it requests a Service Ticket from the KDC using its TGT.
Client KDC (Domain Controller)
│ │
│── TGS-REQ (TCP/UDP 88) ──────────▶│
│ TGT + SPN of target service │
│ (e.g. cifs/fileserver.corp.local│
│ or host/workstation.corp.local)│
│ │
│◀─ TGS-REP ────────────────────────│
│ Service Ticket (encrypted with │
│ target service's secret key) │
The client presents the Service Ticket directly to the target service. No further DC involvement is needed at this stage.
Client Target Service / Workstation
│ │
│── AP-REQ ────────────────────────▶│
│ Service Ticket + Authenticator │
│ │
│◀─ AP-REP (optional) ──────────────│
│ Mutual authentication confirmed │
After authentication, the client queries AD via LDAP to retrieve Group Policy Objects (GPOs) and user/group membership.
Client Domain Controller
│ │
│── LDAP Query (TCP 389) ──────────▶│
│ Request: GPOs, group membership │
│◀─ LDAP Response ──────────────────│
│ │
│── SMB (TCP 445) ─────────────────▶│
│ Download GPO files from SYSVOL │
│◀─ GPO files ──────────────────────│
┌─────────────────────────────────────────────────────────────┐
│ 1. DNS SRV Lookup UDP 53 → DNS Server │
│ 2. CLDAP Ping UDP 389 → Domain Controller │
│ 3. AS-REQ / AS-REP TCP 88 → KDC (DC) [Get TGT] │
│ 4. TGS-REQ / TGS-REP TCP 88 → KDC (DC) [Get ST] │
│ 5. AP-REQ TCP 445 → Target Service │
│ 6. LDAP Query TCP 389 → DC [GPO/groups] │
│ 7. SMB/SYSVOL TCP 445 → DC [GPO files] │
└─────────────────────────────────────────────────────────────┘
The following ports must be open between clients and Domain Controllers for authentication to function correctly.
| Port | Protocol | Service | Purpose |
|---|---|---|---|
| 53 | TCP/UDP | DNS | DC discovery via SRV records |
| 88 | TCP/UDP | Kerberos | TGT and Service Ticket exchange |
| 389 | TCP/UDP | LDAP | DC Locator (CLDAP ping), directory queries |
| 636 | TCP | LDAPS | Encrypted LDAP (if configured) |
| 445 | TCP | SMB | SYSVOL access for GPO files |
| 135 | TCP | RPC Endpoint Mapper | RPC-based AD operations |
| 49152–65535 | TCP | RPC Dynamic Ports | Dynamic RPC for NetLogon, replication |
| 3268 | TCP | Global Catalog LDAP | Forest-wide queries |
| 3269 | TCP | Global Catalog LDAPS | Encrypted forest-wide queries |
⚠️ Firewall Rules for Remote Sites
If clients are authenticating across a WAN or through a firewall (e.g. a remote branch connecting to a DC at HQ), all of the above ports must be permitted. Blocking UDP 88 or UDP 53 are the most common causes of Kerberos failures in routed environments. Consider deploying a local DC or RODC at each site to reduce WAN dependency.
If Kerberos fails (e.g. the client accesses a resource by IP address rather than FQDN, or the target SPN is missing), Windows falls back to NTLM authentication.
Client Target Server / DC
│ │
│── NEGOTIATE ─────────────────────▶│
│◀─ CHALLENGE (nonce) ──────────────│
│── AUTHENTICATE ──────────────────▶│
│ (NTLM hash of password + nonce) │
│ │
│ [DC validates hash] │
│◀─ Success / Failure ──────────────│
⚠️ NTLM is a Security Risk
NTLM is vulnerable to pass-the-hash and relay attacks. Wherever possible, ensure clients authenticate by FQDN (not IP) to encourage Kerberos usage. NTLM can be monitored and restricted via Group Policy underComputer Configuration > Windows Settings > Security Settings > Local Policies > Security Options.
| Symptom | Likely Cause | Fix |
|---|---|---|
| Login slow or times out | Client cannot reach DC — DNS or port issue | Check DNS resolution of _ldap._tcp.dc._msdcs.<domain>; verify TCP/UDP 88 and 389 are open |
| Kerberos error KRB5KRB_AP_ERR_SKEW | Client clock more than 5 minutes out of sync with DC | Ensure NTP is configured; Kerberos requires clocks within 5 min of each other |
| "No logon servers available" | DC unreachable or NetLogon service down | Verify network path to DC; check nltest /dsgetdc:<domain> |
| Falling back to NTLM unexpectedly | SPN missing or client using IP address | Register missing SPN with setspn; use FQDN instead of IP for resource access |
| GPOs not applying | SMB/445 blocked to DC, or SYSVOL unreachable | Verify TCP 445 is open to DC; check gpresult /r for GPO errors |
| Authentication works locally but fails over VPN/WAN | Kerberos ports blocked by firewall | Open TCP/UDP 88, UDP 53, TCP 389, TCP 445 between client subnet and DC subnet |
# Test DC discovery — find the closest DC for a domain
nltest /dsgetdc:corp.local
# Check Kerberos tickets held by the current session
klist
# Purge Kerberos ticket cache (forces re-authentication)
klist purge
# Test DNS SRV record resolution for DC discovery
Resolve-DnsName -Name "_ldap._tcp.dc._msdcs.corp.local" -Type SRV
# Run a GPO result check to verify policy application
gpresult /r
# Test LDAP connectivity to a specific DC
Test-NetConnection -ComputerName dc01.corp.local -Port 389
# Test Kerberos port connectivity
Test-NetConnection -ComputerName dc01.corp.local -Port 88