Best Network Security Practices to Restrict NTLM Authentication in 2025

Understanding NTLM Authentication and Its Security Risks

Overview of NTLM Authentication (NTLMv1 and NTLMv2)

NT LAN Manager – NTLM is a challenge-response authentication protocol for use in the windows environment. It was mainly created for networks not using Active Directory (AD) or Kerberos authentication. The following are the two versions of Restrict NTLM Authentication:

• NTLMv1: The older and weaker version that relies on obsolete encryption methods. A very simple hashing mechanism is in use, and so it is extremely vulnerable to attacks.
• NTLMv2: This is the improved version that was released to correct faults in the previous version: NTLMv1. Although NTLMv2 uses stronger cryptographic algorithms and closes some security loopholes, it pales in comparison to Kerberos.

Despite what NTLMv2 purports to improve upon both versions of the previous Restrict NTLM Authentication now considered to be obsolete and insecure. As a result, Microsoft has been trying to encourage organizations to turn off NTLM and then use a much safer means of accessing resources, specifically Kerberos or cloud-based authentication solutions.

Why NTLM is Considered Insecure in Modern Environments

Modern security standards are much tougher when it comes to authentication procedures and mechanisms in use, yet there is Restrict NTLM Authentication because of old applications and poorly configured environments. These are, however, the risks posed by reliance on NTLM:

• Weak Cryptography – Restrict NTLM Authentication relies on MD4 and MD5 hashing algorithms that are termed weak from the standpoint of modern-day cryptographic standards.
• Lack of Mutual Authentication – NTLM only authenticates the client to the server, not the other way around, making it susceptible to man-in-the-middle burglar techniques.
• Relay Attacks susceptibility – Once an attacker has intercepted an NTLM authentication request, he is able to forward it to obtain unauthorized access.
• Theft of Credentials – Restrict NTLM Authentication hashes can be obtained from memory (for example, using Mimikatz) for pass-the-hash (PTH) attacks.
• Difficulty in Restriction – Most organizations unknowingly apply Restrict NTLM Authentication relying on certain legacy applications and misconfigured systems.

Common Vulnerabilities and Security Concerns

Restrict NTLM Authentication feeds several high-profile attack vectors on networks expecting and, in most cases, encountering passive attacks:

• Pass-the-Hash (PTH) Attacks: Attackers steal Restrict NTLM Authentication password hashes and use them to authenticate themselves instead of requiring the plaintext password to authenticate.
• Relay Attacks: They capture Restrict NTLM Authentication authentication requests and forward to obtain unauthorized access.
• Brute Force and Dictionary Attacks: Weak passwords can be cracked easily because Restrict NTLM Authentication does not have strong password policies.
• Lateral Movement across the Network: When an attacker has Restrict NTLM Authentication credentials, they move laterally across the network, escalate privileges, and gain access to sensitive data.

The Need for Change

Given these loopholes in security, organizations should undertake swifter action in curtailing Restrict NTLM Authentication and enforcing the more robust alternatives of Kerberos authentication or cloud-based authentication. The coming sections shall elaborate on auditing, stopping, and banning NTLM authentication from one’s network.

Best Practices for Restricting NTLM in 2025

The work with Restrict NTLM Authentication restricting has taken on a prominent role in network security enhancement. Whereas NTLM was a common term in the days of Windows, today with the passage of time and in-light of recent cyber threats, it has become more of an unnecessary evil. Organizations must take immediate steps to restrict Restrict NTLM Authentication use further, thus enforcing stronger authentication policies.

Importance of Limiting NTLM Usage

NTLM is still widely used across many networks, mostly because of legacy applications and misconfigurations. However, its continued use has become a security concern with issues like:

• A man-in-the-middle attack and relay attack occurred: Restrict NTLM Authentication does not provide mutual authentication, so authentication requests can be intercepted and relayed by an attacker.
• Pass-the-hash attack: The attacker can obtain Restrict Restrict NTLM Authentication Authentication password hashes and use them to authenticate without the need to ever crack a password.
• Weak Encryption – Restrict NTLM Authentication is based on obsolete hashing algorithms (MD4 and MD5) which can be easily brute-forced.
• Limited Visibility and Control – Many organizations inadvertently employ Restrict NTLM Authentication due to misconfigured applications, thus making tracking and ripping the use of Restrict NTLM Authentication extremely difficult.

As a result, companies should aim to phase out Restrict NTLM Authentication for better alternatives like Kerberos, certificate-based authentication, or cloud identity solutions (Microsoft Entra ID, formerly known as Azure AD) to avoid breaches.

Policies for Restricting NTLM

Microsoft provides several native policies and settings for auditing, restricting, and blocking NTLM authentication. The adoption approach should be gradual in a way that existing applications compatibilities are assured and security risks are minimized.

