A.1 MIT

In MIT Kerberos 5, Kerberos database tasks are performed by the kadmind daemon. Normally, this daemon is run on KDC startup when the main Kerberos daemon, krb5kdc, is started. The kadmind daemon listens for client requests on TCP port 749. The client, kadmin, can be run on any machine that is able to communicate with the KDC. It is recommended that a firewall be used to limit network access to port 749 to restrict unauthorized users from connecting to the administrative daemon.

The kadmin client uses configuration from /etc/krb5.conf to locate the master KDC that runs the kadmind server. It will use the value of the admin_server parameter located in the realm that the client is a member of. If you compiled with DNS support (the default), it will also attempt to use DNS to locate the admin server service. If these methods fail, kadmin will give up attempting to look for a server, and exit with an error message. You can manually specify a realm name and server address with the -r and -s options, respectively.

After a connection has been established between the kadmin client and the kadmind server, the client performs mutual authentication with the administration server, using a temporary credential cache to acquire tickets to authenticate with the server, for security reasons.

Note that a MIT kadmin client is required to communicate with an MIT kadmind server. You cannot use Heimdal kadmin to administer an MIT KDC.

There is also a fail-safe copy of kadmin named kadmin.local that accesses the Kerberos database directly on the KDC. To run kadmin.local, you must be root on the master KDC. The commands available in kadmin.local are the same as the commands available in kadmin.

A.1.1 Connecting to kadmin

You do not need any special privileges on the client machine to use kadmin; all you need is the password to a principal that has privileges enabled in the kadmin ACL file.

% /usr/local/sbin/kadmin
Authenticating as principal jgarman/admin@WEDGIE.ORG with password.
Enter password:
kadmin:

Inside of kadmin, a list of available commands is always available through the "?" command.

The fail-safe copy of kadmin, kadmin.local, requires root privileges to run. You have to be root on the master KDC to run kadmin.local because it modifies the Kerberos database directly. As such, running kadmin.local does not require any Kerberos daemons to be running, and in fact it is most commonly used to set up the initial Kerberos principals when establishing a new realm. Starting kadmin.local is very similar to starting kadmin:

# /usr/local/sbin/kadmin.local 
Authenticating as principal jgarman/admin@WEDGIE.ORG with password.
kadmin.local:

listprincs [glob-pattern]

Aliases

list_principals, get_principals, getprincs

The listprincs command lists the principals currently residing in the Kerberos database. Without parameters, listprincs lists all principals. An optional glob-pattern can be used to limit the output to a particular subset of principals.

The output of listprincs is terse; each line of output contains the principal name and nothing more. For more information about a principal or set of principals, see the getprinc command.

The listprincs command requires that the user have L permissions on the principals that they are listing.

Examples

kadmin:  listprincs
K/M@WEDGIE.ORG
jdoe/admin@WEDGIE.ORG
jdoe@WEDGIE.ORG
jgarman/admin@WEDGIE.ORG
kadmin/admin@WEDGIE.ORG
kadmin/changepw@WEDGIE.ORG
kadmin/history@WEDGIE.ORG
krbtgt/WEDGIE.ORG@WEDGIE.ORG

getprinc principal-name

Aliases

get_principal

The getprinc command retrieves detailed information about a principal from the Kerberos database. The getprinc command requires one parameter, a principal name that matches one principal that exists in the Kerberos database.

getprinc requires that users have I permissions on the principals that they are retrieving information on.

Examples

kadmin:  getprinc jgarman/admin
Principal: jgarman/admin@WEDGIE.ORG
Expiration date: [never]
Last password change: Wed Nov 13 00:38:06 GMT 2002
Password expiration date: [none]
Maximum ticket life: 0 days 10:00:00
Maximum renewable life: 0 days 00:00:00
Last modified: Wed Nov 13 00:38:06 GMT 2002 (kadmind@WEDGIE.ORG)
Last successful authentication: [never]
Last failed authentication: [never]
Failed password attempts: 0
Number of keys: 2
Key: vno 5, Triple DES cbc mode with HMAC/sha1, no salt
Key: vno 5, DES cbc mode with CRC-32, no salt
Attributes:
Policy: [none]

The output contains the following fields:

Expiration date

This is the date and time at which the principal will no longer be able to acquire tickets. It can be set per-principal or as part of a policy.

Last password change

This is the date that the principal's password was last changed, either through kpasswd or through a change password command executed by an administrator. Will show [never] if the principal's password has never been reset.

Password expiration date

This is the date when the principal's password expires. Password expiration dates can be set per-principal or as part of a policy. If this principal's password never expires, [none] will be shown in this field.

Maximum ticket life and Maximum renewable life

These fields show the maximum lifetime of tickets that can be issued on behalf of this principal.

Last modified

This field shows the time that any of the principal's data was last modified, and what principal made the change. If a principal's password is changed through kpasswd, the modification appears to come from the special principal kadmind. If a modification is made from inside the administrative interface, the administrator's principal is shown in this field. In the above case, jgarman/admin's password was last modified on November 13, 2002 through kpasswd.

Last successful authentication, Last failed authentication, and Failed password attempts

Unfortunately, these fields always show [never]. While all of the other updates to a principal's information, such as password changes or policy changes, must be made through the master KDC, any KDC (master or slave) can perform authentication. There is currently no way for a slave KDC to report back to the master KDC that an authentication has occurred, so the MIT code disables these fields.

Number of keys (and Key listing)

This field enumerates the different key encryption types and salts that are associated with this principal. This field can help troubleshoot problems that may occur when trying to interoperate between Kerberos implementations that support different key types.

Attributes

This field enumerates special attributes that are associated with principals. Typical user principals will not have any attributes, but some attributes can be useful for security purposes. MIT sets the DISALLOW_TGT_BASED attributes on the kadmin/changepw and kadmin/admin principals to prevent the KDC from issuing TGTs for these principals. In addition, MIT sets the DISALLOW_ALL_TIX on the master key's principal, K/M, to prevent any tickets (including service tickets) to be issued for it. A full list of attributes can be found in the next section, Section A.1.5.1.

Policy

This field lists the policy that this principal is subject to. Policies are discussed in more detail in Chapter 6.

addprinc [-expire expiredate] [-pwexpire pwexpiredate] [-maxlife maxtixlife] 
  [-kvno kvno] [-policy policyname] [-randkey] [-pw password] [-maxrenewlife
  maxrenewlife] [-e keysaltlist] [(+/-)attribute] principal-name

Aliases

add_principal, ank

The addprinc command adds a new principal into the Kerberos database. This command requires one argument, the name of the new principal to add. The command also recognizes several optional arguments that specify policy information the new principal should be subject to. More information about password policies is available in Chapter 6.

Other options include the randkey option, which adds the principal with a random key. This option is good to use for services that require secure keys that don't have to be memorized by a human. If the principal needs to have a special key encryption type or salt, it can be specified with the -e option. Following is a full list of all of the options available to addprinc:

-expire expiredate

This option sets an expiry date for the principal. After the date specified, tickets will no longer be issued for the principal, and requests by the principal to obtain service tickets will not be honored.

-pwexpire pwexpiredate

This option sets the password expiry date for the principal.

-maxlife maxtixlife

This option sets the maximum lifetime of tickets issued for the principal.

-kvno kvno

This option sets the key version number for the principal's key to kvno. Unless you need to override the default for some reason, this option is not recommended.

-policy policyname

This option sets the principal's policy to policyname. Policies are discussed in more detail in Chapter 6.

-randkey

This option gives the new principal a random encryption key, instead of prompting the administrator for a password.

-pw password

This option sets the principal's password to password instead of prompting on the terminal for one.

-maxrenewlife maxrenewlife

This option sets the maximum renewable lifetime of tickets issued for the principal.

-e keysaltlist

This option forces the key encryption type and salts generated for the principal to those listed in keysaltlist. If more than one encryption type and salt type are desired, then keysaltlist should be a space-separated list of encryption type:salt pairs enclosed by quotation marks.

The following attributes can be set on a new principal. An attribute can be prefixed by either a plus (+) or a minus (-) sign, denoting whether to enable or disable that attribute.

allow_postdated

This attribute allows the issuance of postdated tickets for the principal. By default, the KDC will issue postdated tickets for a new principal.

allow_forwardable

This attribute allows the issuance of forwardable tickets for the principal. By default, the KDC will issue forwardable tickets for a new principal.

allow_renewable

This attribute allows the issuance of renewable tickets for the principal. By default, the KDC will issue renewable tickets for a new principal.

allow_proxiable

This attribute allows the issuance of proxiable tickets for the principal. By default, the KDC will issue proxiable tickets for a new principal.

allow_dup_skey

This attribute allows the KDC to issue this principal tickets containing the session key of another user. This functionality is used during User-to-User authentication. By default, this attribute is enabled.

requires_preauth

This attribute requires pre-authentication to be performed before tickets will be issued on this principal's behalf. Pre-authentication is discussed in more detail in Chapter 6. By default, principals do not have to pre-authenticate.

requires_hwauth

This attribute requires hardware pre-authentication to be performed before tickets will be issued on this principal's behalf. By default, principals do not have to use hardware pre-authentication.

allow_svr

