Virtualization - Cloud

Day: December 21, 2020

Difference between NTLM, Kerberos & LDAP authentication

NTLM: Authentication is the well-known and loved challenge-response authentication mechanism, using NTLM means that you really have no special configuration issues. As Microsoft likes to say, “It just works.”


Older than Kerberos, and is for authentication as well. Can still be used as a backup to Kerberos authentication being down.

Kerberos: It’s complex ticket-based authentication mechanism that authenticates the client to the server and authenticates the server to the client. While Kerberos is more secure, it can be a bit challenging to set up properly. Win 2003 with the latest SP can be configured to use either NTLM or Kerberos. Well, besides being more secure, Kerberos has two key advantages that make it worth consideration.


Authentication for ticket based domain authentication i.e. logging into the domain. Replaced NTLM.

Kerberos is the authentication protocol that is used in Windows 2000 and above where as NTLM was used in Windows Server NT 4 ad below. As for LDAP, it is the protocol that is used with Active Directory, Novell Directory Service, and newer Unix systems.. If you have older workstations you may still need to use NTLM, but if you only have Windows Me clients or below you can disable it using Group Policy. Windows 2000 professional and above used Kerberos

LDAP: It is primarily a directory access protocol. They do different things. LDAP has a primitive authentication mechanism called “simple bind” that applications can use to verify credentials if they can’t handle other authentication protocols. It gets tricky because LDAP also includes an extensible authentication framework called SASL that allows alternate authentication protocols to be added.
Protocol to allow other programs to access the Active Directory Framework, used in VBScript extensively. Think of it as a “hole to allow you to peek inside your Active Directory Domain”.

Advantages of Kerberos: Better Security, Faster authentication, Mutual authentication, Kerberos is an open standard, Support for authentication delegation, Support for the smart card logon feature.

  1. Performance – Kerberos caches information about the client after authentication. This means that it can perform better than NTLM particularly in large farm environments.
  2. Delegation – Kerberos can delegate the client credentials from the front-end web server to other back-end servers like SQL Server.
    Work Flows

In Active Directory (AD), two authentication protocols can be used:


NT LAN Manager (NTLM): This is a challenge-response authentication protocol that was used before Kerberos became available. However, an organization may still have computers that use NTLM, so it’s still supported in Windows Server.
Kerberos: This protocol works on the basis of tickets, and requires the presence of a trusted third party.

The basics of how NTLM works

Here’s a step-by-step description of how NTLM authentication works:


• The user provides their username, password, and domain name at the interactive logon screen of a client.
• The client develops a hash of the user’s password and discards the actual password.
• The client sends the username in plain text to the server it wants to access.
• The server sends a challenge to the client. This challenge is a 16-byte random number.
• The client then sends a response to the server. This response is the challenge encrypted by the hash of the user’s password.
• The server sends the challenge, response, and username to the domain controller (DC).
• The DC retrieves the hash of the user’s password from its database, and then encrypts the challenge using it.
• The DC compares the encrypted challenge it has computed (in the above step) to the response of the client. If these two match, the user is authenticated.

NTLMv2 – A big improvement over NTLMv1

NTLMv2 is a more secure version of NTLM (discussed above). It differs from its predecessor in the following ways:


• It 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 client nonce, server nonce, timestamp and username. It then encrypts this with the hash of the user’s password with the HMAC-MD5 algorithm. In contrast, in NTLMv1, the client only adds the client nonce and the server nonce to the server’s challenge. It then encrypts this with the hash of the user’s password with the relatively weak DES algorithm.

NTLMv2 gives a better defense against replay attacks and brute-force attacks. However, Kerberos is an even more secure authentication protocol because of its use of encrypted tickets.

How Kerberos works

NTLMv2 – A big improvement over NTLMv1 NTLMv2 is a more secure version of NTLM (discussed above). It differs from its predecessor in the following ways:

Here is the step-by-step process of how Kerberos works:

