Exercise 3: Build a KDC ======================= These exercises assume your host is pc1.ws.nsrc.org and you will be building a realm REALM1.WS.NSRC.ORG - change `1` to the appropriate value for your machine. 1. Install ntp -------------- Because tickets are timestamped, it's important that your machine always has an accurately synchronized clock. Double-check it's installed: # apt-get install ntp This will run a daemon (ntpd) which keeps your clock synchronized. Note: if you have a large network then it makes sense to have two local timeservers and all other machines sync to those. You would then change /etc/ntpd.conf to point to your time server(s). 2. Install kdc packages ----------------------- # apt-get install krb5-kdc krb5-admin-server If you get a dialog box about setting up a kerberos realm, just accept [Ok] 3. Configure krb5 library ------------------------- Now we are going to configure the krb5 client library, manually associating your own machine with your own realm. (We could instead change the DNS, but doing it here lets you control your own settings) # editor /etc/krb5.conf [libdefaults] default_realm = REALM1.WS.NSRC.ORG dns_lookup_realm = true dns_lookup_kdc = true [realms] REALM1.WS.NSRC.ORG = { kdc = pc1.ws.nsrc.org admin_server = pc1.ws.nsrc.org } [domain_realm] pc1.ws.nsrc.org = REALM1.WS.NSRC.ORG 4. Create and initialize your database -------------------------------------- Create Kerberos database: kdb5_util create -r REALM1.WS.NSRC.ORG -s # This can pause for several minutes. Eventually you will be asked to # choose a database master password. Use "abcd" for this exercise, # but normally you'd choose something much stronger. Create the ACL file and grant admin rights to all */admin principals: # editor /etc/krb5kdc/kadm5.acl */admin@REALM1.WS.NSRC.ORG * Now we use kadmin.local (running as root) to create the first few principals: a host principal for the host itself (putting the randomly-chosen key into its own keytab file); a regular principal "student" and a KDC admin principal "student/admin" # kadmin.local addprinc -randkey host/pc1.ws.nsrc.org ktadd host/pc1.ws.nsrc.org addprinc student -- you'll be prompted to choose a password addprinc student/admin -- you'll be prompted to choose a password ^D Now start the daemons: # /etc/init.d/krb5-kdc start # /etc/init.d/krb5-admin-server start At this point, you should be able to get a ticket from your own realm: $ kinit student Password for student@REALM1.WS.NSRC.ORG: $ klist (Note that you've obtained a ticket from your own realm, using the username and password you created in your own KDC) If this doesn't work, then debug as follows: * Check your clock is synchronized (type `date`) * Check your krb5.conf * Check kdc is running: `ps auxwww | grep krb5kdc` * Look at KDC logs in /var/log/auth.log 5. Managing principals ---------------------- From now on, you don't need `kadmin.local` as root to administer the Kerberos database; you can use `kadmin` instead, as a normal user. This runs over a TCP socket (so it can be run from a remote workstation, not necessarily the KDC). The traffic is authenticated and encrypted using Kerberos. $ kadmin -p student/admin ... enter password for 'student/admin' which you chose earlier Type '?' for a list of commands. The important ones are: listprincs -- list principals addprinc -- add principal cpw -- change password delprinc -- delete principal Use ^D (ctrl-D) to exit. Try the following: * Change the password for the `student` principal. In another screen, check that you can `kinit student` with the new password. * Create a new user principal of your choice, and check you can get a ticket for it with kinit. 6. Kerberos ssh --------------- Since we have modified krb5.conf earlier, restart sshd: # service ssh restart Create a local `student` user: # useradd -m -s /bin/bash student Note that we have not set any password. However you should be able to login using a kerberos ticket: $ kinit student $ ssh student@localhost 7. Extra exercises ------------------ If you have spare time, you and your neighbour can add [realms] and [domain_realms] sections for each other, and you can try to get a ticket directly from the other realm and use it to login to the other machine: kinit student@REALM2.WS.NSRC.ORG ssh student@pc2.ws.nsrc.org You could also try setting up cross-realm authentication. Each KDC has to share a secret with its neighbour. On both KDCs create the following principals; for each principal enter the same (preferably long and complex) passphrase on both KDCs. # kadmin -p student/admin addprinc krbtgt/REALM2.WS.NSRC.ORG@REALM1.WS.NSRC.ORG addprinc krbtgt/REALM1.WS.NSRC.ORG@REALM2.WS.NSRC.ORG (The first sets up realm2 to trust realm1; the second sets up realm1 to trust realm2) At this point, Kerberos authentication will work, but ssh on pc1 will reject a user who has authenticated as someone@REALM2 because pc1 is part of REALM1. -- on pc1, logging in to pc2 $ kinit student $ ssh -v student@pc2.ws.nsrc.org -- should be rejected To permit it, create file `~/.k5login` containing the authorized principal(s), one per line. -- on pc2 # editor ~student/.k5login student@REALM1.WS.NSRC.ORG Notes ----- In a real environment, you would add at least one slave KDC for resilience. There is information how to do this at http://web.mit.edu/kerberos/krb5-1.8/krb5-1.8.3/doc/krb5-install.html#Install%20the%20Slave%20KDCs