Compartilhamento de pasta do Windows 2008 R2 em exibições de domínio Desconhecido Contato

Question

[Windows Server 2008 R2 SP1, os hotfixes mais recentes em 15 de março de 2013] . Eu tenho um grupo de segurança chamado "IT" em Domain1. Eu tenho um servidor2 no domínio2. Existe uma relação de confiança unidirecional do domínio1 no domínio2. Eu quero compartilhar uma pasta chamada "Apps" no servidor2 para que o grupo de TI no domínio 1 possa acessá-lo. Eu estou compartilhando com sucesso, mas algo é estranho. Quando adicionei originalmente Domain1 \ IT como um grupo para acessar a pasta compartilhada, ela aparecia com o ícone e o texto corretos na caixa de diálogo de compartilhamento. Mas quando eu reabrir a caixa de diálogo Compartilhamento para analisar as permissões, levará um longo muito tempo para enumerar e, finalmente, exibirá um? ícone, com o texto "< Contato desconhecido >". A pasta compartilhada é acessada corretamente pelo grupo de TI no Domain1, mas isso me faz sentir que algo está errado. Alguém sabe por quê?

    

Answer 1

When a trust is established between a domain in a forest and a domain outside of that forest, security principals from the external domain can access resources in the internal domain. Active Directory creates a foreign security principal object in the internal domain to represent each security principal from the trusted external domain. These foreign security principals can become members of domain local groups in the internal domain. Directory objects for foreign security principals are created by Active Directory and should not be manually modified. You can view foreign security principal objects from Active Directory Users and Computers by enabling advanced features.

Portanto, o seu "Contato Desconhecido" é conhecido como entidade de segurança estrangeira no Domain2. Existe um contêiner no contexto de nomenclatura padrão do seu diretório em CN=ForeignSecurityPrincipals,DC=domain2,DC=com . Dentro desse contêiner devem estar os ponteiros que o Active Directory usará para resolver todas as pessoas do Domínio1 que são conhecidas pelo Domínio2. Domínio2 conhece os SIDs, mas tem que pedir Domain1 para traduzir esse SID em um SamAccountName.

Como sua confiança é unidirecional, o Domain2 não pode fazer isso porque o Domain1 não confia nele.

Você pode habilitar a tradução anônima do SID no domínio 1, mas isso é um risco de segurança. Ou você pode confiar em você de duas maneiras.

O que você tem agora, "Contato Desconhecido" não impede que nada funcione como você percebeu, pois o SID é suficiente para verificar a confiança da floresta. É apenas um tipo de problema estético agora.

Mais documentação da MS:

Implementation

LookupAccountSid will call into LsaLookupSids with a single SID to resolve. So LsaLookupSids is covered in this section.

LSA on the computer that the call is sent to (using the LSA RPC interface) will resolve the SIDs it can map and send on the remaining unresolved SIDs to a domain controller in the primary domain. The domain controller will resolve additional SIDs to account names from the local database, including SIDs found in SidHistory on a global catalog.

If SIDs cannot be resolved there, the domain controller will send remaining SIDs to domain controllers in a trusted domain where the domain part of the SID matches the trust information.

E, finalmente, esta parte do blog AskDS da Microsoft (que é um ótimo blog):

Assuming the ports are open, there is some other piece blocking the translation. Most commonly, we will see this when there is a one way trust involved and anonymous translations are blocked. You can easily allow anonymous SID/Name translation in Group Policy. This policy is only applied to Domain controllers since they are the servers that will actually process the translation request.

link

Editar: Como solução alternativa, você pode considerar a criação de um grupo de segurança no Domínio2 chamado "Pessoas que podem acessar o Apps no Servidor2" e adicionar os objetos do domínio1 ao grupo.