# Guia: NTLMv1 vs NTLMv2 — Política, Verificação e Como Habilitar/RestringIR/Permitir

NTLMv1 é um protocolo de autenticação antigo com vulnerabilidades conhecidas (captura de hash, pass-the-hash, relays). Ambientes modernos devem **desabilitar NTLMv1** e **forçar NTLMv2** sempre que possível. Este documento descreve: por que isso é importante, como auditar/consultar o estado atual em hosts/domínios e como aplicar mudanças (abrir compatibilidade ou reforçar para NTLMv2) via GPO e registro/PowerShell.

> <mark style="color:$danger;">Atenção: use com cautela; reinício remoto em produção pode interromper serviços.</mark>

***

### 1. Por que desabilitar NTLMv1 (pontos-chave)

* **Segurança**: NTLMv1 usa algoritmos fracos e é suscetível a captura de credenciais e ataques de replay/relay.
* **Conformidade**: muitas políticas de segurança e regras de auditoria exigem protocolos de autenticação robustos (NTLMv2 ou Kerberos).
* **Redução de risco**: desabilitar NTLMv1 reduz superfície de ataque, especialmente em redes com dispositivos legados e scanners/impressoras que expõem serviços.

> Recomendação: manter NTLMv1 **desabilitado em produção**; se necessário por compatibilidade, aplicar apenas em OUs ou hosts específicos e documentar o motivo.

***

### 2. Como consultar o status atual (host local)

#### 2.1 Verificar `LmCompatibilityLevel` (registro)

No host, abrir PowerShell como Administrador e rodar:

```powershell
# Ler valor atual
Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa' -Name LmCompatibilityLevel
```

Interpretação: `LmCompatibilityLevel` controla o comportamento LM/NTLM.

* `0` — envia LM & NTLM responses (muito permissivo)
* `1` — permite NTLMv1 (com NTLMv2 session security se negociado)
* `2` — envia apenas NTLM (permite NTLMv1; não LM)
* `3` — envia NTLMv2 response only; negociates NTLMv2 if supported (valor padrão em muitos sistemas)
* `4` — envia NTLMv2 response only. Refuse LM.
* `5` — **Send NTLMv2 response only. Refuse LM & NTLM (refuse NTLMv1)** — recomendado para forçar NTLMv2

> Observação: além do `LmCompatibilityLevel`, políticas “Restrict NTLM” podem negar tráfego mesmo quando `LmCompatibilityLevel` permite.

#### 2.2 Verificar políticas “Restrict NTLM” (local ou GPO)

* Abra `gpedit.msc` (máquina local) ou use o Group Policy Management para ver GPOs aplicados. Caminho:\
  `Computer Configuration → Windows Settings → Security Settings → Local Policies → Security Options`
* Itens relevantes:
  * **Network security: LAN Manager authentication level** (LmCompatibilityLevel equivalente)
  * **Network security: Restrict NTLM: Audit Incoming NTLM traffic**
  * **Network security: Restrict NTLM: Incoming NTLM traffic**
  * **Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers**
  * **Network security: Restrict NTLM: NTLM authentication in this domain**

#### 2.3 Auditar tentativas NTLM (Event Viewer)

* Event Viewer → `Applications and Services Logs → Microsoft → Windows → NTLM → Operational`.
* Habilite logs de auditoria via GPO se necessário para ver detalhes de uso, versão e origem de autenticações NTLM.

***

### 3. Como **habilitar/permissive (permitir NTLMv1)**

> Use apenas se necessário e em hosts/OU de teste. Documente e minimize o escopo.

#### 3.1 Via Registro / PowerShell (local)

Executar PowerShell como Administrador:

```powershell
# Definir para 0 (mais permissivo: envia LM & NTLM)
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa' -Name LmCompatibilityLevel -Value 0 -Type DWord

# Ou definir para 1 (permite NTLMv1; tenta NTLMv2 session security quando negociado)
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa' -Name LmCompatibilityLevel -Value 1 -Type DWord

# Ou definir para 2 (permite NTLMv1 sem LM)
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa' -Name LmCompatibilityLevel -Value 2 -Type DWord

# Reinicie a máquina
Restart-Computer
```

#### 3.2 Via GPO (domínio)

1. Abra o Group Policy Management Editor no GPO alvo.
2. Navegue até: `Computer Configuration → Policies → Windows Settings → Security Settings → Local Policies → Security Options`.
3. Edite **Network security: LAN Manager authentication level** e escolha uma das opções permissivas:
   * `Send LM & NTLM responses` (LmCompatibilityLevel = 0)
   * `Send LM & NTLM - use NTLMv2 session security if negotiated` (LmCompatibilityLevel = 1)
   * `Send NTLM response only` (LmCompatibilityLevel = 2)
