A simple under the covers description of NTLM/Kerberos

I did not write this, but I liked it. All credit to Summit7.

NTLM

NTLM is a Windows challenge/response authentication protocol that leverages the interactive use of a login box that requires the end user to input their network credentials manually. Those credentials would include the users Username, password and domain name if logging into an organizations domain.

Plain English: end users log in by entering a username, password and domain into a login box. That being said we need to understand at least the basics of the process.

1. NTLM authenticates end users by first creating an encrypted one-way hash of the users password, discarding the original password and then sending the user name to the server in plain text.
2. The server responds to the client with a 16-bit challenge called a nonce.
3. The client encrypts the nonce and the hash of the users password and returns them to the server. This is the Response.
4. The server in turn sends three items to the domain controller; the users name, the challenge sent to the client and the clients response to the challenge. The domain controller retrieves the hash of the user name is has received from the Security Account Manager (SAM) database and uses that hash to encrypt the challenge.
5. Once the challenge has been encrypted by the domain controller it is compared to the challenge encrypted by the client and if they match the end user is authenticated successfully.

Plain English: If you enter your password incorrectly the hashes will not match and you won’t be able to log into the network.

Kerberos

The Kerberos security protocol has been a part of Windows since Windows Server 2000 and was intended as a replacement for NTLM. Obviously that hasn’t happened and the two can often be found working together or in a mixture across Windows environments everywhere.

Kerberos is a Windows Security Protocol designed to authenticate users and services on an organisations network and relies on three components; a client, a service and a trusted third party. The trusted third party in most Windows networks would likely be the Key Distribution Center (KDC) which creates the shared secret that is leveraged to allow access to the service. A simple view of the process might look like this:

1. A user account is created in the domain and assigned a password.
2. The Kerberos client adds a text string, or a SALT and the Kerberos version number to the unencrypted password and runs them through a process known as the “string2key” This conversion generates the “shared secret”.
3. At the client the user enters their username and password and requests access to an application or service.
4. When the user submits their username and password the Kerberos client creates the secret key on the client based on that information. Because the client uses the same key to generate the secret key that the KDC does the two will match, or should anyway. If they don’t match authentication fails and access id denied.

Plain English: If you enter your password incorrectly the hashes will not match and you won’t be able to log into the network.

Thanks to Summit7 for this – full link –> http://summit7systems.com/claims-based-authentication-adfs-3-0-and-sharepoint-2013-beginners-guide/