Em um cenário de segurança cibernética em constante evolução, é fundamental proteger as comunicações e a troca de dados. Um desses protocolos que tem sido um ponto focal de discussão é o NTLM (NT LAN Manager), que é usado para autenticar usuários em ambientes Microsoft. Com os recentes avanços e preocupações com a segurança, houve uma mudança das versões mais antigas do NTLM para o NTLMv2, mais seguro. Hoje, vamos nos aprofundar em um script do PowerShell que ajuda a gerenciar as respostas de autenticação NTLM, definindo o LmCompatibilityLevel no registro do Windows.
Histórico
Originalmente desenvolvido como um protocolo de autenticação pela Microsoft, o NTLM passou por várias atualizações para solucionar diversas vulnerabilidades de segurança. No entanto, com o surgimento de mecanismos de autenticação mais seguros, especialmente o NTLMv2, ficou evidente a necessidade de restringir ou desativar as versões mais antigas. Esse script ajuda os profissionais de TI e os provedores de serviços gerenciados (MSPs) a fazer essa transição sem problemas, sem precisar navegar manualmente por configurações complexas do registro.
O roteiro
#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 {}
Acesse mais de 300 scripts no NinjaOne Dojo
Detalhamento
O roteiro é essencialmente dividido em três fases: início, processo e fim.
- Iniciar fase: O script começa com a definição de duas funções:
- Test-IsElevated: Verifica se o script é executado com privilégios de administrador.
- Set-ItemProp: Cria ou define uma propriedade de chave de registro.
- Fase do processo: Ele verifica se o usuário tem direitos elevados. Caso contrário, um erro é sinalizado. Caso contrário, ele modifica o LmCompatibilityLevel em dois possíveis caminhos de registro. Após a modificação, o script confirma a configuração aplicada.
- Fase final: Não é usado explicitamente, mas é um espaço reservado para possíveis atualizações ou extensões futuras do script.
Casos de uso em potencial
Estudo de caso: Imagine Jenny, uma administradora de TI em uma organização de médio porte. Recentemente, eles passaram por uma auditoria de segurança, revelando que alguns sistemas ainda usam versões desatualizadas do NTLM. Com centenas de máquinas para gerenciar, não é possível atualizar manualmente cada uma delas. Usando esse script, Jenny atualiza sem problemas todos os sistemas, garantindo que eles aceitem apenas respostas NTLMv2.
Comparações
Embora a Política de Grupo também possa ser usada para gerenciar as configurações NTLM em uma organização, os scripts do PowerShell, como o discutido, oferecem mais granularidade e automação. Elas podem ser integradas a ferramentas de automação ou fluxos de trabalho maiores, tornando o processo simplificado e menos propenso a erros manuais.
Implicações
Ao definir o LmCompatibilityLevel, os profissionais de TI determinam como os sistemas lidam com a autenticação NTLM. A restrição ao NTLMv2 aumenta a segurança, reduzindo os riscos associados a versões mais antigas e menos seguras. No entanto, é fundamental garantir a compatibilidade, pois sistemas ou aplicativos mais antigos podem enfrentar problemas de conectividade após as alterações.
Recomendações
- Sempre faça backup do estado atual do registro antes de fazer alterações.
- Inicialmente, teste o script em um ambiente controlado para entender seu impacto.
- Mantenha-se informado sobre as práticas recomendadas de segurança mais recentes e integre-as em suas auditorias de rotina.
Considerações finais
Embora scripts do PowerShell como esses capacitem os profissionais de TI a aprimorar a segurança, ferramentas de monitoramento e gerenciamento como o NinjaOne elevam ainda mais esses recursos. Com monitoramento, automação e relatórios integrados , plataformas como o NinjaOne garantem que sua infraestrutura de TI permaneça robusta, segura e eficiente, complementando scripts e intervenções manuais.
Lembre-se de que, no âmbito da TI, as medidas proativas, combinadas com as ferramentas certas, abrem caminho para uma segurança aprimorada e um gerenciamento eficiente do sistema.