Como funcionam as relações de confiança para florestas no Ative Directory
Os Serviços de Domínio Ative Directory (AD DS) fornecem segurança em vários domínios ou florestas por meio de relações de confiança de domínio e floresta. Antes que a autenticação possa ocorrer entre relações de confiança, o Windows deve primeiro verificar se o domínio 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 calcula um caminho de confiança entre o controlador de domínio (DC) para o servidor que recebe a solicitação e um controlador de domínio no domínio da conta solicitante.
Os mecanismos de controle de acesso fornecidos pelo AD DS e o modelo de segurança distribuído do Windows fornecem um ambiente para a operação de confianças de domínio e floresta. Para que essas relações de confiança funcionem corretamente, cada recurso ou computador deve ter um caminho de confiança direto para um controlador de domínio no domínio em que está localizado.
O caminho de confiança é implementado pelo serviço Logon de Rede usando uma conexão RPC (chamada de procedimento remoto) autenticada com a autoridade de domínio confiável. Um canal seguro também se estende a outros domínios do AD DS por meio de relações de confiança entre domínios. Esse canal seguro é usado para obter e verificar informações de segurança, incluindo identificadores de segurança (SIDs) para usuários e grupos.
Nota
Os Serviços de Domínio suportam 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 de 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 de floresta.
Para começar a usar relações de confiança nos Serviços de Domínio, crie um domínio gerenciado que use relações de confiança de floresta.
Fluxos de relações de confiança
O fluxo de comunicações seguras sobre trusts determina a elasticidade de um trust. A forma como você cria ou configura uma relação de confiança determina até onde a comunicação se estende dentro ou entre florestas.
O fluxo de comunicação sobre trusts é determinado pela direção do trust. As relações de confiança podem ser unidirecionais ou bidirecionais, e podem ser transitivas ou não transitivas.
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 na Árvore 1 podem acessar recursos em domínios na Árvore 2 e os usuários na Árvore 2 podem acessar recursos na Árvore 1, quando as permissões apropriadas são atribuídas ao recurso.
Relações de confiança unidirecionais e bidirecionais
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 unidirecional criado entre dois domínios. 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 não transitivas ou transitivas, dependendo do tipo de confiança que está sendo criada.
Numa 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 em ambas as direções. Algumas relações bidirecionais podem ser não transitivas ou transitivas, dependendo do tipo de confiança que está sendo criada.
Todas as confianças de domínio em uma floresta do AD DS local são relações de confiança transitivas bidirecionais. Quando um novo domínio filho é criado, uma confiança transitiva bidirecional é criada automaticamente entre o novo domínio filho e o domínio pai.
Confianças transitivas e não transitivas
A transitividade determina se uma relação de confiança pode ser estendida para fora dos dois domínios com os quais foi formada.
- Uma confiança transitiva pode ser usada para estender relações de confiança com outros domínios.
- Uma relação de confiança não transitiva pode ser usada para negar relações de confiança com outros domínios.
Cada vez que você cria um novo domínio em uma floresta, uma relação de confiança transitiva bidirecional é criada automaticamente entre o novo domínio e seu domínio pai. Se domínios filho forem adicionados ao novo domínio, o caminho de confiança flui para cima através da hierarquia de domínio, estendendo o caminho de confiança inicial criado entre o novo domínio e seu domínio pai. As relações de confiança transitivas fluem para cima através de uma árvore de domínio à medida que ela é formada, criando relações de confiança transitivas entre todos os domínios na árvore de domínio.
As solicitações de autenticação seguem esses caminhos de confiança, para que as contas de qualquer domínio na floresta possam ser autenticadas por qualquer outro domínio na floresta. Com um processo de logon único, as contas com as permissões adequadas podem acessar recursos em qualquer domínio da floresta.
Confianças de floresta
As confianças de floresta ajudam você a gerenciar infraestruturas segmentadas do AD DS e dão suporte ao acesso a recursos e outros objetos em várias florestas. Os trusts florestais são úteis para prestadores de serviços, empresas em processo de fusão ou aquisição, extranets de negócios colaborativos e empresas que procuram uma solução para a autonomia administrativa.
Usando confianças de floresta, você pode vincular duas florestas diferentes para formar uma relação de confiança transitiva unidirecional ou bidirecional. Uma relação de confiança de floresta permite que os administradores conectem duas florestas do AD DS com uma única relação de confiança para fornecer uma experiência de autenticação e autorização perfeita entre as florestas.
Uma relação de confiança de floresta só pode ser criada entre um domínio raiz de floresta em uma floresta e um domínio raiz de floresta em outra floresta. Os trusts florestais só podem ser criados entre duas florestas e não podem ser implicitamente estendidos a uma terceira floresta. Esse comportamento significa que, se uma relação de confiança de floresta for criada entre a Floresta 1 e a Floresta 2, e outra confiança de floresta for criada entre a Floresta 2 e a Floresta 3, a Floresta 1 não terá uma relação de confiança implícita com a Floresta 3.
O diagrama a seguir mostra duas relações de confiança de floresta separadas entre três florestas do AD DS em uma única organização.
Este exemplo de configuração fornece o seguinte acesso:
- Os usuários na Floresta 2 podem acessar recursos em qualquer domínio na Floresta 1 ou na 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 da Floresta 1 e da Floresta 3 compartilhem recursos, uma confiança transitiva bidirecional deve ser criada entre as duas florestas.
Se uma relação de confiança de floresta unidirecional for criada entre duas florestas, os membros da floresta confiável poderão utilizar recursos localizados na floresta confiável. No entanto, o trust opera em apenas uma direção.
Por exemplo, quando uma confiança de floresta unidirecional é criada entre a Floresta 1 (a floresta confiável) e a Floresta 2 (a floresta confiável):
- Os membros da Floresta 1 podem acessar recursos localizados na Floresta 2.
- Os membros da Floresta 2 não podem acessar recursos localizados na Floresta 1 usando a mesma confiança.
Importante
Os Serviços de Domínio do Microsoft Entra suportam várias direções para confianças de floresta.
Requisitos de confiança florestal
Antes de criar uma relação de confiança de floresta, você precisa verificar se tem a infraestrutura DNS (Sistema de Nomes de Domínio) correta. As confianças de floresta só podem ser criadas quando uma das seguintes configurações de DNS estiver disponível:
Um único servidor DNS raiz é o servidor DNS raiz para ambos os namespaces DNS de floresta - a zona raiz contém delegações para cada um dos namespaces DNS e as dicas de raiz de todos os servidores DNS incluem o servidor DNS raiz.
Quando não houver nenhum servidor DNS raiz compartilhado e os servidores DNS raiz em cada namespace DNS da floresta, use encaminhadores condicionais DNS para cada namespace DNS para rotear consultas para nomes no outro namespace.
Importante
Qualquer floresta dos Serviços de Domínio Microsoft Entra com uma relação de confiança deve usar essa configuração de DNS. Hospedar um namespace DNS diferente do namespace DNS da floresta não é um recurso dos Serviços de Domínio Microsoft Entra. Encaminhadores condicionais é a configuração adequada.
Quando não há nenhum servidor DNS raiz compartilhado e os servidores DNS raiz em cada namespace DNS da floresta são usados, as zonas secundárias DNS são configuradas em cada namespace DNS para rotear consultas para nomes no outro namespace.
Para criar uma relação de confiança de floresta no AD DS, tem de ser membro do grupo Administradores do Domínio (no domínio raiz da floresta) ou do grupo Administradores de Empresa no Ative Directory. A cada relação de confiança é atribuída uma senha que os administradores em ambas as florestas devem saber. Os membros dos Administradores de Empresa em ambas as florestas podem criar as relações de confiança em ambas as florestas de uma só vez e, nesse cenário, uma senha criptograficamente aleatória é gerada e gravada automaticamente para ambas as florestas.
Uma floresta de domínio gerenciado oferece suporte a até cinco confianças de floresta de saída unidirecionais para florestas locais. A confiança de floresta de saída para os Serviços de Domínio do Microsoft Entra é criada no centro de administração do Microsoft Entra. A confiança da floresta de entrada deve ser configurada por um usuário com os privilégios observados anteriormente no Ative Directory local.
Processos e interações de confiança
Muitas transações entre domínios e entre florestas dependem de confianças de domínio ou floresta para concluir várias tarefas. Esta seção descreve os processos e interações que ocorrem à medida que os recursos são acessados entre relações de confiança e as referências de autenticação são avaliadas.
Visão geral do processamento de referência de autenticação
Quando uma solicitação de autenticação é encaminhada para um domínio, o controlador de domínio nesse domínio deve determinar se existe uma relação de confiança com o domínio do qual a solicitação vem. A direção da relação de confiança e se a relação de confiança é transitiva ou não transitiva também deve ser determinada antes de autenticar o usuário 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 referências para autenticação em um domínio de forma diferente
Processamento de referência Kerberos V5
O protocolo de autenticação Kerberos V5 depende do serviço Logon de Rede em 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 (KDC) online e ao armazenamento de contas do Ative Directory para tíquetes de sessão.
O protocolo Kerberos também usa relações de confiança para serviços de concessão de tíquetes entre regiões (TGS) e para validar certificados de atributo de privilégio (PACs) em um canal seguro. O protocolo Kerberos executa a autenticação entre regiões somente com realms Kerberos do sistema operacional que não são da marca Windows, como um realm Kerberos MIT, e não precisa interagir com o serviço Logon de rede.
Se o cliente usar 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 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 referenciada:
O domínio atual é confiável diretamente pelo domínio do servidor que está sendo solicitado?
- Se sim, envie ao cliente uma referência para o domínio solicitado.
- Em caso negativo, avance para o passo 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?
- Se sim, envie ao cliente uma referência para o próximo domínio no caminho de confiança.
- Se não, envie ao cliente uma mensagem de entrada negada.
Processamento de referência NTLM
O protocolo de autenticação NTLM depende do serviço Logon de Rede em controladores de domínio para autenticação de cliente e informações de autorização. Esse protocolo autentica clientes que não usam a autenticação Kerberos. O NTLM usa relações de confiança para passar solicitações de autenticação entre domínios.
Se o cliente usa 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. Este servidor cria um desafio ao qual o cliente responde. Em seguida, o servidor envia a resposta do usuário para um controlador de domínio em seu domínio de conta de computador. Este controlador de domínio verifica a conta de utilizador em relação à sua base 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, encaminhará a solicitação ou negará a solicitação usando a seguinte lógica:
O domínio atual tem uma relação de confiança direta com o domínio do usuário?
- Se sim, o controlador de domínio envia as credenciais do cliente para um controlador de domínio no domínio do usuário para autenticação de passagem.
- Em caso negativo, avance para o passo seguinte.
O domínio atual tem uma relação de confiança transitiva com o domínio do usuário?
- Se sim, passe a solicitação de autenticação para o próximo domínio no caminho de confiança. Este controlador de domínio repete o processo verificando as credenciais do utilizador em relação à sua própria base de dados de contas de segurança.
- Se não, envie ao cliente uma mensagem de logon negado.
Processamento baseado em Kerberos de solicitações de autenticação em relações de confiança de floresta
Quando duas florestas são conectadas por uma relação de confiança de floresta, as solicitações de autenticação feitas usando os protocolos Kerberos V5 ou NTLM podem ser roteadas entre florestas para fornecer acesso a recursos em ambas as florestas.
Quando uma relação de confiança de floresta é estabelecida pela primeira vez, cada floresta coleta todos os namespaces confiáveis em sua floresta de parceiro e armazena as informações em um objeto de domínio confiável. Os namespaces confiáveis incluem nomes de árvore de domínio, sufixos UPN (nome principal do usuário), sufixos SPN (nome principal do serviço) e namespaces de ID de segurança (SID) usados na outra floresta. Os objetos TDO são replicados para o catálogo global.
Nota
Não há suporte para sufixos UPN alternativos em relações de confiança. Se um domínio local usar o mesmo sufixo UPN que os Serviços de Domínio, entrar deverá usar sAMAccountName.
Antes que os protocolos de autenticação possam seguir o caminho de confiança da floresta, o SPN (nome da entidade de serviço) do computador de recurso 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 de 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 contata o controlador de domínio para obter um tíquete de serviço para o SPN do computador de recurso. 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, o controlador de domínio 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 para obter o tíquete de serviço e continua a seguir a cadeia de referência até chegar ao domínio onde o recurso está localizado.
O diagrama e as etapas a seguir fornecem uma descrição detalhada do processo de autenticação Kerberos usado quando computadores que executam o Windows tentam acessar recursos de um computador localizado em outra floresta.
User1 entra no Workstation1 usando credenciais do domínio europe.tailspintoys.com . Em seguida, o usuário tenta acessar um recurso compartilhado no FileServer1 localizado na floresta usa.wingtiptoys.com.
Workstation1 contata o KDC Kerberos em um controlador de domínio em seu domínio, ChildDC1, e solicita um tíquete de serviço para o SPN FileServer1.
ChildDC1 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 em busca de informações sobre quaisquer relações de confiança de floresta estabelecidas com sua floresta. Se encontrado, ele compara os sufixos de nome listados no objeto de domínio confiável (TDO) de confiança da floresta com o sufixo do SPN de destino para encontrar uma correspondência. Quando uma correspondência é encontrada, o catálogo global fornece uma dica de roteamento de volta para ChildDC1.
As dicas de roteamento ajudam a direcionar as solicitações de autenticação para a floresta de destino. As dicas só são usadas quando todos os canais de autenticação tradicionais, como o controlador de domínio local e, em seguida, o catálogo global, não conseguem localizar um SPN.
ChildDC1 envia uma referência para seu domínio pai de volta para Workstation1.
Workstation1 contata um controlador de domínio em ForestRootDC1 (seu domínio pai) para uma referência a um controlador de domínio (ForestRootDC2) no domínio raiz da floresta da floresta wingtiptoys.com.
Workstation1 contata ForestRootDC2 na floresta de wingtiptoys.com para um tíquete de serviço para o serviço solicitado.
ForestRootDC2 entra em contato com seu catálogo global para localizar o SPN, e o catálogo global encontra uma correspondência para o SPN e o envia de volta para ForestRootDC2.
Em seguida, ForestRootDC2 envia a referência para usa.wingtiptoys.com de volta para Workstation1.
Workstation1 entra em contato com o KDC no ChildDC2 e negocia o tíquete para User1 obter acesso ao FileServer1.
Depois que o Workstation1 tem um tíquete de serviço, ele envia o tíquete de serviço para FileServer1, que lê as credenciais de segurança do User1 e constrói um token de acesso de acordo.
Objeto de domínio confiável
Cada confiança de domínio ou floresta dentro de uma organização é representada por um TDO (Objeto de Domínio Confiável) armazenado no contêiner Sistema dentro de seu domínio.
Conteúdo TDO
As informações contidas em um TDO variam dependendo se um TDO foi criado por uma confiança de domínio ou por uma confiança de floresta.
Quando uma relação de confiança de domínio é criada, atributos como o nome de domínio DNS, SID de domínio, tipo de confiança, transitividade de confiança e o nome de domínio recíproco são representados no TDO. Os TDOs de confiança de floresta armazenam atributos adicionais para identificar todos os namespaces confiáveis da floresta parceira. Esses atributos incluem nomes de árvore de domínio, sufixos UPN (nome principal do usuário), sufixos SPN (nome principal do serviço) e namespaces de ID de segurança (SID).
Como as relações de confiança são armazenadas no Ative Directory como TDOs, todos os domínios em uma floresta têm conhecimento das relações de confiança que estão em vigor em toda a floresta. Da mesma forma, quando duas ou mais florestas são unidas por meio de confianças de floresta, os domínios raiz da floresta em cada floresta têm conhecimento das relações de confiança que estão em vigor em todos os domínios em florestas confiáveis.
Alterações de senha TDO
Ambos os domínios em uma relação de confiança compartilham uma senha, que é armazenada no objeto TDO no Ative Directory. Como parte do processo de manutenção da conta, a cada 30 dias o controlador de domínio confiável altera a senha armazenada no TDO. Como todas as relações de confiança bidirecionais são, na verdade, duas relações de confiança unidirecionais indo em direções opostas, o processo ocorre duas vezes para relações de confiança bidirecionais.
Um trust tem um lado de confiança e um lado de confiança. No lado confiável, qualquer controlador de domínio gravável pode ser usado para o processo. No lado confiável, o emulador PDC executa a alteração de senha.
Para alterar uma senha, os controladores de domínio concluem o seguinte processo:
O emulador de controlador de domínio primário (PDC) no domínio confiável cria uma nova senha. Um controlador de domínio no domínio confiável nunca inicia a alteração de senha. É sempre iniciado pelo emulador PDC de domínio confiável.
O emulador PDC no domínio confiável define o campo OldPassword do objeto TDO como o campo NewPassword atual.
O emulador PDC no domínio confiável define o campo NewPassword do objeto TDO como a nova senha. Manter uma cópia da senha anterior torna possível reverter para a senha antiga se o controlador de domínio no domínio confiável não receber a alteração, ou se a alteração não for replicada antes que uma solicitação seja feita usando a nova senha de confiança.
O emulador de PDC no domínio confiável faz uma chamada remota para um controlador de domínio no domínio confiável solicitando que ele defina a senha na conta confiável 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 no domínio. No domínio confiável, a alteração dispara uma replicação urgente do objeto de domínio confiável.
A senha agora é alterada em ambos os controladores de domínio. A replicação normal distribui os objetos TDO para os outros controladores de domínio no domínio. No entanto, é possível que o controlador de domínio no domínio confiável 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 seguro, 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 esteja indisponível em algum momento durante o processo e não receba 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 confiável nunca altera a nova senha, a menos que tenha sido autenticado com êxito (configurar um canal seguro) usando a nova senha. Esse comportamento é o motivo pelo qual as senhas antiga e nova são mantidas no objeto TDO do domínio confiável.
Uma alteração de senha não é finalizada até que a autenticação usando a senha seja bem-sucedida. A palavra-passe antiga armazenada pode ser utilizada através do canal seguro até que o controlador de domínio no domínio fidedigno receba a nova palavra-passe, permitindo assim um serviço ininterrupto.
Se a autenticação usando a nova senha falhar porque a senha é inválida, o controlador de domínio confiável tentará autenticar usando a senha antiga. Se ele se autenticar com sucesso com a senha antiga, ele retomará o processo de alteração de senha em 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 confiança do lado confiável e não poderá criar um canal seguro no lado confiável.
Portas de rede usadas por 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 abranger um ou mais firewalls. Quando esse é o caso, você pode encapsular o tráfego de confiança através de um firewall ou abrir portas específicas no firewall para permitir que o tráfego passe.
Importante
Os Serviços de Domínio Ative Directory não suportam a restrição do tráfego RPC do Ative Directory a portas específicas.
Leia a seção Windows Server 2008 e versões posteriores do artigo de Suporte da Microsoft Como configurar um firewall para domínios e relações de confiança do Ative Directory para saber mais sobre as portas necessárias para uma relação de confiança de floresta.
Serviços e ferramentas de apoio
Para dar suporte a relações de confiança e autenticação, alguns recursos adicionais e ferramentas de gerenciamento são usados.
Logon de rede
O serviço Logon de Rede mantém um canal seguro 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 Logon de Rede ajuda a manter senhas de confiança, reúne informações de confiança e verifica relações de confiança interagindo com o processo LSA e o TDO.
Para confianças de floresta, as informações de confiança incluem o registro FTInfo (Informações de Confiança da Floresta), que inclui o conjunto de namespaces que uma floresta confiável afirma gerenciar, anotado com um campo que indica se cada declaração é confiável pela floresta confiável.
Autenticação – Fornece credenciais de usuário através de um canal seguro 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 localizar ou localizar controladores de domínio em um domínio ou entre domínios.
Validação de passagem – As credenciais dos usuários em outros domínios são processadas pelo Net Logon. Quando um domínio confiável precisa verificar a identidade de um usuário, ele passa as credenciais do usuário por meio do Logon de Rede para o domínio confiável para verificação.
Verificação de Certificado de Atributo de Privilégio (PAC) – Quando um servidor que usa o protocolo Kerberos para autenticação precisa verificar a PAC em um tíquete de serviço, ele envia a PAC através do canal seguro para seu controlador de domínio para verificação.
Autenticação de Segurança Local
A Autoridade de Segurança Local (LSA) é um subsistema protegido que mantém informações sobre todos os aspetos da segurança local em um sistema. Coletivamente conhecida como política de segurança local, a LSA fornece vários serviços para traduçã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. A LSA é responsável por verificar a validade de todos os tíquetes de sessão apresentados por serviços em domínios confiáveis ou não confiáveis.
Ferramentas de gestão
Os administradores podem usar Domínios e Relações de Confiança do Ative Directory, Netdom e Nltest para expor, criar, remover ou modificar relações de confiança.
- Domínios e Relações de Confiança do Ative Directory é o MMC (Console de Gerenciamento Microsoft) usado para administrar relações de confiança de domínio, níveis funcionais de domínio e floresta e sufixos de nome principal de usuário.
- 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óximos passos
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 pelos Serviços de Domínio. Em seguida, você pode Criar uma relação de confiança de floresta de saída para um domínio local.