+If you don't want it to be possible to log in to a user account via
+Kerberos, create an empty `.k5login` file in their home directory.
+Otherwise, by default, you can log in to a user account with a Kerberos
+principal from the default realm (ATHENA, presumably) whose username
+matches; that is to say, an Athena user whose username matches a local
+username can log in to that local account. (One option to avoid this is
+to create a `.k5login` file in `/etc/skel` so that new accounts you
+later add get this file by default.)
+
+## Upgrading cryptographic strength
+
+You may wish to change the encryption algorithms (*enctypes*) included in your keytab. With server principals (like `daemon/servername.mit.edu` or `host/servername.mit.edu`) it is particularly important to support *only* strong algorithms. If you support a weak algorithm, an attacker can request a service ticket encrypted with that key, allowing them to do an offline attack and potentially extract your secret key.
+
+To change the supported enctypes, run `kadmin`:
+
+ kadmin -p daemon/kronborg.mit.edu -k -t daemon.kronborg.keytab
+
+From within `kadmin`, to create new keys:
+
+ ktadd -k daemon.kronborg.keytab -e aes256-cts:normal,aes128-cts:normal daemon/kronborg.mit.edu
+
+After all tickets currently issued against your service expire (which will happen after at most one day), you should remove the old keys from your keytab. If there are no outstanding tickets, you can do this from within `kadmin`: