Active Directory Concepts (2)

What Is NTLM Used For?

 

Windows New Technology LAN Manager (NTLM) is a suite of security protocols offered by Microsoft to authenticate users’ identity and protect the integrity and confidentiality of their activity. At its core, NTLM is a single sign on (SSO) tool that relies on a challenge-response protocol to confirm the user without requiring them to submit a password.

Despite known vulnerabilities, NTLM remains widely deployed even on new systems in order to maintain compatibility with legacy clients and servers. While NTLM is still supported by Microsoft, it has been replaced by Kerberos as the default authentication protocol in Windows 2000 and subsequent Active Directory (AD) domains.

How Does the NTLM Protocol Work?

NTLM authenticates users through a challenge-response mechanism. This process consists of three messages:

    •     Negotiation message from the client
    •     Challenge message from the server
    •     Authentication message from the client

NTLM Authentication Process

NTLM authentication typically follows the following step-by-step process:
    The user shares their username, password and domain name with the client.
    The client develops a scrambled version of the password — or hash — and deletes the full password.
    The client passes a plain text version of the username to the relevant server.
    The server replies to the client with a challenge, which is a 16-byte random number.
    In response, the client sends the challenge encrypted by the hash of the user’s password.
    The server then sends the challenge, response and username to the domain controller (DC).
    The DC retrieves the user’s password from the database and uses it to encrypt the challenge.
    The DC then compares the encrypted challenge and client response. If these two pieces match, then the user is authenticated and access is granted.

The Difference Between NTLM and Kerberos?

Like NTLM, Kerberos is an authentication protocol. It replaced NTLM as the default/standard authentication tool on Windows 2000 and later releases.

The main difference between NTLM and Kerberos is in how the two protocols manage authentication. NTLM relies on a three-way handshake between the client and server to authenticate a user. Kerberos uses a two-part process that leverages a ticket granting service or key distribution center.

Another main difference is whether passwords are hashed or encrypted. NTLM relies on password hashing, which is a one-way function that produces a string of text based on an input file; Kerberos leverages encryption, which is a two-way function that scrambles and unlocks information using an encryption key and decryption key respectively.

Even though the Kerberos protocol is Microsoft’s default authentication method today, NTLM serves as a backup. If Kerberos fails to authenticate the user, the system will attempt to use NTLM instead.

Why Was NTLM Replaced by Kerberos?

NTLM was subject to several known security vulnerabilities related to password hashing and salting.

In NTLM, passwords stored on the server and domain controller are not “salted” — meaning that a random string of characters is not added to the hashed password to further protect it from cracking techniques. This means that adversaries who possess a password hash do not need the underlying password to authenticate a session. As a result, systems were vulnerable to brute force attacks, which is when an attacker attempts to crack a password through multiple log-in attempts. If the user selects a weak or common password, they are especially susceptible to such tactics.

NTLM’s cryptography also fails to take advantage of new advances in algorithms and encryption that significantly enhance security capabilities.
Kerberos Protocol

What Is Kerberos

Kerberos was developed by researchers at the Massachusetts Institute of Technology (MIT) in the 1980s. The name is derived from the Greek mythological character Kerberos, the three-headed dog who guards the underworld.

Kerberos is a computer network security protocol that authenticates service requests between two or more trusted hosts across an untrusted network, like the internet. It uses secret-key cryptography and a trusted third party for authenticating client-server applications and verifying users' identities.

In practice, the three security components in the Kerberos protocol are represented as:

    •     A client seeking authentication
    •     A server the client wants to access
    •     The ticketing service or key distribution center (KDC)

Common Ports 88 and 464

Kerberos Authentication

Here is the twelve-step process for Kerberos authentication:

    The user shares their username, password, and domain name with the client.
    The client assembles a package — or an authenticator — which contains all relevant information about the client, including the user name, date and time. All information contained in the authenticator, aside from the user name, is encrypted with the user’s password.
    The client sends the encrypted authenticator to the KDC.
    The KDC checks the user name to establish the identity of the client. The KDC then checks the AD database for the user’s password. It then attempts to decrypt the authenticator with the password. If the KDC is able to decrypt the authenticator, the identity of the client is verified.
    Once the identity of the client is verified, the KDC creates a ticket or session key, which is also encrypted and sent to the client.
    The ticket or session key is stored in the client’s Kerberos tray; the ticket can be used to access the server for a set time period, which is typically 8 hours.
    If the client needs to access another server, it sends the original ticket to the KDC along with a request to access the new resource.
    The KDC decrypts the ticket with its key. (The client does not need to authenticate the user because the KDC can use the ticket to verify that the user’s identity has been confirmed previously).
    The KDC generates an updated ticket or session key for the client to access the new shared resource. This ticket is also encrypted by the server’s key. The KDC then sends this ticket to the client.
    The client saves this new session key in its Kerberos tray, and sends a copy to the server.
    The server uses its own password to decrypt the ticket.
    If the server successfully decrypts the session key, then the ticket is legitimate. The server will then open the ticket and review the access control list (ACL) to determine if the client has the necessary permission to access the resource.

How Does Kerberos Authentication Work in an AD Environment?

