Port 749: Kerberos Administration — The Keys to the Realm

Port 749 is where identities are born and die.

While port 88 handles the authentication tickets that let users prove who they are, port 749 carries something more fundamental: the administrative commands that create, modify, and destroy those identities in the first place. This is the kadmin service—the Kerberos Administration daemon—and it is one of the most privileged services in any enterprise network.

What Runs on Port 749

The kadmind daemon listens on TCP and UDP port 749, accepting remote requests to administer the Kerberos principal and policy databases.¹ When a Kerberos administrator needs to:

• Create a new user principal
• Reset someone's password
• Generate a keytab for a service
• Modify password policies
• Delete accounts that should no longer exist

Those commands travel to port 749.

The client tool, kadmin, can run from any machine that can reach the Key Distribution Center (KDC). It authenticates using Kerberos itself—you need valid credentials to manage credentials—and then issues commands through an encrypted RPC channel.²

There's also kadmin.local, which runs directly on the master KDC and bypasses network authentication entirely. This is for emergencies, for bootstrapping, for when the authentication system itself needs repair.

The Administrative Architecture

Kerberos has a deliberate separation of concerns:

Port 464's kpasswd service exists specifically so that ordinary users can change their own passwords without needing administrative privileges.³ Port 749's kadmind is different—it's for administrators who need to manage other people's principals, create service accounts, export keytabs, and configure policies.

The distinction matters. Port 464 is a narrow door: users can only change their own passwords. Port 749 is the master key.

How kadmin Works

When you run kadmin and authenticate, your client obtains a service ticket for kadmin/admin@REALM or kadmin/changepw@REALM.⁴ The kadmind daemon validates this ticket, then checks an Access Control List (ACL) to determine what you're allowed to do.

The ACL file defines privileges with granular precision:

• add — Create new principals
• delete — Remove principals
• modify — Change principal attributes
• change-password — Set passwords for other principals
• get — Read principal information
• list — Enumerate principals
• get-keys — Extract encryption keys (extremely sensitive)

Most administrators get subsets of these permissions. The principle of least privilege applies doubly here—granting someone the ability to create principals in your Kerberos realm is granting them the ability to create identities your entire infrastructure will trust.

The Story Behind Port 749

Kerberos emerged from MIT's Project Athena, a five-year initiative launched in May 1983 to integrate computing into the curriculum.⁵ The project faced a fundamental problem: how do you authenticate users across a network of shared workstations and servers?

The answer in 1983 was terrifying: you didn't, really. Protocols like Telnet and rlogin sent passwords in plaintext. Anyone with a packet sniffer could harvest credentials by the dozen.⁶ And public workstations were worse—someone could modify the login program to capture passwords before anyone noticed.

Steve Miller and Clifford Neuman designed Kerberos based on the Needham-Schroeder protocol, with contributions from Jerome Saltzer and Jeffrey Schiller.⁷ The system went into production at MIT in September 1986, and by January 1987, it was authenticating 5,000 users across 650 workstations and 65 servers.⁸

But authentication alone wasn't enough. Someone had to manage the database of principals. Jeff Schiller designed and wrote the administration server and its user interface—the original kadmin.⁹

The name "Kerberos" comes from Greek mythology: Cerberus, the three-headed dog who guards the gates of Hades. Just as Cerberus controlled who could enter and leave the underworld, Kerberos controls access to network resources. The three heads are sometimes interpreted as representing the three parties in Kerberos authentication: the client, the server, and the KDC that mediates between them.¹⁰

Port 749 wasn't specified in the original MIT implementation—early versions used different port assignments. The kerberos-adm service was eventually registered with IANA as port 749 for both TCP and UDP, becoming the standard administrative endpoint for Kerberos V5.¹¹

The Protocol Evolution

Kerberos Version 5 was formally specified in RFC 1510 in September 1993, authored by John Kohl and Clifford Neuman.¹² This was replaced by RFC 4120 in July 2005, which clarified the protocol and incorporated lessons from years of deployment.¹³

The administration protocol itself evolved separately. RFC 3244, published in February 2002, documented Microsoft's extensions to the Kerberos password protocols for Windows 2000 compatibility.¹⁴ This allowed the MIT implementation to interoperate with Active Directory environments, which had adopted Kerberos as their primary authentication protocol when Windows 2000 shipped on February 17, 2000.¹⁵

Today, kadmind on port 749 can support:

• Traditional MIT kadmin protocol
• Microsoft set-password protocol (RFC 3244)
• Incremental database propagation to replica KDCs

Security Considerations

Port 749 is a high-value target. Anyone who compromises the kadmind daemon has the ability to:

• Create principals that impersonate legitimate users
• Export keytabs that allow persistent access
• Modify or delete existing accounts
• Extract encryption keys from the database

The vulnerability history reflects this sensitivity:

CVE-2025-24528: A vulnerability in log file handling when incremental propagation is enabled allows authenticated attackers to crash kadmind or potentially execute arbitrary code.¹⁶

CVE-2018-5729/5730: NULL pointer dereference and LDAP container check bypass vulnerabilities that could allow authenticated kadmin users to cause denial of service or bypass security restrictions.¹⁷

Historic buffer overflow (krb5 1.5.1): A remotely exploitable overflow in kadmind could yield the permissions of the running user—typically root.¹⁸

PAC parsing vulnerability: Integer overflows in PAC parsing could lead to remote code execution in KDC, kadmind, or application servers on 32-bit platforms.¹⁹

The consistent theme: these vulnerabilities require authentication first. Kerberos's design assumes that authenticated administrators are semi-trusted. The ACL system provides defense in depth, but a vulnerability in the daemon itself can bypass those controls.

Protecting Port 749

In production environments:

• Firewall aggressively: Only administrative workstations should reach port 749
• Use DNS SRV records carefully: The _kerberos-adm._tcp SRV record tells clients where to find kadmind—limit this to your master KDC²⁰
• Audit ACL permissions: Review who has what privileges regularly
• Monitor for unusual activity: Bulk principal creation or keytab exports should trigger alerts
• Consider network segmentation: The KDC should be in a restricted management network

Related Ports

Current Usage

Kerberos administration on port 749 remains critical infrastructure for:

• Enterprise Active Directory: While Microsoft has its own administrative tools, the underlying Kerberos infrastructure uses these same principles
• MIT Kerberos realms: Universities, research institutions, and organizations running native MIT Kerberos
• Cross-realm trust: Organizations federating authentication between different Kerberos realms
• Service account management: Automated systems that provision and rotate service credentials

The port sees less direct traffic than port 88—authentication happens constantly, while administration is occasional. But when it does carry traffic, that traffic shapes the identity landscape of the entire realm.