4. Verifique também políticas `Network security: Restrict NTLM` para garantir que não hajam negações.

***

### 4. Como **restringir / forçar apenas NTLMv2** (recomendado)

#### 4.1 Via Registro / PowerShell (local)

```powershell
# Definir para 5 — Send NTLMv2 response only. Refuse LM & NTLM (recusa NTLMv1)
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa' -Name LmCompatibilityLevel -Value 5 -Type DWord
Restart-Computer
```

> Valor `5` força NTLMv2 e recusa NTLMv1; é a configuração desejada para endurecer.

#### 4.2 Via GPO (domínio)

1. No GPO alvo: `Computer Configuration → Policies → Windows Settings → Security Settings → Local Policies → Security Options`.
2. Configure **Network security: LAN Manager authentication level** → **Send NTLMv2 response only. Refuse LM & NTLM**.

#### 4.3 Políticas “Restrict NTLM” (controle granular)

* Para controle adicional, use as políticas em `Computer Configuration → Policies → Windows Settings → Security Settings → Local Policies → Security Options`:
  * **Network security: Restrict NTLM: Audit Incoming NTLM traffic** — primeiro habilite auditoria para identificar dependências.
  * Após validar, altere **Incoming NTLM traffic** para `Deny all domain accounts` (ou `Deny all accounts`) conforme o rollout.
  * Ajuste **Outgoing NTLM traffic to remote servers** e **NTLM authentication in this domain** conforme necessidade.

**Processo recomendado**: habilitar auditoria → coletar e corrigir dependências → aplicar deny/forçar NTLMv2.

***

### 5. Como verificar depois da mudança

1. Conferir `LmCompatibilityLevel` no host (PowerShell) — ver seção 3.1.
2. Conferir Event Viewer → `Microsoft → Windows → NTLM → Operational` para tentativas/rejeições.
3. Testar autenticação em aplicações críticas (impressoras, scanners, aplicações legadas, serviços web) em ambiente controlado.
4. Rodar scans de vulnerabilidade (ex.: Nessus) em hosts para confirmar ausência de suporte a NTLMv1.

***

### 6. Checklist de rollout seguro

* [ ] Habilitar auditoria NTLM (Restrict NTLM: Audit Incoming) em OU/pilot.
* [ ] Coletar logs por 1–2 semanas (ou conforme risco) e identificar dependências.
* [ ] Atualizar/patchar aplicações legadas com suporte NTLMv2/Kerberos quando possível.
* [ ] Planejar exceções documentadas apenas para hosts específicos.
* [ ] Aplicar `LmCompatibilityLevel = 5` via GPO em fases (OU pilot → OU produção).
* [ ] Monitorar logs e alertas por 30 dias após alteração.
* [ ] Documentar rollback (ex.: GPO revertido para LmCompatibilityLevel = 2) e motivos.

***

### 7. Riscos ao **habilitar NTLMv1** (resumo)

* Aumento substancial da superfície de ataque para captura de credenciais.
* Não atende a controles modernos de segurança e pode quebrar conformidade.
* Pode facilitar ataques de relay ou pass-the-hash.

***

### 8. Exemplo de comunicação interna (texto curto para anexar ao change request)

> **Change request:** Ajustar política de autenticação para `LmCompatibilityLevel = 5` (forçar NTLMv2). Justificativa: mitigar riscos de captura de credenciais e cumprir política de segurança. Testes serão realizados na OU `TEST-NTLM` por 14 dias antes do rollout em produção. Caso haja necessidade, exceções serão documentadas e aprovadas pelo time de segurança.

***

### 9. Scripts rápidos (para referência)

#### 9.1 Ler valor atual (PowerShell)

```powershell
Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa' -Name LmCompatibilityLevel
```

#### 9.2 Aplicar NTLMv2 apenas (local)

```powershell
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa' -Name LmCompatibilityLevel -Value 5 -Type DWord
Restart-Computer
```

#### 9.3 Aplicar permissivo (habilitar NTLMv1) — local

```powershell
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa' -Name LmCompatibilityLevel -Value 1 -Type DWord
Restart-Computer
```

#### 9.4 Script para aplicar em múltiplos hosts via Invoke-Command (exemplo)

```powershell
$hosts = @('host1','host2')
Invoke-Command -ComputerName $hosts -ScriptBlock {
    Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa' -Name LmCompatibilityLevel -Value 5 -Type DWord
    Restart-Computer -Force
}
```


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://wiki.datadike.com/product-guide/articles/estudo-de-caso-controlando-contas-do-ldap/guia-ntlmv1-vs-ntlmv2-politica-verificacao-e-como-habilitar-restringir-permitir.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.