R: O Protocolo de autenticação Kerberos usa tickets de sessão criptografados com uma chave simétrica derivada da senha do servidor ou serviço ao qual um usuário do Windows solicita acesso. Para solicitar um ticket de sessão, o Usuário deve apresentar um ticket especial, chamado ticket-granting ticket (TGT) para o serviço Kerberos Key Distribution Center (KDC) em um controlador de domínio (DC). Todos os usuários do Windows obtêm um TGT do KDC no início de sua sessão de login do Windows depois de se autenticarem com sucesso no KDC usando sua senha.
o KDC criptografa o TGT de um usuário com uma chave que deriva da senha da conta de domínio do anúncio krbtgt. A conta krbtgt e sua senha são compartilhadas entre os Serviços KDC de todos os DCs em um domínio. A conta krbtgt é criada automaticamente como parte do processo de instalação do dcpromo AD no primeiro DC em um domínio. Ele aparece no contêiner de usuários do snap-in de Usuários e computadores do Microsoft Management Console (MMC) do Active Directory e é desativado por padrão. Ao contrário de outras contas de usuário de anúncios, a conta krbtgt não pode ser usada para fazer logon interativamente no domínio. Por ser uma conta integrada, o krbtgt também não pode ser renomeado.
um controlador de domínio somente leitura (RODC) é um novo tipo de DC que a Microsoft introduziu no Windows Server 2008. Um RODC hospeda partições somente leitura do banco de dados de anúncios. Ele não armazena os hashes de senha de todas as contas de usuário em um domínio do Windows; em vez disso, um RODC armazena apenas os hashes de senha das contas definidas na política de replicação de senha (PRP) do RODC. Este método significa que o compromisso de um RODC representa muito menos risco do que o compromisso de um clássico read/write DC (RWDC) que contém cópias dos hashes de senha de todas as contas de usuário em um domínio. É por isso que um RODC pode ser implantado de uma forma que pode ser considerada menos segura. As organizações normalmente as implantam em filiais ou em suas zonas desmilitarizadas (DMZs).
um RODC atua como um Kerberos KDC para uma filial ou DMZ e, como tal, também requer uma conta krbtgt. Para garantir que o krbtgt de um RODC comprometido não possa ser aproveitado para solicitar ingressos para outros RODCs ou RWDCs, cada RODC tem uma conta krbtgt local especial. Esta conta tem o formato krbtgt123, onde ” 123 ” é uma sequência de números aleatórios. Esta string aleatória identifica exclusivamente o RODC e é gerada quando um RODC é instalado.
as diferentes contas krbtgt locais dos RODCs em um domínio são armazenadas no AD e aparecem em usuários e computadores do Active Directory no contêiner Usuários. Todos os RWDCs no domínio também mantêm uma cópia dos hashes de senha das contas krbtgt dos RODCs no domínio. Portanto, um TGT emitido por um RODC é válido para solicitar tickets de sessão contra o mesmo RODC e também contra qualquer outro RWDC no domínio.
se um RODC recebe uma solicitação de ticket de sessão que é baseada em um TGT que não é válido-o que significa que o TGT não foi emitido pelo próprio RODC-ele retorna um erro Kerberos pedindo ao computador cliente para solicitar uma nova solicitação TGT contra o próprio RODC. Se o RODC não tiver uma cópia do hash de senha do usuário, o RODC encaminhará a solicitação TGT para um RWDC. Nesse caso, o RODC atua como um proxy, pelo qual encaminha a resposta do RWDC diretamente para o computador cliente. Ao mesmo tempo, o RODC aciona o processo de armazenamento em cache do hash da senha do Usuário para que o RODC possa criar um TGT para esse usuário específico no futuro. O Cache é bem-sucedido se o PRP do RODC permitir que o hash da senha da conta do usuário seja armazenado em cache no RODC.
Relacionados: Como faço para instalar e configurar um controlador de domínio somente leitura (RODC)?
