O que quebra em um domínio do Windows se um membro tiver um desvio de tempo alto? [fechadas]

Question

Assume como garantido pela maioria das pessoas de TI que em um domínio do Windows, se o relógio de um servidor membro estiver desligado por mais de 5 minutos (ou quantos minutos você configurou) do seu controlador de domínio - logons e as autenticações falharão.

Mas isso não é necessariamente verdade. Pelo menos não para todos os processos de autenticação em todas as versões do Windows. Por exemplo, eu posso definir o meu tempo no meu cliente Windows 7 para ser distorcido tudo para heck - logoff / logon ainda funciona bem. O que acontece é que meu cliente envia um AS_REQ (com seu carimbo de data / hora) para o controlador de domínio e o DC responde com KRB_AP_ERR_SKEW. Mas a mágica é que quando o DC responde com o erro do Kerberos mencionado acima, o DC também inclui o seu carimbo de data / hora, que o cliente usa para ajustar seu próprio horário e reenviar o AS_REQ, que é aprovado .

Esse comportamento não é considerado uma ameaça à segurança porque a criptografia e os segredos ainda estão sendo usados na comunicação.

Isso também não é apenas uma coisa da Microsoft. RFC 4430 descreve esse comportamento.

Então, minha pergunta é que alguém sabe quando isso mudou? E por que outras coisas falham? Por exemplo, o Office Communicator me dá a partida se meu relógio começar a se afastar muito. Eu realmente gostaria de ter mais detalhes sobre isso.

edit: Aqui está a parte da RFC 4430 da qual estou falando:

If the server clock and the client clock are off by more than the
policy-determined clock skew limit (usually 5 minutes), the server
MUST return a KRB_AP_ERR_SKEW. The optional client's time in the
KRB-ERROR SHOULD be filled out. If the server protects the error by
adding the Cksum field and returning the correct client's time, the

client SHOULD compute the difference (in seconds) between the two
clocks based upon the client and server time contained in the
KRB-ERROR message. The client SHOULD store this clock difference and use it to adjust its clock in subsequent messages. If the error is
not protected, the client MUST NOT use the difference to adjust
subsequent messages, because doing so would allow an attacker to
construct authenticators that can be used to mount replay attacks.