If you use a DOMAIN LOCAL group, you'll be able to add the users from both domains to the one group.
Better still, add a Global/Universal group from the BRANCH domain (and the same from the CENTRAL domain) to the Domain Local group:
CENTRAL DOMAIN
SPECIAL GROUP
CENTRAL\Alice
CENTRAL\Bob
BRANCH DOMAIN
SPECIAL GROUP
BRANCH\Carol
BRANCH\dave
CENTRAL DOMAIN
JOINT DOMAIN LOCAL GROUP
CENTRAL\Special Group
BRANCH\Special Group
That way, adding new members to the JOINT group just means adding them to the global group within their domain.
This has been a fun topic of discussion on Server Fault. There appear to be varying "religious views" on the topic.
I agree with Microsoft's recommendation: Use a sub-domain of the company's already-registered Internet domain name.
So, if you own foo.com
, use ad.foo.com
or some such.
The most vile thing, as I see it, is using the registered Internet domain name, verbatim, for the Active Directory domain name. This causes you to be forced to manually copy records from the Internet DNS (like www
) into the Active Directory DNS zone to allow "external" names to resolve. I've seen utterly silly things like IIS installed on every DC in an organization running a web site that does a redirect such that someone entering foo.com
into their browser would be redirected to www.foo.com
by these IIS installations. Utter silliness!
Using the Internet domain name gains you no advantages, but creates "make work" every time you change the IP addresses that external host names refer to. (Try using geographically load-balanced DNS for the external hosts and integrating that with such a "split DNS" situation, too! Gee-- that would be fun...)
Using such a subdomain has no effect on things like Exchange email delivery or User Principal Name (UPN) suffixes, BTW. (I often see those both cited as excuses for using the Internet domain name as the AD domain name.)
I also see the excuse "lots of big companies do it". Large companies can make boneheaded decisions as easily (if not moreso) than small companies. I don't buy that just because a large company makes a bad decision that somehow causes it to be a good decision.
Best Answer
You need to be able to resolve the FQDN of the active directory that you wish to trust and also one or more domain controllers in that environment as well. This is typically done with either a DNS conditional forwarder that points to one or more of their DCs, or a stub zone.
If you do not have working name resolution between the two environments, you cannot create a trust.