This attribute allows the KDC to issue service tickets for this principal. By default, the KDC will issue service tickets for every principal.

allow_tgs_req

This attribute allows the KDC to issue Ticket Granting Tickets for this principal. By default, the KDC will issue a TGT to any requesting principal.

allow_tix

This attribute allows the KDC to issue tickets for this principal. Disabling this attribute disallows the issuance of any ticket for or on behalf of this principal. By default, this attribute is enabled.

needchange

This attribute forces a password change when the principal next requests a ticket. Once the password is successfully changed, this attribute is cleared. By default, this attribute is disabled.

password_changing_service

This attribute is set on the principals used for password changing (for example, kadmin/changepw). You should never have to use this attribute; it is only included here for completeness.

The addprinc command requires that the administrator have A permissions on the principal he is adding.

Example

kadmin: ank -randkey -allow_tgs_req host/desktop.wedgie.org
WARNING: no policy specified for host/desktop.wedgie.org@WEDGIE.ORG; defaulting to no 
policy
Principal "host/desktop.wedgie.org@WEDGIE.ORG" created.

This example creates a host principal for desktop.wedgie.org with a random key and marks it so that no TGTs can be issued for it.

modprinc [-expire expiredate] [-pwexpire pwexpiredate] [-maxlife maxtixlife] 
  [-kvno kvno] [-policy policyname] [-clearpolicy] [(+/-)attribute] principal-name

Aliases

modify_principal

The modprinc command modifies selected attributes of the principal. It accepts most of the arguments that are accepted by addprinc, and adds one: clearpolicy. The optional clearpolicy argument removes all policies that are currently applied to the principal given. For more information on the optional arguments accepted by modprinc, see the previous section on addprinc.

The modprinc command requires that the administrator have M permissions on the principal she is modifying.

Example

kadmin:  modprinc -clearpolicy jdoe/admin
Principal "jdoe/admin@WEDGIE.ORG" modified.

cpw principal-name

Aliases

change_password

The cpw command changes the password associated with the principal given as an argument.

The cpw command requires that the administrator have C permissions on the principal whose password he is changing.

Example

kadmin:  cpw jgarman/admin
Enter password for principal "jgarman/admin":
Re-enter password for principal "jgarman/admin":
Password for "jgarman/admin@WEDGIE.ORG" changed.

delprinc principal-name

Aliases

delete_principal

The delprinc command deletes a principal from the Kerberos database. Note that deleting a principal does not automatically delete it from access control lists in which it appears. If a principal is added with the same name as one that is deleted, the new principal inherits all of the privileges of the old principal.

The delprinc command requires that the administrator have the D permission on the principal he is deleting.

Example

kadmin:  delprinc jdoe
Are you sure you want to delete the principal "jdoe@WEDGIE.ORG"? (yes/no): yes
Principal "jdoe@WEDGIE.ORG" deleted.
Make sure that you have removed this principal from all ACLs before reusing.

ktadd [-k keytab] [-e keysaltlist] principal-name | -glob glob-pattern

Aliases

xst

The ktadd command creates a random key for a principal or set of principals in the Kerberos database, and returns those keys to the client so that they can be saved into a keytab file on the client machine. This command is used to create keytabs for service and host principals in a Kerberos realm.

Note that ktadd does not extract the current key from the Kerberos database; it instead creates a new, random key and returns it, incrementing the key version number to indicate that a new key has been generated. This is a deliberate design decision, as it prevents a rogue administrator from simply dumping the entire Kerberos database through kadmin. It also means that the old keys or passwords assigned to this principal will no longer be valid once ktadd is run on the principal, and you cannot run ktadd from more than one system on the same principal since they will receive different keys.

Optional parameters include -k to specify the path to the keytab file to append to; the default is the system keytab file in /etc/krb5.keytab. You can also specify the -e option to indicate the list of encryption keys and salts to use when creating and extracting the new key.

The ktadd command requires that the administrator have I and C permissions on the principals that she is adding to the keytab.

Example

kadmin:  ktadd -k /tmp/key host/slave.wedgie.org@WEDGIE.ORG
Entry for principal host/slave.wedgie.org with kvno 3, encryption type Triple DES cbc 
mode with HMAC/sha1 added to keytab WRFILE:/tmp/key.
Entry for principal host/slave.wedgie.org with kvno 3, encryption type DES cbc mode
with CRC-32 added to keytab WRFILE:/tmp/key.

A.1.2 Ktutil

The ktutil program is a small utility program that allows administrators to manipulate keytab files. Ktutil is the recommended way to append keytabs to one another and delete entries from existing keytabs. The ktutil program requires no arguments, but will require enough privileges to read and write the appropriate keytabs. Typically, this means that you must run ktutil as root.

The ktutil utility starts with an empty keylist. Keys are added to the keylist as keytab files are read in, and keys can be deleted from the keylist. When the keylist is ready, it can be written out to a new keytab file, or appended to an existing one. A synopsis of the commands follows.

clear

This command clears the current keylist held in memory. It does not affect the contents of any keytab files that may have previously been read into ktutil.

list [-e] [-t] [-k]

Aliases

l

The list command displays the principals whose keys are stored in the keylist. By default, the list command will dump the key version number and the principal of each entry in the keylist, along with a numerical identifier referred to as the "slot" that can be used as input to the delete command to uniquely identify a particular entry.

Each of the optional arguments adds additional information to the keylist display. The -e argument also dumps the encryption type of every entry in the keylist. The -t argument dumps the timestamp of when the key was added into the keytab, and the -k argument dumps the hexadecimal encryption key itself.

Example

ktutil:  l -e
slot KVNO Principal
---- ---- --------------------------------------------------------------------
   1    3     host/freebsd.wedgie.org@WEDGIE.ORG (Triple DES cbc mode with HMAC/sha1)
   2    3     host/freebsd.wedgie.org@WEDGIE.ORG (DES cbc mode with CRC-32)
   3    3     ldap/freebsd.wedgie.org@WEDGIE.ORG (Triple DES cbc mode with HMAC/sha1)
   4    3     ldap/freebsd.wedgie.org@WEDGIE.ORG (DES cbc mode with CRC-32)

rkt keytab-file

The rkt command reads the contents of a keytab file and appends the keys in the keytab to the keylist. The original keytab file is unchanged.

addent (-key | -password) -p principal -k kvno -e enctype

The addent command adds an entry to the keylist manually. All parameters to addent are required. The encryption key associated with the new entry can be specified either by a hexadecimal key or by a password that is run through string2key to produce an encryption key. Ktadmin will prompt for the key or password.

The second parameter specifies that principal that is to be added to the keylist. If no realm is specified with the principal name, the default realm is assumed. The remaining parameters specify the key version number and encryption type to be associated with this entry.

Example

To create a new keylist entry for the principal blah@WEDGIE.ORG, with a key version number of 1 and using a DES key derived from a password string:

ktutil:  addent -password -p blah@WEDGIE.ORG -k 1 -e des
Password for blah@WEDGIE.ORG:

delent slot-no

The delent command deletes an entry from the internal keylist. The entry to be deleted is specified by the slot number that it occupies, which can be determined from the output of the list command.

wkt keytab-file

The wkt command writes the contents of the keylist into a keytab file. The wkt command can be rather confusing. Instead of overwriting the contents of the keytab file if it already exists, the wkt command will append the contents of the keylist to the existing keytab file. Therefore, if you want to delete an entry from the system keytab file, you must read it in, delete the offending entry, use the wkt command to write it to a new file, then replace the system keytab file with the new keytab file. If you instead use wkt to write the keylist to the system keytab directly, it will append the keylist to the existing keytab, creating a mess of duplicate entries.

A.1.3 Heimdal

In Heimdal Kerberos, Kerberos database tasks are performed by the kadmind daemon. Normally this daemon is run on KDC startup when the main Kerberos daemon, kdc, is started. The kadmind daemon listens for client requests on TCP port 749. The client, kadmin, can be run on any machine that is able to communicate with the KDC. It is recommended that a firewall be used to limit network access to port 749 to restrict unauthorized users from connecting to the administrative daemon.

Heimdal uses the /etc/krb5.conf configuration file to locate the master KDC running the kadmind server. The value of the admin_server parameter listed in the realm that the client is a member of is used as the server to connect to. If this parameter does not exist, or the administration server is not running on that server, then kadmin will exit with an error message. You can manually specify a realm and kadmind server by using the -r and -a command-line options, respectively.

After a connection has been established between the kadmin client and the kadmind server, the client performs mutual authentication with the administration server, using a temporary credential cache to acquire tickets to authenticate with the server for security reasons.

Note that a Heimdal kadmin client is required to communicate with a Heimdal kadmind server. You cannot use MIT kadmin to administer a Heimdal KDC.

Heimdal also contains a fail-safe method for editing the Kerberos database. By logging into the master KDC directly as root, and using the -l option to kadmin, you can edit the Kerberos database directly on disk without communicating over the network.

A.1.3.1 Connecting to kadmin

The Heimdal kadmin program is used to connect to the Heimdal kadmind server. To connect to a remote kadmind server over the network, you do not have to have any special privileges on your local machine, but you do have to login with a principal that has privileges defined in the kadmind.acl file.

% /usr/heimdal/sbin/kadmin
kadmin>

