Como as relações de confiança funcionam para florestas no Active Directory (versão prévia)

O Active Directory Domain Services (AD DS) fornece segurança em múltiplos 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 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 calcula 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 pelo modelo de segurança distribuída do Windows criam um ambiente propício para a operação de relações de confiança de domínio e entre florestas. Para que essas relações de confiança funcionem corretamente, cada recurso ou computador deve ter um caminho de confiança direta para um DC no domínio no qual ele está localizado.

O serviço Net Logon implementa o caminho de confiança usando uma 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 do AD DS por meio de relações de confiança de interdomínio. Esse canal protegido é usado para obter e verificar informações de segurança, incluindo SIDs (identificadores de segurança) para usuários e grupos.

Nota

Os Serviços de Domínio dão suporte a 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 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.

Fluxos de relação de confiança

O fluxo de comunicações protegidas sobre relações de confiança determina a elasticidade de uma confiança. Como você cria ou configura uma relação de confiança determina até que ponto a comunicação se estende dentro ou entre florestas.

A direção da confiança determina o fluxo de comunicação sobre as relações de confiança. 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 em Árvore 1 e Árvore 2 têm relações de confiança transitivas por padrão. Como resultado, os usuários no Árvore 1 podem acessar recursos em domínios no Árvore 2 e os usuários no Árvore 2 podem acessar recursos no Árvore 1, quando as permissões adequadas são atribuídas ao recurso.

diagrama

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 domínio A e domínio B, os usuários no domínio A podem acessar recursos no domínio B. Por outro lado, 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 no domínio B e 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 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 é criada automaticamente entre o novo domínio filho e o domínio pai.

Relações de confiança transitivas e não transitivas

A transitividade determina se uma relação de confiança pode ser estendida 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 confiança não transitiva pode ser usada para negar relações de confiança com outros domínios.

Sempre 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 por meio de uma árvore de domínio conforme 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 contas de qualquer domínio na floresta possam ser autenticadas por qualquer outro domínio na floresta. Com um único processo de entrada, as contas com as permissões apropriadas podem acessar recursos em qualquer domínio na floresta.

Trusts florestais

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. Os fundos florestais são úteis para provedores de serviços, empresas que passam por fusões ou aquisições, extranets de negócios colaborativas e empresas que buscam uma solução para a 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 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. As relações de confiança de floresta só podem ser criadas entre duas florestas e não podem ser implicitamente estendidas para uma terceira floresta. Esse comportamento significa que, se uma relação de confiança de floresta for criada entre Floresta 1 e Floresta 2, e outra relação de confiança florestal for criada entre Floresta 2 e Floresta 3, Floresta 1 não terá uma relação de confiança implícita com 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 usuários no Forest 1 acessem recursos no Forest 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. No entanto, a confiança funciona 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 um trust de floresta, você precisa verificar se tem a infraestrutura correta do DNS (Sistema de Nomes de Domínio). As relações de confiança entre florestas só podem ser criadas quando uma das seguintes configurações de DNS está 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. Hospedar um namespace DNS diferente do namespace DNS da floresta não é um recurso do Microsoft Entra Domain Services. 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 precisam conhecê-las. Membros de administradores corporativos em ambas as florestas podem criar as relações de confiança em ambas as florestas ao mesmo tempo e, nesse cenário, uma senha que é criptograficamente aleatória é gerada e gravada automaticamente 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. Um usuário com os privilégios observados anteriormente no Active Directory local precisa configurar a relação de 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 floresta para concluir diversas tarefas. Esta seção descreve os processos e interações que ocorrem à medida que os recursos são acessados entre ambientes de confiança e as referências de autenticação são avaliadas.

Visão geral do processo de encaminhamento 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 confiança e se a confiança é transitiva ou não devem ser determinadas 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 indicações para autenticação em um domínio de forma diferente

Processo de encaminhamento pelo Kerberos V5

O protocolo de autenticação Kerberos V5 depende do serviço net logon em controladores de domínio para informações de autenticação e autorização do 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 Kerberos V5 para autenticação, ele solicitará um ticket 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 encaminhada:

1. O domínio solicitado possui relação de confiança direta com o domínio atual?

   • Em caso afirmativo, envie ao cliente uma referência para o domínio solicitado.
   • Se não, vá para a próxima etapa.

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?

   • Em caso afirmativo, 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.