Audit NTLM Usage Before Restricting

Before outright blocking NTLM, organizations should first audit their network to understand where NTLM is being used.

Enable NTLM Auditing via Group Policy

• Go to Group Policy Management Editor (gpedit.msc)
• To do: From the console-tree view, navigate Computer Configuration, Policies, Windows Settings, Security Settings, Local Policies, and Security Options
• Inside Window Security Options, locate the option suitably mentioned as “Network security: Restrict NTLM: Audit NTLM Authentication In This Domain” and set it to “Enable all.”

For analyzing NTLM logs

• Look for EventID 4624 (successful logins) and Event ID 4776 (NTLM authentication requests) from within the Windows Event Viewer.
• Implement Windows Event Forwarding (WEF) for better visibility and centralized logging.

Restrict NTLM Usage with Group Policy

Once auditing identifies where Restrict NTLM Authentication is used, organizations should begin restricting it.

Set NTLM restriction policies 

• Network security: Restrict NTLM: NTLM authentication in this domain

Recommended setting: Deny for all accounts (after verifying no critical applications require NTLM).

• Network security: Restrict NTLM: Incoming NTLM traffic

  Recommended setting: Deny all

Apply these settings cautiously

• Start with “Audit All” mode to detect NTLM-dependent applications.
• Gradually move to “Deny All” once NTLM dependencies are eliminated.

Enforce Kerberos and Modern Authentication Methods

To fully eliminate Restrict NTLM Authentication, ensure that all authentication processes use Kerberos or cloud-based authentication.

Migrate to Kerberos Authentication

• Ensure all Windows Server and domain controllers are configured to prioritize Kerberos.
• Verify that service accounts and applications support Kerberos tickets instead of NTLM.

Use Microsoft Entra ID and Zero Trust Policies

• Implement passwordless authentication with FIDO2 security keys or Windows Hello for Business.
• Enforce Conditional Access policies to block Restrict NTLM Authentication-based logins.
• Deploy Microsoft Defender for Identity to detect and mitigate NTLM-based threats.

Secure Privileged Accounts and Limit NTLM Exposure

To further reduce NTLM risks, restrict its use for privileged accounts and enforce stricter security policies.

Use the Protected Users Group

• Add high-privilege accounts (for example, domain admin) onwards to the Protected Users group, which imposes more legitimate authentication policies and forbids Restrict NTLM Authentication.

Limit NTLM Logons via Active Directory Policies

• Configure Account Policies → Kerberos Policy → Enforce user logon restrictions to prevent NTLM fallback.

Enable Credential Guard

• Use Windows Defender Credential Guard to block NTLM hash extraction and prevent pass-the-hash attacks.

Restricting NTLM is not optional anymore. It must be done to secure a modern organization. With the auditing of NTLM usage, Group Policy restrictions must be enforced, Kerberos should be adopted instead, and security policies must be strengthened-especially in terms of credentials-to limit the risk introduced by credential theft and lateral movement attacks.

Next, we will describe how to efficiently conduct further audit of NTLM authentication and security logs to aid organizations in their path away from NTLM.

Auditing NTLM Authentication in Your Domain

Organizations need to determine how and where Restrict NTLM Authentication authentication is being used in their environments before imposing restrictions or outright bans on it. Auditing Restrict NTLM Authentication authentication will expose legacy applications, misconfigured services, and security weaknesses in their reliance on NTLM. This discusses enabling NTLM auditing, centralizing logs using Windows Event Forwarding, and specifically tracking NTLMv1 logon attempts.

Enabling NTLM Auditing with Group Policy

To make a report on the Restrict NTLM Authentication usage, you would also need to enable Restrict NTLM Authentication auditing using Group Policy. This will enable you to track NTLM authentication requests in the domain and logins that relied on NTLM and not Kerberos.

Steps to Enable NTLM Auditing in Group Policy

Open Group Policy Management Console (GPMC)

Press Win + R, type gpmc.msc, and hit Enter.

Create or Edit a Group Policy Object (GPO)

Drive to Computer Configuration → Policies → Windows Settings → Security Settings → Local Policies → Security Options.

Enable NTLM Auditing by Configuring the Following Policies:

• Network security: Restrict NTLM: Audit NTLM authentication in this domain

Set this to “Enable all” to log every NTLM authentication attempt.

• Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers

Set this to “Audit all” to detect outbound NTLM authentication attempts.

Audit Logon Events (Success/Failure)

Open Computer Configuration, expand Windows Settings, then Security Settings, click Advanced Audit Policy Configuration, and System Audit Policies, and finally open Logon/Logoff.

Enable Audit Logon (Success, Failure) and Audit Authentication Policy Change (Success, Failure).

Force Group Policy Update on Domain Controllers and Clients

• Run gpupdate /force in Command Prompt to apply the changes.