Note that kadmin will not ask for your credentials until after you've submitted your first command.

list glob-pattern

The list command lists the principals currently residing in the Kerberos database. Without parameters, list will list all principals. A glob-pattern is a required parameter to list; the asterisk (*) can be used to list all principals in the database.

The output of list is terse; each line of output contains the principal name and nothing more. For more information about a principal or set of principals, see the get command.

The list command requires that the user have list permissions on the principals that they are listing.

Example

kadmin> list *
  jdoe@WEDGIE.ORG
  default@WEDGIE.ORG
  jgarman@WEDGIE.ORG
  jdoe/admin@WEDGIE.ORG
  kadmin/admin@WEDGIE.ORG
  kadmin/hprop@WEDGIE.ORG
  jgarman/admin@WEDGIE.ORG
  kadmin/changepw@WEDGIE.ORG
  krbtgt/WEDGIE.ORG@WEDGIE.ORG
  changepw/kerberos@WEDGIE.ORG

get glob-pattern

Aliases

get_entry

The get command retrieves detailed information about a principal from the Kerberos database. The get command requires one parameter, a glob pattern that matches one or more principals that exist in the Kerberos database.

The get command requires that the user have get permissions on the principals that they are retrieving information on.

Examples

kadmin> get jgarman*
               Principal: jgarman@WEDGIE.ORG
       Principal expires: never
        Password expires: never
    Last password change: never
         Max ticket life: 1 day
      Max renewable life: 1 week
                    Kvno: 2
                   Mkvno: 0
                  Policy: none
   Last successful login: never
       Last failed login: never
      Failed login count: 0
           Last modified: 2002-11-10 23:54:58 UTC
                Modifier: jgarman/admin@WEDGIE.ORG
              Attributes:
Keytypes(salttype[(salt-value)]): des3-cbc-sha1(pw-salt), des-cbc-md5(pw-salt), des-
cbc-md4(pw-salt), des-cbc-crc(pw-salt)
               Principal: jgarman/admin@WEDGIE.ORG
       Principal expires: never
        Password expires: never
    Last password change: never
         Max ticket life: 1 day
      Max renewable life: 1 week
                    Kvno: 1
                   Mkvno: 0
                  Policy: none
   Last successful login: never
       Last failed login: never
      Failed login count: 0
           Last modified: 2002-10-25 03:02:55 UTC
                Modifier: kadmin/admin@WEDGIE.ORG
              Attributes:
Keytypes(salttype[(salt-value)]): des3-cbc-sha1(pw-salt), des-cbc-md5(pw-salt), des-
cbc-md4(pw-salt), des-cbc-crc(pw-salt)

The output contains the following fields:

Principal expires

This field lists the date and time at which the principal expires. At this time, the principal will no longer be valid either as a client or server principal, and no tickets will be issued for it.

Password expires

This field lists the date and time at which the principal's password (or key) expires. The next time the principal requests a Ticket Granting Ticket as part of its login process, it will be required to change its password.

Last password change

This field lists the date and time at which the principal's password was last changed, either by the user or by a Kerberos administrator.

Max ticket life and Max renewable life

These fields list the maximum lifetime of tickets issued on behalf of this principal.

Kvno

This field lists the key version number of the principal; typically, the key version number is incremented every time the key of that principal changes.

Mkvno

This field lists the master key version number of the principal. The master key can be changed on a regular basis, and this field lists which master key this principal is currently using.

Policy

This field lists the password policy that the principal is subject to. More information about password policies can be found in Chapter 6.

Last successful login, Last failed login, and Failed login count

Unfortunately, these fields will always show never (or zero). The reason for this is that while all of the other updates to a principal's information, such as password changes or policy changes, must be made through the master KDC, any KDC (master or slave) can perform authentication. There is currently no way for a slave KDC to report back to the master KDC that an authentication has occurred, so the Heimdal code disables these fields.

Last modified and Modifier

These fields report the last time any attribute of this principal was modified, and the principal that performed the modification. Newly created principals will have a modifier of kadmin/admin, and any other modifications will contain the users' principal (if the user changes their own password) or an administrators' principal (if an administrator changes an attribute of the principal).

Attributes

This field enumerates special attributes that are associated with principals. Typical user principals will not have any attributes, but some attributes can be useful for security purposes. A full list of attributes can be found in the next section.

Keytypes

This field enumerates all of the key encryption types and salts that are stored for the principal. This field can help troubleshoot problems that may occur when trying to interoperate between Kerberos implementations that support different key types.

add [--random-key] [--random-password] [--password=password] [--key=hexkey] 
  [--max-ticket-life=lifetime] [--max-renewable-life=lifetime] 
  [--attributes=attributes] [--expiration-time=time] [--pw-expiration-time=time] 
  [--use-defaults] principal-name

Aliases

add_new_key, ank

The add command adds a new principal into the Kerberos database. This command requires one argument, the name of the new principal to add, and also recognizes several optional arguments that specify policy information the new principal should be subject to. More information about password policies is available in Chapter 6.

Other options include the random-key option that adds the principal with a random key. This option is good to use for services that require secure keys that don't have to be memorized by a human. Following is a full list of all of the options available to addprinc:

--expiration-time=expiredate

This option sets an expiry date for the principal. After the date specified, tickets will no longer be issued for the principal, and requests by the principal to obtain service tickets will not be honored.

--pw-expiration-time=pwexpiredate

This option sets the password expiry date for the principal.

--max-ticket-life=maxtixlife

This option sets the maximum lifetime of tickets issued for the principal.

--password=password

This option sets the principal's password to the argument given, instead of prompting on the terminal for one. This option is useful when invoking kadmin through a script.

-policy policyname

This option sets the principal's policy to policyname. Policies are discussed in more detail in Chapter 6.

--random-key and --random-password

This option gives the new principal a random encryption key, instead of prompting the administrator for a password. The --random-password parameter is similar, but instead of creating a DES key directly, it creates a random password which is then run through string2key and can handle multiple encryption types.

-max-renewable-life=maxrenewlife

This option sets the maximum renewable lifetime of tickets issued for the principal.

--attributes=attributelist

This option gives the newly created principal the attributes listed in attributelist. A complete list of attributes is provided below.

Every principal can have one or more attributes associated with it. Most of the time, you won't need to specify any attributes; however, here is a list of the attributes available in Heimdal and possible scenarios in which they may be useful. Note that to unset any of the following attributes, prepend the attribute with a minus sign (-). For example, to unset the disallow-all-tix attribute, use --attributes=-disallow-all-tix. Multiple attributes can be listed by separating them with commas.

disallow-postdated

This attribute disallows the issuance of postdated tickets for the principal. By default, the KDC will issue postdated tickets for a new principal.

disallow-forwardable

This attribute disallows the issuance of forwardable tickets for the principal. By default, the KDC will issue forwardable tickets for a new principal.

disallow-renewable

This attribute disallows the issuance of renewable tickets for the principal. By default, the KDC will issue renewable tickets for a new principal.

disallow-proxiable

This attribute disallows the issuance of proxiable tickets for the principal. By default, the KDC will issue proxiable tickets for a new principal.

disallow-dup-skey

This attribute disallows the KDC to issue this principal tickets containing the session key of another user. This functionality is used during User-to-User authentication. By default, the KDC will issue tickets containing the session key of another user for User-to-User authentication.

requires-pre-auth

This attribute requires pre-authentication to be performed before tickets will be issued on this principal's behalf. Pre-authentication is discussed in more detail in Chapter 6. By default, principals do not have to pre-authenticate.

requires-hw-auth

This attribute requires hardware pre-authentication to be performed before tickets will be issued on this principal's behalf. By default, principals do not have to use hardware pre-authentication.

disallow-svr

This attribute disallows the KDC to issue service tickets for this principal. By default, the KDC will issue service tickets for every principal.

disallow-all-tix

Setting this attribute will cause the KDC to deny issuing any tickets for the principal. Enabling this attribute disallows the issuance of any ticket for or on behalf of this principal. By default, this attribute is disabled and the KDC will issue tickets for and on behalf of the principal.

modify [--max-ticket-life=lifetime] [--max-renewable-life=lifetime] 
  [--attributes=attributes] [--expiration-time=time] [--pw-expiration-time=time] 
  [--kvno=kvno] [-policy policyname] principal-name

The modify command modifies selected attributes of the principal. It accepts most of the arguments that are accepted by add, and adds one: kvno. The optional kvno argument changes the key version number listed on the principal. You should never have to change the key version number manually, but it can come in handy in some unusual circumstances. For more information on the optional arguments accepted by modify, see the previous section on add.

The modify command requires that the administrator have modify permissions on the principal she is modifying.

Note that when modifying a principal's attributes, the attributes given will replace any attributes already set on the principal.

Example

kadmin> modify --attributes=requires-pre-auth jgarman

cpw [--random-key] [--random-password] [--password=password] [--key=hexkey] 
  principal-name

Aliases

passwd

The cpw command changes the password of the principal-name given as an argument. Without arguments, cpw will prompt for a new password on the terminal. The other arguments have the same meaning as in the add command.

The cpw command requires that the administrator have change-password (or cpw) permissions on the principal she is modifying.

Example

