Kerberos removes a common and severe security threat. However, it may be difficult to implement for various reasons:
Migrating user passwords from a standard UNIX password database, such as /etc/passwd or /etc/shadow, to a Kerberos password database can be tedious as there is no automated mechanism to perform this task. Refer to the Kerberos FAQ Question 2.23 or see the Section called Additional Resources for more detailed information concerning this issue.
Kerberos has only partial compatibility with the Pluggable Authentication Modules (PAM) system used by most servers running Red Hat Linux. For more information on this issue, see the Section called Kerberos and PAM.
For an application to use Kerberos, its source must be modified to make the appropriate calls into the Kerberos libraries. For some applications, this can be quite problematic due to size or frequency that krb libraries must be called. For other applications, changes must be made to the way in which the server and client side communicate. Again, this may require extensive programming. Closed-source applications that do not have Kerberos support by default are often the most problematic.
Kerberos assumes that you are using trusted hosts on an untrusted network. Its primary goal is to prevent clear-text passwords from being sent across that network. However, if anyone other than the proper user has physical access to any of the hosts, especially the one that issues tickets used for authentication, the entire Kerberos authentication system is at risk of being compromised.
Kerberos is an all or nothing solution. If you decide to use Kerberos on your network, you must remember any passwords transferred to a service which does not use Kerberos for authentication run the risk of being captured by packet sniffers. Thus, your network gains no benefit from the use of Kerberos. To secure your network with Kerberos, you must either kerberize all applications which send clear-text passwords or do not use those applications on your network at all.