The three-headed dog
Posted by Pepijn Oomen
Traditionally Unix uses a passwd file to lookup user information. More recent versions use a separate shadow file for password storage. Although the passwords are not stored in cleartext, both methods do perform a security risk. On a reasonably large network this also provides a maintenance burden since all accounts need to be defined and maintained on each system.
MacOSX works under similar assumptions, since it is just a Unix derivative. Windows has a different way of storage, but in a workgroup setup basically confronts the administrator with the same issues. This is improved in a domain setup, where user accounts are stored on the domain controller, but this is done in a proprietary format. Enter Kerberos:
[...] Kerberos is a solution to your network security problems. It provides the tools of authentication and strong cryptography over the network to help you secure your information systems across your entire enterprise. [...]
Basically, to an administrator this means that Kerberos is the perfect place to store passwords. Note that Kerberos differs from traditional security frameworks in that it not only provides a way for the user to authenticate itself to the server but also the reverse. When a user logs onto a system she can be positive that the system being logged onto is the real thing and not a man-in-the-middle posing as such. From a security point of view this is a real big plus. This two-way authentication is achieved by defining people and systems as principals within the Kerberos system.
Setting up a functioning Kerberos system proves to be a rather trivial matter. Basic documentation on the subject is readily available, but 'll give a quick rundown on the installation of the central server on Debian GNU/Linux Sarge installation.
# apt-get install krb5-kdc krb5-admin-server
This will ask you about the realm and servers, but using defaults will do. When asked for V4 backwards compatibility, you can choose disable if you have no previous Kerberos installation. After this, make sure you have the following entries in your DNS (for DNS domain example.com and Kerberos realm EXAMPLE.COM):
_kerberos.example.com. IN TXT "EXAMPLE.COM"
_kerberos._udp.example.com. IN SRV 0 0 88 server.example.com.
_kerberos-master._udp.example.com. IN SRV 0 0 88 server.example.com.
_kerberos-adm._tcp.example.com. IN SRV 0 0 749 server.example.com.
_kpasswd._udp.example.com. IN SRV 0 0 464 server.example.com.
kerberos.example.com. IN CNAME server.example.com.
Now change the contents of /etc/krb5.conf to be:
[libdefaults]
dns_lookup_realm = true
[realms]
EXAMPLE.COM = {
admin_server = kerberos
}
Your are now ready to add principals to your Kerberos installation by using the kadmin.local command:
kadmin: addprinc user
kadmin: addprinc user/admin
kadmin: addprinc -randkey host/server.example.com
kadmin: ktadd host/server.example.com
Now uncomment the last line of /etc/krb5kdc/kadm5.acl so that principals ending with /admin actually are granted administrative access. When running kadmin from your own account, /admin will automatically be appended. To actually start using Kerberos authentication, install ssh-krb5 and make sure to change the following in /etc/ssh/sshd_config:
KerberosAuthenitation yes
UsePAM no
After reloading this configuration, ssh into the machine and after entering your password, you should obtain a ticket from Kerberos which can be viewed with:
$ klist
Note that you do not obtain a ticket if you do not provide a password, i.e. when using PubkeyAuthentication. The use of this single ticket is questionable, but at least it proves the system is working.
