Como funcionam as relações de confiança para florestas no Active Directory (Prévia)

Os Serviços de Domínio Active Directory (AD DS) fornecem segurança em vários domínios ou florestas por meio de relações de confiança entre domínios e florestas. 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 controlo de acesso fornecidos pelos Serviços de Domínio do Active Directory (AD DS) e pelo modelo de segurança distribuído do Windows proporcionam um ambiente para a operação de relações de confiança de 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 controlador de domínio no domínio em que está localizado.

O serviço Logon de Rede implementa o caminho de confiança 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.

Observação

Os Serviços de Domínio suportam várias direções de confiança de floresta, incluindo uma visualização atual de 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 da Floresta.

Para começar a usar relações de confiança nos Serviços de Domínio, crie um domínio gerido que utilize relações de confiança de floresta.

Fluxos de relações de confiança

O fluxo de comunicações seguras em confianças determina a elasticidade de uma confiança. 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.

A orientação do trust determina o fluxo de comunicação entre trusts. 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 Árvore 2 têm relações de confiança transitivas por padrão. Como resultado, os utilizadores em Árvore 1 podem aceder a recursos em domínios na Árvore 2 e utilizadores em Árvore 2 podem aceder a recursos em Árvore 1, quando as permissões apropriadas são atribuídas no 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 confiança unidirecional entre Domínio A e Domínio B, os usuários em Domínio A podem acessar recursos em 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.

Em uma relação de confiança bidirecional, Domínio A confia Domínio B e Domínio B confia Domínio A. Esta configuração significa que as solicitações de autenticação podem ser passadas entre os dois domínios em ambos os sentidos. Algumas relações bidirecionais podem ser não transitivas ou transitivas, dependendo do tipo de confiança que está sendo criada.

Todas as relações de confiança de domínio em uma floresta do AD DS no 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.

Fideicomissos florestais

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 trusts de floresta, pode-se vincular duas florestas diferentes para formar uma relação de confiança transitiva, unidirecional ou bidirecional. Uma floresta de confiança permite que os administradores conectem duas florestas do AD DS através de uma única relação de confiança, proporcionando uma experiência de autenticação e autorização contínua 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 Floresta 1 e Floresta 2e outra confiança de floresta for criada entre Floresta 2 e Floresta 3, Floresta 1 não tiver uma confiança implícita com 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 utilizadores no Floresta 2 podem aceder a recursos em qualquer domínio na Floresta 1 ou Floresta 3
• Os utilizadores na Floresta 3 podem aceder a recursos em qualquer domínio na Floresta 2
• Os usuários no Forest 1 podem acessar recursos em qualquer domínio no Forest 2

Esta configuração não permite que os utilizadores na Floresta 1 acedam a recursos na Floresta 3 ou vice-versa. Para permitir que os utilizadores em Forest 1 e Forest 3 partilhem recursos, deve ser criada uma confiança transitiva bidirecional 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 relação de confiança de floresta unidirecional é criada entre Floresta 1 (a floresta confiável) e Floresta 2 (a floresta confiável):

• Os membros do Forest 1 podem aceder a recursos localizados em Forest 2.
• Os membros do Forest 2 não podem aceder a recursos localizados em Forest 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 domínio 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 domínios DNS da floresta - a zona raiz contém delegações para cada um dos domínios DNS e as indicações de raiz de todos os servidores DNS incluem o servidor DNS raiz.

• Quando não há um servidor DNS raiz compartilhado e os servidores DNS raiz em cada namespace DNS da floresta usam encaminhadores condicionais 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 são a configuração adequada.

• Quando não há nenhum servidor DNS raiz compartilhado e os servidores DNS raiz em cada namespace DNS de 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, você deve 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 relação de 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. Um usuário com os privilégios observados anteriormente no Ative Directory local deve configurar a confiança da floresta de entrada.

Processos e interações de confiança

Muitas transações entre domínios e entre florestas dependem de relações de confiança de domínio ou de 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 conecta-se a um Centro de Distribuição de Chaves (KDC) online e ao armazenamento de contas do Active 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 PACs (Certificados de Atributo de Privilégio) em um canal seguro. O protocolo Kerberos executa a autenticação entre reinos apenas com realms Kerberos de sistemas operativos que não são da marca Windows, como um realm Kerberos MIT, e não precisa interagir com o serviço Net Logon.

Se o cliente usar Kerberos V5 para autenticação, ele solicitará um tíquete para o servidor no domínio de destino a partir do controlador de domínio da sua 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:

1. O domínio atual é confiável diretamente pelo domínio do servidor solicitado?

   • Se sim, envie ao cliente uma referência para o domínio solicitado.
   • Em caso negativo, avance para o passo seguinte.

2. 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 acesso negado.

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 na base de dados, o controlador de domínio determinará se deve realizar a autenticação de passagem, encaminhar a solicitação ou negar a solicitação, usando a seguinte lógica:

1. 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.

2. 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 acesso 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 entre florestas é estabelecida pela primeira vez, cada floresta recolhe todos os namespaces confiáveis da sua floresta parceira e armazena as informações num 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 SID (ID de segurança) usados 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 relações de confiança. Se um domínio local usar o mesmo sufixo UPN que os Serviços de Domínio, deverá usar sAMAccountNamepara entrar.

Antes que os protocolos de autenticação possam seguir o percurso de confiança na floresta, o SPN (nome da entidade de serviço) do computador de recurso deve ser resolvido em 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 distinguível 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.

1. User1 inicia sessão no Workstation1 utilizando credenciais do domínio europe.tailspintoys.com. Em seguida, o usuário tenta acessar um recurso compartilhado em FileServer1 localizado na floresta usa.wingtiptoys.com.

2. Workstation1 contacta o KDC Kerberos num controlador de domínio no seu domínio, ChildDC1, e solicita um tíquete de serviço para o FileServer1 SPN.

3. 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 o seu banco de dados em busca de informações sobre quaisquer relações de confiança florestal estabelecidas com a sua floresta. Se verificado, ele compara os sufixos de nome listados no objeto de domínio de confiança (TDO) 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.

4. ChildDC1 envia uma referência para seu domínio pai de volta para Workstation1.

5. Workstation1 contacta um controlador de domínio no ForestRootDC1 (o seu domínio pai) para obter uma referência a um controlador de domínio (ForestRootDC2) no domínio raiz da floresta de wingtiptoys.com.

6. Workstation1 contacta ForestRootDC2 na floresta de wingtiptoys.com para um bilhete de serviço para o serviço solicitado.

7. 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.

8. ForestRootDC2 envia a referência para usa.wingtiptoys.com de volta para Workstation1.

9. Workstation1 entra em contato com o KDC em ChildDC2 e negocia o tíquete para o User1 obter acesso ao FileServer1.

10. Depois que 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 User1e constrói um token de acesso de acordo.

Objeto de domínio confiável

Um TDO (Trusted Domain Object) armazenado no contêiner System dentro de seu domínio representa cada domínio ou confiança de floresta dentro de uma organização.

Conteúdo TDO

As informações contidas em um TDO variam dependendo de o TDO ter sido criado por um trust de domínio ou por um trust 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 entre florestas, os domínios raiz da floresta em cada floresta têm conhecimento das relações de confiança que estão estabelecidas em todos os domínios das 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 que vão em direções opostas, o processo ocorre duas vezes para relações de confiança bidirecionais.

Um trust tem um lado confiador e um lado confiável. No lado seguro, 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:

1. 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.

2. O emulador PDC no domínio que confia define o campo OldPassword do objeto TDO com o campo NewPassword atual.

3. O emulador PDC no domínio confiável define o campo NewPassword do objeto TDO para 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.

4. 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.

5. O controlador de domínio no domínio confiável altera a senha de confiança para a nova senha.

6. 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 Active 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 Net Logon mantém um canal seguro de um computador com 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, 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 de Floresta, as informações de confiança incluem o registro Informações de Confiança da Floresta (FTInfo), 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.

Autoridade 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 Active Directory, Netdom e Nltest para expor, criar, remover ou modificar relações de confiança.

• Domínios e Relações de Confiança do Active Directory é a Microsoft Management Console (MMC) usada 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 dos 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.