What This Does

• Logs all NTLM authentication requests in Event Viewer under Security Logs.
• Identifies devices, users, and services using NTLM instead of Kerberos.
• Helps prepare for NTLM restrictions by finding dependencies.

Aggregating NTLM Logs Using Windows Event Forwarding (WEF)

NTLM authentication logs can be scattered across multiple devices, making manual review time-consuming. Windows Event Forwarding (WEF) centralizes Restrict NTLM Authentication logs, allowing security teams to monitor all NTLM authentication attempts from a single location.

Setting Up Windows Event Forwarding for NTLM Logs

Configure the Collector Server

• On a Windows Server (preferably a Security Information and Event Management (SIEM) server), open Event Viewer (eventvwr.msc).
• Navigate to Subscriptions and click Create Subscription.
• Name the subscription (e.g., “NTLM Event Logs”).
• Choose “Collector-initiated” or “Source-initiated” depending on the environment.
• Select the servers or workstations to forward logs from.
• Click Select Events and filter logs for:

Event ID 4624 – Successful logon (NTLM usage).

Event ID 4776 – NTLM authentication attempts.

Event ID 8004 – NTLM authentication detected in domain.

• Save and activate the subscription.

Configure Client Computers to Forward NTLM Logs

• On each client or server, run the following command in PowerShell to set the WEF client:
• wecutil qc
• Add the client computers to the Event Log Forwarding group in Active Directory.

Why Use WEF?

• Centralized NTLM Monitoring – No need to check logs on individual machines.
• Faster Incident Response – Security teams can detect NTLM usage in real time.
• Supports SIEM Integration – Forward NTLM logs to Microsoft Sentinel, Splunk, or ELK Stack for deeper analysis.

Auditing NTLMv1 Logon Success

NTLMv1 is much weaker than NTLMv2 so it should really be gotten rid of altogether. The method you’ll use for finding systems still using NTLMv1 is to enable logon success auditing and keep track of the NTLMv1 authentication attempts.

Steps to Audit NTLMv1 Logins

Enable Logon Success Auditing

• Open Group Policy Management Console (GPMC).
• Navigate to:

  Computer Configuration → Windows Settings → Security Settings → Local Policies → Audit Policy.

• Enable Audit Logon Events (Success, Failure).
• Enable Audit Account Logon Events (Success, Failure).

Identify NTLMv1 Authentication Events in Event Viewer

• Open Event Viewer (eventvwr.msc).
• Go to Windows Logs → Security.
• Filter logs for Event ID 4776 (The computer attempted to validate credentials for an account).
• Look for NTLMv1 logins by checking the Authentication Package field.

  If the field shows NTLM, it’s likely NTLMv1.

NTLMv2 authentication will specify NTLMv2.

Use PowerShell to Detect NTLMv1 Usage

Run the following command to filter the NTLMv1 authentication attempts:

Get-WinEvent -LogName Security are likely derived from filters designed to identify ID 4776 messages specifically describing NTLM authentication. This script will format the output as an AutoSize table.

Why Audit NTLMv1?

• NTLMv1 is so easy to be attacked through brute force and relay.
• Finding usage of NTLMv1 is the first step to stopping it.
• Some legacy apps are using NTLMv1, so they should be updated or reconfigured.

Auditing NTLM use is a keystone towards enforcing Restrict NTLM Authentication restrictions. This is where organizations may enable auditing of NTLM, put Windows Event Forwarding into effect, and track NTLMv1 login events. The combination of these steps provides organizations with the ability to analyze NTLM authentication completely, revealing security threats.

The following section will cover how to configure Group Policy to restrict and block NTLM authentication while setting up a more secure network environment.

Configuring Group Policy to Restrict NTLM

Restricting NTLM authentication is an important activity in network security and protection against attacks such as pass-the-hash and relay. Microsoft offers Group Policy settings that allow organizations to manage, limit, or disable NTLM authentication completely in their Active Directory environment.

This section describes how to configure policies on NTLM authentication, understand default and possible policy values, and enforce NTLM restrictions through Active Directory Group Policy.

Setting NTLM Authentication Policies

Restrict NTLM Authentication is restricted primarily through Group Policy settings in Security Options. Those policies essentially help administrators to monitor, restrict, or deny NTLM authentication based on their organization’s security needs.

How to Set Up NTLM Authentication Policies in Group Policy

Open the Group Policy Management Console (GPMC)

• Win + R, gpmc.msc, and Enter

Go to NTLM Authentication Policies

• Computer Configuration → Policies → Windows Settings → Security Settings → Local Policies → Security Options.

Configure the Following NTLM Policies

Force Group Policy Update

After applying these settings, run the following command on all domain controllers and client machines to enforce the policy:

gpupdate /force

Why This Matters?

