Cómo configurar la autenticación NTLM en Windows mediante PowerShell

En un panorama de ciberseguridad en constante evolución, es primordial proteger las comunicaciones y el intercambio de datos. Uno de estos protocolos que ha sido objeto de debate es la autenticación NTLM (NT LAN Manager), que se utiliza para autenticar usuarios en entornos Microsoft. Con los recientes avances y la preocupación por la seguridad, se ha producido un cambio de las antiguas versiones de NTLM a la más segura NTLMv2. Hoy profundizaremos en un script de PowerShell que ayuda a gestionar las respuestas de autenticación NTLM mediante la configuración de LmCompatibilityLevel en el registro de Windows.

Antecedentes

Desarrollado originalmente como protocolo de autenticación por Microsoft, la autenticación NTLM ha sido objeto de varias actualizaciones para hacer frente a diversas vulnerabilidades de seguridad. Sin embargo, a medida que surgieron mecanismos de autenticación más seguros, especialmente NTLMv2, se hizo evidente la necesidad de restringir o desactivar las versiones anteriores. Este script ayuda a los profesionales de TI y a los proveedores de servicios gestionados (MSP) a realizar esta transición sin problemas, sin tener que navegar manualmente por complejas configuraciones del registro.

El script para configurar la autenticación NTLM en Windows

#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 {}

 

Análisis detallado

El script se divide esencialmente en tres fases: inicio, proceso y final.

• Fase de inicio: el script comienza con la definición de dos funciones:
• Test-IsElevated: comprueba si el script se ejecuta con privilegios de administrador.
• Set-ItemProp: crea o establece una propiedad de clave de registro.
• Fase del proceso: verifica que el usuario tiene derechos elevados. En caso contrario, se indica un error. De otra manear, pasa a modificar el LmCompatibilityLevel en dos posibles rutas del registro. Tras la modificación, el script confirma la configuración aplicada.
• Fase final: no se utiliza explícitamente, pero es un marcador de posición para posibles futuras actualizaciones o ampliaciones del script.

Posibles casos de uso

Estudio de caso: Imagina a Marta, administradora de TI en una empresa mediana. Recientemente se han sometido a una auditoría de seguridad que ha revelado que algunos sistemas siguen utilizando versiones de NTLM obsoletas. Con cientos de máquinas que gestionar, no es factible actualizar manualmente cada una de ellas. Usando este script, Marta actualiza sin problemas todos los sistemas, asegurándose de que sólo aceptan respuestas NTLMv2.

Comparaciones

Aunque la directiva de grupo también se puede utilizar para gestionar la configuración de NTLM en una organización, scripts de PowerShell, como el que tratamos en este post, ofrecen más granularidad y automatización. Pueden integrarse en herramientas de automatización o flujos de trabajo más amplios, agilizando el proceso y haciéndolo menos propenso a errores manuales.

FAQ

• ¿Cómo comprueba el script si se tienen privilegios de administrador?
  El script utiliza la función Test-IsElevated para determinar si se está ejecutando con derechos de administrador.
• ¿Qué ocurre si quiero establecer un valor de LmCompatibilityLevel diferente?
  Puedes hacerlo proporcionando el parámetro -LmCompatibilityLevel al ejecutar el script, por ejemplo, Disable-LmNtlmV1.ps1 -LmCompatibilityLevel 3.
• ¿Es compatible con versiones anteriores de Windows?
  El script es compatible con Windows 10 y Windows Server 2016 en adelante.

Implicaciones

Al establecer el LmCompatibilityLevel, los profesionales de TI dictan cómo los sistemas manejan la autenticación NTLM. La restricción a NTLMv2 mejora la seguridad, reduciendo los riesgos asociados a versiones más antiguas y menos seguras. Sin embargo, es crucial garantizar la compatibilidad, ya que los sistemas o aplicaciones más antiguos pueden tener problemas de conectividad tras los cambios.

Recomendaciones

• Haz siempre una copia de seguridad del estado actual del registro antes de realizar cambios.
• Primero, prueba el script en un entorno controlado para comprender su impacto.
• Mantente al día sobre las mejores prácticas de seguridad e intégralas en tus auditorías rutinarias.

Reflexiones finales

Mientras que los scripts PowerShell como estos permiten a los profesionales de TI mejorar la seguridad, las herramientas de supervisión y gestión como NinjaOne elevan aún más estas capacidades. Con supervisión, automatización e informes integrados, plataformas como NinjaOne garantizan que tu infraestructura de TI siga siendo sólida, segura y eficiente, complementando los scripts y las intervenciones manuales.

Recuerda que, en el ámbito de las TI, las medidas proactivas, combinadas con las herramientas adecuadas, allanan el camino hacia una mayor seguridad y una gestión eficaz del sistema.