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