• Reduces Restrict NTLM Authentication exposure, minimizing risks of NTLM relay attacks.
• Improves security by enforcing Kerberos, the preferred authentication protocol.
• Allows a phased transition, starting with monitoring before enforcing restrictions.

Default and Possible Policy Values

Each NTLM restriction policy has multiple configurable values, allowing organizations to tailor security controls based on operational needs. Below are the possible settings:

NTLM Restriction Policy Values and Their Effects

How to Choose the Right Policy?

• Start with “Audit all” to identify NTLM dependencies.
• Gradually move to “Deny all domain accounts” for increased security.
• Only select “Deny all” if NTLM is fully eliminated from the network.

Enforcing NTLM Restrictions with Active Directory

For larger organizations, Active Directory (AD) Group Policy Objects (GPOs) provide a centralized way to enforce NTLM restrictions across all domain-joined systems.

Steps to Enforce NTLM Restrictions Using AD GPO

Create a New Group Policy Object (GPO)

• Open Group Policy Management Console (GPMC).
• Right-click Group Policy Objects → Click New → Name it “Restrict NTLM Policy”.

Define NTLM Restrictions in Security Settings

• The user is instructed the following instructions for adding a password: Go along the direction of Computer Configurations → Policies → Windows settings → Security settings → Local policies → Security options.
• Modify the following:

             Network security: Restrict NTLM: NTLM authentication in this domain → “Deny all domain accounts”.

                   Network security: LAN Manager authentication level → “Send NTLMv2 response only. Refuse LM & NTLM”.

Link the GPO to Active Directory Organizational Units (OUs)

• Under Group Policy Management, locate the OU containing domain-joined computers.
• Right-click the OU → Select Link an Existing GPO → Choose “Restrict NTLM Policy”.

Test Before Full Deployment

• Apply the policy to a test group of users and systems before enforcing it domain-wide.
• Monitor Event Logs for any authentication failures that may indicate NTLM dependencies.

Apply the GPO to the Entire Domain (Once Tested)

Once testing is successful, apply the policy at the domain level for full enforcement.

Among the most critical steps in network hardening is the restriction of NTLM authentication via Group Policy. By imposing stricter NTLM policies, auditing NTLM traffic, and enforcing restrictions on a domain-wide basis, organizations have a clear opportunity to greatly reduce their attack surface and enhance authentication security.

The subsequent focus will be the migration of Restrict NTLM Authentication-dependent applications to Kerberos authentication for a full move away from NTLM.

Security Considerations and Potential Impacts

Although restricting NTLM authentication is crucial for securing the network, it does not go without hitches. Organizations must understand their vulnerability to NTLM, take counter measures, and anticipate the repercussions of NTLM disabling within their environment.

This section looks at the inherent security risks of NTLM, what constitutes effective countermeasures, and possible repercussions that restriction of NTLM may have on applications and services.

Countermeasures for NTLM Vulnerabilities

NTLM authentication has many inherent security defects, making it vulnerable to credential theft, replay attacks, and relay attacks. The following are the anti-NTLM authentication security enhancement measures:

Enforcing Kerberos Authentication Instead of NTLM

Kerberos is a more advanced type of NTLM. Mutual authentication, stronger encryption, and replay attack-resistance mark it out as an upgrade. Organizations should:

• Identify and migrate applications that rely on NTLM to use Kerberos instead.
• Ensure all domain-joined systems are configured to use Kerberos as the primary authentication method.
• Use the Group Policy setting:

Network security: Restrict NTLM: NTLM authentication in this domain → Deny all domain accounts.

Implement NTLM Auditing and Monitoring

Terminate full NTLM disablement audits by understanding how actually the use are done.

• Group Policy Activate NTLM auditing for logging NTLM authentication attempts.
• Windows Event Forwarding (WEF) or SIEM tool use to gather and analyze NTLM logs.
• Identify legacy applications and services that still rely on NTLM.

Deploy NTLM Relay Attack Protections

NTLM relay attacks allow attackers to intercept and reuse credentials to authenticate as legitimate users. To prevent this:

• Enable SMB signing to protect against man-in-the-middle attacks.
• Use Extended Protection for Authentication (EPA) to add session binding.
• Deploy Credential Guard on Windows systems to protect against credential theft.

Restrict NTLM Traffic with Network Segmentation and Firewalls

By limiting NTLM traffic flow, organizations can reduce exposure and block unauthorized authentication attempts.

• Restrict NTLM usage to specific, trusted systems if complete elimination is not feasible.
• Block outbound NTLM authentication to remote systems to prevent credential leakage.
• Use firewalls and access control lists (ACLs) to limit NTLM authentication attempts.

Possible Impacts of NTLM Restrictions on Applications and Services

NTLM restriction increases security but, if not treated with due diligence, can hinder applications, services, and user workflows. The organization must consider the following impacts and proactively plan for the disabling of NTLM:

Legacy Apps May Fail to Operate

Many older applications are NTLM-authentication dependent; should NTLM be restricted, these applications may fail to authenticate.

Solution

• Identify legacy applications using NTLM by analyzing NTLM authentication logs.
• Check vendor support for Kerberos authentication or consider migrating to modern solutions.
• Use NTLM exceptions (only temporarily) for critical applications while transitioning to Kerberos.

Cross-Domain Authentication Issues

NTLM is often used for authentication between different Active Directory domains. Disabling NTLM could cause:

• Login failures for users authenticating across domains.
• Problems accessing shared resources in a multi-domain environment.
• Solution:

Ensure Kerberos trust relationships are properly configured between domains.

Use Kerberos constrained delegation (KCD) for cross-domain authentication.

Service Accounts and Automated Scripts May Fail

NTLM is sometimes used by service accounts, scheduled tasks, and automated scripts for authentication. Restricting NTLM could break:

• Background services relying on NTLM for authentication.
• PowerShell or batch scripts that use NTLM-based authentication.
• Solution:

Convert service accounts and scripts to use Kerberos authentication.

Test and update automation workflows before enforcing NTLM restrictions.

Remote Desktop and File Sharing (SMB) Issues

NTLM is often used for Remote Desktop Protocol(RDP) and file-sharing (SMB) authentication purposes. Restricting NTLM could result in:

• Users being unable to connect to remote desktops using NTLM credentials.
• Issues with access to file shares and printers, which need NTLM authentication.
• Solution:

Enable Kerberos authentication for RDP sessions.

Ensure SMB signing is enabled and enforce Kerberos authentication for file shares.

Use Group Policy settings to enforce secure authentication methods.

Authentication Failures in Third-Party Cloud and Hybrid Environments

Some cloud and hybrid identity solutions may still depend on NTLM authentication. Disabling NTLM could impact:

• Integration with third-party authentication systems.
• Hybrid Active Directory authentication workflows.
• Solution:

Verification that cloud services can facilitate the use of OAuth, SAML, or Kerberos modern authentication protocols.

Conduct any testing of authentication changes in a staging environment before implementing them system-wide.

Key Conclusions and Next Steps

• The implementation of NTLM authentication needs to be phased out, as it is inherently insecure.
• Using Kerberos authentication and auditing NTLM use with restriction against NTLM traffic provide essential foundations toward better improved security.
• The improper planning of turning off NTLM can affect applications, services and user authentication workflows.
• Organizations must analyze NTLM dependencies and migrate critical applications before fully restricting NTLM.

In the next section, we will discuss alternative authentication methods and migration strategies to completely eliminate NTLM from your environment.

Blocking NTLM Authentication in Windows Server 2025

To adequately safeguard the network, an indispensable step is to block NTLM authentication in Windows Server 2025. NTLM used to be a popular authentication protocol; however, now, it is a security risk as a result of its vulnerabilities, which make it unfit to survive in the present environments. The only remedy for organizations is to turn off NTLM and then enforce stricter authentication protocols like Kerberos, plus extra measures like Credential Guard.

This part elaborates in detail on how to implement NTLM blocking, the effects of NTLM prohibition, and how to use Credential Guard in conjunction with NTLM.

Steps to Fully Block NTLM in the Domain

Before completely blocking NTLM, it is important to first audit its usage to identify dependencies and gradually phase it out. Once auditing is complete, follow these steps to enforce NTLM restrictions in your Windows Server 2025 domain.

Step 1: Audit NTLM Usage Before Blocking It

Prioritizing requests enable clients to behave correctly in a timeout or requiring repeated authentication without compromising security.

Enable NTLM auditing using Group Policy

• Open Group Policy Management Console (GPMC).
• Navigate to:

Computer Configuration →  Policies Windows Settings Security Settings →  Local Policies  → Security Options.

• Locate the policy:

Network security: Restrict NTLM: Audit NTLM authentication in this domain

• Set the policy to: Enable all (DC only).
• Apply and monitor NTLM logs using Event Viewer (Event ID 8004).

Identify User Authentication Applications by reviewing the logs for NTLM Authentication, and verify what services were relying on NTLM before disabling them completely.

Step 2: Restrict NTLM Authentication via Group Policy

Once you have identified NTLM dependencies and transitioned them to Kerberos, you can begin restricting NTLM step by step.

Modify NTLM authentication policies using Group Policy

• Open Group Policy Management Console (GPMC).
• Navigate to:
• Security options provided under Local policies will lead us to Windows Settings→ Security Settings→ Local Policies→ Security Options.
• Locate the following policies and apply these recommended settings:

• Apply the Group Policy settings and ensure they are enforced across the domain.
• Reboot affected systems to apply the changes.

