On Saturday, January 07, 2006 11:38:47 AM +0100 Turbo Fredriksson <[EMAIL PROTECTED]> wrote:
> Security? Nah, both need _extra ordinary security_ so it's easier to > safegard ONE machine than two (* nr of slaves of course :). On the contrary, depending on what you are using your LDAP directory for, it may not require any more security than any other application. Even if this is not the case, traditional operational practice dictates extreme paranoia where KDC's are concerned, because of the massive impact of a compromise. If your LDAP server is compromised, you reinstall the machine, restore the database from backups, and get on with life, just like for any other service. Depending on what you store in the directory, it's possible the intruder obtained sensitive information, but that's also true of other services, such as a mail server. Again, depending on what you store in the directory, it's possible that an intruder who gains the ability to modify the LDAP database has used that to gain access to other services. Such things might be annoying to track down and fix, but they can be fixed. Any changes the intruder made can be rolled back; any deleted data can be restored from backups, etc. If a KDC is compromised, it becomes necessary to assume that the intruder has a complete copy of the Kerberos database, including the keys for every principal. Recovering from such a compromise requires issuing new passwords to _every_ user and re-keying _every_ service -- and doing it in such a way that someone who knows the old keys does not discover the new ones. Any service which has not been re-keyed is vulnerable to the attacker; since he knows the service's key, he can impersonate any user, EVEN IF THE KDC IS SHUT DOWN. A similar problem applies in the reverse direction; an attacker can impersonate the KDC and any service to a user whose key he knows, EVEN IF THE REAL KDC IS SHUT DOWN. This is such a massively bad situation that it is worth taking every effort to protect the Kerberos database from compromise. Running other services on the same machine is simply not worth the potential pain. -- Jeffrey T. Hutzelman (N3NHS) <[EMAIL PROTECTED]> Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