The user attempts to join the network through the client’s interactive logon screen.
• The client constructs a package called an authenticator which has information about the client (username, date, and time). Except for the username, all the other information contained in the authenticator is encrypted with the user’s password.
• The client then sends the encrypted authenticator to the KDC.
• The KDC immediately knows the identity of the client that has sent the authenticator by looking at the username. The KDC will then look into its AD database for the user’s password, which is a shared secret. It then decrypts the authenticator with the password. If the KDC is able to decrypt the authenticator, it means that the identity of the client is verified.
• Once the identity of the client is verified, the KDC creates a ticket granting ticket (TGT), which is encrypted by a key that only the KDC knows.
• The KDC sends the TGT to the client. The client stores the TGT in its Kerberos tray. It can use this ticket whenever it needs to access a resource on a server on the network (within a typical time limit of eight hours).
• When the client needs to access another server, it sends the TGT to the KDC along with a request to access the resource.
• The KDC decrypts the TGT with its key. This step verifies that the client has previously authenticated itself to the KDC.
• The KDC generates a ticket for the client to access the shared resource. This ticket is encrypted by the server’s key. The KDC then sends this ticket to the client.
• The client saves this ticket in its Kerberos tray, and sends a copy of it to the server.
• The server uses its own password to decrypt the ticket
.

If the server successfully decrypts the ticket, it knows that the ticket is legitimate. The server will then open the ticket and decide whether the client has the necessary permission to access the resource by looking through the access control list (ACL).

Azure AD Connect setup

Guest Post -Thanks to cloudsapient blog

Azure AD Connect Authentication (sign-in) Options:
Below are the four different authentication (sign-in) mechanisms provided by Azure AD when you are using Azure AD Connect, based on your feasibility from security and compliance perspective you can choose the one appropriate. During Azure AD Connect installation wizard you will have the ability to choose one of the authentication mechanism.

1. Password Hash Synchronization (PHS):
–When we install Azure AD Connect with “Express Settings” then Password Harsh Synchronization (PHS) authentication mechanism is the default configuration.
–AAD Connect synchronizes a hash, of the hash, of an AD user’s password from an on-premises AD to Azure AD.
–To synchronize user’s password, Azure AD Connect sync extracts user’s password hash from the on-premises Active Directory. Extra security processing is applied to the password hash before it is synchronized to the Azure Active Directory.
–PHS process runs every 2 minutes and we cannot modify the frequency of this process.

2.Pass-through Authentication (PTA):
–Users credentials are validated by on-premises Active Directory Domain Controller via AAD Connect Authentication Agent, On-premises AD user’s passwords are not stored in Azure AD in any form.
–For Pass-through Authentication to work, users need to be provisioned into Azure AD from on-premises Active Directory using Azure AD Connect. Pass-through Authentication does not apply to cloud-only users.
–Communication between Authentication Agent and Azure AD is uses certificate-based authentication. These certificates are automatically renewed every few months by Azure AD.
–Microsoft recommends to have more than one AAD Connect Authentication Agent to provide high availability of authentication requests.
–PTA can also be used in conjunction with PHS for high availability scenarios, As per Microsoft “Enabling Password Hash Synchronization gives you the option to failover authentication if your on-premises infrastructure is disrupted. This failover from Pass-through Authentication to Password Hash Synchronization is not automatic. You’ll need to switch the sign-in method manually using Azure AD Connect. If the server running Azure AD Connect goes down, you’ll require help from Microsoft Support to turn off Pass-through Authentication.”

3. Federation with ADFS:
–In ADFS federation scenario, Azure AD will be redirecting authentication request to ADFS.

4. Federation with PingFederate:
–If you are already using PingFederate in your environment then you may choose this method for authentication. AAD Connect natively supports PingFederate, please refer below official document from PingFederate regarding implementation of this.
https://support.pingidentity.com/s/article/PingFederate-Microsoft-Azure-End-to-End-Integration

© 2024 Tech Blog

Theme by Anders NorenUp ↑