Warning: These settings will completely block NTLM authentication, which may cause disruptions if NTLM-dependent applications are still in use.

Step 3: Use Local Security Policy to Block NTLM on Individual Systems

If you need to block NTLM on specific systems before applying it domain-wide, use Local Security Policy:

• Open Local Security Policy (secpol.msc).
• Navigate to:

Security Settings → Local Policies → Security Options

• Modify the following policies:

Network security: Restrict NTLM: Incoming NTLM traffic → Set to Deny all accounts

Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers → Set to Deny all

This method allows you to test NTLM blocking on a few machines before rolling it out domain-wide.

Step 4: Block NTLM Authentication Using Windows Firewall Rules

For an additional layer of protection, use Windows Firewall to block NTLM authentication traffic.

Create a firewall rule to block NTLM traffic

• Open Windows Defender Firewall with Advanced Security (wf.msc).
• Click Inbound Rules → New Rule.
• Select Custom rule and click Next.
• In the Programs and Services section, choose All programs and click Next.
• Under Protocol and Ports, select:

Protocol type: TCP

• Local Ports: 135, 137, 138, 139, 445 (Used by NTLM).
• Click Next and select Block the connection.
• Name the rule “Block NTLM Authentication” and save it.

This rule prevents NTLM authentication over SMB and RPC ports, forcing Kerberos authentication.

Using Credential Guard for Enhanced Security

Credential Guard by Windows Server 2025, a VBS (Virtualization-Based Security) feature that keeps authentication credentials safe against theft and replay.

What Is Credential Guard?

Credential Guard, built by Microsoft on the virtualization technology in Microsoft Hyper-V, isolates and secures Restrict NTLM Authentication and Kerberos credentials so they cannot be extracted by attackers.

Advantages of Credential Guard

• Prevents NTLM hash dumping, thus mitigating against pass-the-hash attacks.
• Protects LSASS-stored credentials.
• Requires little configuration and is backed up by Windows Defender support.

How to Enable Credential Guard on Windows Server 2025

Follow these steps to enable Credential Guard for enhanced authentication security:

• Open Group Policy Management Console (GPMC).
• Navigate to:

Computer Configuration → Administrative Templates → System → Device Guard

Enable the following settings

• Turn On Virtualization-Based Security → Set to Enabled
• Select Platform Security Level → Set to Secure Boot and DMA Protection
• Credential Guard Configuration → Set to Enabled with UEFI Lock

Apply the Group Policy settings and restart the system.

Once Credential Guard is enabled, Restrict NTLM Authentication hashes and Kerberos tickets are stored in an isolated memory space, making it harder for the attackers to steal.

Highlight and Next Steps

• NTLM is now an outdated authentication protocol with serious security concerns.
• Blocking NTLM on Windows Server 2025 will enhance security but the process must be managed correctly to avoid disruption.
• Adopt a phased approach: carry out an audit of NTLM usage; then, over time, enforce restrictions via Group Policy and firewall rules.
• Deploy Credential Guard for added protection against credential theft and against NTLM relay attacks.
• Test all improvements in a lab environment before blocking NTLM fully across the domain.

If organizations follow through with these steps, they will establish a trustworthy blocking of NTLM authentication, migration to Kerberos, and security hardening for Windows Server 2025.

Migrating applications and services away from NTLM – Learn to get critical applications transitioned to modern authentication methods!

Enhancing Authentication Security Beyond NTLM

Having learned that NTLM as an authentication method is highly compromised and outdated, organizations must start authorizing stronger and more modern authentication methods in protecting their networks. Once NTLM blocking is in place, further emphasis must be put on setting up authentication mechanisms, which would have greater security, scalability, and flexibility.

Here we examine Kerberos authentication, Microsoft Entra ID (formerly Azure AD being one), and security policies with a Zero Trust approach as the three core pillars defining a greater push to improve authentication security beyond NTLM.

Implementation of Kerberos Authentication

What Is Kerberos Authentication?

Kerberos is a much more secure authentication protocol than NTLM. Its ticket-based authentication and mutual verification between client and server make it immune to replay attacks and pass-the-hash attacks.

Advantages of Kerberos Over NTLM

• Mutual Authentication: Both the client and server recognize each other.
• No NTLM Relay Attack Possible: It does not use static password hashes.
• Time-Limited Tickets: This limits the exposure of stolen credentials.
• Supports Multi-Factor Authentication (MFA): This would strengthen security.

Enforcing Kerberos Authentication on Windows Server 2025:

For a successful transition from NTLM to Kerberos authentication, consider the following steps:

Step 1: Check that Kerberos Can Authenticate

• Check if Active Directory (AD) is configured appropriately. ·
• Run the command and find out which authentication protocol sequence gets used:·
• klist sessions
• If NTLM is still in use, check logs for NTLM-dependent applications.

