Kerberos
in Practice
Kerberos is technically an authentication protocol. It basically provides a protocol in which users can authenticate themselves to the Kerberos system, and Kerberos will then manage the users authentication to other systems.
In short, it is a form of single-sign-on system – where the user ideally enters their password only once to access all aspects of the systems to which they are allowed access.
In places where you have a significant number of systems to administer, as well as a sizeable user base, it can become quite an effort to maintain security. The task of maintaining individual Unix passwords for each user on each system is far too time-consuming.
To manage user passwords, we installed the MIT implementation of Kerberos. this software package comprises of a set of tools and systems to manage user password and credentials over the Border Management systems. A number of other software systems have been built to include Kerberos authentication functionality such as the SSH and Samba servers.
KDC – Key Distribution Centre, the Kerberos server which is attached to a database containing all user and host principals.
principal – a key which may be used to identify a host or user. User principals are based on the username eg. joebloggs@CRYPT.GEN.NZ and are keyed by a password only known to that user. Host principals include the host name eg. host/edmond@CRYPT.GEN.NZ and have a random ( unknown ) password key.
key – in this context a key is an instance of a principal which has been placed into a data file. This is analogous to placing the password for the principal into a file : for user principals this should not be done, but for host principals this is done to allow the host system to easily identify itself to other systems, The key is essentially a secret shared between the host and the KDC.
In this document, examples of command-line administration are in Courier font. User commands within the examples are in Courier bold.
For example purposes, we'll use the Kerberos Realm CRYPT.GEN.NZ.
There are 3 KDCs serving the firewall realm :
· baldric ( Master )
· edmond ( Slave )
Propagation of the KDC data from the master to the slaves is performed every night. In some situations it may be necessary to do this more often.
Kerberos dictates that not only will each user will have a key, but also hosts systems will have a private key. This is used to provide host authentication : when a user logs into a system then that user can be assured that the system logged into is really the one that the user is expecting. A host key is very similar to a user key, with the exception that it has an unknown random password, and that a copy of the private key is exported from the KDC and installed on the host itself.
Always use fully qualified domain names ( FQDNs ) for hosts when using Kerberos. In particular, the /etc/hosts file should also be configured so that the host’s IP address resolves to a FQDN, so that the host’s own entry in /etc/hosts looks like :
10.65.16.199 queenie.crypt.gen.nz queenie
A host system key is normally only added when the host is configured. The host key is created in the KDC, then exported into a key file to be copied onto the host. It is worth pointing out that the host key must be kept as secure as possible.
The key file is stored in the JumpStart area on edmond:/opt/local/master/(host)/etc/krb5.keytab
eg.
edmond:
kadmin
Authenticating
as principal joebloggs/admin@CRYPT.GEN.NZ with password.
Enter
password: (password)
kadmin: addprinc
-randkey host/queenie.crypt.gen.nz@CRYPT.GEN.NZ
WARNING:
no policy specified for host/queenie.crypt.gen.nz@CRYPT.GEN.NZ;
defaulting to no policy
Principal
"host/queenie.crypt.gen.nz@CRYPT.GEN.NZ" created.
kadmin: ktadd
-k /opt/local/master/queenie/etc/krb5.keytab host/queenie.crypt.gen.nz
Entry
for principal host/queenie.crypt.gen.nz@CRYPT.GEN.NZ with kvno 3,
encryption type DES cbc mode with CRC-32 added to keytab
WRFILE:/tmp/krb5.keytab.queenie.
kadmin:
kadmin: quit
This is seldom done. In most cases deleting and recreating the principal will suffice, or simply removing it from the host’s keytab and re-adding it with the ktadd function in kadmin.
If a host is decommissioned, then it is necessary to remove its identity from the KDC. This is simply done with the delprinc command in kadmin.
eg.
edmond:
kadmin
Authenticating
as principal joebloggs/admin@CRYPT.GEN.NZ with password.
Enter
password: (password)
kadmin: delprinc
host/queenie.crypt.gen.nz@CRYPT.GEN.NZ
Are
you sure you want to delete the principal
"host/queenie.crypt.gen.nz@CRYPT.GEN.NZ"? (yes/no): yes
Principal
"host/queenie.crypt.gen.nz@CRYPT.GEN.NZ" deleted.
Make
sure that you have removed this principal from all ACLs before reusing.
kadmin:
quit
edmond:
Users are added, changed, and deleted more often than hosts.
When changing users, be sure to note that Kerberos is responsible for the users’ password only. There must be an actual user account on the Unix system for the user in order to identify certain user attributes, although the Unix password will normally be locked.
Note that only real, live users own principals in Kerberos. We do not ( at this stage ) have generic-user principals for accounts such as “oracle”, “netscape”, and so on. These have not been necessary and may pose a security risk if the name and password becomes well known.
Adding a principal for a user is simply a matter of using the addprinc command in kadmin. The command will prompt you to enter the password for the principal.
eg
edmond:
kadmin
Authenticating
as principal joebloggs/admin@CRYPT.GEN.NZ with password.
Enter
password: (password for joebloggs/admin)
kadmin:
kadmin: addprinc
xblogj@CRYPT.GEN.NZ
WARNING:
no policy specified for xblogj@CRYPT.GEN.NZ; defaulting to no policy
Enter
password for principal "xblogj@CRYPT.GEN.NZ": (password)
Re-enter
password for principal "xblogj@CRYPT.GEN.NZ": (password)
Principal
"xblogj@CRYPT.GEN.NZ" created.
kadmin:
Normally the only change to a user principal will be to change their password. This is simply done in kadmin :
eg.
kadmin: cpw
xblogj@CRYPT.GEN.NZ
Enter
password for principal "xblogj@CRYPT.GEN.NZ": (password)
Re-enter
password for principal "xblogj@CRYPT.GEN.NZ": (password)
Password
for "xblogj@CRYPT.GEN.NZ" changed.
kadmin:
Deleting a principal is done by using the delprinc command in kadmin :
eg.
kadmin: delprinc
xblogj@CRYPT.GEN.NZ
Are
you sure you want to delete the principal
"xblogj@CRYPT.GEN.NZ"? (yes/no): yes
Principal
"xblogj@CRYPT.GEN.NZ" deleted.
Make
sure that you have removed this principal from all ACLs before reusing.
kadmin:
It is quite often necessary for users to have privileged access to parts of a system. Cases include not only the super-user account of root, but also to various application administration accounts, for example the “oracle” and “netscape” accounts.
The MIT Kerberos kit comes with a very useful utility : ksu. Ksu has 2 very useful functions :
· it can control which users can change their identity to another account
· it can control which Unix commands a user can issue to run under another account
In some respects, ksu is similar to the sudo command that is used in some systems. The additional advantage of ksu is that there is no need for additional authentication prompts which sudo requires.
When a user has one password to get into all systems there is a strong requirement to keep that password secret. If a user not only has login access to all systems, but also access through ksu to the root account on all systems then there is a large amount of responsibility hanging on the security of just one password.
To mitigate this problem, at we can configure administrators to have an additional “root” principal with a password separate from their normal user principal password. Under kadmin we just use the command :
addprinc
(admin_user)/root@CRYPT.GEN.NZ
To implement this in ksu, we simply change the entries in the /.k5login file to designate the root principals :
eg. in /.k5login
joebloggs/root@CRYPT.GEN.NZ
anotheruser/root@CRYPT.GEN.NZ
The effect of this is that administrators are prompted for their “root” password whenever they ksu to the root account. Every administrative user has their own “root” password which is personal to that user, and there is therefore no need to distribute root passwords to administrators – this can be a problem when there is a significant number of systems.
It was eventually decreed that no person will have vanilla ksu access to the root account. All users with root access will have a user/root principal and password.
Similarly with root access, access to the kadmin Kerberos administration utility is restricted. We did this by creating (name)/admin@CRYPT.GEN.NZ principals for administrators and assigning passwords to them.
Access to kadmin is configured in the file /usr/local/var/krb5kdc/kadm5.acl, this contains the following entry :
*/admin@CRYPT.GEN.NZ *
- which restricts access to kadmin to only those users who can authenticate with a username/admin principal.
It is quite often necessary to set up scripts which need to log into other systems, quite often with privileged access. One example is backup scripts which need to access remote systems and run particular commands as root in order to run backup jobs across the network. Placing plain-text passwords into these scripts is hazardous, as anyone discovering such a password will be able to access these systems.
Normally, commands such as rsh and rcp are used – these are profoundly insecure approaches which are easily exploited to get access to other systems ( quite often to the root level ).
The approach taken was to create a Kerberos principal for the backup job which we will call “mtdump”, with a random password. So under kadmin, the following command is used :
kadmin:
addprinc
–randkey mtdump@CRYPT.GEN.NZ
which creates a principal for mtdump with a random password that nobody ever knows.
We also create a Unix account for the mtdump user on each system, with a locked password entry. In kadmin, the key for the principal is then dumped to a file :
kadmin:
ktadd
–k /opt/local/sysadmin/etc/mtdump.keytab mtdump@CRYPT.GEN.NZ
… and be sure that the keyfile /opt/local/sysadmin/etc/mtdump.keytab can be read by root only.
Now, for the cron job to “authenticate” as the mtdump user, it runs the following command :
/usr/local/bin/kinit -f -k -t
/opt/local/sysbackup/etc/mtdump.keytab mtdump
Here, the –f option is to request a forwardable key – which will be required later in the process.
The authentication is good only for the shell which runs the kinit command, so for a script to run a command on a remote host as “mtdump” would require a command like :
/usr/local/bin/kinit -f -k -t
/opt/local/sysbackup/etc/mtdump.keytab mtdump ; \
/usr/local/bin/krsh
-l mtdump –F (remote_host) (command)
Note that krsh is using the –F option to forward a forwardable ticket to the remote system.
It gets worse. For backups we want the mtdump user to have access to run a certain command on the remote system as root – the command basically does a find & cpio piping the output to a remote shell again back to the system with the tape drive. So, we add this into the /.krb5users file on the remote system to allow the mtdump user to run the sysbackup_agent script :
mtdump@CRYPT.GEN.NZ
/opt/local/sysbackup/sbin/sysbackup_agent.pl
.. which allows the mtdump user to run the sysbackup agent as root and no other commands.
So, our command now looks like :
/usr/local/bin/kinit -f -k -t
/opt/local/sysbackup/etc/mtdump.keytab mtdump ; \
/usr/local/bin/krsh
-l mtdump –F (remote_host) /usr/local/bin/ksu root \
-q -n mtdump –e
/opt/local/sysbackup/sbin/sysbackup_agent.pl
The sysbackup_agent in turn runs something like :
find / -depth –print | cpio –ocB | /usr/local/bin/krsh –l
mtdump \
(tape_drive_host)
/usr/bin/dd bs-64k of=/dev/rmt/0
which runs a remote dd command on the (tape_drive_host) as the mtdump user to write the cpio data stream to a tape device.
Surprisingly, this whole thing actually works and is very secure. Nobody can log in as the mtdump user because nobody knows its password. Only the root user on the originating system can access the keytab file for mtdump and therefore only root can access the remote system as the mtdump user. The mtdump keytab file does not need to be copied around the network onto mutliple hosts, there is only one copy to be kept on the originating host.
In the case that the originating system is compromised to the root level, the keyfile may be stolen – in which case the intruder can get into the remote host as the mtdump user but not as root because mtdump has been restricted to run the sysbackup_agent program only.
It is also possible for the krsh program to encrypt its datastream, although this hasn’t been used in our backup jobs to date.
Using Kerberos authentication across firewalls is moderately painless, but see the list of Shortcomings below for some problems. All that is required is to allow the KDC ports ( ports 88 and 750 ) through the firewall so that systems on the outside can connect to the KDC on the inside.
If users want to change their password on systems outside the firewall, then also allow for port 749 ( the kadmin port ) to go through.
The following things should be taken into account when using Kerberos in a Firewall type environment :
·
It is not possible to securely allow
Kerberos based encrypted FTP sessions across a Firewall-1 based firewall. This
is because the FTP PORT command is encrypted, and the Firewall-1 system relies
on interpreting this command to allow the DATA connection to be made. Passive
FTP mode may be a reasonable alternative.
·
Kerberos rcp ( Remote Copy ) does not
work across Firewall-1 firewalls. Similarly with FTP, Firewall-1 cannot
interpret aspects of the protocol. Some work-around allowing high ports can be
used if necessary.
·
While there is some amount of
interoperability between MIT Kerberos and Microsoft’s Windows2000 Kerberos,
integration is often difficult and restricted. It is apparently feasible for
MIT Kerberos based systems to use a Win2000 KDC for authentication to some
extent.
·
There is no notification to the user
if their Kerberos password has, or is about to, expire. One way is to
disable password expiry and depend on users being responsible to update their
passwords as they see fit. Some software could be written to implement
something better.
·
We haven’t been able to get a good (
free, and internationally available ) Kerberos client system for Windows
clients. We have used SSH instead which has been sufficient for our purposes.
· Similar to Firewall-1 Gauntlet firewalls and Kerberos don’t mix too well. Gauntlet’s telnet and ftp proxies are not Kerberos-aware.
The following is a list of features in
Kerberos which has made our life a little easier :
·
Integration with Samba.
·
Integration with SSH daemon – Kerberos
provides good key management and credential forwarding functions to the strong
encryption of SSH.
·
centralised passwords.
·
passwords don’t need to be reset when
a system is rebuilt.
· authorisation with ksu. Life would be tough without it.
· Security could be vastly improved if tokens were used for strong authentication rather than normal passwords. One such system is CryptoCard ( www.cryptocard.com ) which offers a one-time-password system which can be integrated with MIT Kerberos.
[libdefaults]
default_realm = CRYPT.GEN.NZ
default_tgs_enctypes = des-cbc-crc
default_tkt_enctypes = des-cbc-crc
[realms]
CRYPT.GEN.NZ = {
kdc =
baldric.crypt.gen.nz:88
kdc = edmond.crypt.gen.nz:88
admin_server = baldric.crypt.gen.nz:749
default_domain = crypt.gen.nz
}
[domain_realm]
.crypt.gen.nz =
CRYPT.GEN.NZ
[logging]
kdc = SYSLOG
admin_server = SYSLOG
default = SYSLOG
The following is the KDC configuration file from /usr/local/var/krb5kdc.
[kdcdefaults]
kdc_ports = 750,88
[realms]
CRYPT.GEN.NZ = {
database_name = /usr/local/var/krb5kdc/principal
admin_keytab = FILE:/usr/local/var/krb5kdc/kadm5.keytab
acl_file = /usr/local/var/krb5kdc/kadm5.acl
key_stash_file = /usr/local/var/krb5kdc/.k5.CRYPT.GEN.NZ
kdc_ports = 750,88
kadmind_port = 749
max_life = 10h 0m 0s
max_renewable_life = 7d 0h 0m 0s
master_key_type = des-cbc-crc
supported_enctypes = des-cbc-crc:normal des:normal des:v4 des:norealm
des:onlyrealm des:afs3
}
The MIT Kerberos home page :
http://web.mit.edu/kerberos/www/index.html
The Moron’s Guide to Kerberos :
http://gost.isi.edu/brian/security/kerberos.html
Internationally available versions of MIT Kerberos :
http://www.crypto-publish.org