There are an ever increasing number of scenarios out there in the business world where two different companies, or company divisions, may be using Active Directory for their directory service but may not be setting up an actual trust between the two. A more common reason for that is the different company idea-two different companies need to be able to have users access resources in each other’s environments but must minimize that access as much as possible.
A hypothetical business scenario for that would be a washing machine manufacturer needing access to its part suppliers in order to communicate needs and feedback for parts-two disparate organizations which must cooperate to a certain extent as part of their business model. If that example was a company that made its own parts for the washing machines then it could have an intraforest domain for the parts division(s), but in the case of an external parts supplier it would be an external or cross forest Trust (the capital T will be used throughout this blog post to indicate the Active Directory Trust-not the state of mind) which goes well beyond the actual trust (meaning the feeling, not the IT word) you have in that supplier.
I’ve been involved in many scenarios over the years that could have been avoided by limiting the trust based on the following rule: The guideline for whether to establish a Trust, and which Trust to do, with another organization is that it should never exceed the practical trust you have in who you are Trusting.
Though not the topic of today’s blog post I want to point out that we have an awesome product that fills this gap perfectly: Active Directory Federated Services (ADFS) .
So what do you do if you haven’t had the opportunity yet to roll out ADFS but still need access to another organization’s resources, or need to allow access to yours? Though not recommended, you could use “pass through” authentication and create user accounts of the same name and password in the two environments and use them to allow access. This would not work when Kerberos is the authentication mechanism but it’s unlikely that Kerberos will work anyway barring a cross forest trust. And certainly there are other methods.
There’s an additional aspect to configuring Trusts, though, that is normally not thought of until you notice it’s absence. That is that accessing those resources across a Trust is typically a pretty quick action. Much of that flows as a result of the requirements Active Directory Trusts have for DNS name resolution.
Picture a series of actions that kick off when a client in organization A tries to access a resource in organization B with a network topology that meets somewhere but without a Trust or Federation. We’ll use the example of connecting to the opposite domain and running a scripted LDAP query (maybe to create objects, perhaps to query for attribute values of objects) which passes in a URL like LDAP://domain1.forestb.com from our organization A client. We need to find the IP address of a server which answers to that moniker, don’t we?
So, in the absence of an AD Trust, and its DNS requirement, what’s there to keep an access from one organization from taking a longer time than necessary as the query to locate domain1.forestb.com goes hither and yon throughout the network-and perhaps even out to the Interwebs-to get resolved for this client?
Consider the delay that may ensue as the client attempts to find the remote DC’s IP.
Now let’s consider a way that we may be able to make answer to that DNS query quicker-or successful depending on your situation.
A basic requirement for network access of the two organizations is that they must have some network location where the two organizations mutually connect. To get things to work quicker the solution is to you must start by having a DNS server that both organizations mutually forward to, perhaps in that network location or DMZ where they coincide.
Well, that will get it to work but that would probably not be as quick as connecting to a resource in your own organization. To speed that up you can do a little trick that we’ll call “fooling the DC Locator”.
I’ve talked about the DC Locator code a bit in other blog posts, mostly in discussions of other behaviors and issues. The DC Locator runs in the Netlogon service of every Windows computer and is used to keep a running tab of where the closest domain controllers are and whether they are responsive.
A lot more detail on the DC Locator process is here . I encourage any person who is tasked with administering Active Directory to spend time reading the above link. It may occasionally come in handy as a reference as well.
For the purposes of our scenario the portion below is most relevant (taken from the Technet link above):
Domain Controller Location in the Closest Site
During a search for a domain controller, the Locator attempts to find a domain controller in the site closest to the client. When the domain that is being sought is a Windows Server 2003 domain, the domain controller uses the information stored in Active Directory to determine the closest site. When the domain being sought is a Windows NT 4.0 domain, domain controller discovery occurs when the client starts and uses the first domain controller that it finds.
Each Windows Server 2003–based domain controller registers DNS records that indicate the site where the domain controller is located. The site name (the relative distinguished name of the site object in Active Directory) is registered in several records so that the various roles the domain controller might perform (for example, global catalog server or Kerberos server) can be associated with the domain controller’s site. When DNS is used, the Locator searches first for a site-specific DNS record before it begins to search for a DNS record that is not site-specific (thereby preferentially locating a domain controller in that site).
A client computer stores its own site information in the registry, but the computer is not necessarily located physically in the site associated with its IP address. For example, a portable computer that was moved to a new location could contact a domain controller in its home site, which is not the site to which the computer is currently connected. In this situation, the domain controller looks up the client site on the basis of the client IP address by comparing the address to the sites that are identified in Active Directory, and then returns the name of the site that is closest to the client. The client then updates the information in the registry.
Why is that some important? Because of the importance of finding a domain controller in an AD site which is close to the client. That seems like a non sequitur since if the two organizations are not in the same forest then they couldn’t possibly have a common Active Directory site or DCs within that same site, but the client has a routine behavior that requires it to check.
So, if you were to create a site in organization A which matches the name of the site in AD for organzation B (where our target server5.domain1.forestb.com resides) then the DNS query the client will use to locate that server will be answered much more quickly.
Here are the reasons for that:
1) The DNS server to answer the query is present (even if just by a forwarder).
2) The client constructs it’s DNS query exactly as if it was a client in organization, or forest, B.
Why does the second reason occur? Because we first try a DNS query to find a DC within the same AD site as the client. Under the hood the initial query to find a domain controller to respond to the client needs consists of two basic parts: the destination domain for the resource (supplied in our LDAP URL), and the AD site the client resides in.
These two parts are combined into a DNS query for a site specific SRV record which matches like _ldap._tcp.SiteName._sites.dc._msdcs.DnsDomainName . In our case, if the site we created in both organizations was named Tacoma, then the client would query for _ldap._tcp.Tacoma._sites.dc._msdcs.domain1.forestb.com . Since this is an actual record that exists on the DNS server (or one that we forward to) the response will be answered much more quickly than a query which asks for an AD site that doesn’t exist at all in the destination domain.
Active Directory was not designed or tested for this behavior to be used in that way but it can work well sometimes for that need. The best thing to do, when you are in a situation where you must give limited access to a partner organization is to decide whether you trust that other organization enough for a Trust, or to set up and use ADFS to fill your needs. Either resolution is more robust and (and tested!) to work far better than fooling your DNS topology to speed up your queries.
Microsoft
