Como as relações de confiança funcionam para florestas no Active Directory
O Active Directory Domain Services (AD DS) fornece segurança a vários domínios ou florestas por meio de relações de confiança entre domínios e florestas. Antes de acontecer a autenticação nas relações de confiança, o Windows deve primeiro verificar se o domínio que está sendo solicitado por um usuário, computador ou serviço tem uma relação de confiança com o domínio da conta solicitante.
Para verificar essa relação de confiança, o sistema de segurança do Windows computa um caminho de confiança entre o controlador de domínio (DC) para o servidor que recebe a solicitação e um DC no domínio da conta solicitante.
Os mecanismos de controle de acesso fornecidos pelo AD DS e o modelo de segurança distribuído pelo Windows fornecem um ambiente para a operação de relações de confiança entre domínios e florestas. Para que essas relações de confiança funcionem corretamente, cada recurso ou computador deve ter um caminho de confiança direto para um DC no domínio no qual ele está localizado.
O caminho de confiança é implementado pelo serviço Net Logon usando uma conexão de RPC (chamada de procedimento remoto) autenticada para a autoridade de domínio confiável. Um canal protegido também se estende a outros domínios de AD DS por meio de relações de confiança entre domínios. Esse canal protegido é usado para obter informações de segurança e verificá-las, incluindo identificadores de segurança (SIDs) para usuários e grupos.
Observação
Os Domain Services dão suporte a várias direções de confiança de floresta, incluindo relações de confiança bidirecionais e relações de confiança unidirecionais que podem ser de entrada ou saída.
Para obter uma visão geral de como as relações de confiança se aplicam aos Serviços de Domínio, consulte Conceitos e recursos da floresta.
Para começar a usar as relações de confiança nos Serviços de Domínio, crie um domínio gerenciado que use relações de confiança entre florestas.
Fluxo das relações de confiança
O fluxo de comunicações protegidas por relações de confiança determina a elasticidade de uma relação de confiança. A maneira como você cria ou configura uma relação de confiança determina até onde a comunicação se estende dentro ou entre as florestas.
O fluxo de comunicação por relações de confiança é determinado pela direção dessa relação. As relações de confiança podem ser unidirecionais ou bidirecionais, e podem ser transitivas ou intransitivas.
O diagrama a seguir mostra que todos os domínios na Árvore 1 e na Árvore 2 têm relações de confiança transitivas por padrão. Como resultado, os usuários da Árvore 1 podem acessar recursos em domínios da Árvore 2, e os usuários da Árvore 2 podem acessar recursos da Árvore 1 quando as permissões apropriadas são atribuídas no recurso.
Relações de confiança unidirecional e bidirecional
As relações de confiança permitem que o acesso aos recursos possa ser unidirecional ou bidirecional.
Uma relação de confiança unidirecional é um caminho de autenticação criado entre dois domínios que funciona num único sentido. Em uma relação de confiança unidirecional entre o Domínio A e o Domínio B, os usuários no Domínio A podem acessar recursos no Domínio B. No entanto, os usuários no Domínio B não podem acessar recursos no Domínio A.
Algumas relações de confiança unidirecionais podem ser transitivas ou intransitivas, dependendo do tipo de relação de confiança criado.
Em uma relação de confiança bidirecional, o Domínio A confia no Domínio B e o Domínio B confia no Domínio A. Essa configuração significa que as solicitações de autenticação podem ser passadas entre os dois domínios, nas duas direções. Algumas relações de confiança bidirecionais podem ser transitivas ou intransitivas, dependendo do tipo de relação de confiança criado.
Todas as relações de confiança entre domínios em uma floresta do AD DS local são transitivas e bidirecionais. Quando um novo domínio filho é criado, uma relação de confiança transitiva bidirecional é automaticamente criada entre o novo domínio filho e o domínio pai.
Relações de confiança transitivas e intransitivas
A transitividade determina se uma relação de confiança pode ser estendida para além dos dois domínios entre os quais ela foi formada.
- É possível usar uma relação de confiança transitiva para estender relações de confiança com outros domínios.
- É possível usar uma relação de confiança intransitiva para negar relações de confiança com outros domínios.
Toda vez que você criar um novo domínio em uma floresta, uma relação de confiança transitiva bidirecional é automaticamente criada entre o novo domínio e seu domínio pai. Se domínios filho forem adicionados ao novo domínio, o caminho da relação de confiança seguirá em direção ao topo da hierarquia de domínio, estendendo o caminho da relação de confiança inicial criado entre o novo domínio e seu domínio pai. As relações de confiança transitivas seguem em direção ao topo de uma árvore de domínio formada, criando esse tipo de relação entre todos os domínios da árvore.
As solicitações de autenticação seguem esses caminhos de confiança, portanto, as contas de qualquer domínio na floresta podem ser autenticadas por qualquer outro domínio na mesma floresta. Com um processo de conexão simples, as contas com as permissões apropriadas podem acessar os recursos em qualquer domínio da floresta.
Relações de confiança de floresta
As relações de confiança entre florestas ajudam a gerenciar uma infraestrutura segmentada de AD DS e dar suporte ao acesso a recursos e outros objetos em várias florestas. As relações de confiança entre florestas são úteis para os provedores de serviços de aplicativo, as organizações sob processo de fusão ou aquisição, as extranets comerciais colaborativas, e as organizações em busca de uma solução para uma maior autonomia administrativa.
O uso de relações de confiança entre florestas torna possível vincular duas florestas diferentes para formar uma relação de confiança transitiva unidirecional ou bidirecional. Uma relação de confiança entre florestas permite que os administradores conectem duas florestas de AD DS com um único relacionamento de confiança para fornecer uma experiência direta de autenticação e autorização em todas as florestas.
Uma relação de confiança entre florestas apenas pode ser criada entre um domínio raiz de floresta em uma floresta e um domínio raiz de floresta em outra floresta. As relações de confiança entre florestas só podem ser criadas entre duas florestas, e não podem ser estendidas de forma implícita para uma terceira floresta. Isso significa que se uma relação de confiança entre florestas for criada entre a Floresta 1 e a Floresta 2, e outra relação de confiança de floresta for criada entre a Floresta 2 e a Floresta 3, a Floresta 1 não terá uma confiança implícita com a Floresta 3.
O diagrama a seguir mostra dois relacionamentos separados de relações de confiança entre florestas entre três florestas do AD DS em uma única organização.
Esta configuração de exemplo fornece o seguinte acesso:
- Os usuários na Floresta 2 podem acessar recursos em qualquer domínio na Floresta 1 ou Floresta 3
- Os usuários na Floresta 3 podem acessar recursos em qualquer domínio na Floresta 2
- Os usuários na Floresta 1 podem acessar recursos em qualquer domínio na Floresta 2
Essa configuração não permite que os usuários na Floresta 1 acessem recursos na Floresta 3 ou vice-versa. Para permitir que os usuários na Floresta 1 e na Floresta 3 compartilhem recursos, deve ser criada uma relação de confiança transitiva bidirecional entre as duas florestas.
Se uma relação de confiança entre florestas unidirecional for criada entre duas florestas, os membros da floresta confiável poderão utilizar os recursos localizados na floresta confiante. Entretanto, a relação de confiança opera em apenas uma direção.
Por exemplo, quando uma relação de confiança de floresta unidirecional é criada entre a Floresta 1 (a floresta confiável) e a Floresta 2 (a floresta confiante):
- Os membros da Floresta 1 podem acessar os recursos localizados na Floresta 2.
- Os membros da Floresta 2 não podem acessar os recursos localizados na Floresta 1 usando a mesma relação de confiança.
Importante
O Microsoft Entra Domain Services dá suporte a várias direções para relações de confiança de floresta.
Requisitos para relação de confiança entre florestas
Antes de criar uma relação de confiança entre florestas, é necessário verificar se a infraestrutura de DNS (sistema de nomes de domínio) no local está correta. As relações de confiança entre florestas só podem ser criadas quando uma das seguintes configurações de DNS esteja disponível:
Um único servidor raiz de DNS raiz é o servidor raiz para ambos os namespaces do DNS da floresta – a zona raiz contém delegações para cada um dos namespaces do DNS e as dicas de raízes de todos os servidores DNS incluem o servidor raiz de DNS.
Se não houver nenhum servidor raiz de DNS compartilhado e os servidores raízes de DNS de cada namespace do DNS da floresta utilizarem encaminhadores condicionais para cada namespace do DNS a fim de encaminhar as consultas de nomes para o outro namespace.
Importante
Qualquer floresta do Microsoft Entra Domain Services com relação de confiança deve usar essa configuração DNS. Não é um recurso do Microsoft Entra Domain Services a hospedagem de um namespace do DNS diferente do namespace do DNS da floresta. Os encaminhadores condicionais são a configuração correta.
Quando não houver nenhum servidor raiz de DNS compartilhado, e os servidores raízes de DNS de cada namespace do DNS da floresta são utilizados, as zonas secundárias de DNS são configuradas em cada namespace do DNS para encaminhar as consultas de nomes para o outro namespace.
Para criar uma relação de confiança entre florestas no AD DS, você deve ser membro do grupo de Administradores do Domínio (no domínio raiz da floresta) ou do grupo de Administradores Corporativos no Active Directory. É atribuída uma senha a cada relação de confiança, e os administradores em ambas as florestas devem conhecê-las. Os membros dos administradores corporativos em ambas as florestas podem criar relações de confiança em ambas de uma só vez e, nesse cenário, uma senha criptograficamente aleatória é gerada de forma automática e gravada para ambas as florestas.
Uma floresta do domínio gerenciado dá suporte a até cinco relações de confiança de floresta de saída unidirecionais para florestas locais. A relação de confiança de saída entre florestas para o Microsoft Entra Domain Services é criada no centro de administração do Microsoft Entra. A relação de confiança de entrada entre florestas deve ser configurada por um usuário com os privilégios indicados previamente no Active Directory local.
Processos de confiança e interações
Muitas transações entre domínios e entre florestas dependem de relações de confiança de domínio ou floresta para concluir diversas tarefas. Esta seção descreve os processos e as interações que ocorrem à medida em que os recursos são acessados entre relações de confiança e o encaminhamento de autenticação são avaliados.
Visão geral do processo de encaminhamento de autenticação
Quando uma solicitação de autenticação é encaminhada a um domínio, o controlador de domínio no domínio solicitado deve determinar se existe uma relação de confiança com o domínio solicitante. A direção e a transitividade da relação de confiança também devem ser determinadas antes que o usuário seja autenticado para acessar recursos no domínio. O processo de autenticação que ocorre entre domínios confiáveis varia de acordo com o protocolo de autenticação em uso. Os protocolos Kerberos V5 e NTLM processam os encaminhamentos de autenticação para um domínio de forma diferente
Processo de encaminhamento pelo Kerberos V5
O protocolo de autenticação Kerberos V5 depende do serviço Netlogon nos controladores de domínio para informações de autenticação e autorização de cliente. O protocolo Kerberos se conecta a um Centro de Distribuição de chaves online (KDC) e ao armazenamento de conta do Active Directory para tíquetes de sessão.
O protocolo Kerberos também usa relações de confiança para os serviços de concessão de tíquete (TGS) entre realms e para validar o PACs (certificados de atributo de privilégio) em um canal protegido. O protocolo Kerberos executa a autenticação entre realms somente com realms Kerberos de sistemas operacionais diferentes do Windows, como um realm Kerberos do MIT, e não precisa interagir com o serviço Netlogon.
Se o cliente usar o Kerberos V5 para autenticação, ele solicitará um tíquete para o servidor no domínio de destino de um controlador de domínio em seu domínio de conta. O KDC do Kerberos atua como um intermediário confiável entre o cliente e o servidor, e fornece uma chave de sessão que permite que as duas partes se autentiquem. Se o domínio de destino for diferente do domínio atual, o KDC seguirá um processo lógico para determinar se uma solicitação de autenticação pode ser encaminhada:
O domínio solicitado possui relação de confiança direta com o domínio atual?
- Em caso afirmativo, envie ao cliente um encaminhamento para o domínio solicitado.
- Caso contrário, vá para a etapa seguinte:
Existe uma relação de confiança transitiva entre o domínio atual e o próximo domínio no caminho de confiança?
- Em caso afirmativo, envie ao cliente um encaminhamento para o próximo domínio no caminho de confiança.
- Caso contrário, envie ao cliente uma mensagem de entrada negada.
Processo de encaminhamento pelo NTLM
O protocolo de autenticação NTLM depende do serviço Netlogon nos controladores de domínio para informações de autenticação e autorização de cliente. Esse protocolo autentica clientes que não usam a autenticação do Kerberos. O NTLM utiliza relações de confiança para passar solicitações de autenticação entre domínios.
Se o cliente usar NTLM para autenticação, a solicitação inicial de autenticação vai diretamente do cliente para o servidor de recursos no domínio de destino. Esse servidor cria um desafio para o cliente responder. Em seguida, o servidor envia a resposta do usuário a um controlador de domínio em seu domínio de conta no computador. Esse controlador de domínio verifica a conta do usuário no banco de dados de contas de segurança.
Se a conta não existir no banco de dados, o controlador de domínio determinará se a autenticação de passagem deve ser executada, se deve encaminhar a solicitação, ou negá-la usando a seguinte lógica:
O domínio atual tem uma relação de confiança direta com o domínio do usuário?
- Em caso afirmativo, o controlador de domínio envia as credenciais do cliente para autenticação de passagem a um controlador de domínio no domínio do usuário.
- Caso contrário, vá para a etapa seguinte:
O domínio atual tem uma relação de confiança transitiva com o domínio do usuário?
- Em caso afirmativo, passe a solicitação de autenticação para o próximo domínio no caminho de confiança. Esse controlador de domínio repete o processo verificando as credenciais do usuário em seu próprio banco de dados de contas de segurança.
- Caso contrário, envie ao cliente uma mensagem de logon negado.
Processamento de solicitações de autenticação em relações de confiança entre florestas baseado em Kerberos
Quando duas florestas estão conectados por uma relação de confiança entre florestas, as solicitações de autenticação feitas usando os protocolos Kerberos V5 e NTLM podem ser roteadas entre florestas para fornecer acesso aos recursos em ambas.
Quando uma relação de confiança entre florestas é estabelecida pela primeira vez, cada floresta coleta todos os namespaces confiáveis em sua floresta de parceiros e armazena as informações em um objeto de domínio confiável. Namespaces confiáveis incluem nomes de árvore de domínio, sufixos UPN (nome UPN), sufixos SPN (nome de entidade de serviço) e namespaces SID (identificador de segurança) usadas na outra floresta. Os objetos TDO são replicados para o catálogo global.
Observação
Não há suporte para sufixos UPN alternativos em confianças. Se um domínio local usar o mesmo sufixo UPN que os Serviços de Domínio, o logon deverá usar sAMAccountName.
Antes que os protocolos de autenticação possam seguir o caminho de confiança da floresta, o nome da entidade de serviço (SPN) do computador de recursos deve ser resolvido para um local na outra floresta. Um SPN pode ser um dos seguintes nomes:
- O nome DNS de um host.
- O nome DNS de um domínio.
- O nome distinto de um objeto ponto de conexão de serviço.
Quando uma estação de trabalho em uma floresta tenta acessar dados em um computador de recurso em outra floresta, o processo de autenticação Kerberos entra em contato com o controlador de domínio para obter um tíquete de serviço para o SPN do computador de recursos. Depois que o controlador de domínio consulta o catálogo global e determina que o SPN não está na mesma floresta que o controlador de domínio, ele envia uma referência para seu domínio pai de volta para a estação de trabalho. Nesse ponto, a estação de trabalho consulta o domínio pai sobre o tíquete de serviço e continua a seguir a cadeia de encaminhamento até alcançar o domínio em que o recurso está localizado.
O diagrama e as etapas a seguir fornecem uma descrição detalhada do processo de autenticação Kerberos usado quando os computadores que executam o Windows tentam acessar recursos de um computador localizado em outra floresta.
O Usuário1 entra na EstaçãoDeTrabalho1 usando credenciais do domínio europe.tailspintoys.com. Em seguida, o usuário tenta acessar um recurso compartilhado no ServidorArquivor1 localizado na floresta usa.wingtiptoys.com.
A EstaçãoDeTrabalho1 entra em contato com o KDC do Kerberos em um controlador de domínio em seu domínio, FilhoDC1e solicita um tíquete de serviço para o SPN do ServidorArquivo1.
O FilhoDC1 não encontra o SPN em seu banco de dados de domínio e consulta o catálogo global para ver se algum domínio na floresta tailspintoys.com contém esse SPN. Como um catálogo global é limitado à sua própria floresta, o SPN não é encontrado.
Em seguida, o catálogo global verifica seu banco de dados para obter informações sobre as relações de confiança entre florestas estabelecidas com a sua floresta. Caso encontrado, ele compara os sufixos de nome listados no objeto de domínio confiável das relações de confiança entre florestas (TDO) ao sufixo do SPN de destino para encontrar uma correspondência. Quando uma correspondência é encontrada, o catálogo global fornece uma dica de roteamento ao FilhoDC1.
Dicas de roteamento ajudam a direcionar solicitações de autenticação para a floresta de destino. As dicas são usadas apenas quando todos os canais de autenticação tradicionais, como o controlador de domínio local e o catálogo global, falharem ao localizar um SPN.
O FilhoDC1 envia uma referência para seu domínio pai de volta para a EstaçãoDeTrabalho1.
A EstaçãoDeTrabalho1 entra em contato com um controlador de domínio em FlorestaRaizDC1 (seu domínio pai) para obter um encaminhamento a um controlador de domínio (FlorestaRaizDC2) no domínio raiz da floresta wingtiptoys.com.
A EstaçãoDeTrabalho1 contata a FlorestaRaizDC2 na floresta wingtiptoys.com para um tíquete de serviço ao serviço solicitado.
A FlorestaRaizDC2 contata seu catálogo global para localizar o SPN e o catálogo global encontra uma correspondência e a envia de volta para a FlorestaRaizDC2.
Em seguida, a FlorestaRaizDC2 envia o encaminhamento para usa.wingtiptoys.com de volta para a EstaçãoDeTrabalho1.
A EstaçãoDeTrabalho1 entra em contato com o KDC no FilhoDC2 e negocia o tíquete do Usuário1 para obter acesso ao ServidorArquivo1.
Depois que a EstaçãoDeTrabalho1 tiver um tíquete de serviço, ele o enviará serviço para o ServidorArquivo1, que lerá as credenciais de segurança de Usuário1 e construirá um token de acesso adequado.
Objetos de domínio confiáveis
Cada relação de confiança de domínio ou de floresta em uma organização é representada por um TDO (Objeto de Domínio Confiável) armazenado no contêiner do Sistema dentro de seu domínio.
Conteúdo do TDO
As informações contidas em um TDO variam dependendo se um TDO foi criado por uma relação de confiança de domínio ou de floresta.
Quando uma relação de confiança de domínio é criada, atributos como o nome do domínio DNS e o SID do domínio, o tipo e a transitividade da confiança, e o nome de domínio recíproco são representados no TDO. Os TDOs das relações de confiança entre florestas armazenam atributos adicionais para identificar todos os namespaces de sua floresta parceira. Esses atributos incluem nomes de árvore de domínio, os sufixos UPN (nomes UPN) e SPN (nome da entidade de serviço) e SID (identificador de segurança).
Como as relações de confiança são armazenadas em Active Directory como TDOs, todos os domínios em uma floresta têm conhecimento das relações de confiança que existem em toda a floresta. Da mesma forma, quando duas ou mais florestas são unidas por meio de relações de confiança, os domínios raiz da floresta em cada uma delas têm conhecimento das relações de confiança que existem em todos os domínios nas florestas confiáveis.
Alterações de senha do TDO
Ambos os domínios em uma relação de confiança compartilham uma senha, que é armazenada no objeto TDO no Active Directory. Como parte do processo de manutenção da conta, a cada 30 dias, o controlador de domínio confiante altera a senha armazenada no TDO. Esse processo ocorre duas vezes para relações de confiança bidirecionais, pois elas são, na verdade, duas relações de confiança unidirecional indo em direções opostas.
Uma relação de confiança tem um lado confiante e um lado confiável. No lado confiável, qualquer controlador de domínio gravável pode ser usado para o processo. No lado confiante, o emulador de PDC executa a alteração de senha.
Para alterar uma senha, os controladores de domínio concluem o seguinte processo:
O emulador do controlador de domínio primário (PDC) no domínio confiante cria uma nova senha. Um controlador de domínio no domínio confiável nunca inicia a alteração de senha. Ele é sempre iniciado pelo emulador de PDC do domínio confiante.
O emulador de PDC no domínio confiante define o campo OldPassword do objeto TDO para o campo NewPassword atual.
O emulador de PDC no domínio confiante define o campo NewPassword do objeto TDO como a nova senha. Manter uma cópia da senha anterior possibilita reverter para a senha antiga se o controlador de domínio no domínio confiável falhar ao receber a alteração, ou caso a alteração não seja replicada antes que seja feita uma solicitação que utilize a nova senha de confiança.
O emulador de PDC no domínio confiante faz uma chamada remota para um controlador de domínio no domínio confiável solicitando que ele defina senha na conta de confiança para a nova senha.
O controlador de domínio no domínio confiável altera a senha de confiança para a nova senha.
Em cada lado da relação de confiança, as atualizações são replicadas para os outros controladores de domínio naquele domínio. No domínio confiante, a alteração dispara uma replicação urgente do objeto de domínio confiável.
A senha agora está alterada em ambos os controladores de domínio. A replicação normal distribui os objetos TDO para os outros controladores de domínio naquele domínio. No entanto, é possível que o controlador de domínio no domínio confiante altere a senha sem atualizar com êxito um controlador de domínio no domínio confiável. Esse cenário pode ocorrer porque um canal protegido, que é necessário para processar a alteração de senha, não pôde ser estabelecido. Também é possível que o controlador de domínio no domínio confiável possa estar indisponível em algum momento durante o processo e não receber a senha atualizada.
Para lidar com situações em que a alteração de senha não é comunicada com êxito, o controlador de domínio no domínio confiante nunca altera a nova senha, a menos que uma autenticação (configuração de canal protegido) usando a nova senha tenha acontecido com êxito. Esse comportamento é o motivo pelo qual as senhas antigas e as novas são mantidas no objeto TDO do domínio confiante.
Uma alteração de senha não é finalizada até que a autenticação usando a nova senha seja realizada com sucesso. A senha antiga armazenada pode ser usada no canal protegido até que o controlador de domínio no domínio confiável receba a nova senha, habilitando assim serviço ininterrupto.
Se a autenticação que usa a nova senha falhar porque a senha é inválida, o controlador de domínio confiante tentará a autenticação usando a senha antiga. Se ele for autenticado com êxito com a senha antiga, ele retoma o processo de alteração de senha dentro de 15 minutos.
As atualizações de senha de confiança precisam ser replicadas para os controladores de domínio de ambos os lados da relação de confiança dentro de 30 dias. Se a senha de confiança for alterada após 30 dias e um controlador de domínio tiver apenas a senha N-2, ele não poderá usar a relação de confiança do lado confiante e não poderá criar um canal protegido no lado confiável.
Portas de rede usadas pelas relações de confiança
Como as relações de confiança devem ser implantadas em vários limites de rede, elas podem ter que passar por um firewall ou mais. Quando esse for o caso, você pode encapsular o tráfego de confiança em um firewall ou abrir portas específicas no firewall para permitir a passagem do tráfego.
Importante
O Active Directory Domain Services não dá suporte à restrição do tráfego do Active Directory RPC para portas específicas.
Leia a seção do Windows Server 2008 e versões posteriores do artigo Suporte da Microsoft Como configurar um firewall para os domínios e relações de confiança do Active Directory para saber mais sobre as portas necessárias para uma relação de confiança de floresta.
Serviços e ferramentas de suporte
Para dar suporte a relações de confiança e autenticação são usados alguns recursos e ferramentas de gerenciamento adicionais.
Logon de Rede
O serviço Netlogon mantém um canal protegido de um computador baseado no Windows para um DC. Ele também é usado nos seguintes processos relacionados à confiança:
Configuração e gerenciamento de confiança – o Netlogon ajuda a manter senhas de confiança, coleta informações de confiança e verifica relações de confiança interagindo com o processo LSA e o TDO.
Para relações de confiança entre florestas, as informações de confiança incluem o registro Informações de Confiança entre Florestas (FTInfo), que inclui o conjunto de namespaces que uma floresta confiável alega gerenciar, anotada com um campo que indica se cada declaração é confiável pela floresta confiante.
Autenticação – Fornece as credenciais do usuário em um canal protegido para um controlador de domínio e retorna os SIDs de domínio e os direitos de usuário para o usuário.
Local do controlador de domínio – Ajuda a encontrar ou localizar controladores de domínio em um domínio específico ou entre domínios.
Validação de passagem – As credenciais de usuários em outros domínios são processadas pelo Netlogon. Quando um domínio confiante precisa verificar a identidade de um usuário, ele passa as credenciais do usuário por meio do Netologon ao domínio confiável para verificação.
Verificação de PAC (Certificado de Atributo de Privilégio) – Quando um servidor que usa o protocolo Kerberos para autenticação precisa verificar o PAC em um tíquete de serviço, ele envia o PAC pelo canal protegido para seu controlador de domínio para verificação.
Autoridade de Segurança Local
A Autoridade de Segurança Local (LSA) é um subsistema protegido que mantém informações sobre todos os aspectos da segurança local em um sistema. Coletivamente conhecido como política de segurança local, a LSA fornece vários serviços para conversão entre nomes e identificadores.
O subsistema de segurança LSA fornece serviços no modo kernel e no modo de usuário para validar o acesso a objetos, verificar os privilégios do usuário e gerar mensagens de auditoria. O LSA é responsável por verificar a validade de todos os tíquetes de sessão apresentados pelos serviços em domínios confiáveis ou não confiáveis.
Ferramentas de gerenciamento
Os administradores podem usar os domínios e relações de confiança do Active Directory , o Netdom e Nltest para expor, criar, remover ou modificar relações de confiança.
- Os Domínios e as Relação de Confiança do Active Directory é o Console de Gerenciamento Microsoft (MMC) que é usado para administrar relações de confiança de domínio, níveis funcionais de domínio e floresta e sufixos de nome UPN.
- As ferramentas de linha de comando Netdom e Nltest podem ser usadas para localizar, exibir, criar e gerenciar relações de confiança. Essas ferramentas se comunicam diretamente com a autoridade LSA em um controlador de domínio.
Próximas etapas
Para começar a criar um domínio gerenciado com uma relação de confiança de floresta, consulte Criar e configurar um domínio gerenciado dos Serviços de Domínio. Em seguida, você pode Criar uma relação de confiança de saída entre florestas para um domínio local.