Short answer: a Kerberos v5 Key Distribution Center (KDC) is a trusted authentication service that issues time-limited tickets to users, computers, and services. NetSmart 1.0.7 adds a managed KDC on TCP and UDP port 88, with encrypted principal keys, password management, downloadable client configuration, health reporting, and web start/stop controls.
Kerberos is useful when several internal services need a shared authentication system and users should not repeatedly send passwords to each service. The client proves its identity to the KDC, receives a ticket, and presents the appropriate service ticket to a compatible application.
What is a Kerberos KDC?
The KDC is the central trust service for a Kerberos realm. A realm is the administrative authentication boundary, usually written in uppercase, such as EXAMPLE.COM. A principal is a named Kerberos identity representing a user, host, administrator, or service.
The KDC performs two closely related roles:
- Authentication Service (AS): validates the initial identity request and issues a Ticket-Granting Ticket (TGT).
- Ticket-Granting Service (TGS): accepts a valid TGT and issues tickets for individual services.
The MIT Kerberos documentation defines a ticket as an encrypted protocol message that provides authentication. Tickets expire, limiting how long copied credentials remain useful.
How Kerberos authentication works
- The user or computer requests initial credentials from the KDC.
- After successful verification, the KDC issues a Ticket-Granting Ticket.
- When the client needs a compatible service, it uses the TGT to request a service-specific ticket.
- The KDC returns a ticket protected for that service.
- The client presents the service ticket, and the service validates it without receiving the user's password.
User or computer
|
| request initial ticket
v
Kerberos KDC ---- issues TGT
^
| request service ticket
v
Application, server, or network serviceThis ticket flow can support single sign-on across compatible services: authenticate once, then use service tickets until the credentials expire or require renewal. Kerberos authenticates identities; each application must still enforce its own authorization rules.
What NetSmart 1.0.7 provides
- A managed Kerberos v5 KDC
- Standard Kerberos service on TCP and UDP port 88
- Encrypted storage for principal keys
- Principal password management
- Downloadable client configuration
- Service health reporting
- Web controls to start and stop the KDC
- Docker port and configuration support for deployment
The web management layer reduces repetitive configuration work, but it does not remove the need to plan the realm, DNS names, time source, firewall rules, service principals, backups, and recovery access.
Why use Kerberos?
Passwords are not sent to every service
With a correctly integrated application, the client presents a service ticket rather than sending the user's reusable password to each destination. This reduces password exposure across the network and limits how many systems must directly handle user credentials.
Centralized authentication
Principals and key material are managed within one realm. Administrators can apply consistent identity naming, password operations, ticket policies, and service registration across compatible systems.
Short-lived credentials
Kerberos tickets have defined lifetimes. A ticket is not equivalent to an indefinite password, and privileged ticket lifetimes can be configured more conservatively.
Mutual authentication
Kerberos-capable protocols can verify the service as well as the client. This helps clients avoid presenting authentication material to an impostor that does not possess the service's expected key.
Service automation
Hosts and services can use principals and protected keytabs for non-interactive authentication. Keytabs must be handled as secrets because possession of a service key can allow impersonation of that service.
Where a KDC is useful
| Environment | Kerberos value |
|---|---|
| Windows or Samba domain | Authenticates domain users, computers, and AD-compatible services. |
| Linux server fleet | Provides shared authentication for Kerberos-aware SSH, web, database, and file services. |
| Internal applications | Supports ticket-based sign-in without giving every application the user's password. |
| Service-to-service access | Uses service principals and keytabs for controlled machine authentication. |
| Lab or development realm | Provides a contained environment for testing Kerberos integration and client configuration. |
Kerberos depends on accurate time
Kerberos uses timestamps and ticket lifetimes to reduce replay risk. Clients, application servers, and the KDC must keep their clocks synchronized. MIT's administration guidance notes that hosts outside the permitted clock skew can have ticket requests or responses rejected.
Use a reliable NTP source for every Kerberos participant. NetSmart's managed NTP service can provide a consistent internal time source, but it should itself synchronize with trusted upstream servers and be monitored for drift.
DNS and hostname requirements
Kerberos service principals commonly include fully qualified hostnames. Forward and reverse DNS, the client configuration, service principal name, and keytab must agree. The MIT Kerberos application-server guidance warns that hostname canonicalization must match the principal stored in the host's keytab.
Before enrolling applications, establish stable DNS names and decide whether clients will discover the realm through DNS or the downloadable configuration provided by NetSmart.
Security and availability checklist
- Expose TCP and UDP port 88 only to networks and clients that require Kerberos.
- Keep the NetSmart administration interface on a trusted network and protect it with HTTPS.
- Restrict access to principal management, password operations, exported configuration, and backups.
- Treat keytabs, principal keys, database backups, and recovery credentials as high-value secrets.
- Synchronize the KDC, clients, and application servers through reliable NTP sources.
- Verify forward and reverse DNS before diagnosing application authentication failures.
- Monitor KDC health and test ticket acquisition instead of checking only whether the port is open.
- Plan backup, restore, and redundant KDC capacity when authentication availability is business-critical.
What Kerberos does not replace
- Authorization: a valid ticket proves identity; the application still decides what that identity may do.
- Transport security: Kerberos can authenticate endpoints and some protocols can negotiate protection, but HTTPS, TLS, or another secure transport may still be required.
- Endpoint security: malware or an attacker controlling a signed-in device may be able to use cached tickets.
- High availability: one KDC is still one failure domain. Critical realms need redundancy and tested recovery.
Frequently asked questions
Which port does Kerberos use?
Kerberos v5 normally uses both TCP and UDP port 88. Publish and permit only the transport paths required by authorized clients and services.
What is the difference between a TGT and a service ticket?
A Ticket-Granting Ticket lets a client request additional tickets from the KDC. A service ticket is issued for one specific service principal and is presented to that service.
Does Kerberos provide single sign-on?
It can provide single sign-on for compatible services. After initial authentication, the client can obtain service tickets without repeatedly entering the password, subject to ticket policy and application support.
Why does Kerberos fail when clocks differ?
Kerberos checks timestamps to help prevent replay of old authentication messages. Requests outside the allowed clock skew are rejected.
Is a keytab a password?
A keytab is not plain text, but it contains long-term keys for principals. Treat it with the same or greater care as a service password.
Managed authentication without hiding the fundamentals
NetSmart 1.0.7 makes a Kerberos v5 KDC easier to operate through encrypted principal-key storage, password management, client configuration downloads, health reporting, and web controls. Successful deployment still depends on disciplined DNS, time synchronization, key protection, firewall policy, monitoring, and recovery planning.
Explore NetSmart network and identity services or open the NetSmartApp Docker image.