Step 2: Update Group Policy to Enforce Kerberos

• Open Group Policy Management Console (GPMC).
• Navigate to:
• This goes like this: computer Configuration → Windows Settings → Security Settings → Local Policies → Security Options.
• Modify these settings:

Step 3: Test and Deploy Kerberos Authentication

• Restart affected systems and verify that Kerberos authentication is being used.
• Monitor logs for Kerberos ticket requests using Event Viewer (Event ID 4769).
• If NTLM usage is still detected, review and migrate any legacy applications.

Using Microsoft Entra ID (Formerly Azure AD) for Modern Authentication

Why Move to Microsoft Entra ID?

Microsoft Azure Entra ID (formerly Azure Active Directory) provides cloud identity management that enables organizations to securely implement user authentication across hybrid and cloud environments.

Key Benefits of Microsoft Entra ID

• Negates the NTLM and Kerberos dependency for cloud application environment.
• Authenticates with MFA and Passwordless Login.
• SSO authentication is seamlessly integrated.
• Uses Conditional Access Security and Identity Protection Security.

How to Migrate Authentication to Microsoft Entra ID

Step 1: Sync On-Prem Active Directory with Entra ID

• Use Azure AD Connect to sync on-prem Active Directory accounts to Microsoft Entra ID.
• Run the following PowerShell command to check synchronization:
• Get-ADSyncScheduler
• Ensure user identities are properly linked in Hybrid AD environments.

Step 2: Enable Modern Authentication for Applications

• Move Restrict NTLM Authentication and Kerberos applications over to OAuth 2.0 and OpenID Connect.
• Configure SSO (Single Sign-On) with Microsoft Entra ID.

Enable password-less authentication by Microsoft Authenticator, FIDO2 security keys or Windows Hello.

Step 3: Implement Conditional Access Policies

• Gate to the Microsoft Entra Admin Center → Security → Conditional Access.
• Define policies such as:

Require MFA for sensitive applications.

Block logins from untrusted locations.

Enforce device compliance requirements.

Requiring Microsoft Azure AD could deliver successful removal of the NTLM requirement and improved security in hybrid and cloud scenarios.

Implementing Zero Trust Security Policies

What Is Zero Trust Security?

The security model called Zero Trust does not trust any device, user, or application by default. Instead, every authentication attempt is verified and continuously monitored.

Key Principles of Zero Trust

• Verify Identity – Use MFA and strong authentication methods.
• Limit Access – Implement least privilege access controls.
• Monitor Activity – Use continuous security monitoring and analytics.
• Assume Breach – Enforce strict segmentation and access controls.

How to Implement Zero Trust for Authentication Security

Use Identity-Based Access Controls

• All users must implement Multi-Factor Authentication (MFA).
• Role-based access control (RBAC) should be put in place to limit privileges.
• Passwordless authentication should be utilized wherever applicable.

Enforce Device Compliance and Security

• Require Device Compliance Policies to Access Systems.
• Implement Endpoint Detection and Response (EDR) Solutions to Monitor Threats.
• Enable Microsoft Defender for Identity for Credential Attack Detection.

Enable Network Segmentation and Micro-Segmentation

• Restrict access using Microsoft Defender for Endpoint and firewall policies.
• Use Application Gateway and Web Application Firewall (WAF) to filter traffic.

Continuously Monitor Authentication and Security Logs

• Use Microsoft Sentinel (SIEM) for real-time authentication monitoring.
• Track suspicious login activity (Event ID 4625 for failed logins).

Zero Trust eliminates reliance on outdated methods, such as Restrict NTLM Authentication, for authentication while firmly asserting that authentication safety is being delivered with continued verification.

Key Takeaways and Next Steps

• Kerberos authentication is often considered preferable to NTLM because of the binding strength it provides, and further due to its mutual authentication capabilities.
• Microsoft Entra ID enables cloud-based authentication with MFA, SSO, and Conditional Access policies.
• Zero Trust security ensures authentication is continuously verified and access is restricted based on identity, device security, and risk level.
• Organizations should migrate applications and services to modern authentication methods to fully eliminate NTLM dependency.

The implementation of Kerberos, Microsoft Entra ID, and Zero Trust enables organizations to provide superior authentication security, decrease risks, and future-proof their IT infrastructure.

Upcoming Next Section: Moving Legacy Applications and Services Away from NTLM – Learn how to migrate mission-critical applications to modern authentication methods!

Advanced Security Measures and Tools

Advanced security should therefore be put in place by the organizations to harden the authentication security and reduce the risks posed by NTLM. Among them are using Protected Users to guard privileged accounts as well as restricting logon rights through Active Directory Authentication Policies Policy.

