SMB Signing Obrigatório: Preparar a Rede Antes do Enforcement

O sintoma que este artigo resolve: após actualizar clientes para Windows 11 24H2 ou servidores para Windows Server 2025, partilhas de rede em NAS antigos, impressoras de rede ou appliances com Samba antigo deixam de abrir, com erros 0xc000a000 (STATUS_INVALID_SIGNATURE) ou 0x80070035 (caminho não encontrado). A causa: a Microsoft tornou o SMB signing obrigatório por defeito — Windows 11 24H2 Enterprise/Pro/Education exige assinatura nas duas direcções, e Windows Server 2025 exige assinatura outbound. Dispositivos que não assinam ficam fora. A resolução é auditada em duas frentes: identificar quem assina e quem não assina antes da actualização, e corrigir ou isolar os dispositivos que falham.

⚠ Atenção: desactivar o SMB signing nos clientes para “resolver” o problema devolve a rede ao estado pré-24H2 — sem protecção contra ataques de relay e spoofing. A Microsoft não recomenda este caminho (Control SMB signing behavior). Corrige o dispositivo, não desactives a assinatura.

Neste artigo

O que Está a Acontecer — O que muda com o SMB signing por defeito

O SMB signing anexa a cada mensagem SMB uma assinatura criptográfica calculada com a chave de sessão e o cipher suite negociado. A assinatura cobre o hash da mensagem completa, incluindo as identidades de origem e destino. Se alguém alterar a mensagem em trânsito, o hash não coincide e a ligação é rejeitada — é a defesa contra ataques de relay e tampering no protocolo SMB.

O que muda nos sistemas recentes é o requisito por defeito. O Windows 11 24H2 nas edições Enterprise, Pro e Education passa a exigir assinatura nas duas direcções (outbound e inbound). O Windows Server 2025 exige assinatura outbound (tráfego que ele envia como cliente). Só o Windows 11 24H2 Home fica fora da exigência. Uma ligação a um servidor que não assina — tipicamente um NAS com SMB1/SMB2 antigo ou uma impressora multifunções — é recusada no estabelecimento da sessão, com erros que aparentam “partilha inexistente” mas que são, na verdade, falhas de negociação de assinatura (SMB signing overview).

O impacto prático em PMEs está nos dispositivos que ninguém associa a SMB: NAS antigos, copiadoras que fazem scan-to-folder, appliances de backup e routers com Samba. São justamente os que ficam de fora quando o enforcement chega. A recomendação de base da Microsoft para maximizar a eficácia: usar Kerberos em vez de NTLMv2, não ligar por endereço IP e não usar registos CNAME para apontar partilhas (Control SMB signing behavior).

Cenários em que Este Problema Aparece

  • Frota mista Windows 11 23H2 → 24H2 — a actualização de funcionalidades activa o requisito sem aviso explícito nos dispositivos que ligavam a NAS sem assinatura.
  • Scan-to-folder em multifunções — a impressora enviava para uma partilha Windows. Com inbound signing exigido pelo Windows 11/Server 2025, o scan falha.
  • NAS de marca antiga (firmware pré-2018 sem SMB signing) — o mapeamento de rede deixa de ligar com 0xc000a000.
  • Servidores de ficheiros Windows Server 2019/2016 — continuam a funcionar como servidores. Mas quando o cliente 24H2 liga, ambos os lados têm de negociar assinatura. Se o lado antigo a desactivou por GPO herdada, falha.
  • Backups por partilha de rede — jobs de backup que apontam a UNC paths de appliances sem assinatura quebram silenciosamente após a actualização.

Passo 1 — Auditar o Estado Actual do SMB Signing

Antes de qualquer actualização de frota, mapeia o estado actual: que clientes exigem assinatura, que servidores a oferecem e onde estão as ligações sem assinatura.

No cliente Windows (PowerShell como administrador):

# Estado da configuração do cliente e do servidor SMB
Get-SmbClientConfiguration | Select-Object RequireSecuritySignature
Get-SmbServerConfiguration | Select-Object RequireSecuritySignature

O primeiro cmdlet mostra se o cliente exige assinatura outbound (RequireSecuritySignature = True ou False). O segundo mostra o mesmo para as ligações inbound que o servidor aceita. Nas máquinas 24H2 Enterprise/Pro, ambos devolvem True por defeito — é o enforcement activo.

Para ver as ligações activas e se estão assinadas:

Get-SmbConnection | Select-Object ServerName, ShareName, Signed

O Get-SmbConnection lista as sessões SMB activas do cliente. A coluna Signed é o dado crítico: False numa ligação a um NAS ou appliance identifica exactamente o dispositivo que vai falhar após o enforcement. Corre este comando nos PCs com mais usos de partilhas e guarda o resultado — é o inventário do problema.

Passo 2 — Identificar Dispositivos que Falham

O Event Viewer dá a auditoria do lado cliente. Não existe um evento de “assinatura rejeitada” no cliente: a falha surge como o erro 0xc000a000 (STATUS_INVALID_SIGNATURE) na própria ligação. O que existe é auditoria dedicada: active-a no cliente e os servidores que não assinam ficam registados no canal SMBClient/Audit (eventos 31998 e 31999):

Set-SmbClientConfiguration -AuditServerDoesNotSupportSigning $true
Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-SMBClient/Audit'; Id=31998,31999} `
  -MaxEvents 50 | Select-Object TimeCreated, Message

