ntp
package for this purpose. Refer to /usr/share/doc/ntp/index.html
for details about how to set up Network Time Protocol servers, and http://www.ntp.org for more information about NTP.
krb5-libs
, krb5-server
, and krb5-workstation
packages on the dedicated machine which runs the KDC. This machine needs to be very secure — if possible, it should not run any services other than the KDC.
/etc/krb5.conf
and /var/kerberos/krb5kdc/kdc.conf
configuration files to reflect the realm name and domain-to-realm mappings. A simple realm can be constructed by replacing instances of EXAMPLE.COM and example.com with the correct domain name — being certain to keep uppercase and lowercase names in the correct format — and by changing the KDC from kerberos.example.com to the name of the Kerberos server. By convention, all realm names are uppercase and all DNS hostnames and domain names are lowercase. For full details about the formats of these configuration files, refer to their respective man pages.
kdb5_util
utility from a shell prompt:
/usr/sbin/kdb5_util create -s
create
command creates the database that stores keys for the Kerberos realm. The -s
switch forces creation of a stash file in which the master server key is stored. If no stash file is present from which to read the key, the Kerberos server (krb5kdc
) prompts the user for the master server password (which can be used to regenerate the key) every time it starts.
/var/kerberos/krb5kdc/kadm5.acl
file. This file is used by kadmind
to determine which principals have administrative access to the Kerberos database and their level of access. Most organizations can get by with a single line:
*/admin@EXAMPLE.COM *
kadmind
has been started on the server, any user can access its services by running kadmin
on any of the clients or servers in the realm. However, only users listed in the kadm5.acl
file can modify the database in any way, except for changing their own passwords.
Note
kadmin
utility communicates with the kadmind
server over the network, and uses Kerberos to handle authentication. Consequently, the first principal must already exist before connecting to the server over the network to administer it. Create the first principal with the kadmin.local
command, which is specifically designed to be used on the same host as the KDC and does not use Kerberos for authentication.
kadmin.local
command at the KDC terminal to create the first principal:
/usr/kerberos/sbin/kadmin.local -q "addprinc username/admin"
/sbin/service krb5kdc start /sbin/service kadmin start
addprinc
command within kadmin
. kadmin
and kadmin.local
are command line interfaces to the KDC. As such, many commands — such as addprinc
— are available after launching the kadmin
program. Refer to the kadmin
man page for more information.
kinit
to obtain a ticket and store it in a credential cache file. Next, use klist
to view the list of credentials in the cache and use kdestroy
to destroy the cache and the credentials it contains.
Note
kinit
attempts to authenticate using the same system login username. If that username does not correspond to a principal in the Kerberos database, kinit
issues an error message. If that happens, supply kinit
with the name of the correct principal as an argument on the command line (kinit <principal>
).