PowerShell : comment définir l’authentification NTLM dans Windows

Dans un contexte de cybersécurité en constante évolution, il est primordial de sécuriser les communications et les échanges de données. Le protocole NTLM (NT LAN Manager), utilisé pour authentifier les utilisateurs dans les environnements Microsoft, est l’un de ceux qui ont fait l’objet de discussions. Avec les progrès récents et les préoccupations en matière de sécurité, les anciennes versions de NTLM ont été remplacées par la version plus sûre NTLMv2. Aujourd’hui, nous allons étudier un script PowerShell qui permet de gérer les réponses d’authentification NTLM en définissant le niveau de compatibilité LmCompatibilityLevel dans le registre Windows.

Contexte

Développé à l’origine comme protocole d’authentification par Microsoft, NTLM a fait l’objet de plusieurs mises à jour pour remédier à diverses failles de sécurité. Cependant, avec l’apparition de mécanismes d’authentification plus sûrs, notamment NTLMv2, la nécessité de restreindre ou de désactiver les anciennes versions est devenue évidente. Ce script aide les professionnels de l’informatique et les fournisseurs de services gérés (MSP) à effectuer cette transition en douceur, sans avoir à naviguer manuellement dans des paramètres de registre complexes.

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

 

Description détaillée

Le script est divisé en trois phases : le début (begin), le processus (process) et la fin (end).

• Phase de début : Le script commence par définir deux fonctions :
• Test-IsElevated : Vérifie si le script s’exécute avec des privilèges d’administrateur.
• Set-ItemProp : Crée ou définit une propriété de clé de registre.
• Phase de processus : Vérifie que l’utilisateur dispose de droits élevés. Si ce n’est pas le cas, une erreur est signalée. Si c’est le cas, cette phase modifie le niveau de compatibilité (LmCompatibilityLevel) dans deux chemins d’accès potentiels du registre. Après la modification, le script confirme le paramètre appliqué.
• Phase de fin : Elle n’est pas explicitement utilisée, mais il s’agit d’un espace réservé pour d’éventuelles mises à jour ou extensions du script.

Cas d’utilisation potentiels

Étude de cas : Imaginez Adeline, administratrice informatique dans une entreprise de taille moyenne. Cette dernière a récemment fait l’objet d’un audit de sécurité qui a révélé que certains systèmes utilisaient encore des versions NTLM obsolètes. Avec des centaines de machines à gérer, impossible de toutes les mettre à jour manuellement. À l’aide de ce script, Adeline met à jour tous les systèmes de manière fluide, en s’assurant qu’ils n’acceptent que les réponses NTLMv2.

Comparaisons

Bien que la stratégie de groupe puisse également être utilisée pour gérer les paramètres NTLM au sein d’une organisation, les scripts PowerShell, comme celui présenté ici, offrent davantage de précision et d’automatisation. Ils peuvent être intégrés à des outils d’automatisation ou à des flux de travail plus importants, ce qui permet de rationaliser le processus et de réduire le risque d’erreurs manuelles.

FAQ

• Comment le script vérifie-t-il l’existence de privilèges d’administrateur ?
  Le script utilise la fonction Test-IsElevated pour déterminer s’il s’exécute avec des droits d’administrateur.
• Que faire si je veux définir une valeur différente pour LmCompatibilityLevel ?
  Vous pouvez le faire en indiquant le paramètre -LmCompatibilityLevel lors de l’exécution du script, par exemple Disable-LmNtlmV1.ps1 -LmCompatibilityLevel 3.
• Est-il rétrocompatible avec les anciennes versions de Windows ?
  Le script prend en charge Windows 10 et Windows Server 2016 et les versions ultérieures.

Implications

En définissant le niveau de compatibilité LmCompatibilityLevel, les professionnels de l’informatique déterminent la manière dont les systèmes gèrent l’authentification NTLM. Le fait de se limiter à NTLMv2 améliore la sécurité et réduit les risques associés aux versions plus anciennes et moins sûres. Toutefois, il est essentiel de veiller à la compatibilité, car les anciens systèmes ou applications peuvent être confrontés à des problèmes de connectivité après les changements.

Recommandations

• Sauvegardez toujours l’état actuel du registre avant d’effectuer des modifications.
• Dans un premier temps, testez le script dans un environnement contrôlé afin de comprendre son impact.
• Restez informé des bonnes pratiques de sécurité les plus récentes et intégrez-les dans vos audits de routine.

Conclusion

Si les scripts PowerShell de ce type permettent aux professionnels de l’informatique de renforcer la sécurité, des outils de surveillance et de gestion tels que NinjaOne améliorent encore ces capacités. Grâce à la surveillance, à l’automatisation et au reporting, des plateformes comme NinjaOne garantissent que votre infrastructure informatique reste performante, sécurisée et efficace, en complément des scripts et des interventions manuelles.

N’oubliez pas que dans le domaine de l’informatique, les mesures proactives, associées aux bons outils, ouvrent la voie à une sécurité accrue et à une gestion efficace des systèmes.