4

[Windows Server 2008 R2 SP1, latest hotfixes as of March 15, 2013]. I have a security group called "IT" in Domain1. I have a server2 in Domain2. There is a one-way trust from Domain1 into Domain2. I want to share a folder called "Apps" on server2 so that the IT group on Domain1 can access it. I am successfully sharing, but something is weird. When I originally added Domain1\IT as a group to access the shared folder, it showed up with correct icon and text in the sharing dialog. But when I re-open the Sharing dialog to review the permissions, it take a very long time to enumerate, and then finally shows a ? icon, with the text "<Unknown Contact>". The shared folder is correctly accessible by the IT group in Domain1, but this makes me feel that something is wrong. Anyone know why?

Sharing dialog - Win2008R2

0

1 Answer 1

5

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.

So your "Unknown Contact" is what's known as a foreign security principal in Domain2. There is a container in the default naming context of your directory at CN=ForeignSecurityPrincipals,DC=domain2,DC=com. Inside that container should be pointers that Active Directory will use to resolve all the people from Domain1 that are known to Domain2. Domain2 knows the SIDs, but it has to ask Domain1 to kindly translate that SID into a SamAccountName.

Because your trust is one-way, Domain2 can't do that because Domain1 doesn't trust it.

You could enable anonymous SID translation in Domain1, but that's a security risk. Or you could make your trust 2-way.

What you have now, "Unknown Contact" isn't preventing anything from working as you have noticed, as the SID is sufficient to check forest trust. It's just kind of an aesthetic problem right now.

More MS documentation:

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.

And finally, this bit from the Microsoft AskDS blog (which is a great blog btw):

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.

http://blogs.technet.com/b/askds/archive/2011/07/28/troubleshooting-sid-translation-failures-from-the-obvious-to-the-not-so-obvious.aspx

Edit: As a workaround, you could consider creating a security group in Domain2 called "People who can access Apps on Server2" and add the user principals from Domain1 to that group.

1
  • Thanks Ryan. Good to know that it's more of an aesthetic issue. I like the workaround you suggest about adding specific principals from Domain1 to a Security Group in Domain2. Domain2 is actually a DMZ, so my other options are limited for security reasons. Good blog post too. Mar 18, 2013 at 19:26

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .