AD Autenticação entre florestas - grupos ausentes do PAC

Question

Eu tenho uma configuração do Active Directory que consiste em duas florestas:

• 1 floresta de vários domínios com 1 domínio raiz da floresta e 2 domínios filho diretos
• 1 floresta de domínio único para fins de publicação da DMZ

Eu criei três relações de confiança de saída no domínio da DMZ, uma confiança de floresta transitiva no domínio raiz da floresta e duas relações de confiança externas não transitivas (também conhecidas como Trusts de atalho).

Todos os DCs em todos os quatro domínios são servidores de catálogo global.

Eu tentei visualizá-lo abaixo:

Agora, aqui está o problema. Quando eu garanto o acesso em um recurso em dmzRoot.tld a um grupo de segurança no domínio childA , ele funciona para usuários em childA que são membros do grupo Segurança, mas não para usuários no domínio childB , mesmo embora eles sejam membros do grupo de segurança em childA .

Digamos que eu queira conceder ao administrador local acesso a um servidor membro no dmzRoot.tld , por exemplo. Eu adicionei childA.ForestRoot.tld\dmzAdministrators ao grupo Administradores internos do servidor membro.

childA.ForestRoot.tld\dmzAdministrators tem os seguintes membros:

• childA \ dmzAdmin
• childB \ superUser

Agora, se eu autenticar como childA\dmzAdmin , posso fazer logon no servidor integrante como administrador local e, se eu der uma olhada na saída de whoami /groups , o grupo childA.ForestRoot.tld\dmzAdministrators estará claramente listado. / p>

Se eu autenticar como childB\superUser , no entanto, recebo uma mensagem informando que a conta não está autorizada para logon remoto. Se eu verificar whoami /groups para a conta childB\superUser , o grupo childA.ForestRoot.tld\dmzAdministrators NÃO está listado.

Parece quase como se o grupo childA SID nunca fosse incluído no PAC ao autenticar childB usuários, mesmo que todos os DCs sejam do GC.

Desativei a validação do PAC na máquina em dmzRoot.tld que testei, mas isso não ajudou.

Alguma sugestão sobre como eu soluciono isso de forma eficaz? Como faço para seguir o rastro de autenticação para determinar onde ele falha?

    

Answer 1

Acontece que as relações de confiança de atalho estavam causando o problema.

Quando a autenticação Kerberos do AD percorre domínios, a região de destino (por exemplo, dmzRoot.tld ) identifica uma relação de confiança através da qual a região de origem dos usuários (por exemplo, childA.ForestRoot.tld ) é um domínio confiável.

Como a confiança de floresta transitiva em relação a ForestRoot.tld e a confiança externa (atalho confiança) em direção a childA corresponde a essa condição, a região de destino precisa escolher uma e a confiança de atalho tem precedência (porque é explícita) sobre a relação de confiança implícita na confiança da floresta.

Como a quarentena do filtro SID está ativada nas relações de confiança de saída Por padrão, somente os SIDs do domínio confiável (neste caso, o domínio childA ) serão honrados na autenticação, os SIDs externos serão filtrados.

Em conclusão, existem duas soluções para isso:

• Remova as relações de confiança externas e confie na confiança da floresta. Como a confiança da floresta é transitiva, todos os SIDs de toda a floresta permanecerão em seu token.
• Desative a Quarentena do Filtro SID na confiança de saída do dmzRoot.tld domínio

Espero que tenha sentido