There are a series of steps performed during the Kerberos authentication process, but in real-time, the process is very quick. The steps below outline how Kerberos authentication works in Active Directory.

    When a user logs on to Active Directory, the user authenticates to the Authentication Server (AS) located on the Domain Controller (DC) using the user’s password which of course the DC knows.
    The DC sends the user a Ticket Granting Ticket (TGT) Kerberos ticket for the realm Kerberos has authority to authenticate for. The TGT is then cached on the users computer for later use and presented to any DC to prove authentication for Kerberos service tickets.
    The user decides they want to access the Skype service, which causes the user’s workstation to lookup the Service Principal Name (SPN) for the user’s exchange server.
    Once the SPN is identified, the computer communicates with the DC again and presents the user’s TGT as well as the SPN to the Ticket Granting Service for the resource to which the user needs to communicate.
    The DC replies with the Ticket Granting Service (TGS) Kerberos service ticket.
    The user’s workstation presents the TGS to the Exchange server for access.
    Skype connects successfully.
 
Applications That Use NTLM

NTLM was replaced as the default authentication protocol in Windows 2000 by Kerberos. However, NTLM is still maintained in all Windows systems for compatibility purposes between older clients and servers.

For example, computers still running Windows 95, Windows 98, or Windows NT 4.0 will use the NTLM protocol for network authentication with a Windows 2000 domain. Meanwhile, computers running Windows 2000 will use NTLM when authenticating servers with Windows NT 4.0 or earlier, as well as when accessing resources in Windows 2000 or earlier domains. NTLM is also used to authenticate local logons with non-domain controllers.
NTLM Benefits and Challenges

NTLM is considered an outdated protocol. As such, its benefits — when compared to a more modern solution, such as Kerberos — are limited. Yet the original promise of NTLM remains true: Clients use password hashing to avoid sending unprotected passwords over the network.

At this point there are several clear disadvantages to relying on NTLM authentication:

   Single authentication. NTLM is a single authentication method. It relies on a challenge-response protocol to establish the user. It does not support multifactor authentication (MFA), which is the process of using two or more pieces of information to confirm the identity of the user.
   Security vulnerabilities. The relatively simplistic form of password hashing makes NTLM systems vulnerable to several modes of attacks, including pass-the-hash and brute-force attacks.
   Outdated cryptography. NTLM does not leverage the latest advances in algorithmic thinking or encryption to make passwords more secure.

How Can You Protect Your Network Using NTLM?

Given the known security risks associated with NTLM, CrowdStrike recommends that organizations try to reduce NTLM usage in their network as much as possible.

For organizations still relying on NTLM for compatibility reasons, CrowdStrike offers the following recommendations to enhance security and minimize risk.

   Enforce NTLM mitigations. To be fully protected from NTLM relay attacks, you will need to enable server signing and EPA on all relevant servers.
   Patch! Make sure your systems are fully protected with the latest security updates from Microsoft.
   Use advanced techniques. Apply advanced NTLM relay detection and prevention techniques similar to the ones disclosed by Preempt (now CrowdStrike) in our Black Hat 2019 talk.
   Identify weak variations. Some NTLM clients use weak NTLM variations (e.g., don’t send a MIC). This puts your network at a greater risk of being vulnerable to NTLM relay.
   Monitor NTLM traffic in your network. Try to restrict insecure NTLM traffic.

Get rid of clients sending LM responses and set the Group Policy Object (GPO) network security: LAN Manager authentication level to refuse LM responses.

FSMO Roles in Active Directory

    •     Schema Master
    •     Domain Naming Master
    •     Infrastructure Master
    •     Relative ID (RID) Master
    •     PDC Emulator

PDC Emulator

The Primary Domain Controller Emulator (PDC Emulator or PDCE) is a domain-level role; there is one PDCE in each domain in an Active Directory forest.

The PDC Emulator controls authentication within a domain, whether Kerberos v5 or NTLM. When a user changes their password, the change is processed by the PDC Emulator.

Backward compatibility.
The PDCE mimics the single-master behavior of a Windows NT primary domain controller. To address backward compatibility concerns, the PDCE registers as the target DC for legacy applications that perform writable operations and certain administrative tools that are unaware of the multi-master behavior of Active Directory DCs.
Time synchronization.
Each PDCE serves as the master time source within its domain. The PDCE in forest root domain serves as the preferred Network Time Protocol (NTP) server in the forest. The PDCE in every other domain within the forest synchronizes its clock to the forest root PDCE; non-PDCE DCs synchronize their clocks to their domain’s PDCE; and domain-joined hosts synchronize their clocks to their preferred DC. One example of the importance of time synchronization is Kerberos authentication: Kerberos authentication will fail if the difference between a requesting host’s clock and the clock of the authenticating DC exceeds the specified maximum (5 minutes by default); this helps counter certain malicious activities, such as replay attacks.
Password update processing.
When computer and user passwords are changed or reset by a non-PDCE domain controller, the committed update is immediately replicated to the domain’s PDCE. If an account attempts to authenticate against a DC that has not yet received a recent password change through scheduled replication, the request is passed to the domain PDCE, which will process the authentication request and instruct the requesting DC to either accept or reject it. This behavior ensures that passwords can reliably be processed even if recent changes have not fully propagated through scheduled replication. The PDCE is also responsible for processing account lockouts, since all failed password authentications are passed to the PDCE.
Group Policy updates.
All Group Policy object (GPO) updates are committed to the domain PDCE. This prevents versioning conflicts that could occur if a GPO was modified on two DCs at approximately the same time.
Distributed file system.
By default, distributed file system (DFS) root servers will periodically request updated DFS namespace information from the PDCE. While this behavior can lead to resource bottlenecks, enabling the Dfsutil.exe Root Scalability parameter will allow DFS root servers to request updates from the closest DC.