Horário errado na rede: por que o NTP é crítico para sua empresa

O tempo é infraestrutura, mesmo que ninguém perceba

Quando se fala em infraestrutura de TI, quase todo mundo pensa em servidores, links de internet, firewall e backup. Pouca gente lembra do relógio. Mesmo assim, quase todo sistema corporativo parte do princípio de que o horário da máquina está certo. Login de usuário, emissão de nota fiscal, validação de certificado digital, autenticação em dois fatores e registro de auditoria dependem de um horário confiável e igual em todos os equipamentos da rede.

O NTP (Network Time Protocol) resolve esse problema. Ele mantém os relógios de servidores, estações, roteadores e dispositivos sincronizados com fontes de tempo de alta precisão. O protocolo usa a porta UDP 123 e é organizado em camadas chamadas stratum. O stratum 0 são relógios atômicos e receptores GPS. O stratum 1 são os servidores ligados diretamente a essas fontes. Cada nível abaixo sincroniza com o anterior. No Brasil, o NTP.br, mantido pelo NIC.br, oferece servidores públicos gratuitos alinhados à Hora Legal Brasileira.

O problema é que o relógio raramente falha de forma visível. Ele vai se desviando aos poucos: alguns segundos por dia num servidor físico, ou bem mais numa máquina virtual mal configurada. Um dia o desvio passa do limite que algum sistema tolera, e o sintoma aparece longe da causa. O usuário não consegue entrar, a nota é rejeitada ou o sistema acusa certificado inválido. Muitas vezes a equipe passa horas investigando senha, rede ou aplicação antes de olhar para o relógio.

O que quebra quando o relógio sai de sincronia

Horário errado é um problema silencioso porque seus efeitos aparecem em áreas sem ligação aparente. Estes são os impactos mais comuns que vemos em empresas:

• Autenticação Kerberos e Active Directory: se a estação estiver muito adiantada ou atrasada em relação ao controlador de domínio, o tíquete Kerberos é recusado. O usuário recebe falha de logon, os mapeamentos de rede não sobem e as políticas de grupo não são aplicadas. No log aparece o erro KRB_AP_ERR_SKEW.
• Certificados digitais e HTTPS: todo certificado tem data de início e de expiração. Uma máquina com a data errada pode considerar um certificado válido como "ainda não válido" ou "expirado". Isso quebra o acesso a sites, VPNs, e-mail e sistemas web internos.
• Autenticação multifator (MFA): códigos temporários como os do Microsoft Authenticator e do Google Authenticator são gerados em janelas de 30 segundos. Um servidor fora de sincronia rejeita códigos corretos, e o usuário fica bloqueado sem entender o motivo.
• Logs e investigação de incidentes: numa análise de segurança, é preciso reconstruir a sequência de eventos entre firewall, servidor, estação e nuvem. Se cada equipamento marca um horário diferente, a linha do tempo deixa de fazer sentido e a evidência perde valor, inclusive em apurações ligadas à LGPD.
• Documentos fiscais: a emissão de NF-e e NFC-e compara o horário informado com o horário da SEFAZ. Um servidor de emissão com relógio incoerente gera rejeições e atrasa o faturamento.
• Backups, agendamentos e replicação: rotinas agendadas rodam fora da janela prevista, a replicação de banco de dados e de arquivos pode resolver conflitos de forma errada e softwares de backup podem tratar versões recentes como antigas.

Em todos esses casos, o sintoma parece ser de outra área. Por isso, ao diagnosticar falhas intermitentes de autenticação ou de certificado, conferir o horário deve ser um dos primeiros passos.

Como o tempo funciona no Active Directory

Num domínio Windows, a sincronização de horário segue uma hierarquia pensada para que todos os computadores tenham o mesmo horário, ainda que esse horário não seja perfeito. As estações e os servidores membros sincronizam com um controlador de domínio. Os controladores de domínio sincronizam entre si. No topo fica o controlador que tem a função PDC Emulator no domínio raiz da floresta. Ele é a referência de tempo de toda a organização e deve ser o único configurado para consultar uma fonte externa confiável.

O serviço responsável é o Windows Time (w32time). Quando a hierarquia está correta, quase não precisa de manutenção. O problema surge quando alguém, tentando resolver um erro pontual, aponta um servidor qualquer para uma fonte externa, configura estações manualmente ou deixa o PDC Emulator sincronizando com o relógio do host de virtualização. Nesses casos, a rede passa a ter várias "verdades" de horário diferentes.

Por padrão, a política Kerberos do Active Directory tolera uma diferença máxima de 5 minutos entre o relógio do cliente e o do controlador de domínio. Acima disso, a autenticação falha. A solução correta é manter a hierarquia de tempo funcionando. Aumentar essa tolerância só esconde o problema e enfraquece a proteção contra ataques de repetição.

Para descobrir qual servidor é o PDC Emulator, use o comando netdom query fsmo num controlador de domínio. É nele que a configuração de fonte externa deve ser feita. Os outros controladores e os computadores do domínio devem continuar usando a hierarquia padrão.

Configurando o NTP corretamente, passo a passo

A configuração não é complicada, mas precisa ser feita na ordem certa e no equipamento certo. Este é o roteiro que usamos em ambientes Windows com Active Directory e servidores Linux:

1. Libere o tráfego NTP: confirme que o firewall de borda permite saída UDP 123 do PDC Emulator para os servidores NTP escolhidos. Sem isso, nenhuma configuração funciona.
2. Configure o PDC Emulator com fontes externas: no servidor que tem essa função, execute w32tm /config /manualpeerlist:"a.st1.ntp.br,0x8 b.st1.ntp.br,0x8 c.st1.ntp.br,0x8" /syncfromflags:manual /reliable:yes /update. Depois, reinicie o serviço com net stop w32time && net start w32time e force a sincronização com w32tm /resync /rediscover.
3. Valide a sincronização: o comando w32tm /query /status mostra a fonte atual, o stratum e a última sincronização bem-sucedida. Já w32tm /stripchart /computer:a.st1.ntp.br /samples:5 /dataonly mede o desvio em relação ao servidor externo.
4. Mantenha os demais equipamentos na hierarquia: nos outros controladores de domínio, servidores membros e estações, a fonte deve ser o próprio domínio. Se algum foi configurado manualmente, volte ao padrão com w32tm /config /syncfromflags:domhier /update e reinicie o serviço. Para conferir de onde cada máquina obtém o horário, use w32tm /query /source.
5. Configure os servidores Linux: em distribuições atuais, prefira o chrony. No arquivo de configuração, adicione linhas como server a.st1.ntp.br iburst nts para usar o NTS (Network Time Security), que autentica as respostas de tempo e é suportado pelo NTP.br. Valide com chronyc tracking e timedatectl, que deve mostrar "System clock synchronized: yes".
6. Não esqueça dos equipamentos de rede e virtualização: firewalls, switches, roteadores, storages e hosts de virtualização também precisam de NTP. Sem isso, os logs desses equipamentos ficam descasados do restante da rede.

Use sempre mais de uma fonte externa. Com três ou mais servidores, o algoritmo consegue descartar uma fonte com problema e manter a precisão. Uma fonte única é um ponto de falha: se ela ficar indisponível ou fornecer horário errado, toda a rede vai junto.

Armadilhas comuns que causam desvio de horário

Mesmo em ambientes bem administrados, alguns cenários causam desvio de horário com frequência. Conhecê-los evita boa parte dos chamados de "não consigo fazer login" que acontecem sem motivo aparente:

• Controlador de domínio virtualizado sincronizando com o host: no VMware e no Hyper-V, as ferramentas de integração podem ajustar o relógio da VM pelo relógio do host. Num controlador de domínio, principalmente no PDC Emulator, isso cria duas fontes de tempo em conflito. Desative a sincronização periódica com o host nesses servidores e revise os parâmetros avançados que forçam ajuste de horário em eventos como restauração de snapshot e migração entre hosts.
• Host de virtualização sem NTP: se o ESXi ou o Hyper-V estiver com horário errado, toda VM que depender dele herda o erro. Configure NTP em todos os hosts do cluster.
• Restauração de snapshot ou backup: ao voltar uma VM para um ponto anterior, o relógio pode voltar junto até a próxima sincronização. Em controladores de domínio, isso pode também causar inconsistências de replicação.
• Bateria do CMOS esgotada: em servidores e estações físicos, a bateria da placa-mãe mantém o relógio quando o equipamento está desligado. Quando ela acaba, a máquina liga com data antiga e pode falhar na autenticação antes de conseguir sincronizar.
• Fuso horário desatualizado: o NTP trabalha em UTC, e o fuso é aplicado pelo sistema operacional. O Brasil acabou com o horário de verão em 2019, e sistemas antigos sem atualização de fuso podem adiantar uma hora em datas que antes eram de horário de verão.
• GPOs conflitantes: políticas de grupo que configuram servidores NTP para todas as máquinas, inclusive estações, quebram a hierarquia do domínio e espalham fontes inconsistentes pela rede.

A forma mais segura de evitar essas surpresas é monitorar. Ferramentas como o Zabbix podem acompanhar o desvio de horário dos servidores e alertar quando ele passa de um limite definido, por exemplo 30 segundos, bem antes de chegar aos 5 minutos que interrompem a autenticação. Assim, o problema é tratado antes de afetar os usuários.

Horário confiável como parte da gestão de TI

Sincronizar o horário parece um detalhe pequeno, mas cuidar dele mostra o grau de maturidade da gestão de TI. Empresas que tratam o NTP como parte da infraestrutura, com hierarquia documentada, fontes redundantes, monitoramento ativo e revisão após cada mudança no ambiente virtual, praticamente deixam de ter falhas de autenticação intermitentes. Também têm logs confiáveis para auditoria e investigação de incidentes.

Na Duk Informática & Cloud, a sincronização de tempo faz parte do checklist de implantação e de revisão periódica de todos os ambientes que administramos. Com mais de 18 anos de experiência e mais de 550 empresas atendidas, sabemos que muitos problemas difíceis de diagnosticar começam em configurações básicas como essa. Como Microsoft Gold Partner, cuidamos de ponta a ponta de Active Directory, virtualização, data center próprio em Alphaville e monitoramento contínuo com SLA.

Se sua empresa tem quedas de login sem explicação, erros de certificado ou rejeições de nota fiscal sem causa clara, vale começar pelo relógio. A equipe da Duk pode avaliar seu ambiente, corrigir a hierarquia de tempo e deixar o monitoramento ativo para que o problema não volte.