A reply from the server serves as confirmation that the host and the server can communicate.Ĭonnectivity failures while pinging the KDC's FQDN usually point to DNS server or client configuration errors. The output of the ping command shows successful resolution of the FQDN to an IP Address, and a sample reply from the server. To verify connectivity between hosts, ping each host's FQDN:
Test the local DNS name resolution using the nslookup technique described at the beginning of the section. If the server does not already have a FQDN assigned to it and DNS services are not available, name resolution can be implemented by editing the local hosts file (typically this is located in /etc) on each server and client, adding the following line:ġ27.0.0.1 localhost linuxwork The output of the second command should contain the FQDN of the server. The output of the first command should contain the IP address of the server. If the server already has an FQDN assigned to it, test forward and reverse look-up with the following commands: $ nslookup If this is the case, verify that each server has a FQDN assigned to it before performing the tests outlined in this section. Note: Active Directory depends heavily on DNS, so it is likely that the Active Directory Domain Controller is also running the Microsoft DNS server package. If reverse domain name resolution is not available, set the rdns variable to false in clients' nf Kerberos also expects the server's FQDN to be reverse-resolvable.
The following section describes how to meet these requirements.Įach server in a Kerberos authentication realm must be assigned a Fully Qualified Domain Name (FQDN) that is forward-resolvable. For instance, the site would conventionally use EXAMPLE.COM for its realm name.Īll servers and clients that participate in a Kerberos realm must be able to communicate with each other and have accurate system clocks. Conventionally, the realm names is the site's domain name fully capitalized.
Selecting a descriptive name for the Kerberos authentication realm is also important. Physical and network security will be critical for this server, since a compromised KDC compromises the security of the entire realm. Before deploying Kerberos, a server must be selected to take on the role of KDC.
Readers wishing to integrate with an Active Directory Domain can skip directly to the Client Configuration section.Ī central part of Kerberos' trusted third party authentication scheme is the Key Distribution Center (KDC), which is a centralized repository for users' password information. In an Active Directory environment, the KDC is typically one of the services provided by the Domain Controller (DC). The following guide contains several notes that give specific configuration information for Active Directory. Microsoft's Active Directory is a common closed-source implementation of a Kerberos authentication realm. The same concepts apply to Heimdal, although the syntax of various commands is different. These regulations are no longer a concern, and for sake of brevity, this guide will provide instructions for the MIT version. Two common open-source implementation of the Kerberos protocol are the original MIT implementation, and Heimdal, an implementation that was created to avoid United States export regulations. It is directed at system administrators that need to supplement their understanding of Kerberos and its advanced configuration. This guide aims to supplement the documentation available in the official Ubuntu documentation by re-iterating certain key concepts in more detail and providing information on network service configuration. Designing an Authentication System is an accessible introduction to the principals of Kerberos' authentication scheme. More information about the Kerberos protocol is available from MIT's Kerberos site. Kerberos is an authentication protocol using a combination of secret-key cryptography and trusted third parties to allow secure authentication to network services over untrusted networks.