How to Set NTLM Authentication in Windows Using PowerShell

In an ever-evolving cybersecurity landscape, securing communications and data exchange is paramount. One such protocol that has been a focal point of discussion is NTLM (NT LAN Manager), which is used to authenticate users in Microsoft environments. With recent advancements and concerns about security, there’s been a shift from older NTLM versions to the more secure NTLMv2. Today, we’ll delve deep into a PowerShell script that helps manage NTLM authentication responses by setting the LmCompatibilityLevel in the Windows registry.

Background

Originally developed as an authentication protocol by Microsoft, NTLM has undergone several updates to tackle various security vulnerabilities. However, as more secure authentication mechanisms emerged, especially NTLMv2, the need to restrict or disable older versions became evident. This script aids IT professionals and Managed Service Providers (MSPs) in making this transition smoothly, without manually navigating through complex registry settings.

The Script

#Requires -Version 5.1

<#
.SYNOPSIS
    Set the LM and NTLMv1 authentication responses via LmCompatibilityLevel in the registry
.DESCRIPTION
    Set the LM and NTLMv1 authentication responses via LmCompatibilityLevel in the registry
.EXAMPLE
    No parameters needed.
    Sets LAN Manager auth level to 5, "Send NTLMv2 response only. Refuse LM & NTLM."
.EXAMPLE
     -LmCompatibilityLevel 5
    Sets LAN Manager auth level to 5, "Send NTLMv2 response only. Refuse LM & NTLM."
.EXAMPLE
     -LmCompatibilityLevel 3
    Sets LAN Manager auth level to 3, "Send NTLMv2 response only."
    This is the default from Windows 7 and up.
.EXAMPLE
    PS C:> Disable-LmNtlmV1.ps1 -LmCompatibilityLevel 5
    Sets LAN Manager auth level to 5, "Send NTLMv2 response only. Refuse LM & NTLM."
.OUTPUTS
    None
.NOTES
    Minimum OS Architecture Supported: Windows 10, Windows Server 2016
    Reference chart: https://ss64.com/nt/syntax-ntlm.html
    Release Notes:
    Initial Release
By using this script, you indicate your acceptance of the following legal terms as well as our Terms of Use at https://www.ninjaone.com/terms-of-use.
    Ownership Rights: NinjaOne owns and will continue to own all right, title, and interest in and to the script (including the copyright). NinjaOne is giving you a limited license to use the script in accordance with these legal terms. 
    Use Limitation: You may only use the script for your legitimate personal or internal business purposes, and you may not share the script with another party. 
    Republication Prohibition: Under no circumstances are you permitted to re-publish the script in any script library or website belonging to or under the control of any other software provider. 
    Warranty Disclaimer: The script is provided “as is” and “as available”, without warranty of any kind. NinjaOne makes no promise or guarantee that the script will be free from defects or that it will meet your specific needs or expectations. 
    Assumption of Risk: Your use of the script is at your own risk. You acknowledge that there are certain inherent risks in using the script, and you understand and assume each of those risks. 
    Waiver and Release: You will not hold NinjaOne responsible for any adverse or unintended consequences resulting from your use of the script, and you waive any legal or equitable rights or remedies you may have against NinjaOne relating to your use of the script. 
    EULA: If you are a NinjaOne customer, your use of the script is subject to the End User License Agreement applicable to you (EULA).
.COMPONENT
    ProtocolSecurity
#>

[CmdletBinding()]
param (
    [Parameter()]
    [ValidateRange(0, 5)]
    [int]
    $LmCompatibilityLevel = 5
)

begin {
    function Test-IsElevated {
        $id = [System.Security.Principal.WindowsIdentity]::GetCurrent()
        $p = New-Object System.Security.Principal.WindowsPrincipal($id)
        if ($p.IsInRole([System.Security.Principal.WindowsBuiltInRole]::Administrator))
        { Write-Output $true }
        else
        { Write-Output $false }
    }
    function Set-ItemProp {
        param (
            $Path,
            $Name,
            $Value,
            [ValidateSet("DWord", "QWord", "String", "ExpandedString", "Binary", "MultiString", "Unknown")]
            $PropertyType = "DWord"
        )
        New-Item -Path $Path -Force -ErrorAction SilentlyContinue | Out-Null
        if ((Get-ItemProperty -Path $Path -Name $Name -ErrorAction SilentlyContinue)) {
            Set-ItemProperty -Path $Path -Name $Name -Value $Value -Force -Confirm:$false | Out-Null
        }
        else {
            New-ItemProperty -Path $Path -Name $Name -Value $Value -PropertyType $PropertyType -Force -Confirm:$false | Out-Null
        }
    }
}
process {
    if (-not (Test-IsElevated)) {
        Write-Error -Message "Access Denied. Please run with Administrator privileges."
        exit 1
    }
    $Path = @(
        "HKLM:SYSTEMCurrentControlSetServicesLsa"
        "HKLM:SYSTEMCurrentControlSetControlLSA"
    )
    $Name = "LmCompatibilityLevel"
    # $Value = $LmCompatibilityLevel
    # Sets LmCompatibilityLevel to $LmCompatibilityLevel
    try {
        $Path | ForEach-Object {
            Set-ItemProp -Path $_ -Name $Name -Value $LmCompatibilityLevel
        }
        
    }
    catch {
        Write-Error $_
        exit 1
    }
    $Path | ForEach-Object {
        $Value = Get-ItemPropertyValue -Path $_ -Name $Name -ErrorAction SilentlyContinue
        if ($null -eq $Value) {
            Write-Host "$_$Name set to: OS's default value(3)."
        }
        else {
            Write-Host "$_$Name set to: $Value"
        }
    }
}
end {}

 

Detailed Breakdown

The script is essentially divided into three phases: begin, process, and end.

• Begin Phase: The script starts with defining two functions:
• Test-IsElevated: Checks if the script runs with Administrator privileges.
• Set-ItemProp: Creates or sets a registry key property.
• Process Phase: It verifies the user has elevated rights. If not, an error is flagged. Otherwise, it goes ahead to modify the LmCompatibilityLevel in two potential registry paths. Post modification, the script confirms the applied setting.
• End Phase: Not explicitly used, but it’s a placeholder for potential future updates or extensions to the script.

Potential Use Cases

Case Study: Imagine Jenny, an IT administrator in a mid-sized organization. They’ve recently undergone a security audit, revealing that certain systems still use outdated NTLM versions. With hundreds of machines to manage, manually updating each one isn’t feasible. Using this script, Jenny seamlessly updates all systems, ensuring they only accept NTLMv2 responses.

Comparisons

While Group Policy can also be used to manage NTLM settings across an organization, PowerShell scripts, like the one discussed, offer more granularity and automation. They can be integrated into larger automation tools or workflows, making the process streamlined and less prone to manual errors.

FAQs

• How does the script check for administrator privileges?
  The script uses the Test-IsElevated function to determine if it’s running with admin rights.
• What if I want to set a different LmCompatibilityLevel value?
  You can do so by providing the -LmCompatibilityLevel parameter when running the script, e.g., Disable-LmNtlmV1.ps1 -LmCompatibilityLevel 3.
• Is it backward compatible with older Windows versions?
  The script supports Windows 10 and Windows Server 2016 and up.

Implications

By setting the LmCompatibilityLevel, IT professionals dictate how systems handle NTLM authentication. Restricting to NTLMv2 improves security, reducing risks associated with older, less secure versions. However, it’s crucial to ensure compatibility, as older systems or applications might face connectivity issues post changes.

Recommendations

• Always backup the current registry state before making changes.
• Initially, test the script in a controlled environment to understand its impact.
• Stay informed about the latest security best practices and integrate them into your routine audits.

Final Thoughts

While PowerShell scripts like these empower IT professionals to enhance security, monitoring and management tools like NinjaOne further elevate these capabilities. With integrated monitoring, automation, and reporting, platforms like NinjaOne ensure that your IT infrastructure remains robust, secure, and efficient, complementing scripts and manual interventions.

Remember, in the realm of IT, proactive measures, combined with the right tools, pave the way for enhanced security and efficient system management.