Port 88 is where a Kerberos key distribution center listens, which on a Windows network means every domain controller. Clients request tickets there and present them to services elsewhere. Blocking it does not harden anything, it stops authentication.
- Every domain controller is a KDC and listens on TCP and UDP 88
- UDP first, TCP when the ticket outgrows a datagram
- A password never crosses it. Tickets do
- The clock must be within five minutes or nothing authenticates
- The third leg of the exchange does not use port 88 at all
On this page
The exchangeWhat actually happens on port 88
The Kerberos protocol exists so that a password is proved once and never sent again, and port 88 is where that proof happens.
RFC 4120, the Kerberos version 5 specification, splits the KDC into two services that answer on the same port: the authentication service, AS, and the ticket granting service, TGS. The RFC notes that both are normally entry points into one Kerberos server.
The AS issues a ticket granting ticket. At logon, the Kerberos client sends an AS request to port 88 on a domain controller. It does not send the password.
It sends a timestamp encrypted with a key derived from the password, and the KDC can decrypt it only if it holds the same key. Success returns a ticket granting ticket, the TGT, which is the proof of identity that client uses for the rest of the day.
The TGS issues a service ticket. When that user opens a file share, the client goes back to port 88 with the TGT and names the target service. The ticket granting service replies with a service ticket for that one service, encrypted with a key derived from the password of the account the service runs as.
The client talks to the server. The service ticket goes to the file server, the database or the web application on that service's own port, not on port 88. The server validates the ticket without contacting a KDC at all, which is why Kerberos scales the way it does and why access stays fast.
| Exchange | Where it happens | What the client ends up holding |
|---|---|---|
| AS request and reply | Port 88, authentication service | A TGT for the logon session |
| TGS request and reply | Port 88, ticket granting service | A service ticket for one named service |
| Application request | The service's own port | Access, with no KDC involved |
The consequence worth carrying: Kerberos uses port 88 at logon and at first access to each service, and is silent afterward. A network where port 88 works intermittently produces failures that look random, because they land only on the clients that happened to need a new ticket.
Nothing in this is specific to Microsoft. The same TGT and TGS exchanges run against MIT Kerberos and Heimdal KDC systems on the same port, and Active Directory is simply the largest deployment of them.
UDP and TCPUDP first, TCP when the ticket grows
Port 88 is registered on both transports and Kerberos genuinely uses both, which is the detail most firewall rules get wrong.
The default transport is UDP, because a ticket exchange is a small request and a small reply, and UDP avoids the cost of a handshake for something that happens constantly. When the KDC reply is too large for a UDP datagram, the exchange retries over TCP on the same port number.
RFC 4120 spells the mechanism out. A KDC that cannot fit the reply in a datagram returns the error KRB_ERR_RESPONSE_TOO_BIG, which forces the client to retry over the TCP transport. The retry is not a fallback the client can skip, so the difference between the two transports decides whether those users authenticate.
Large replies are not exotic. A Kerberos ticket carries the security identifiers of every group the user belongs to, so a user in a hundred groups gets a large ticket.
Organizations that have accumulated group membership for a decade hit this constantly, and it produces one of the most confusing failure modes on a Windows network: authentication works for most people and fails for the ones with the most access.
The firewall rule to write is both. TCP 88 and UDP 88, in both directions between clients and the domain controllers acting as KDC servers. A rule permitting only UDP 88 passes testing and then fails for exactly the users nobody wants to have problems.
The other portsWhat else has to be open
The Kerberos protocol is never alone, and domain controllers that answer on port 88 and nothing else are still unusable. Every port in this table is part of the same access path.
| Port | Protocol | Why it is needed |
|---|---|---|
| 88 TCP and UDP | Kerberos | Ticket requests to the KDC, and tickets back |
| 464 TCP and UDP | kpasswd | Password changes, a separate service |
| 389 TCP and UDP | LDAP | Directory lookups and group policy |
| 636 TCP | LDAPS | LDAP over TLS |
| 53 TCP and UDP | DNS | Finding the KDC servers in the first place |
| 445 TCP | SMB | Group policy files from SYSVOL |
| 123 UDP | NTP | Clock synchronization, which Kerberos requires |
DNS deserves the emphasis. Clients find their KDC by looking up service records, so a DNS failure looks exactly like a Kerberos failure and is far more common. Check name resolution before touching anything on port 88.
The clockThe clock, which breaks this more than the port does
Kerberos tickets carry timestamps and the protocol rejects anything outside a tolerance window, five minutes by default.
That design choice is a security control: it prevents replay attacks, because a captured ticket request is useless a few minutes later. It also means a client whose clock has drifted more than five minutes from the KDC cannot authenticate at all, however perfect the network path is.
Note what that tolerance is: Kerberos needs the clocks close, not precise, which is why ordinary network time is enough for it. Networks that need precision measured in microseconds run PTP instead, for reasons that have nothing to do with authentication.
RFC 4120 gives the error its name, KRB_AP_ERR_SKEW, and uses five minutes as its example of an allowable skew. Every domain controller should take its time from the same source, which is what a stratum hierarchy is for.
The failure is abrupt and total for that machine, and the error message names a clock skew, which is one of the few genuinely helpful messages in this area. A virtual machine resumed from a snapshot, devices with a dead CMOS battery, and a domain controller pointing at the wrong time source are the three usual causes.
SymptomsWhen port 88 is blocked or filtered
The common issues are specific enough to recognize on sight.
Logon takes a long time and then works. The client tried Kerberos, waited for a timeout, and fell back to NTLM. Everything functions and every logon is slow, which is the version of this problem that survives for years because nobody files a ticket about it.
Some users authenticate and some do not. UDP 88 is permitted and TCP 88 is not, and the users failing are the ones whose group membership pushed the Kerberos ticket past the datagram size.
Access works at the office and not on the VPN. The tunnel carries traffic to the network but the firewall in front of the KDC servers is not permitting port 88 from the VPN address range.
A newly joined machine cannot reach any resources. Time first, then DNS, then port 88. In that order, because that is the order of how often each is the cause of these issues.
PitfallsWhere people go wrong
Blocking port 88 to make a domain controller more secure. It disables authentication instead. Restricting which source networks may reach the KDC is the security control that works.
Permitting UDP 88 only. It works until a user with large group membership tries, and then it fails in a way nobody connects to the firewall change made three months earlier.
Assuming a password crosses port 88. It does not. What travels is proof that the client holds the key, and tickets. That property is the whole security argument for the protocol.
Chasing Kerberos when the clock is wrong. More than five minutes of skew and Kerberos authentication cannot work at all. Check the time before the port.
Forgetting port 464 for password changes. Users authenticate normally and cannot change their password, which presents as a completely separate fault from any Kerberos issue.
Reading a successful NTLM logon as a working Kerberos configuration. The fallback hides the problem and gives up single sign-on and the more secure authentication at the same time.
ExposureWhat an open port 88 exposes
Port 88 has to be reachable, so the question is not whether to permit it but what a system that reaches it can do with no credentials at all. The three well known techniques all work against ordinary, correctly configured KDC behavior.
Username enumeration. The KDC answers a request for a real principal differently from a request for an unknown one, so anything that can reach port 88 can test a username list without trying a password. Lockout counters never move, because no password is ever sent.
Pre-authentication that was turned off. RFC 4120 explains why pre-authentication exists: without it, an attacker can send an AS request purely to collect known plaintext and attack the principal's key offline. Accounts flagged as not requiring it hand that material to anyone who asks.
Service ticket cracking. Any account holding a TGT can ask the ticket granting service for a service ticket for any account that has a service principal name. Part of that ticket is encrypted with a key derived from the service account's password, and the cracking happens offline, logging nothing on the target.
The controls are unremarkable. Restrict which source networks may reach the KDC, keep pre-authentication required on every account, and give service accounts long random passwords. None of that involves closing the port.
ComparisonFour ways to prove who you are, and the row that decides at scale
| Criterion | Kerberos, port 88 | NTLM | LDAP simple bind | Certificates |
|---|---|---|---|---|
| Password crosses the network | No | No, a challenge response | Yes, unless wrapped in TLS | No |
| Resistant to replay attacks | Yes, by timestamp | Weakly | No | Yes |
| Needs a KDC per request | No, only for tickets | Yes, for every server | Yes | No |
| Single sign-on | Yes | Partial | No | Yes |
| Depends on accurate clocks | Yes, within five minutes | No | No | Certificate lifetime only |
| Mutual authentication | Yes | No | No | Yes |
| Status | The default since 2000 | Legacy fallback | Avoid without TLS | Growing |
The row that matters operationally is the second one. A server validating a Kerberos ticket does not have to ask a KDC anything, which is why an access design built on port 88 keeps working under load that would flatten the alternatives.
FAQFrequently asked questions
What is port 88 used for?
Kerberos authentication. Clients send ticket requests to a KDC on port 88 and receive tickets in return, which they then present to servers instead of a password.
Is port 88 TCP or UDP?
Both. Kerberos tries UDP first and falls back to TCP when the reply is too large, so a firewall rule has to permit both or authentication fails for some users.
What listens on port 88?
The key distribution center, universally abbreviated KDC. On a Windows network that is every domain controller, because the KDC role runs on all of them.
Can I block port 88?
Not between clients and the KDC. Blocking it stops domain authentication and all the access that depends on it. Restricting which networks can reach it is the useful security control.
Does my password travel over port 88?
No. The client proves it holds a key derived from the password, and after that only tickets travel. Keeping passwords off the network is the reason this protocol exists.
Why do some users fail to authenticate and others succeed?
Usually because only UDP 88 is permitted. Users in many groups get tickets too large for UDP, so their exchange retries over TCP and hits a closed port.
What is a ticket granting ticket?
The proof of identity a client receives at logon. It is used to request service tickets later without authenticating again, which is what makes single sign-on work.
Why does Kerberos need accurate time?
Kerberos tickets carry timestamps and are rejected outside a tolerance window, five minutes by default. That denies an attacker any use of a captured request, and it makes clock drift a total failure.
What port does a Kerberos password change use?
Port 464, for the kpasswd service. It is separate from port 88, and forgetting it produces users who can log in but cannot change their password.
Why is my logon slow but successful?
Kerberos was attempted, timed out, and the client fell back to NTLM. Something on the path to port 88 is blocked or unreachable.
Do I need port 88 open on the VPN?
Yes, from the VPN address range to the domain controllers, along with DNS. This is the commonest reason domain resources work in the office and not remotely.
Is Kerberos only for Windows?
No. Kerberos came out of MIT, and Linux, macOS and many applications speak it. Active Directory is the largest deployment by a wide margin, which is why the two are so often discussed as one thing.
What else needs to be open besides port 88?
DNS on 53, LDAP on 389 and 636, SMB on 445 for group policy, NTP on 123 for the clock, and 464 for password changes. Port 88 alone is not enough for a working domain.
Keep readingRelated concepts
Read next · Directory and identity Active Directory Explained Every domain controller is a KDC, so this port is not a networking detail so much as the thing the directory runs on. Open this next15 min- Ports · 12 min What Is a Port Number? Why a service gets a fixed number at all, and what registered means.
- Directory and identity · 13 min LDAP Explained The other protocol a domain controller answers, and the one people confuse with this when authentication fails.
- Protocols · 10 min PTP, NTP, and Why a Clock Breaks Authentication First What the drift breaks.
- Ports · 10 min Port 135, the Endpoint Mapper, and the Ports It Points At What else has to be open for a domain to work.
- Ports · 11 min The LDAP Ports, and Which One Your Application Should Use The other port every domain controller answers.