Processo de encaminhamento pelo NTLM

O protocolo de autenticação NTLM depende do serviço Net Logon em controladores de domínio para informações de autenticação e autorização do cliente. Esse protocolo autentica clientes que não usam a autenticação Kerberos. O NTLM usa trusts 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. Esse servidor cria um desafio ao qual o cliente responde. Em seguida, o servidor envia a resposta do usuário a um controlador de domínio em seu domínio de conta de computador. Esse controlador de domínio verifica a conta de usuário em relação ao 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 deve executar 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 enviará as credenciais do cliente para um controlador de domínio no domínio do usuário para autenticação de passagem.
   • Se não, vá para a próxima etapa.

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. 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.
   • Se não, envie ao cliente uma mensagem de acesso 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.

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, o login deve 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 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, 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 do tíquete de serviço e continua seguindo a cadeia de referência até chegar ao 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 computadores que executam o Windows tentam acessar recursos de um computador localizado em outra floresta.

Diagrama de floresta de confiança

1. User1 faz login 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.

2. A Workstation1 entra em contato com o KDC do Kerberos em um controlador de domínio em seu domínio, ChildDC1e solicita um tíquete de serviço para o SPN do FileServer1.

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

   Dicas de roteamento ajudam a direcionar 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 o catálogo global, não conseguem localizar um SPN.

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

5. A Workstation1 entra em contato com um controlador de domínio em ForestRootDC1 (seu domínio pai) para obter um encaminhamento a um controlador de domínio (ForestRootDC2) no domínio raiz da floresta wingtiptoys.com.

6. A Workstation1 contata a ForestRootDC2 na floresta wingtiptoys.com para um tíquete de serviço ao serviço solicitado.

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

8. Em seguida, a ForestRootDC2 envia o encaminhamento para usa.wingtiptoys.com de volta para a Workstation1.

9. A Workstation1 entra em contato com o KDC no FilhoDC2 e negocia o tíquete do Usuário1 para obter acesso ao FileServer1.

10. Depois que Workstation1 tiver um tíquete de serviço, ele envia o tíquete de serviço para FileServer1, que lê as credenciais de segurança de User1e constrói um token de acesso de acordo.

Objeto de domínio confiável

Um TDO (Objeto de Domínio Confiável) armazenado no contêiner System dentro de seu domínio representa cada domínio ou confiança de floresta em uma organização.

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 confiança de domínio é criada, atributos como o nome de domínio DNS, o SID de domínio, o tipo de confiança, a transitividade de 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, sufixos UPN (nome principal de usuário), sufixos SPN (nome principal de serviço) e namespaces SID (identificador de segurança).

Como as relações de confiança são armazenadas no Active 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 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 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.

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 confiável, o emulador PDC executa a alteração de senha.

Para alterar uma senha, os controladores de domínio completam o seguinte processo:

1. O emulador do 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. Ele é sempre iniciado pelo emulador de PDC do domínio confiante.

2. O emulador de PDC no domínio confiante define o campo OldPassword do objeto TDO para 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 possibilita 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 de uma solicitação ser feita que use 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 de confiança como 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 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 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 talvez 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 ela tenha sido autenticada com êxito (configurar um canal seguro) usando a nova senha. Esse comportamento é o motivo pelo qual as senhas antigas e novas 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 senha armazenada antiga pode ser usada no canal protegido até que o controlador de domínio no domínio confiável receba a nova senha, permitindo assim o 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 for autenticado com êxito com a senha antiga, ele retomará 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 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, ela 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 trusts

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 isso ocorrer, você pode encaminhar o tráfego de confiança por meio de um firewall ou abrir portas específicas no firewall para permitir que o tráfego passe.

Importante

O Active Directory Domain Services não dá suporte à restrição do tráfego RPC do Active Directory a 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.

Ferramentas e serviços de suporte

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 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 Net Logon ajuda a manter senhas de confiança, coleta informações de confiança e verifica as 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 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 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 Net Logon para o domínio confiável para verificação.

• Verificação do PAC (Certificado de Atributo privilegiado) – 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 seguro para seu controlador de domínio para verificação.

Autoridade de Segurança Local

A LSA (Autoridade de Segurança Local) é um subsistema protegido que mantém informações sobre todos os aspectos 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 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 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.