kadmin> cpw jgarman
jgarman@WEDGIE.ORG's Password:
Verifying password - jgarman@WEDGIE.ORG's Password:

delete principal-name

The delete command deletes a principal from the Kerberos database. Note that deleting a principal does not automatically delete it from various access control lists that the principal may be listed on. If a principal is readded with the same name as one that is deleted, then the new principal will inherit all of the privileges of the old principal.

The delete command requires that the administrator have delete permission on the principal he is deleting.

Example

kadmin> delete jgarman
kadmin>

ext_keytab [-k keytab] glob-pattern ...

Aliases

ext

The ext_keytab command creates a random key for a principal or set of principals in the Kerberos database, and returns those keys to the client so that they can be saved into a keytab file on the client machine. This command is used to create keytabs for service and host principals in a Kerberos realm.

Note that ext_keytab will not extract the current key from the Kerberos database; it instead creates a new, random key and return it, incrementing the key version number to indicate that a new key has been generated. This is a deliberate design decision, as it prevents a rogue administrator from simply dumping the entire Kerberos database through kadmin. It also means that the old keys or passwords assigned to this principal will no longer be valid once ext_keytab is run on the principal, and you cannot run ext_keytab from more than one system on the same principal since they will receive different keys.

The only optional parameter that ext_keytab understands is -k to place the key into a different keytab than the default, /etc/krb5.keytab. Any number of principal names or glob patterns matching principals can follow the command; all of the principals that match the list given will be appended to the keytab file.

The ext_keytab command requires that the administrator have get privileges on the principal(s) he is extracting.

Example

kadmin> ext_keytab -k /tmp/hostkey host/desktop.wedgie.org

kadmin>

A.1.4 Ktutil

The ktutil program is a small utility program that allows administrators to manipulate keytab files. Ktutil is the recommended way to append keytabs to one another and delete entries from existing keytabs. The ktutil program requires no arguments, but will require enough privileges to read and write the appropriate keytabs. Typically, this means that you must run ktutil as root.

The Heimdal ktutil program operates differently from the MIT ktutil program. Heimdal ktutil is entirely command-line driven, and not interactive like MIT ktutil. The command-line option that is most commonly used is the --keytab or -k option, which specifies what keytab that the current command should operate on. By default, the ktutil command operates on the system keytab. It is located in /etc/krb5.keytab.

list [--keys] [--timestamp]

The list command displays the principals whose keys are stored in the keytab. By default, the list command will dump the key version number, the encryption type, and the principal of each entry in the keytab.

Each of the optional arguments adds additional information to the keytab display. The --timestamp argument dumps the timestamp of when the key was added into the keytab, and the --keys argument dumps the hexadecimal encryption key itself.

Example

% ktutil --keytab=/tmp/one.key list --timestamp
Vno  Type         Principal           Date
  3  des-cbc-md5  jgarman@WEDGIE.ORG  2003-04-23
  5  des-cbc-md5  jgarman@WEDGIE.ORG  2003-04-23

add [-p principal] [-V kvno] [-e enctype] [-w password]

The add command adds an entry to the keytab manually. Any parameters not specified on the command line will be prompted for interactively. If no realm is specified with the principal name, the default realm is assumed. The remaining parameters specify the key version number and encryption type to be associated with this entry.

Example

Here's how to create a new keylist entry for the principal blah@WEDGIE.ORG with a key version number of 1, using a DES key derived from a password string:

% ktutil --keytab=/tmp/two.key add -p blah@WEDGIE.ORG -V 1 -e des-cbc-crc
Password:
Verifying password - Password:

remove -p principal | -V kvno | -e enctype

The remove command removes an entry from the keytab. Entries to be removed can be specified by one or more of three parameters: the principal, the key version number, or the encryption type. At least one of these must be specified on the command line.

Example

% ktutil --keytab=/tmp/one.key remove -p jgarman@WEDGIE.ORG

get principal

The get command creates a keytab for a given service principal, and creates the principal if it doesn't already exist. A new key is generated for the given principal, and that key is placed both in the keytab and the Kerberos database. This command is most often used to create service keytabs.

Example

% ktutil --keytab=/tmp/one.key get host/kerberos.wedgie.org@WEDGIE.ORG

A.1.5 Windows Domain Controllers

Administering a Windows domain controller is dramatically different than the other KDCs that we've discussed here. MIT and Heimdal both have similar command line based administration tools, while Windows' administration tools are integrated into a the larger Microsoft Active Directory.

Behind the scenes, Active Directory uses an LDAP server as the data store for the Kerberos database. All of the user information as well as each principal's secret key are held inside the Active Directory Domain Controller's LDAP server. Microsoft provides graphical applications that can query and modify data contained within the LDAP server, and we'll examine these applications from a Kerberos-centric view. We won't cover Windows-specific features.

