MENU
  1. Início
  2. Windows
  3. Windows Server
  4. Erro no Windows Event Forwarding (WEF) — Event ID 105 / 0x80090322 (WinRM/Kerberos): diagnóstico e correção definitiva

Erro no Windows Event Forwarding (WEF) — Event ID 105 / 0x80090322 (WinRM/Kerberos): diagnóstico e correção definitiva

Windows Server

Event ID 105 no Windows Event Forwarding (WEF) acompanhado de erro WinRM/Kerberos pode travar o envio de logs ao coletor. Este guia ensina o diagnóstico e a correção definitiva ajustando o SPN usado pelo WinRM para “HOST”, eliminando falhas de autenticação.

Índice

Resumo do problema

Em um ambiente Windows Server 2019 com assinatura WEF ativa, o servidor source deixou de encaminhar eventos ao coletor. O log Microsoft-Windows-Forwarding/Operational registrava Event ID 105 com ErrorCode 2150858909 e mensagem de falha de autenticação Kerberos no WinRM (por exemplo, erros do tipo “unknown security error”). A causa mais comum é SPN incorreto/ausente para o serviço WinRM/WSMAN no objeto de computador do coletor.

Correção direta (definitiva)

Forçar o cliente WinRM no servidor‑origem a usar o SPN de tipo HOST em vez de WSMAN. Isso alinha a validação Kerberos com um SPN que sempre existe nas contas de computador, eliminando a lacuna de autenticação:

reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WSMAN\Client ^
    /v spnprefix /t REGSZ /d "HOST" /f

Após aplicar, reinicie o serviço WinRM (ou o servidor):

Restart-Service WinRM -Force
ou em CMD:
net stop winrm & net start winrm

Por que funciona? Por padrão, o WinRM monta o SPN como WSMAN/<FQDN>. Se esse SPN não estiver presente no objeto de computador do coletor (ou estiver duplicado em outra conta), o Kerberos falha. Ao definir spn_prefix="HOST", o cliente passa a solicitar HOST/<FQDN>, SPN que já existe por padrão em todas as contas‑máquina.

Entendendo a causa

O WEF utiliza o WinRM (WS-Management) como transporte. Em cenários “push”, o servidor‑origem autentica contra o coletor usando Kerberos. O Kerberos valida o nome do serviço por meio do SPN (Service Principal Name). Quando o SPN solicitado não corresponde ao que o KDC/AD conhece para aquele computador de destino, a autenticação falha e o encaminhamento de eventos é interrompido.

  • SPN esperado por padrão: WSMAN/<FQDN-do-coletor> (ou com porta, p.ex. :5985).
  • SPN sempre existente: HOST/<FQDN> e variações (HOST/<NetBIOS>), registrados automaticamente nas contas‑máquina.
  • Falhas típicas: SPN WSMAN ausente, duplicado ou vinculado ao objeto incorreto; DNS reverso inconsistentes; relógio fora de sincronia; fallback para NTLM bloqueado por política.

Sintomas usuais

  • Eventos Event ID 105 no log Microsoft-Windows-Forwarding/Operational do servidor‑origem informando falha de autenticação com código de erro WinRM/Kerberos.
  • Assinaturas WEF ficam em estado Retrying / Backoff.
  • Test-WSMan -ComputerName <coletor> -Authentication Kerberos falha.
  • Conectividade TCP (5985/5986) aparentemente OK, porém a sessão WinRM não se estabelece com Kerberos.

Guia de diagnóstico passo a passo

  1. Verificar nome e DNS
    • O FQDN do coletor resolve para o IP correto? nslookup <coletor>
    • Existe consistência entre nome NetBIOS e FQDN?
    • Conectividade às portas: Test-NetConnection <coletor> -Port 5985 (e 5986, se HTTPS).
  2. Checar hora e domínio (Kerberos exige sincronia < 5 min) w32tm /query /status echo %USERDNSDOMAIN%
  3. Listar SPNs no objeto de computador do coletor setspn -l <Coletor$> Procure por entradas WSMAN/<FQDN> e HOST/<FQDN>. Se WSMAN não existir, o Kerberos falhará quando o cliente solicitar esse SPN.
  4. Detectar SPN duplicado (causa clássica de falhas Kerberos) setspn -X -F Se houver duplicidades, remova a entrada da conta incorreta (setspn -d <SPN> <Conta>) e mantenha apenas no objeto correto.
  5. Testar a sessão WinRM com Kerberos # do servidor-origem klist purge Test-WSMan -ComputerName <ColetorFQDN> -Authentication Kerberos Falha com erro de “principal incorreto” ou genérico indica problema de SPN.
  6. Aplicar a correção recomendada (SPN HOST) reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WSMAN\Client ^ /v spnprefix /t REGSZ /d "HOST" /f net stop winrm & net start winrm Alternativa PowerShell: New-Item -Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WSMAN\Client' -Force | Out-Null New-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WSMAN\Client' -Name 'spn\_prefix' -PropertyType String -Value 'HOST' -Force | Out-Null Restart-Service WinRM -Force
  7. Validar o WEF # No coletor: wecutil es No source: wecutil gs "NomedaAssinatura" Monitore o log Microsoft-Windows-Forwarding/Operational (source) e Microsoft-Windows-EventCollector/Operational (collector).

