In Greek mythology, Kerberos is the three-headed dog that guards the entrance to the underworld. In computing, it's a program that "guards the entrance" to a computer network.
The "heart" of a Kerberos system is the Key Distribution Center (KDC). All the computers associated with a KDC make up what's called a "strengthened realm", example DC.ADMINNOTES.COM
Kerberos works by way of exchanging encrypted tickets between machines.
This scenario shows how Kerberous was designed to work ;
User first logs in directly (not over the network) to a Kerberized desktop computer that is in the DC.ADMINNOTES.COM realm.
User requests authentication for the DC.ADMINNOTES.COM realm, and must enter his or her Kerberos password.
Behind the scenes: Kerberos software installed on the desktop is used to derive a key from the password. This key is used to encrypt the exchanges between the local machine and the (remote) KDC in order to achieve authentication. The password is not transmitted between the two machines.
When authentication is complete, user gets a "ticket" (also called a "credential") from the KDC.
The user can now connect over the network to other Kerberized hosts without entering his Kerberos password again. Without entering ANY password, in fact! Kerberos negotiates the authentication for each login using the ticket, all behind the scenes.
With the introducion of Windows 2003, Kerberos Authentication has changed, alot , and for the better.
Normally, a computer account is required for Kerberos authentication. A user must obtain a service ticket for the computer in order to gain access to the computer's resources. Without this user-to-host authentication, the host computer must perform access control based on mapping the user name to a name that it maintains in its local account database. The user must run KSETUP to set up a local mapping.
In Windows 2000, the KDC selects the first encryption type. In Windows Server 2003, the KDC selects the strongest encryption type supported by the client.
Key version numbers are an optional part of the Kerberos specification. They may be included as part of the Kerberos encrypted data when that data is encrypted with a long-lived key. Windows Server 2003 introduces the use of key version numbers
This means that the KDC will not issue a service ticket for an account that does not have an SPN (such as a user account). The motivation for this is that it would make it easier to mount an offline dictionary attack against a service if that service were just a user account with a human-generated password. For an account that does not have an SPN, the KDC will return an error indicating that User-2-User is required
In the past, SPNs were canonicalized to the Security Accounts Manager (SAM) account name (for example, mycomputer$). This caused problems when a user requested a service with a non-canonical name—the system was unable to detect that it had a cached ticket for a service and thus would request a new service ticket. Now, the solution is to just use the SPN that was requested (with no name canonicalization).
For more information, check out the Windows 2003 Technical Reference