Typically, administrators administer Windows domain controllers through the Microsoft Management Console (MMC) interface. We discuss the necessary commands to perform the same tasks that we have covered for the Unix KDCs. Note that the administration protocol used by Windows is dramatically different from either MIT or Heimdal's kadmin protocols. It is not possible to administer a Windows domain controller through an MIT or Heimdal kadmin.

To access MMC, you must have domain administrator credentials. Login as the domain Administrator user (or another user that is a member of the Enterprise Administrators group). Go to Start Run, and type mmc. This will bring up the Microsoft Management Console application. Choose Console Add/Remove Snap In... and click Add. Choose Active Directory Users and Computers from the list, and click Add, then Close. Click OK to close the Add/Remove Snap In... dialog. Now you'll have a screen that looks similar to Figure A-1.

Figure A-1. Listing the users in an Active Directory domain

This window is the equivalent to listing the available principals in a Unix KDC. Every User object is mapped to a Kerberos principal, and any OU (Organizational Unit, represented as folders underneath the domain) can contain User objects. The username portion of the Kerberos principal is made up of the user logon name, which can be viewed in the Account tab of the object properties page. To access the properties of a particular object, double-click on it. The Account tab in the properties page is depicted in Figure A-2.

Figure A-2. Active Directory user properties dialog box

The properties page is equivalent to the get or getprinc commands in Unix KDC kadmin utilities. This properties page contains all of the relevant Kerberos-related information about the selected principal, as well as a lot of extraneous Windows-related properties that we won't worry about.

These two windows are the main interfaces that you'll use to administer your Windows domain controller.

A.1.5.1 Adding a principal

To add a principal into a Windows domain controller, simply right click on the OU that you wish the user to be a member of (for example, Users) and choose New User. Windows will bring up a New User wizard, shown in Figure A-3.

Figure A-3. Active Directory New User wizard

The new principal for this user is shown as the User logon name text box. The pre-Windows 2000 logon name is only used for NTLM authentication and not for Kerberos, so it can be ignored. The next page asks for a password and has a few options regarding password expiration and account expiration. The last page is simply a confirmation, and clicking Finish will commit the changes back to the Active Directory server.

There is one peculiarity to be aware of when using a Windows domain controller for Unix clients. The default encryption type for Kerberos keys stored in a Windows domain controller is RC4. Before you can use these principals from most Unix clients or application servers, you must modify the principal to use DES encryption keys. The process to do this is documented in the next section.

A.1.5.2 Modifying principal attributes

To modify a principal's attributes, right-click on the principal's entry in the Active Directory Users and Computers window, and select Properties. The dialog box will appear (Figure A-2). Select the Account tab. Near the bottom is a list of checkboxes with the title "Account Options." There are two options in particular to pay attention to. These options are the "Use DES encryption types for this account" option and the "Do not require Kerberos preauthentication" option. Both of these options are important for interoperability with Unix clients and application servers.

As discussed in the previous section, the default encryption type for new principals in Windows Active Directory is RC4. However, Unix clients only understand DES (and triple DES) keys. To successfully authenticate as a principal residing in a Windows domain controller from a Unix machine, you must check the "Use DES encryption types for this account" checkbox.

Windows domain controllers also differ from Unix KDCs in that they require clients to perform pre-authentication by default. Some older implementations of Kerberos 5 do not understand pre-authentication and so this option may have to be checked as well. More information on pre-authentication can be found in Chapter 6.

Here's one last snag that you'll run into if you're using a Windows domain controller with Unix-based application servers: you cannot directly create a principal that has an instance component. Therefore, service and host principals must be created with "fake" usernames, and a mapping established later between this username and the intended full principal. The process for performing this mapping is covered in Chapter 8, which discusses interoperability between Kerberos implementations.

A.1.5.3 Changing passwords

To change a principal's password through MMC, right-click on the principal's entry and choose Reset Password. A dialog box will appear asking for a new password and also gives an option to force the principal to change his password the next time he logs in.

A.1.5.4 Deleting principals

To delete a principal through MMC, right-click on the principal and click Delete.

A.1.5.5 Adding keys into keytabs

If you're adding service or host principals for Unix application servers, you'll need some way to extract a keytab from the Windows domain controller. Out of the box, Windows does not allow you to do this. However, Microsoft supplies a utility named ktpass in the Windows 2000 Resource Kit that creates a keytab for a given principal name and password. More information about ktpass and how to use it can be found in Chapter 8, which includes a discussion of interoperability scenarios between Windows- and Unix-based Kerberos implementations.