Tabela de ações de diagnóstico e alternativas

PassoObjetivoComando / Ação
Verificar SPNs existentesConfirmar se o SPN WSMAN ou HOST está registradosetspn -l <Computador>
Registrar SPN WSMAN (se insistir em WSMAN)Mapear o SPN esperado ao objeto de computadorsetspn -s WSMAN/<Computador>:5985 <Computador>
Forçar SPN HOST (recomendado)Usar SPN sempre presente nas contas‑máquinareg add ... spn_prefix "HOST"
Testar autenticaçãoDiferenciar problema de Kerberos de outras falhasTest-WSMan -Authentication Kerberos
Habilitar Basic (temporário)Diagnóstico; confirmar que a pilha WinRM está funcionalwinrm set winrm/config/client/auth @{Basic="true"}
TrustedHosts ou HTTPSContorno de confiança quando SPN não fechawinrm set winrm/config/client @{TrustedHosts="Alvo"} ou configurar HTTPS
Conferir domínio e tempoGarantir condições mínimas do Kerberosw32tm /query /status

Validações pós‑correção

  • Do servidor‑origem, Test-WSMan -Authentication Kerberos -ComputerName <ColetorFQDN> deve passar.
  • O status da assinatura WEF volta a Active e os eventos começam a fluir (verifique o incremento do contador de entregas).
  • O log Microsoft-Windows-Forwarding/Operational deixa de registrar o Event ID 105.

Boas práticas de segurança e confiabilidade

  • Sincronização de hora: NTP consistente entre domínio, DCs, coletor e sources.
  • Rede: portas 5985 (HTTP) e, idealmente, 5986 (HTTPS) liberadas end‑to‑end. Em ambientes de produção, prefira HTTPS + Kerberos.
  • DNS: mantenha A/PTR corretos; evite apelidos (CNAME) que causem “principal incorreto” sem o SPN correspondente.
  • GPO: documente e aplique a criação do valor spn_prefix via Group Policy Preferences para padronizar máquinas novas.
  • Menor exposição: evite depender de TrustedHosts fora de lab; se precisar, combine com HTTPS, escopo restrito e auditoria.

Automatizando via GPO (Group Policy Preferences)

  1. Abra o Group Policy Management e edite uma GPO vinculada à OU de servidores‑origem.
  2. Navegue em Computer Configuration > Preferences > Windows Settings > Registry.
  3. Adicione um item Registry:
    • Action: Update
    • Hive: HKEYLOCALMACHINE
    • Key Path: SOFTWARE\Microsoft\Windows\CurrentVersion\WSMAN\Client
    • Value name: spn_prefix
    • Value type: REG_SZ
    • Value data: HOST
  4. Forçar atualização: gpupdate /force (ou reiniciar).

FAQ — Perguntas frequentes

Preciso criar o SPN WSMAN manualmente?

Não, se você adotar a estratégia de forçar “HOST” no cliente WinRM. O SPN HOST/<FQDN> já existe nas contas‑máquina e valida Kerberos corretamente. Se você optar por manter WSMAN/<FQDN>, então precisa garantir que ele esteja presente no objeto de computador correto (setspn -s ...) e sem duplicidades.

Usar HOST funciona com HTTPS?

Sim. O Kerberos valida o SPN independentemente do transporte ser HTTP ou HTTPS. Para HTTPS, garanta que o certificado do coletor contenha o FQDN (CN/SAN) e seja confiável pelos sources.

“unknown security error” sempre significa SPN?

Nem sempre. A mensagem genérica pode encapsular outras condições (tempo fora de sincronia, canal TLS, política de autenticação). Porém, no contexto de WEF com Event ID 105, SPN incorreto/ausente é o fator predominante. Siga o roteiro de diagnóstico deste artigo para isolar.

Posso conviver com NTLM?

Não é recomendado. Além de menos seguro, muitas organizações bloqueiam NTLM por política. O objetivo é manter Kerberos saudável com SPN correto.

Posso usar CNAME para o coletor?

É possível, mas exige que o SPN corresponda ao nome efetivamente usado na conexão. Se os clients conectam a wef.contoso.com (CNAME apontando para server01), o SPN deve refletir wef.contoso.com. Forçar “HOST” ajuda, desde que o HOST inclua o FQDN acessado.

Interpretação de códigos e logs (prática)

  • Event ID 105 (source): falha ao entregar eventos ao coletor. Inspecione ErrorCode (geralmente mostrado em decimal).
  • Para correlacionar, capture também no coletor o log Microsoft-Windows-EventCollector/Operational.
  • Dica: converta o valor decimal do ErrorCode para hexadecimal no PowerShell para facilitar a identificação do erro SSPI/Kerberos: # Exemplo de conversão genérica: $dec = <ErrorCodeDecimal> '0x{0:X}' -f $dec

