Exportar (0) Imprimir
Expandir Tudo

Apêndice B: Como funciona o processo de autenticação com RODCs

Atualizado: maio de 2009

Aplica-se a: Windows Server 2008

O cenário a seguir ajuda a explicar como funciona o processo de autenticação com RODCs. Neste cenário:

  • O usuário Bob quer fazer logon em uma estação de trabalho chamada BOB_WS.

  • A sub-rede na qual a estação de trabalho BOB_WS está instalada é atendida por um RODC.

  • A conta de usuário de BOB tem permissão para armazenar credenciais em cache no RODC, mas as credenciais ainda não estão armazenadas.

  • A conta de computador de BOB tem permissão para armazenar credenciais em cache no RODC, mas as credenciais ainda não estão armazenadas.

Bob tenta fazer logon na estação de trabalho BOB_WS. Primeiro, o TGT deve ser recuperado no controlador de domínio. O processo de recuperação do TGT neste cenário é mostrado na ilustração a seguir.

56b3c0af-fc60-4dd5-a041-d3d3ac6248c5
  1. O RODC é anunciado como o KDC da filial. Isso significa que quando BOB_WS procura um controlador de domínio para autenticar a solicitação de logon de Bob, ele localiza e usa o RODC como um KDC. O pacote de autenticação Kerberos de BOB_WS prepara uma solicitação de TGT e a envia ao RODC.

  2. O RODC recebe a solicitação de TGT de BOB_WS. Como o RODC não sabe a senha da conta do Bob, ele não consegue criar o TGT para ele. O RODC encaminha a solicitação de TGT a um controlador de domínio gravável do Windows Server 2008.

  3. O controlador de domínio gravável do Windows Server 2008 autentica a solicitação.

  4. O resultado é retornado ao RODC. Se Bob fornecer as credenciais corretas, o resultado será um TGT. Se a validação das credenciais de Bob falhar, o resultado será uma mensagem de erro. Neste cenário, se Bob inserir um nome de usuário e uma senha válidos ao fazer logon, a validação será bem-sucedida.

  5. Simultaneamente ao retorno do TGT para o RODC, o controlador de domínio gravável também adiciona o nome distinto (também conhecido como DN) da conta de Bob ao atributo msDS-AuthenticatedToAccountList da conta de computador do RODC. Isso cria um registro de que Bob foi autenticado pelo RODC.

  6. Em seguida, o RODC passa o resultado para BOB_WS.

  7. Depois de o RODC enviar o TGT novamente a BOB_WS, ele também pede para o controlador de domínio gravável replicar as credenciais do Bob em sua réplica do banco de dados do Active Directory.

  8. Quando o controlador de domínio gravável recebe a solicitação de replicação das credencias de Bob no RODC, ele consulta a Diretiva de Replicação de Senha para ver se o RODC tem permissão para armazenar em cache as credenciais da conta do Bob.

  9. Se a verificação indicar que as credenciais podem ser armazenadas em cache, o controlador de domínio gravável permitirá a replicação das credenciais da conta do Bob no RODC.

  10. Simultaneamente ao envio das credenciais solicitadas pelo RODC, o controlador de domínio gravável grava o nome distinto da conta de Bob no atributo msDS-RevealedList da conta de computador do RODC. Isso cria um registro de que as credenciais da conta do Bob agora estão armazenadas em cache no RODC.

  11. O RODC armazena as credenciais do Bob nos atributos apropriados da conta de usuário dele, no banco de dados do Active Directory.

Neste momento:

  • O controlador de domínio gravável tem um registro de que permitiu a replicação das credenciais do Bob no RODC.

  • As credenciais da conta do Bob foram armazenadas em cache no RODC.

  • Bob tem o TGT que foi gerado pelo controlador de domínio gravável.

Em seguida, Bob precisa obter um tíquete de serviço de BOB_WS para poder trabalhar nela, como mostra a ilustração a seguir.

b5576794-3589-4fc5-aab1-857b9befcc39
  1. BOB_WS envia a solicitação de tíquete de serviço de Bob ao RODC. A solicitação contém o TGT que foi emitido pelo controlador de domínio gravável.

  2. O RODC não sabe a senha da conta krbtgt comum que os controladores de domínio graváveis usam; portanto, ele precisa encaminhar as solicitações de tíquete de serviço para um controlador de domínio gravável. Mas o RODC tem as credenciais de Bob armazenadas em cache; portanto, ele pode atender às solicitações de tíquetes de serviço de Bob. Como resultado, depois de o controlador de domínio gravável responder com êxito à solicitação encaminhada, o RODC retorna uma mensagem de erro de Kerberos, em vez de retornar o tíquete de serviço solicitado, à BOB_WS. Essa mensagem de erro indica que o TGT que Bob usou na solicitação de tíquete de serviço não é mais válido e que um novo deve ser emitido.

  3. Depois de receber essa mensagem de erro, BOB_WS descarta o TGT emitido pelo controlador de domínio gravável e solicita um novo ao RODC.

  4. O RODC tem as credenciais de Bob armazenadas em cache; portanto, ele prepara um TGT e o assina com a senha da própria conta krbtgt.

  5. Em seguida, o RODC envia o novo TGT novamente à BOB_WS.

  6. BOB_WS envia a solicitação de tíquete de serviço ao RODC novamente. Agora, a solicitação de tíquete de serviço contém o TGT que foi emitido pelo RODC.

  7. O RODC processa a solicitação de tíquete de serviço. Como ele não tem as credenciais de conta de computador de BOB_WS armazenadas em cache, não pode criar o tíquete de serviço. Ele precisa encaminhar a solicitação de tíquete de serviço a um controlador de domínio gravável.

  8. O controlador de domínio gravável recebe a solicitação de tíquete de serviço do RODC. O controlador de domínio gravável:

    1. Valida o TGT. (O controlador de domínio gravável pode validar o TGT porque ele sabe a senha da conta krbtgt específica do RODC.)

    2. Determina se a Diretiva de Replicação de Senha permite ao RODC armazenar em cache as credenciais da conta do Bob. O RODC tem permissão para criar TGTs apenas das contas cujas credenciais podem ser armazenadas em cache.

    3. Avalia a associação da conta do Bob e prepara uma parte do Certificado de Autenticação de Privilégios (PAC) do tíquete de serviço. Ele não usa a parte do PAC do TGT que foi preparada pelo RODC. Isso evita a elevação dos privilégios, caso o RODC esteja comprometido e coloque informações falsas na parte do PAC do TGT.

  9. O controlador de domínio gravável cria um tíquete de serviço e envia-o de volta ao RODC.

  10. Em seguida, o RODC encaminha o tíquete de serviço para a BOB_WS.

  11. Bob pode começar a trabalhar na BOB_WS.

  12. Depois de o RODC enviar o tíquete de serviço novamente a BOB_WS, ele também pede para o controlador de domínio gravável replicar as credenciais da BOB_WS em sua réplica do banco de dados do Active Directory.

  13. Quando o controlador de domínio ascendente recebe a solicitação de replicação das credencias da conta de BOB_WS no RODC, ele consulta a Diretiva de Replicação de Senha para determinar se o RODC tem permissão para armazenar em cache as credenciais da conta de BOB_WS.

  14. Se as credenciais forem armazenadas em cache, o controlador de domínio gravável permitirá a replicação das credenciais da conta de BOB_WS no RODC.

  15. Simultaneamente ao envio das credenciais solicitadas pelo RODC, o controlador de domínio gravável grava o nome distinto da conta de BOB_WS no atributo msDS-RevealedList da conta de computador do RODC. Isso cria um registro de que as credenciais de BOB_WS agora estão armazenadas em cache no RODC.

  16. O RODC armazena as credenciais do computador BOB_WS nos atributos apropriados da conta de computador dele, no banco de dados do Active Directory.

Neste momento:

  • Bob está conectado à estação de trabalho BOB_WS e pode solicitar um tíquete de serviço para acessar recursos localizados nos servidores, da mesma maneira que solicitou tíquetes de serviço para sua própria estação de trabalho.

  • Se algum dos computadores que Bob acessa tiver permissão para armazenar credenciais em cache no RODC, ele fará isso durante o processamento de uma solicitação de tíquete de serviço.

  • O RODC armazena em cache as credenciais da conta de computador de BOB_WS.

  • O controlador de domínio gravável cria um registro de que revelou as credenciais da conta de computador de BOB_WS para o RODC.

Quando BOB tentar fazer logon novamente na estação de trabalho BOB_WS, o RODC não precisará contatar o controlador de domínio gravável para processar a solicitação de logon, pois ele já terá em cache as credenciais da conta do Bob e da conta da BOB_WS, como mostra a ilustração a seguir.

9384fbc6-340b-4204-a9c8-57633bcbb854
  1. O RODC é anunciado como o KDC da filial. Isso significa que quando BOB_WS procura um controlador de domínio para autenticar a solicitação de logon de Bob, ele localiza e usa o RODC como um KDC. O pacote de autenticação Kerberos de BOB_WS prepara uma solicitação de TGT e a envia ao RODC.

  2. O RODC recebe a solicitação de TGT de BOB_WS. Como ele já sabe a senha da conta do Bob, pode criar o TGT para ele. O RODC usa a própria conta krbtgt ao criar o TGT.

  3. O RODC envia o TGT de volta à BOB_WS, que o armazena em um cache de tíquetes associado à sessão de logon de Bob.

  4. Para poder trabalhar na BOB_WS, Bob precisa de um tíquete de serviço para obter acesso. O pacote de autenticação da BOB_WS cria a solicitação de tíquete de serviço e a envia ao RODC. O pacote de autenticação da BOB_WS prepara uma solicitação de TGT e a envia ao RODC.

  5. O RODC recebe a solicitação de tíquete de serviço da BOB_WS e, como já sabe a senha da respectiva conta de computador, pode criar o tíquete de serviço de Bob para acessar BOB_WS. O RODC usa a própria conta krbtgt ao criar o TGT.

  6. O RODC envia o tíquete de serviço de volta à BOB_WS, que o armazena no cache de tíquetes associado à sessão de logon de Bob.

  7. Bob pode começar a trabalhar na BOB_WS.

ImportantImportante
Este cenário mostra a importância do armazenamento em cache das senhas das contas de computador da filial. Se a senha de uma conta de computador não estiver armazenada em cache e o link WAN com um controlador de domínio gravável não estiver disponível, um usuário da filial não conseguirá fazer logon no computador, pois não poderá recuperar o tíquete de serviço dessa conta de computador.

Isso foi útil para você?
(1500 caracteres restantes)
Agradecemos os seus comentários

Contribuições da comunidade

ADICIONAR
Mostrar:
© 2014 Microsoft