Configuring the Kerberos Domain Controller KDC
There are three distinct phases to configuring a Kerberos authentication environment: <
1. First, you need to configure your Kerberos KDC, which listens for ticket requests from Kerberos clients.
2. Next, you have to populate the database on the KDC with the Kerberos principals for which you will be seeking authentication.
3. Finally, you have to configure your Kerberos-enabled servers to make use of Kerberos authentication for popular services such as Telnet and FTP.
All Kerberos systems need the correct software. If Kerberos is not installed on your system, you need to locate and download three packages before you can begin the configuration:
■ krb5-workstation-1.2.1-8: the workstation binaries
■ krb5-server-1.2.1-8: the server binaries
These packages are readily available in RPM format from your favorite repository. Note that you must install krb5-workstation-1.2.1-8.i386.rpm before krb5-server-1.2.1-8.i386.rpm because it's one of its dependencies. Execute the following commands in this order to install these three packages:
[ramon]$ sudo rpm -i krb5-workstation-1.2.1-8.i386.rpm
Begin the Kerberos configuration by creating a primary KDC. First, check out the /etc/ krb5.conf file. This is the general Kerberos configuration file, which is divided into several sections, or stanzas. Each of these section starts with a heading, followed by a number of variable assignments:
[stanza heading] variableï = value variable2 = value
The sample /etc/krb5.conf file supplied with the server package is a good starting point for your configuration. Pay special attention to the [logging] and the [realms] sections.
The [logging] section instructs the KDC and the Kerberos administration server to send log events to a specific file or facility. The variables defined in the [logging] section are as follows:
■ admin_server specifies a target file or device for the administrative server to perform its logging.
■ kdc specifies a target file or device to which the KDC server should log its events.
■ default specifies how to perform logging in the absence of an entry for admin_server or kdc.
The values to be used for these variables can be as follows:
■ FILE=f7 7ename to specify a regular Linux file.
■ STDERR to specify the standard error log.
■ CONSOLE to specify the Linux console.
■ DEVICE=devicename to specify a Linux device other than a file.
■ SYSLOG[:<severity>[:<faci7ity>]] to specify syslog logging to the named facility with the named severity level.
Listing 13.1 shows a sample [logging] section that is logging KDC, the administrative server, and other events to three separate files.
Listing 13.1 The [logging] section of krb5.conf [logging]
default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log
The [realms] section of krb5.conf contains one or more blocks of information delimited by the following syntax:
[realms]
REALM_NAME_1 = { variable1 = value variable2 = value }
REALM_NAME_2 = { variable1 = value variable2 = value }
Each REALM_NAME_N section uses similar variables to the [logging] section:
■ admin_server specifies the name of the host running the administration server for the given realm. -g
■ kdc specifies the name of the host running the KDC for the given realm. « =
■ default_domain specifies the default domain to which hosts in this realm belong. <
Listing 13.2 shows an example of a [realms] section containing a single realm definition (HONTANON.COM) where both the KDC and the administration server are running on the host kerberos.hontanon.com. Note that the port numbers are specified after the hosts to separate the KDC service (TCP port 80) from the administration service (TCP port 749).
Listing 13.2 The [realms] section of krb5.conf [realms]
HONTANON.COM = { kdc = kerberos.hontanon.com:88 admin_server = kerberos.hontanon.com:749 default_domain = hontanon.com
The [domain_realm] section of krb5.conf defines a translation from any host name to a Kerberos realm name for the services provided by that host. For example, Listing 13.3 shows a [domain_realm] section that defines hosts ending in hontanon.com or anyhostname .hontanon.com to be in the HONTANON.COM realm.
Listing 13.3 The [domain_realm] section of krb5.conf
[domain_realm] .hontanon.com = HONTANON.COM hontanon.com = HONTANON.COM
The KDC Configuration File (kdc.conf)
Now let's take a look at the Kerberos KDC configuration file (/var/kerberos/krb5kdc/ kdc.conf) that is supplied with the Kerberos server package. This is the file where the KDC looks for configuration information that is specific to any one realm. The default file is a good starting point, but there are two sections that you'll want to pay attention to:
The [kdcdefaults] section contains default information for all realms. The following variables are typical examples of these defaults:
■ acl_file points to the file used to define the access control lists (ACLs) to the KDC. This file is described in detail later in this chapter.
■ dict_file points to a file that contains a list of passwords that are not allowed for use because they are too weak.
■ admin_keytab points to the location of the keytab file that the Kerberos administration server uses to authenticate to the database. This file is described in detail later in this chapter.
The [realms] section is similar to the equivalent section in the krb5.conf file described in the previous section and typically contains the following variable definitions:
■ master_key_type is the type of encryption used to protect the communication of the KDC's master key.
■ supported_enctypes is a reference to all the types of encryption supported by the KDC for this realm.
Listing 13.4 shows the complete contents of a typical kdc.conf file.
Listing 13.4 Contents of a typical kdc.conf file
[ramon]$ more /var/kerberos/krb5kdc/kdc.conf
[kdcdefaults]
ac1_fi1e = /var/kerberos/krb5kdc/kadm5.ac1 dict_fi1e = /usr/dict/words admin_keytab = /var/kerberos/krb5kdc/kadm5.keytab [realms]
HONTANON.COM = { master_key_type = des-cbc-crc supported_enctypes = des-cbc-crc:norma1 des3-cbc-raw:norma1^
des3-cbc-sha1:norma1 des-cbc-crc:v4 des-cbc-crc:afs3 }
You may want to create a similar configuration for your KDC. On my server, I also have a DNS alias kerberos.hontanon.com pointing to the IP address of my server, mostly for convenience. This allows me to change the IP address of the server platform, if needed, without having to change the configuration files. I simply make a DNS change for the host name to point to the new address.
The kdb5_util Utility
The kdb5_uti1 utility comes bundled with the Kerberos server package and allows you to perform administrative procedures on the Kerberos authentication database. You can use kdb5_uti1 to create the database, add new principals (humans and machines), and modify and delete those principals.
Let's start by creating the KDC database with the kdb5_uti1 utility, as shown in Listing 13.5.
Listing 13.5 Creating the KDC database with kdb5_util
[ramon]$ sudo /usr/kerberos/sbin/kdb5_util create -r HONTANON.COM -s
Initializing database '/var/kerberos/krb5kdc/principa1' for realm 'HONTANON.COM', master key name 'K/[email protected]'
You will be prompted for the database Master Password. It is important that you NOT FORGET this password.
Enter KDC database master key:
Re-enter KDC database master key to verify:
The command in Listing 13.5 prompts you for the Kerberos master key (you should pick a word that is hard to guess, containing both mixed-case characters and numbers) and creates the following files:
■ /var/kerberos/krb5kdc/principal: This is a Kerberos database file.
■ /var/kerberos/krb5kdc/principal.kadm5: This is the Kerberos administrative database.
■ /var/kerberos/krb5kdc/principal.kadm5.lock: This is the lock file associated with the Kerberos administrative database.
■ /var/kerberos/krb5kdc/.k5.HONTANON.COM: This file is called the stash, a local copy of the master key that is used to authenticate the KDC to itself before starting the kadmind and krb5kdc daemons.
WARNING The stash file should be heavily guarded and should by owned and readable only by the root user. The stash file should not be part of your regular backup scheme because this would force you to protect the privacy of your backup media (which would contain the master key of the KDC).
The kadm5.acl File
Take a look at the kadm5.acl file, typically located in /var/kerberos/krb5kdc. This file defines which principals are allowed to use the kdb5_util to modify which parts of the database. You need to have at least one Kerberos principal in this file, along with a list of permissions for that principal. The format of entries in the kadm5.acl file is as follows:
principal permissions [target-principal]
These fields have the following meanings:
■ principal is an entry that uses the syntax primary/instance@REALM
where primary is a username (e.g., ramon in the following example), instance defines a specific role (e.g., admin in the following example) and REALM corresponds to a Kerberos realm (e.g., HONTANON.COM in the following example). For example, a complete principal specification would be ramon/[email protected].
■ The permissions field can be made up of one or more of the characters listed in Table 13.1.
|
Option |
Meaning |
|
a |
Allow the addition of principals. |
|
A |
Prohibit the addition of principals. |
|
d |
Allow the deletion of principals. |
|
D |
Prohibit the deletion of principals. |
|
m |
Allow the modification of principals. |
|
M |
Prohibit the modification of principals. |
|
c |
Allow the changing of passwords for principals. |
|
C |
Prohibit the changing of passwords for principals. |
|
i |
Allow inquiries to the database. |
|
I |
Prohibit inquiries to the database. |
|
l |
Allow the listing of principals or policies. |
|
L |
Prohibit the listing of principals or policies. |
|
* Allow all privileges. | |
target-principal is an optional field that you can use to restrict certain actions to only apply to the specified principal.
For example, if you have a principal alice/[email protected] who simply needs to list all principals in the Kerberos database and change their passwords, you could use the following entry:
alice/[email protected] cli
To grant the principal bob/[email protected] all access to the principal */ [email protected] only (any principal in the HONTANON.COM realm that has the instance root), you would add the following line:
o s
To grant the principal ramon/[email protected] permission to change all of the database fields on any principal, add the following line:
ramon/[email protected] *
The kadmin.local Utility
Next, you need to add an administrator to the Kerberos database using the kadmin.local utility. This utility is a command-line interface to the Kerberos administration server and it must be executed on the same host as the Kerberos KDC. The administrator principal that you choose to add must be present in the kadm5.acl file.
Once you enter the kadmin.local utility, a kadmin.local: prompt appears, where you can specify one of the following commands:
■ addprinc principal: This command adds a new principal to the database.
■ delprinc principal: This command deletes an existing principal from the database.
■ modprinc principal: This command allows you to modify an existing principal.
■ renprinc new old: This command renames a principal from new to old.
■ cpw principal: This command allows you to change a principal's password.
■ getprinc principal: This command displays a principal's record.
■ listprincs: This command lists all principals in the database.
■ ktadd -k keytab principal [principal]: This command adds one or more principal(s) to a keytab.
■ ktremove -k keytab principal [principal]: This command removes one or more principal(s) from a keytab.
To create an administrator ramon/[email protected], enter the following command. In this example, the addprinc command adds a new principal to the Kerberos database with administrator privileges.
[ramon]$ sudo /usr/kerberos/sbin/kadmin.local
Authenticating as principal root/[email protected] with password. kadmin.local: addprinc ramon/[email protected]
Enter password for principal "ramon/[email protected]":
Re-enter password for principal "ramon/[email protected]":
Principal "ramon/[email protected]" created.
Next, you need to create a kadmind keytab. A keytab is just a special key that will be used by the Kerberos administration daemon (kadmind) to decrypt the administrators' Kerberos tickets before granting them access to the Kerberos database. Note that there are two principals for whom you will be creating keytabs: kadmin/admin and kadmin/changepw. These two principals are automatically created by Kerberos when the database is first generated. You use the kadmin.local command, as before, to create the keytabs, as shown in Listing 13.6.
Listing 13.6 Creating the keytabs with kadmin.local
[ramon]$ sudo /usr/kerberos/sbin/kadmin.local
Authenticating as principal root/[email protected] with password.
kadmin.local: ktadd -k /var/kerberos/krb5kdc/kadm5.keytab kadmin/admin kadmin/changepw
Entry for principal kadmin/admin with kvno 4, encryption type DES^ cbc mode with CRC-32 added to keytab WRFILE:/var/kerberos/krb5kdc/ kadm5.keytab.
Entry for principal kadmin/admin with kvno 4, encryption type Triple DES cbc mode raw added to keytab WRFILE:/var/kerberos/krb5kdc/kadm5.keytab.
Entry for principal kadmin/changepw with kvno 4, encryption type DES cbc mode with CRC-32 added to keytab WRFILE:/var/kerberos/krb5kdc/kadm5.keytab.
Entry for principal kadmin/changepw with kvno 4, encryption type^ Triple DES cbc mode raw added to keytab WRFILE:/var/kerberos/krb5kdc/ kadm5.keytab.
The ktadd command is invoked with the -k switch, followed by the location of the keytab file. This file should match the value of the admin_keytab variable in the kdc.conf file (/var/kerberos/krb5kdc/kadm5.keytab in the example earlier in this section).
You are now ready to start both the main KDC daemon and the administration daemon with the following commands:
[ramon]$ sudo /usr/kerberos/sbin/krb5kdc
[ramon]$ sudo /usr/kerberos/sbin/kadmind
Once the commands have been entered, the processes will fork and move into the background, freeing up your terminal for other work. If you want these processes to start at system boot time, you can add symbolic links to the scripts
/etc/rc.d/init.d/krb5kdc H
to the /etc/rc.d/rc5.d directory.
NOTE If at all possible, dedicate a system to perform the KDC functions exclusively. Running other services (FTP, WWW, and SMTP) on the KDC increases the risk that the Kerberos database will be compromised via a vulnerability in these additional services.
Populating the KDC Database
Once the Kerberos server is up and running, you can start adding the principals that you wish to authenticate. You populate the Kerberos database using the kadmin utility. This is very similar to the kadmin.local utility. In fact, the only difference is that while the kadmin.local utility must be executed at the KDC, kadmin can be executed remotely and uses Kerberos authentication to grant remote access to the KDC database.
You can add a new principal using the command:
kadmin: addprinc principal
For example, to add username ramon and create an initial password, do the following:
[ramon]$ /usr/kerberos/sbin/kadmin
Authenticating as principal ramon/[email protected] with password.
Enter password:
kadmin: addprinc alice
Enter password for principal "[email protected]":
Re-enter password for principal "[email protected]":
Principal "[email protected]" created.
Note that in order to use the kadmin command, you have to authenticate yourself as the principal ramon/[email protected], who has been given administrative privileges to modify the Kerberos database.
Once a principal has been created for a given user, they can change their Kerberos password themselves by issuing the kpasswd command:
[a1ice]$ kpasswd
Password for [email protected]: Enter new password: Enter it again: Password changed. Configuring Kerberos-Enabled Servers
Once you have successfully configured a KDC and have populated its database with the information from the principals that you want to authenticate, it's time to enable your servers to use Kerberos authentication when a user requests access to a specific service.
The first step is making the KDC database aware of the servers and services that you wish to authenticate. You have to create a principal for each service/server combination.
For example, to allow the server caldera.hontanon.com to use Kerberos authentication for both the Telnet and FTP daemons, you need to create the following principals:
host/caldera.hontanon.com ftp/caldera.hontanon.com
The host/caldera.hontanon.com principal is used for authentication of the telnet, rsh, and rlogin services. You can add these principals to the database using the addprinc command inside the kadmin utility, just as in the previous section. See Listing 13.7 for the details.
Listing 13.7 Using kadmin to add principals to the KDC database [ramon]$ kadmin
Authenticating as principal ramon/[email protected] with password. Enter password:
kadmin: addprinc host/caldera.hontanon.com
Enter password for principal "host/caldera.hontanon.com@~CAHONTANON.COM": Re-enter password for principal "host/[email protected]": kadmin: addprinc ftp/caldera.hontanon.com
Enter password for principal "ftp/caldera.hontanon.com@~CAHONTANON.COM": Re-enter password for principal "ftp/[email protected]": Principal "ftp/[email protected]" created.
You have created the appropriate host and ftp principals in the KDC's database, but you still have to enable the caldera.hontanon.com server to authenticate itself to the KDC for these two services. The authenticating server (caldera.hontanon.com) needs to have keytabs for the appropriate principals (host, ftp) stored in its local /etc/krb5.keytab. You use the ktadd command inside the kadmin utility to create the keytab file, as shown in Listing 13.8.
Listing 13.8 Using kadmin to create the keytab file (/etc/krb5.keytab)
[ramon]$ sudo /usr/kerberos/sbin/kadmin -p ramon/admin
Authenticating as principal ramon/admin with password.
Enter password:
kadmin: ktadd host/caldera.hontanon.com
Entry for principal host/caldera.hontanon.com with kvno 8, $ encryption type DES cbc mode with CRC-32 added to keytab WRFILE:/etc/ krb5.keytab.
Entry for principal host/caldera.hontanon.com with kvno 8, $ encryption type Triple DES cbc mode raw added to keytab WRFILE:/etc/ krb5.keytab.
kadmin: ktadd ftp/caldera.hontanon.com
Entry for principal ftp/caldera.hontanon.com with kvno 2, $ encryption type DES cbc mode with CRC-32 added to keytab WRFILE:/etc/ krb5.keytab.
Entry for principal ftp/caldera.hontanon.com with kvno 2, $ encryption type Triple DES cbc mode raw added to keytab WRFILE:/etc/ krb5.keytab.
Note that you are running the kadmin command on the target server (caldera .hontanon.com), which must be configured to point to the kadmind daemon on kerberos.hontanon.com. This is defined in the [realms] section of /etc/krb5.conf file, as explained in the previous section, "Configuring the Kerberos Domain Controller (KDC)." You must execute the command as root (using sudo), and you use the -p ramon/admin option to specify which principal you want to use in order to gain administrative permissions to the Kerberos database.
As you can see from its output, the ktadd command adds the appropriate keytab entry to the /etc/krb5.conf file on the target server. In this case, ca1dera.hontanon.com should be ready to use Kerberos authentication for ftp, telnet, rsh, and rlogin.
The next step is to modify the target server's network setup to use the Kerberized versions of the network daemons. If your system is using /etc/inetd.conf to spawn off services, add the following lines:
ftp stream tcp nowait root /usr/kerberos/sbin/ftpd ftpd -a -1
telnet stream tcp nowait root /usr/kerberos/sbin/te1netd te1netd$ -a va1id kshe11 stream tcp nowait root /usr/kerberos/sbin/kshd kshd -ec ek1ogin stream tcp nowait root /usr/kerberos/sbin/k1ogind k1ogind$ -ec
Note that you may have to add the following Kerberos-specific entry to your server's /etc/services file, depending on your distribution (Red Hat 7.0 and Caldera eServer 2.3 include it, but SuSE 7.0 does not):
ek1ogin 2105/tcp # Kerberos encrypted r1ogin
If you are using xinetd, use the following format (ftpd is shown as an example):
[ramon]$ more /etc/xinetd.d/ftp service ftp {
flags = REUSE
socket_type = stream wait = no user = root server = /usr/kerberos/sbin/ftpd server_args = -a -l 1og_on_fai1ure += USERID disable = no
Note that you specified the -la arguments when invoking /usr/kerberos/sbin/ftpd. Let's take a closer look at the options available on each of these Kerberized services. For each of these services (ftp, telnet, kshell, and klogin) you will learn about the command-line options that are particular to the Kerberos version of the server.
ftpd The Kerberos FTP server allows you to make files on your server available for transfer over a TCP connection. Table 13.2 contains the Kerberos-specific command-line options when invoking the /usr/kerberos/sbin/ftpd daemon.
Table 13.2 Kerberos ftpd Daemon Command-line Options
Option Meaning
-A Only allow connections for users who can authenticate via the ftp AUTH mechanism. Prompt for password if they require one.
-a Only allow connections for users who can authenticate via the ftp AUTH mechanism and who are authorized to connect to the FTP server without a password.
-C Users should be prompted for a password unless they present Kerberos authentication credentials.
-r realmfile Specify the Kerberos realm to use. (The ¿= <
default is the value of the default_realm variable in /etc/krb5.conf.)
I recommend that you invoke ftpd with the following options: ftpd -a -1
This command forces the user to use Kerberos authentication to access the FTP server rather than their username/password combination. In addition, the -1 option (not Kerberos-specific) instructs the ftp daemon to write an event to syslog every time a user fails authentication.
telnetd The Kerberos version of the Telnet server uses the command-line options listed in Table 13.3.
|
Option |
Meaning |
|
-a debug |
Turn on authentication debugging code. |
|
-a user |
Only allow connections when the remote user can provide valid authentication information to identify the remote user and is allowed access to the specified account without providing a password. |
|
-a valid |
Only allow connections when the remote user can provide valid authentication information to identify the remote user. The login(1) command will provide any additional user verification needed if the remote user is not allowed automatic access to the specified account. |
|
-a none |
No authentication information required (default). |
|
-a off |
Disable authentication altogether. |
I recommend that you invoke telnetd with the following options: telnet -a valid
This command forces the remote user to provide proper Kerberos authentication before being handed over to the login program for interactive access.
kshd The kshd daemon is the Kerberized version of the rshd remote shell server that comes standard with Linux. Table 13.4 lists the options available when invoking the kshd command.
|
Option |
Meaning |
|
-A |
Don't allocate a reserved port for the stderr connection. |
|
-c |
Require clients to present a cryptographic checksum of initial connection information such as the name of the user that the client is trying to access in the initial authenticator. |
|
-e |
Require client to support encryption. |
|
-M realm |
Specify the Kerberos realm to use. (The default is the value of the default_realm variable in /etc/krb5.conf.) |
I recommend that you invoke kshd with the following options:
This command ensures the privacy of the connection by encrypting all the packets «¡t .H
exchanged. In addition, the -c option prevents an attacker from changing the initial ï J
connection information. iS «3
klogind Table 13.5 lists the options that are unique to the Kerberos implementation of rlogind (klogind).
|
Option |
Meaning |
|
-A |
Don't allocate a reserved port for the stderr connection. |
|
-c |
Require clients to present a cryptographic checksum of initial connection information such as the name of the user that the client is trying to access in the initial authenticator. |
|
-e |
Require client to support encryption. |
|
-P |
Always prompt users for a password. |
|
-p |
Prompt for a password if Kerberos authentication does not succeed. |
|
-M realm |
Specify the Kerberos realm to use. (The default is the value of the default_realm variable in /etc/krb5.conf.) |
I recommend that you invoke klogind with the same options as kshd: klogind -e -c
Do not use either the -P or the -p options. Kerberos authentication should be the only mode of authentication for this service.
Continue reading here: Managing Kerberos Credentials
Was this article helpful?