By using such measures, organizations will be able to diminish the attack surface, deny credential harvesting, and implement strong authentication policies.

Use the Protected Users Group to secure privileged accounts

What Is the Protected Users Group?

Protected Users is a built-in security group in Active Directory that makes privileged user accounts more secure.

Once added into this group, it automatically applies strong security policies like:

• No NTLM Authentication – Members can only use Kerberos authentication.
• No Cached Credentials – Windows won’t store passwords locally.
• No DES or RC4 Encryption – Only AES-based encryption is allowed.
• No Delegation – Credentials cannot be forwarded for authentication.

How to Add Users to the Protected Users Group

Step 1: Open Active Directory Users and Computers (ADUC)

• Open up Active Directory Users and Computers (dsa.msc).
• Navigate to:
• Active Directory → Builtin → Protected Users
• Right-click Protected Users and select Properties.

Step 2: Add Privileged Accounts

• Click Members → Add.
• Enter the usernames of domain administrators, service accounts, or highly privileged users.
• Click OK, then Apply.

Step 3: Verify That NTLM Is Disabled for Protected Users

• Open Event Viewer and go to:

·                        Applications and Services Logs → Microsoft → Windows → NTLM

• Look for Event ID 8004 (indicating Restrict NTLM Authentication was blocked for a Protected User).

Step 4: Test Authentication

• Log in with a Protected User account and verify that only Kerberos authentication is used.
• If any applications fail authentication, check whether they still rely on Restrict NTLM Authentication.

Using the Protected Users group ensures that privileged accounts are immune to Restrict NTLM Authentication-based attacks and credential theft.

Limiting Logon for Users and Services with Active Directory Policies

Why Restrict Logon Permissions?

Default multiuser access from various devices generally facilitates an intrusion into credential compromise processes moving laterally across the network.

Active Directory authentication policies are specifically meant to limit logon accesses and hence reduce risk of:

• Payloads of Pass the Hash (PtH) and Pass the Ticket (PtT).
• A bot-based credential stuffing and brute-force login attempts to access accounts.
• Lateral movement as a result of compromised credentials.

How To Restrict Users and Services Login

Step 1: Open Group Policy Management Console (GPMC)

• Press Win + R, type gpmc.msc, and press Enter.
• Find your way to:<Computer Configuration->Policies->Windows Settings->Security Settings->Local Policies->User Rights Assignment.

Step 2: Modify Logon Restrictions

Step 3: Apply User and Service Account Restrictions

• Assign these policies to specific organizational units (OUs).
• Apply restrictions based on job roles and security levels.
• Use fine-grained password policies to enforce additional security.

Step 4: Monitor Logon Attempts and Failures

• Enable logon auditing in Event Viewer under:

·                              Security Logs → Audit Logon Events

• Search for events with ID 4625 (failed logon attempt) and ID 4648 (logon with explicit credentials).

Important Point: Limiting logon permission prevents unauthorized access, protects privileged accounts, and reduces the risk of lateral movement.

By combining Protected Users group policies and Active Directory authentication restrictions, organizations can:

• Completely eliminate NTLM authentication for privileged accounts.
• Prevent credential theft, relay attacks, and lateral movement.
• Restrict logon access for both users and services to reduce attack vectors.

These advanced security measures help organizations fortify their authentication mechanisms, ensuring that Restrict NTLM Authentication-based threats are fully mitigated.

Migrating Legacy Applications and Services Away from Restrict NTLM Authentication – Learn how to transition mission-critical apps to modern authentication methods!

Conclusion: Strengthening Network Security by Eliminating NTLM

This one-term-not-authenticating Restrict NTLM Authentication makes a great deal on modernizing network security to add refraining actions of attacks based on identity. Strict policies for authentication as well as audit Restrict NTLM Authentication, Group Policy configuration, and added hardening just like Credential Guard and the Protected Users Group reduce the attack surface significantly while exposing itself to any attacks.

However, for Restrict NTLM Authentication restrictions to be effective, they should be managed without a glitch. Security policies should be regularly viewed alongside monitoring of authentication logs and legacy application migrating to current protocols, such as Kerberos and Microsoft Entra ID.

Security measures today have to change as quickly as cybersecurity threats themselves are evolving. Take the proactive route of keeping pace with IT best practices and continue improving your authentication policies for a secure, resilient infrastructure through 2025 and beyond.

Ahsan Ali

Ahsan Ali is a technology blogger and the founder of Techzivo.com, a platform dedicated to delivering insightful and practical content for tech enthusiasts.He currently focuses on creating in-depth articles around cybersecurity, aiming to help readers stay safe and informed in the digital world. With a passion for emerging technologies, Ahsan plans to expand Techzivo’s coverage into other technology micro-niches such as AI, cloud computing, and digital privacy, offering valuable insights for a broader tech-savvy audience.