A primeira linha activa a auditoria (exige Windows 11 24H2 ou Server 2025 no cliente); a segunda lê os últimos 50 eventos de auditoria. Cada evento identifica o servidor que não suporta assinatura. Se houver eventos, os dispositivos listados são quem precisa de correcção antes do enforcement. Em builds anteriores a 24H2, a alternativa é tentar a ligação e ler o erro: 0xc000a000 significa assinatura recusada pelo servidor (a resolver no dispositivo), enquanto o evento 31017 no canal SMBClient/Security indica um problema diferente — rejeição de logon guest inseguro, que se resolve autenticando com credenciais reais em vez de activar o guest.

Do lado do servidor (nos NAS e appliances, quando o firmware o permite), activa o SMB signing no próprio dispositivo. Nos NAS Synology: Control Panel > File Services > SMB > Advanced > Minimum SMB protocol version + activar assinatura. Em Samba (Linux): server signing = mandatory no smb.conf.

Se um dispositivo não tem qualquer opção de assinatura (firmware antigo), as saídas são: actualizar firmware, substituir o dispositivo, ou migrar o fluxo para um caminho alternativo (ex.: scan-to-email em vez de scan-to-folder).

Passo 3 — Corrigir ou Compensar Cada Falha

Para cada dispositivo identificado no Passo 2, ordena as opções por preferência:

  1. Activar signing no dispositivo — NAS/appliance com firmware que suporte assinatura mas não a exija. É a correcção limpa: nenhum cliente muda de configuração.
  2. Actualizar firmware — muitos fabricantes acrescentaram SMB signing em versões de firmware de 2020+. Verifica o changelog do fabricante.
  3. Mudar o fluxo de trabalho — scan-to-folder → scan-to-email ou upload por web. Elimina o SMB do problema.
  4. Substituir o dispositivo — quando o firmware é fim-de-vida, o dispositivo está no fim do ciclo de suporte.

O caminho inverso — desactivar assinatura no cliente 24H2 para “aceitar” o dispositivo antigo — funciona tecnicamente mas deixa a rede exposta a relay attacks e é explicitamente desaconselhado pela Microsoft:

# NÃO RECOMENDADO — apenas como último recurso temporário, documentado e com prazo
Set-SmbClientConfiguration -RequireSecuritySignature $false
Set-SmbServerConfiguration -RequireSecuritySignature $false

O primeiro cmdlet desliga a exigência de assinatura nas ligações outbound do cliente. O segundo desliga no servidor (inbound). Se os usares, documenta o motivo, o dispositivo envolvido e uma data para reverter — e reactiva com Set-SmbClientConfiguration -RequireSecuritySignature $true quando o dispositivo for corrigido ou substituído.

Passo 4 — Aplicar o Enforcement por Fases

Em PMEs com servidores de ficheiros Windows, o enforcement server-side controla-se por GPO em Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options > Microsoft network server: Digitally sign communications (always), ou por PowerShell no servidor:

# No servidor de ficheiros — exigir assinatura inbound
Set-SmbServerConfiguration -RequireSecuritySignature $true -Force
# No cliente (se aplicável — 24H2 já vem assim)
Set-SmbClientConfiguration -RequireSecuritySignature $true -Force

O Set-SmbServerConfiguration -RequireSecuritySignature $true força o servidor a recusar sessões sem assinatura. O -Force evita o prompt de confirmação. Aplica primeiro num servidor de teste com clientes de teste, monitoriza os eventos 31998/31999 no SMBClient/Audit durante uma semana, e só depois sobe para produção via GPO (a GPO dá rollback centralizado; o cmdlet local, não).

A sequência recomendada para uma PME:

  1. Auditar (Passos 1-2) — inventário de ligações Signed = False.
  2. Corrigir dispositivos (Passo 3) — firmware ou substituição.
  3. Enforcement no servidor de ficheiros principal via GPO.
  4. Actualizar clientes para 24H2 em vagas, activando a auditoria de assinatura e monitorizando os eventos 31998/31999.
  5. Server 2025 por último — o requisito outbound activa-se com a actualização e não tem GPO de recuo razoável.

Erros Comuns

Problema Causa provável Solução
0xc000a000 STATUS_INVALID_SIGNATURE ao abrir partilha Servidor assina mas com cipher incompatível Actualizar firmware do dispositivo ou alinhar cipher suites
Partilha “não existe” (0x80070035) após upgrade para 24H2 NAS sem SMB signing rejeitado pelo cliente Corrigir o NAS (Passo 3) — o erro mascara a falha de assinatura
Scan-to-folder falha após actualização do servidor Multifunções não assina e o servidor exige inbound Activar assinatura na impressora ou mudar para scan-to-email
Guest access deixa de funcionar Requerir signing desactiva guest access por definição Migrar para contas reais; guest + signing são mutuamente exclusivos
Ligações via CNAME falham com signing activo Assinatura calculada sobre SPN do CNAME Usar netdom computername /add em vez de CNAME (recomendação Microsoft)

Checklist Rápido de Verificação

  • Inventário de ligações SMB com Get-SmbConnection (coluna Signed) documentado.
  • Sem eventos novos 31998/31999 no SMBClient/Audit após a actualização.
  • NAS e impressoras com assinatura activada ou firmware actualizado.
  • GPO “Digitally sign communications (always)” activa nos servidores de ficheiros.
  • Sem desactivações de signing no cliente — verificar RequireSecuritySignature = True.
  • Kerberos em uso (sem NTLMv2 nas partilhas críticas) e ligações por nome, não por IP.

Artigos Relacionados