Port 464: KPASSWD — The Gatekeeper of Password Rebirth

Port 464 carries the Kerberos password change protocol. Every time a user changes their password in an Active Directory domain, every time an administrator resets a forgotten credential, every time an expired password forces a renewal, the request flows through this port. It is the single door through which identity transforms.

What Port 464 Does

Port 464 runs the kpasswd service, the Kerberos Change/Set Password protocol.¹ While port 88 handles the main Kerberos authentication traffic (ticket-granting, service tickets, the whole dance of proving who you are), port 464 handles the specific moment when a password must change.

The service listens on both TCP and UDP port 464. When you invoke kpasswd on a Unix system, or when Windows silently handles a password change in the background, the request travels to this port on your domain controller.

The protocol is elegant in its simplicity: one request, one reply. You send your old credentials (proof you are who you claim to be) wrapped around your new password (encrypted, of course). The server either accepts the change or rejects it with one of eight possible result codes.²

How the Protocol Works

The kpasswd protocol builds on top of standard Kerberos primitives.³ Here is what happens when you change your password:

Step 1: Authentication

Your client obtains a service ticket for kadmin/changepw@REALM from the KDC on port 88. This ticket proves you have the right to talk to the password change service.

Step 2: The Request

Your client constructs a message containing:

• An AP-REQ (authentication request) using that service ticket
• A KRB-PRIV message (a Kerberos private message) containing your new password, encrypted with a session key

The new password travels inside the KRB-PRIV structure, never in plaintext. Even if someone intercepts the packet, they cannot read what you are changing your password to.

Step 3: The Reply

The server validates your ticket, extracts the new password, applies any password policies (length, complexity, history), and returns a result code:

That last code, 0x0007, is particularly interesting. It means the server requires an initial ticket, not a ticket-granting ticket. More on why that matters below.

The History

Kerberos itself was born at MIT in the 1980s, part of Project Athena.⁴ Steve Miller and Clifford Neuman designed the authentication protocol, drawing on the 1978 Needham-Schroeder symmetric key protocol. They named it after Cerberus (Κέρβερος in Greek), the three-headed hound that guards the gates of Hades.⁵

The naming is not merely decorative. The three heads represent the three parties in Kerberos authentication: the client, the server, and the Key Distribution Center (KDC) that mediates between them. Just as Cerberus guards the boundary between the living and the dead, Kerberos guards the boundary between authenticated and unauthenticated.

A prototype went into production at MIT in September 1986. By January 1987, Kerberos was authenticating 5,000 users across 650 workstations.⁶

But authentication was only half the problem. Users needed a secure way to change their passwords. The original kpasswd protocol emerged from this need, though it was never fully standardized. Different Kerberos implementations had different password change protocols.

RFC 3244, published in February 2002 by Michael Swift (University of Washington), Jonathan Trostle (Cisco Systems), and John Brezak (Microsoft), documented Microsoft's Windows 2000 version of the protocol.⁷ This RFC added a critical capability: the ability for administrators to set passwords for other users, not just change their own.

The RFC carries a telling status: "Informational." It is not an Internet Standard. It documents what Microsoft implemented, warts and all. But because Active Directory became the dominant enterprise identity system, RFC 3244's protocol became the de facto standard for password changes across most of the corporate world.

The Expired Password Purgatory

Here is the most elegant aspect of the kpasswd design: what happens when your password expires.

When a password expires in a Kerberos realm, the KDC will not give you tickets to anything. Not to the file server. Not to email. Not to the ticket-granting service itself. You are locked out of the kingdom.

Except for one door.

The KDC will issue you exactly one ticket: an INITIAL ticket to kadmin/changepw. This ticket cannot be used for anything except talking to the password change service on port 464.⁸

This design prevents a specific attack: if you walked away from your workstation while logged in, an attacker could not use your existing session to change your password (and lock you out). The initial ticket requirement means you must prove you know the current password, right now, to change it.

Port 464 becomes the only exit from authentication purgatory. You must remember the old password to create the new one. There is no other way back into the realm.

Security Considerations

The kpasswd protocol encrypts passwords in transit, but the real security considerations are about what happens around it.

Brute Force Attacks

RFC 3244 warns explicitly: "password policies should be enforced to make sure that users do not pick passwords... that are vulnerable to brute force password guessing attacks."⁹ The protocol itself does not enforce complexity. That is the server's job.

Network Exposure

Port 464 should never be exposed to the public Internet.¹⁰ The protocol assumes a trusted network environment. On the open Internet, it becomes a target for credential stuffing, denial of service, and protocol exploitation. Firewall it. VPN it. Keep it internal.

Kerberoasting

While Kerberoasting attacks primarily target port 88 and service tickets, the broader Kerberos infrastructure (including port 464) requires strong password policies to resist offline cracking.¹¹ If an attacker extracts a service ticket, they can attempt to crack it offline. The same principle applies to intercepted kpasswd traffic: strong passwords make cryptanalysis impractical.

Administrator Privileges

The set-password capability (where an administrator can set another user's password) requires careful privilege management. RFC 3244 notes that administrators authorized to set passwords are "highly trusted" and must protect their own credentials with extreme care.¹² One compromised admin account can reset every password in the realm.

Related Ports

Port 464 lives in a family of Kerberos-related ports:

Port 88 is the front door to authentication. Port 464 is the side door for password maintenance. Port 749 is the back office where administrators manage the realm itself.

What Flows Through Port 464

Every enterprise with Active Directory runs kpasswd traffic through port 464. That is most of the Fortune 500. Most hospitals. Most universities. Most government agencies.

Every time someone forgets their password and calls the help desk, the reset flows through this port. Every time a password policy forces a 90-day rotation, the change flows through this port. Every time a new employee gets their first domain credentials, the initial password set flows through this port.

It is quiet work. Users do not see it. Administrators rarely think about it. But without port 464, passwords would be static, unchangeable, and the entire security model would collapse.

The three-headed dog guards many doors. Port 464 is the door where identity transforms, where the old secret dies and the new one takes its place.