Kerberos Network Design Manual
Realm Administration Basics: Master and Slave
Since the Kerberos environment is sensitive to the security of a single Key Distribution Center, it requires a secure protocol for administrating and propagating the realm database. Divided into two distinct functions, each master KDC has an administration daemon that is responsible for remotely updating the Kerberos database, such as adding principals, or changing passwords. Likewise, the master KDC is responsible for periodically propagating new copies of the realm database through kpropd to its slave servers.
Although some Kerberos distributions, including Cygnus Solutions Kerbnet, has administrative GUIs, most Kerberos administration is done through kadmin, a command-line utility. Controlled by the kadmind on the Kerberos server, an access control list limits which principals may add principals, sets policies, or changes passwords in the realm datab ase.
When invoked, kadmin requests credentials for the user's administrative instance (user/admin@REALM.COM) and prompts the user for the administrative instance password. Once authenticated, the administrative user can add principals, change passwords, stash keys and delete principals from the realm database.
A master KDC is defined as the server running the kadmind, and is the central point of administration in that realm. Slave KDCs are periodically updated through secure communications via the kpropd, or Kerberos database propagation protocol. Using a cached copy of the master database password, each slave KDC receives an encrypted copy of the updated principal database, which is decrypted using the master password.
For more detailed information on Kerberos administration tools and configuration of slave KDCs, please consult documentation for the appropriate Kerberos distribution.
To Kerberize or not to Kerberize, that is the question. Adding Kerberos to the network is not necessarily plug-and-play solution. A network service is only as valuable as the applications that take advantage of it. Because Kerberos is based on application-level libraries, applications must be individually reprogrammed to take advantage of the protocol. While simple TCP/IP services like FTP and telnet are often available in both client and server forms on the Internet, nonstandard or homegrown IP applications might need to be rewritten. Since it often requires a sizable investment in programming time and energy to add server-side and desktop cli ent applications to the Kerberos environment.
While most Kerberos distributions include Kerberized versions of basic applications like FTP, POP and telnet, this may not be enough to justify the complexity of the system. We have found that support for Kerberos is most available under Unix. While Kerberos ticket managers and telnet clients are readily available on most popular desktop platforms (MacOS, Windows 3.x, Windows95, Windows NT), additional Kerberized services are hard to find.
Recall that Kerberos is a network authentication system built upon trust. Instead of decentralizing the task of authentication, Kerberos consolidates the task of verifying users to a single, centralized server. While this does add a single point of administration, it also means that the network is effectively only as secure as the Kerberos KDC--an efficient Kerberos installation requires this trust in the Kerberos server to be well-placed. Some organizations choose to keep their Kerberos servers protected in a vault, but every Kerberos server should at least be a dedicated machine with severely restricted access. Likewise, to balance load and provide some measure of redundancy, plan to dedicate at least one slave server.
Kerberos also is a time-sensitive protocol. One of the ways Kerberos fights replay attacks is to reject old network packets. In a compromise between total security and administrative headaches, most Kerberos implementations allow a time skew of plus or minus five minutes. This allows enough leeway to accommodate small networks with clocks set by hand, but any sane network administrator should plan on implementing some automatic time synchronization procedure. While time can be obtained through the "daytime" port on most versions of Unix, we recommend installing the Network Time Protocol. This has the added benefit of synchronizing every participating node on your network to UTC (Universal Coordinated Time--a French acronym, hence the backwards spelling), that is maintained by atomic clocks world wide. We found XNTP, a Unix-based NTP server, to be a good choice for our environment.
Kerberos adds the benefit of secure connections when used as a centralized authentication service, but its lack of supporting applications can make other technologies a more effective choice.
Kerberos in the Unix Environment
Kerberos provides a mechanism for secure network, but it doesn't include any provisions for controlling access to various services throughout the network. For instance, when implemented on Unix systems, users with valid Kerberos credentials are granted access, as long as their user IDs have a vali d entry in the standard user directory (/etc/passwd, NIS, NIS+, etc). Even though it bypasses the password authentication on the Unix side, a Kerberos user still retains information such as GECOS field (full name, telephone, etc), home directory, primary group and shell type from the Unix directory. Likewise, as Kerberos does not reliably track user sessions, it cannot provide an audit trail of when users have previously logged on or how many users are currently logged on throughout the network.
However, Kerberos can provide a decent single sign-on solution in a Unix network. Basic IP services are supplied to handle login and file transfer, and Kerberos libraries are included in the installation. Using these libraries and source code from unsupported applications, a Unix environment can become completely Kerberos-aware.
In addition, Kerberos includes "ksu," another valuable tool for the Unix environment. By using a separate root instance and a per-machine ACL, administrators can use Kerberos to grant root access to various usersIn general use in our lab, ksu effectively allowed each authorized root user his or her own root password. In Kerberos administration, which uses the user/admin@REALM.COM instance, ksu requires users to have a root instance such as user/root@REALM.COM. To gain root access, a user simply types "ksu." If the user's name is listed in the local root access control list, usually /.k5login in most Unix environments, and the KDC responds with an appropriate root instance ticket, the user is prompted for the root instance password. If the root instance credentials are valid, then the user is given a root shell.