NTLM authentication and Kerberos authentication protocols explained

What you will learn:

A network needs to have security processes put in place to avoid the misuse of its resources. An authentication process goes a big way in identifying whether a person is who they say they are, or a fraud. Active Directory employed the NTLM authentication protocol to securely authenticate its users, which was then succeeded by the Kerberos authentication protocol. In this article, we will take a look at what is NTLM authentication, how it works, the revisions that the protocol got, and also touch upon what Kerberos authentication is and how it works.

What is NTLM authentication?

NT Lan Manager (NTLM) protocol is an authentication protocol developed by Microsoft in 1993. It is a proprietary protocol. NTLM authentication was superior to its predecessor, the LM authentication because NTLM authentication did not send passwords directly from client to server. NTLM authentication uses the challenge-response authentication protocol where the client has to answer to a ‘challenge’ posed by the server granting access to a service. It uses the DES encryption mechanism.

How NTLM authentication works

Let’s say that John needs access to a server in a domain of the AD network. Here’s how a user’s password is used to authenticate and gain access to the domain using NTLM authentication:

  • John provides his username, password, and the name of the domain he wants to access on the interactive logon screen of his system which is the client machine.
  • The client develops a hash using John’s password and discards the actual password.
  • The client machine then sends John’s username in plain text to the server that John wants to access.
  • The server sends a challenge to the client. This challenge is a 16-byte random number.
  • The client uses the hash generated by John’s password to encrypt this challenge sent by the server, and then it sends the encrypted challenge as a response to the DC.
  • The server then sends the challenge, response, and John’s username to the domain controller (DC), or it may verify the authentication process itself.
  • If the server sends the response to the DC, the DC retrieves the hash of the user’s password from its database, and then encrypts the challenge using the hash.
  • The DC then compares the encrypted challenge it has computed to the response sent by the client. IfJohn has entered the right password, then these two will match, and John will be authenticated and granted access to the server.

NTLMv2: a better NTLM authentication process

NTLMv2 is a more secure version of NTLM protocol discussed above, which is also known as NTLMv1. The main differences that make NTLMv2 differentiate itself from its predecessor are as follows:

  • NTLMv2 provides a variable length challenge instead of the 16-byte random number challenge used by NTLMv1.
  • In NTLMv2, the client adds additional parameters to the server’s challenge such as the timestamp and the username.
  • NTLMv2 also uses the more superior HMAC-MD5 encryption algorithm to encrypt the server’s challenge using the hash generated from the user’s password. NTLMv1 used the relatively weaker DES encryption algorithm.

NTLMv2 gives a better defense against attacks such as replay attacks. However, it is still vulnerable to a man-in-the-middle (MITM) attack, apart from other vulnerabilities.  Kerberos was thus implemented as it is an even more secure authentication protocol because of its use of encrypted tickets.

What is Kerberos authentication:

Kerberos was developed at the Massachusetts Institute of Technology in the 1980s, and has been used in Windows since 2000 as its authentication protocol. The name Kerberos is based on the ancient Greek mythological character, Cerberus, which is a three-headed dog that guards the underworld. The reference to Cerberus is because the Kerberos protocol has three components for authentication, which are:

  • The client seeking authentication.
  • The server the client wants to access.
  • The key distribution center (KDC). The KDC is a trusted third party that authenticates users.

The KDC is comprised of two services, which are:

  • The Authentication Service(AS)
  • The Ticket Granting Service(TGS)

How Kerberos authentication works

Let’s say that John is a client who wants access to server A. Here’s how the three components of Kerberos authentication function to provide AD authentication:

  • Initially, when a John joins the network, a secret key is generated using the password that John created, and it shared between John’s system which is the client and the KDS.
  • When John enters his user ID and password for authentication, his system generates a secret key using the password entered.
  • His system then sends a plain text file with the his user ID and an authentication request to the KDC. The authentication request is time stamped. This makes sure that the probability of a replay attack is less. A replay attack is when a hacker retrieves the plain text file and sends it to the KDC masquerading as the user. However, this process takes more time than if the attack did not take place. So, if the request is time stamped, the KDC can detect the time delay in receiving the request, and it will deny it if the time delay is beyond the set threshold.
  • The AS part of KDC checks whether John is present in the KDC database. If he is not present, the KDC denies the request. If he is present, the AS sends back a Ticket Granting Ticket(TGT) which is also time stamped and encrypted using the secret key that was generated with John’s password.
  • Once the TGT is obtained, John’s system decrypts the TGT using the secret key generated from the password. If John entered the right password, the secret key generated by John’s system will match the secret key that the KDC used to encrypt the TGT. Thus, the TGT can be decrypted. If the TGT session time lapses, John’s system sends another request for a TGT.
  • Once the TGT is decrypted, John’s system sends the TGT and a Service Principal Name(SPN) of the required service from server A to the KDC.
  • This time, the TGS part of the KDC verifies the TGT with the database and then sends back an encrypted session key to access server A back to John’s system.
  • John’s system then sends the Session key to Server A, which verifies the key. Once the session key is validated, John is granted permission to access the service from Server A, thus completing the AD authentication process using Kerberos protocol.

Difference between NTLM and Kerberos authentication

Kerberos is a more secure authentication protocol than NTLM authentication, for several reasons. Here are some of them:

NTLM authenticationKerberos authentication
There is no mutual authentication. Only the client is authenticated. Mutual authentication is available as the server can also be verified. 
There is no support for delegation of authenticationKerberos supports delegation of the authentication process
No native protocol support for smart card logonNative protocol support for smart card logon
NTLM is a proprietary authentication protocol by MicrosoftKerberos is an open standard protocol.
1 Star2 Stars3 Stars4 Stars5 Stars (No Ratings Yet)

Microsoft Azure AD Outage caused by Cross-Cloud Migration Operation

Microsoft recently apologized for an Azure Active Directory issue that disrupted access to Office 365 applications and the Azure Admin Portal for two hours or more for some users. Microsoft conducted a root cause analysis in an attempt to offer an explanation on what caused the outage.

In the root cause analysis notice, Microsoft said that a cross-cloud migration operation that was intended to improve the Azure AD service, ended up disrupting services for some organizations. The outage occurred on March 15 for users of the Azure Admin Portal, Teams, Exchange, Azure KeyVault, SharePoint, Storage and other major applications.

The notice also mentioned that Microsoft is currently working on a two-stage process, called the safe deployment process, to improve the Azure AD service. As part of the plan, Microsoft has already completed the first stage of this Safe Deployment Process for the Azure AD service. The second stage is said to be completed by the mid of 2021.

It is to be noted that this incident isn’t the first of its kind for Azure AD. Microsoft added that a similar incident previously occurred on September 2020 were users of Microsoft 365 services experienced various outages tied to the Azure AD service. However, Microsoft promised that the Safe Deployment Process will eliminate such issues from happening again.

1 Star2 Stars3 Stars4 Stars5 Stars (No Ratings Yet)

Microsoft Exchange flaw: daily attacks surge as 8 percent of servers remain unpatched

According to researchers at F-Secure, vulnerable Microsoft Exchange servers are being attacked ‘faster than we can count’. Although Microsoft estimates only around 8 percent of servers remain unpatched, F-Secure says that new groups of hackers have started chasing behind this vulnerability.

It has been almost a month since Microsoft released a patch for the four zero-day vulnerabilities. Yet, 8 percent (or 30,000) servers are still vulnerable, says the tech giant.

This flaw was abused by hackers for various criminal activities such as writing webshells to disk, dumping credentials, adding user accounts, and stealing complete copies of the Active Directory database.

The Department of Homeland Security raised the alarm about this flaw a month back. Per recent reports, out of the 400,000 servers affected by this flaw, 92 percent (or 370,000) of servers have been patched. These attacks were initiated by the state-sponsored hacker group operating out of China, HAFNIUM. Since then, many such hacker groups have joined this pursuit. Recent reports show that the BlackKingdom ransomware group is the latest popular hacker group to jump on this bandwagon.  

1 Star2 Stars3 Stars4 Stars5 Stars (No Ratings Yet)