NTLM vs KERBEROS
Let us understand how NTLM authentication works:
User sends a request to the server passing the domain authentication credentials.
Server creates an encryption token and sends a response back to the User (User's machine)
User gets the encrypted token and uses the token to encapsulate the user's password and re sends the new information back to the server.
Server gets the encrypted password, decrypts the information and sends the information to the Domain Account Controller/Service Account Manager for verification and authentication.
The Service account manager verifies the information and informs the server that the user is either authenticated or the authentication request has been denied.
Once these steps occur a connection with the server will either be established or disestablished. Key notes here is that the NTLM authentication does not require to have the server principle (SPN) established on the local machine for authentication. This is more susceptible to attacks as the information passed is the bare essentials.
Let us understand how Kerberos authentication works:
User sends a request to the KLM (Kerberos Login Manager) which handles the request for authentication for the end user. The user passes the domain authentication, the SPN and the password information in a packet.
Step 2 & 3:
The KLM server takes these details, verifies the information with the Service Request Manager/Domain Account Controller and gets the response from the same. In case the user cannot be authenticated, the user will be notified at this stage.
The KLM passes the request to the server and the server responds directly back to the user. Once the authentication has been established, the user will be able to interact with the server without using the KLM.
Key points to Note:
- NTLM is also called Integrated windows authentication.
- Even though NTLM and Kerberos are susceptible to security hacks, Kerberos authentication is considered to be more secure.
- Everytime NTLM needs to go through the Domain Account Controller to establish authentication
- No double hop for NTLM as the authentication information will not persist from one server to another
- The Kerberos Login Manager is also known as the Key Distribution Centre
- Kerberos works on the principle of a ticket being generated by the KLM and once the ticket has been stamped (you can use the analogy of a Visa stamping process at this junction) or authorized, the user will be able to interact with the server.
- Kerberos allows the double hop process to occur i.e. the authentication information is saved by the KLM and further established the requests between servers because the golden ticket is still with the KLM.
- At times to avoid the double hop we use the concept of a secure store i.e. a pre authorized user to the respective servers in SharePoint. Once the user is authenticated by the SharePoint server, the underlying requests between the SharePoint Server and other servers (like PPS....) is accomplished using the existing secure store service information. [Note: Claims to Windows token service (C2WTS) is based on this principle]
- Kerberos has more encryption methodologies than NTLM (I am familiar with only a few and will iterate them in a future article perhaps....)
- Kerberos authentication setup more complicated than NTLM
- Thumb rule for stand alone machines is to always go for integrated windows authentication
Security is a vast topic. On my laptop I have SharePoint 2010 installed on a Win 7 OS with integrated windows authentication, so the hassles of using Kerberos authentication is definitely not in place. However a key note here is that when I migrate information or a SharePoint site from my laptop onto say a company's system, I ensure that the mode is in Kerberos and all the servers are talking with one another.