Roteiro de correção “à prova de balas”

  1. Confirme DNS + conectividade (5985/5986): problemas de rede não devem mascarar a análise de Kerberos.
  2. Sane hora/domínio (NTP coerente; sem “clock skew”).
  3. Liste SPNs do coletor e remova duplicidades (setspn -X -F).
  4. Aplique spn_prefix=HOST no servidor‑origem e reinicie o WinRM.
  5. Valide com Test-WSMan -Authentication Kerberos e monitore os logs do WEF.

Alternativas temporárias (para diagnóstico)

  • TrustedHosts (HTTP): winrm set winrm/config/client @{TrustedHosts="Coletor"}. Útil para confirmar que o transporte está ok. Use apenas em lab ou com escopos estritos.
  • Basic + HTTPS: habilite Basic momentaneamente no client para isolar se o problema é somente Kerberos, mantendo o tráfego cifrado via HTTPS. Desabilite após o teste.

Impactos e compatibilidade

A abordagem do SPN HOST é compatível com Windows Server 2012 R2, 2016, 2019, 2022 e estações Windows 10/11. Ela não altera a segurança efetiva do Kerberos; apenas instrui o WinRM a solicitar um SPN que já existe e é confiável para o computador de destino.

Exemplos de comandos prontos

Verificar e criar SPN WSMAN (se necessário)

setspn -l COLETOR$
setspn -s WSMAN/coletor.dominio.tld COLETOR$
setspn -s WSMAN/coletor.dominio.tld:5985 COLETOR$

Forçar SPN HOST (recomendado)

New-Item -Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WSMAN\Client' -Force | Out-Null
New-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WSMAN\Client' `
  -Name 'spn_prefix' -PropertyType String -Value 'HOST' -Force | Out-Null
Restart-Service WinRM -Force

Testes e limpeza de credenciais Kerberos

klist
klist purge
Test-WSMan -ComputerName coletor.dominio.tld -Authentication Kerberos

Script de verificação rápida (PowerShell)

Use o snippet abaixo no servidor‑origem para conferir pré‑requisitos e aplicar o spn_prefix quando ausente:

# Verificação e fix automatizada para WEF/WinRM/Kerberos (SPN HOST)
$Key = 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WSMAN\Client'
if (-not (Test-Path $Key)) { New-Item -Path $Key -Force | Out-Null }
$val = (Get-ItemProperty -Path $Key -Name 'spnprefix' -ErrorAction SilentlyContinue).spnprefix
if ($val -ne 'HOST') {
    Write-Host 'Aplicando spn_prefix=HOST...'
    New-ItemProperty -Path $Key -Name 'spn_prefix' -PropertyType String -Value 'HOST' -Force | Out-Null
    Restart-Service WinRM -Force
} else {
    Write-Host 'spn_prefix já está definido como HOST.'
}
Teste opcional
$collector = '&lt;ColetorFQDN&gt;'
try {
    Test-WSMan -ComputerName $collector -Authentication Kerberos -ErrorAction Stop | Out-Null
    Write-Host "Conectividade WinRM/Kerberos OK com $collector"
} catch {
    Write-Warning $_.Exception.Message
}

Erros relacionados e como interpretá-los

Código (hex)ContextoInterpretação práticaRota de ação
0x80090322SSPI/KerberosNome principal do serviço incorreto (SPN não casa com o destino).Forçar HOST no cliente WinRM ou registrar WSMAN no objeto correto.
GenéricoWinRMMensagens como “unknown security error” podem mascarar problemas de SPN, tempo ou política.Seguir o roteiro de DNS/tempo/SPN; limpar tickets com klist purge.

Checklist final

  • DNS direto/reverso consistente para o coletor.
  • Tempo sincronizado (NTP) e membros no mesmo domínio/realms confiáveis.
  • Portas 5985/5986 liberadas e inspeções que não quebrem Kerberos.
  • Sem SPN duplicado para o coletor (setspn -X -F limpo).
  • spn_prefix=HOST aplicado nos sources (via script ou GPO).
  • Test-WSMan com Kerberos bem-sucedido.
  • Assinaturas WEF ativas e eventos fluindo.

Conclusão

O Event ID 105 no WEF com falhas WinRM/Kerberos é, na maioria dos casos, um sintoma de mapeamento SPN inconsistente entre o que o cliente pede e o que o AD conhece. A definição de spn_prefix="HOST" no cliente WinRM elimina essa discrepância sem sacrificar a segurança, pois utiliza um SPN nativo das contas de computador. Combine isso com boas práticas de DNS, tempo e rede, e seu pipeline de logs volta a fluir com estabilidade.

Nota de campo: embora seja possível “consertar” criando manualmente o SPN WSMAN/<FQDN> no objeto de computador do coletor, padronizar o uso de HOST tende a reduzir incidentes futuros — especialmente em ambientes com múltiplos aliases, balanceamento ou mudanças frequentes de nomes.

Windows Server
Event ID 105 Kerberos SPN WEF Windows Server WinRM
Índice