Differences in Administrative Tasks using Kerberos

You'll want or need to perform some administrative tasks differently with Kerberos as compared to without Kerberos.

Remove su.For instance, su requires typing the root password. If you use kerberized telnet with the encryption option, this is comparable to using su from ssh, since you don't risk the password being sniffed. If you work unencrypted, however, you'll want to change your habits.

.k5login file.For example, you might list PennKeys of authorized individuals in root's .k5login file to let them log in remotely to root. In the old world, doing this did not create a satisfactory audit trail to determine which of the authorized sysadmins performed a particular su. With Kerberos, there will be a log entry of the PennKey use. It will be stored on the central KDC, however, rather than being easily accessible by school or center staff. This scenario makes tracking su executions less convenient but also increases the difficulty of a sly sysadmin from wiping away their tracks, since the logs aren't under their own control.

ksu.The standard Unix kerberos package also provides "ksu". As with "su", "ksu" allows changing your security context to another user or root, but it is not a suitable approach when not connected with secure encryption since you are prompted for your User PennKey password. Using ksu, though, identifies who is logging in as root at what time.

Control Files Honored.For kerberized commands, you'll need to research whether the command honors conventions used by the previous tools. Is /etc/securetty, hosts.allow and hosts.deny and so forth honored or not? If your system supports Pluggable Authentication Modules (PAM), does the new behavior match the new behavior?