Create the database
with the following command.
[root@coma ~]
kdb5_util create -s
This will prompt
you for a password. You will only have to enter this password when you
initially configure a slave KDC, so choose something large and random and store
it in a secure place. Really, you may only have to enter this once more, so
make it secure.
Add the first Administrative
User
I do administration as root, so the
first user I add is root/admin. The default realm is appended automatically, so
the command to use is as follows.
[root@coma ~] kadmin.local -q "addprinc root/admin"
Enter a password when prompted. You will need this password every time you administer the database.
[root@coma ~] kadmin.local -q "addprinc root/admin"
Enter a password when prompted. You will need this password every time you administer the database.
Starting the Services
At this point it is necessary to enable
and start the kerberos services.
[root@coma ~] chkconfig kadmin on
[root@coma ~] service kadmin start
[root@coma ~] chkconfig krb5kdc on
[root@coma ~] service krb5kdc start
[root@coma ~] service kadmin start
[root@coma ~] chkconfig krb5kdc on
[root@coma ~] service krb5kdc start
To test if everything is working, run
kadmin. By default, the current user appended with ‘/admin’ is used as the
principle.
[root@coma ~] kadmin
Authenticating as principal root/admin@PHYSIK.UNIZH.CH with password.
Password for root/admin@PHYSIK.UNIZH.CH:
kadmin: listprincs
K/M@PHYSIK.UNIZH.CH
kadmin/admin@PHYSIK.UNIZH.CH
kadmin/changepw@PHYSIK.UNIZH.CH
kadmin/history@PHYSIK.UNIZH.CH
krbtgt/PHYSIK.UNIZH.CH@PHYSIK.UNIZH.CH
root/admin@PHYSIK.UNIZH.CH
The additional principles have been created by the tool. They are required so leave them be.
[root@coma ~] kadmin
Authenticating as principal root/admin@PHYSIK.UNIZH.CH with password.
Password for root/admin@PHYSIK.UNIZH.CH:
kadmin: listprincs
K/M@PHYSIK.UNIZH.CH
kadmin/admin@PHYSIK.UNIZH.CH
kadmin/changepw@PHYSIK.UNIZH.CH
kadmin/history@PHYSIK.UNIZH.CH
krbtgt/PHYSIK.UNIZH.CH@PHYSIK.UNIZH.CH
root/admin@PHYSIK.UNIZH.CH
The additional principles have been created by the tool. They are required so leave them be.
Create a Host Principal for the
KDC
Now you will want to create a host
principal for the KDC. This is required for replication (see below). You also
need to add this principal to the local key table.
[root@coma ~]# kadmin
Authenticating as principal root/admin@EXAMPLE.COM with password.
Password for root/admin@EXAMPLE.COM:
kadmin: addprinc -randkey host/coma.EXAMPLE.COM
NOTICE: no policy specified for host/coma.example.com@EXAMPLE.COM; assigning "default"
Principal "host/coma.example.com@EXAMPLE.COM" created.
kadmin: ktadd host/coma.example.com
[root@coma ~]# kadmin
Authenticating as principal root/admin@EXAMPLE.COM with password.
Password for root/admin@EXAMPLE.COM:
kadmin: addprinc -randkey host/coma.EXAMPLE.COM
NOTICE: no policy specified for host/coma.example.com@EXAMPLE.COM; assigning "default"
Principal "host/coma.example.com@EXAMPLE.COM" created.
kadmin: ktadd host/coma.example.com
Setup the default Policy
You will want to create the default
password policy at this point. All new accounts will have this policy enforced.
[root@coma ~] kadmin
Authenticating as principal root/admin@ EXAMPLE.COM with password.
Password for root/admin@ EXAMPLE.COM:
kadmin: add_policy -maxlife 180days -minlife 2days -minlength 8 -minclasses 3 -history 10 default
You can also add other policies and apply different policies to different principles. The different flags and their meaning are as follows.
[root@coma ~] kadmin
Authenticating as principal root/admin@ EXAMPLE.COM with password.
Password for root/admin@ EXAMPLE.COM:
kadmin: add_policy -maxlife 180days -minlife 2days -minlength 8 -minclasses 3 -history 10 default
You can also add other policies and apply different policies to different principles. The different flags and their meaning are as follows.
Flag
|
Description
|
-maxlife
|
The is the maximum
period before the password must be changed.
|
-minlife
|
This is the minimum
time after a password change before it can be changed again. Without a
minimum time, users can change their password multiple times and overflow the
history (see below) and end up back with the same password.
|
-minclasses
|
This is the number
of distinct character classes that must appear in the password. Character
classes are uppercase letters, lowercase letters, number and symbols. Setting
this to 2 for example would mean a password with at least one lowercase
letter and a number would be valid.
|
-history
|
This is the number
of previous passwords to keep. A password may not duplicate a prior password.
|
Changing the Maximum Renewal
Time
Each principal has its own maximum
renewal life. On RHEL4, new principals are created with a maximum renewal time
of zero. This means you can get a renewable ticket, but they can never be
renewed. Each principal must be manually changed to the desired maximum renewal
time. In addition, the special principal krbtgt/REALM@REALM must be changed to
reflect the maximum renewal time that any principal will have.
[root@coma ~]# kadmin
Authenticating as principal root/admin@ EXAMPLE.COM with password.
Password for root/admin@ EXAMPLE.COM:
kadmin: modprinc -maxrenewlife 2weeks krbtgt/ EXAMPLE.COM @ EXAMPLE.COM
Principal "krbtgt/ EXAMPLE.COM @ EXAMPLE.COM " modified.
[root@coma ~]# kadmin
Authenticating as principal root/admin@ EXAMPLE.COM with password.
Password for root/admin@ EXAMPLE.COM:
kadmin: modprinc -maxrenewlife 2weeks krbtgt/ EXAMPLE.COM @ EXAMPLE.COM
Principal "krbtgt/ EXAMPLE.COM @ EXAMPLE.COM " modified.
Adding Principals
[root@coma ~] kadmin
uthenticating as principal root/admin@ EXAMPLE.COM with password.
Password for root/admin@ EXAMPLE.COM:
kadmin: addprinc -maxrenewlife 7days doug
The various options allow you to tune your password policy.
uthenticating as principal root/admin@ EXAMPLE.COM with password.
Password for root/admin@ EXAMPLE.COM:
kadmin: addprinc -maxrenewlife 7days doug
The various options allow you to tune your password policy.