Domain Trust Not Validating

In this scenario, there are 3 machines, Machine 1 and 2 are each domain controllers for Domain A. Machine 3 is a domain controller for Domain B. I want a one-way trust to be setup so that domain admins in Domain A can administer specific resources in Domain B.

The rub here is the way Machines A and B have been configured (misconfigured). Each are multihomed. Machine 1 is set with its primary NIC to be on Subnet 1. Machine 2 is set with its primary NIC to be on Subnet 2. All 3 of the machines can ping the other 2.

All machines can nslookup the other 2, forward lookup zones have been placed in each DNS for the other Domain. The Name Server assigned to the forward lookup zone that has been added is the Domain Controller responsible for that domain and it is correctly resolving.

Machine 3 is on Subnet 2 and is not multi-homed.

The trust can be setup and validated from Machine 3, but users from Domain A cannot be added to a group in Domain B. When attempting to add users or groups from Domain A into a Group on Domain B, only Domain B can be seen in the tree that is offered. This is true even though the trust has been validated. When the trust is tested (validated) from either Machine 1 or 2, it fails. If setting up the trust is initiated from Machines 1 or 2, it fails, says it cannot find a domain controller for Domain B.

I"m looking for either a way to unwind the misconfigured Machines A and B, but still service subnets 1 and 2 with Domain A. Or a completely new configuration that allows the selective authorization one-way incoming trust to work the way it is supposed to.
rdpcloudAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Bruno PACIIT ConsultantCommented:
Hi,

Just to be sure... In which DomainB group do you try to add users or groups from DomainA ??? Is it a global or local group ? You can not add a foreign account or group in a global group...

Also, as you want a One Way trust relationship are you sure you've not create the trust in the wrong way ?

Have a nice day
0
rdpcloudAuthor Commented:
Thanks for your reply PaciB,

Interestingly, I can successfully create an outgoing trust from Domain B to Domain A. A local domain group in Domain B will accept the addition of a group from Domain A. I can successfully login to Domain B using Domain A accounts. The problem occurs when I try to connect to Domain A from Domain B. If I try to create an outgoing trust from Domain A, I cannot even resolve Domain B, though I can ping it. Very Strange indeed. Domain B is serviced by a single Domain Controller with a single NIC, Domain A has  a very different architecture, I'll revisit its configuration(misconfiguration).

The configuration (misconfiguration) of the Machine's 1 and 2 in Domain A:
We are very interested in this setup, we inherited it and would like to reconfigure it or at least understand it. There are 3 variables to consider, DNS, Active Directory, and IP. We are looking for input concerning a proper setup for Active Directory in an environment where there are 2 subnets and 2 Domain Controllers, must there be a router connecting the two subnets?  It looks like this setup was designed to dodge the need for a router. The 2 Domain Controllers servicing those two subnets are multi-homed in what looks like a sort of "Pushme/Pullyou" type archtecture. Each of the 2 Domain Controllers contains two NIC's, each of the 2 NIC's is directly connected to both subnets like this:

Machine 1:

NIC 1 192.168.1.3
DG=192.168.1.1
DNS=192.168.1.3

NIC 2 172.31.1.3
DG=None
DNS=none (dns is not bound to this second nic)

Machine 2:
NIC 1
172.31.1.100
DG=172.31.1.1
DNS=172.31.1.100

NIC 2
192.168.1.100
DG=None
DNS=None

It appears this architecture is used so the two domain controllers service clients on each of the 2 subnets and can still see each other, yet we are mystified as to the other drawbacks/advantages of this configuration. Microsoft warns against multi-homing DNS/Domain Controllers. We believe the fundamental challenge in "connecting to Domain B from Domain A" is related to this architecture. We are anxious to receive any feedback, insight, or comments anyone may have on this setup.
Thanks
0
Bruno PACIIT ConsultantCommented:
Hi,

Let me give you my personal feeling about your configuration.... Since 10 years I practive Active Directory for many customer project I HAVE NEVER SEEN that sort of strange and complicated configuration !!

First of all... The DC 1 has a default gateway on 192.168.1.x network while DC 2 has its default gateway on 172.31.1.X network !? I suppose that if you have gateways that means you have other equipments on other networks... OK, so in this case that means that DC1 can reach some network via 192.168.1.1 gateway that DC2 can not reach at all because it can not use the same gateway...

If your initial goal was to have DC redundancy for client computers in 2 subnet,  the best way (the simplest is always the best) would be to have a routeur making the link between the both networks and then one DC in each subnet... Doing like that, and by configuring the AD sites topology that matches this network topology, the client computers in one subnet would use their local DC primarily and use the second one on the second subnet in case of no answer of the first one...
You would not need 2 NICs on your DCs... Having 2 NICs can cause issues in AD replication if your DCs are also DNS servers (and they are) because when a DC is a DNS server you can NOT prohibit it to register all its IP address in the DNS zone... If one of the subnet is unreachable by a third DC this third DC have 1 chance of 2 to be isolated...

Anyway, I don't really understand what advantages your IP configuration can give you ? Is it for routeur redundancy ? Is it to avoid the need of a routeur ? In this last case what is 172.31.1.1 and 192.168.1.1 ?

About your trust relationship with Domain B... where exactly is the DC of this domain ? in which subnet ? If it's a third subnet what are the IP routes between all the subnets ?
When you said you can ping the Domain B, what have you pinged exactly ? a name ? an IP ?

Let us know more about your configuration to let us help you more

Have a good day.




0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
IT Pros Agree: AI and Machine Learning Key

We’d all like to think our company’s data is well protected, but when you ask IT professionals they admit the data probably is not as safe as it could be.

rdpcloudAuthor Commented:
Thank you PaciB for your insightful analysis, again I reiterate that this configuration was inherited by us, we did not create it, it may be some clever and complex solution to an unknown challenge our predecessor faced or evidence of incompletely trained architect. It wasn't documented, the rationale for implementing it doesn't seem to be available to us, either in written or in anecdotal form. We're trying to decide how exactly to cut it up so it works in harmony with Active Directory Best Practices, and near as we can tell, multi-homing DC/DNS machines is a non-supported architecture. For precisely the reasons you cite, "you can NOT prohibit a Domain Controller/DNS from registering ALL of its interfaces in the DNS zone (sic)" As a result of this inability to prevent Machine 1 from registering its Subnet 2 NIC in its forward lookup zone, there are many problems you could have, the one you pointed out about a possible third DC having a one in two chance of becoming isolated being among the worst outcomes you could face for multi-homing DNS/DC's.

To answer your question about DomainB, it's handled by a single domain controller on the 172.31.1.0/24 subnet. An outgoing one-way trust is successfully implemented from DomainB to DomainA (such that DomainA users may authenticate in DomainB). If this configuration were locked down such that you never changed it, would it fail? If so, under what circumstances?, other than its inflexibility in servicing any putative "Domain Controller 3".

It is my opinion that routing between Subnets 1 and 2 is not possible for several reasons, and that each must be visible by the same domain. Very Strange specification.... The fact remains, attempts to create outgoing trusts from DomainA to domains residing on subnet 2 in this configuration appear impossible...
0
rdpcloudAuthor Commented:
Hi PaciB,

Thanks for your insight, were you looking into this conundrum for deeper insight? I appreciate the information you provided in previous comments. Do you have any further comments? I'd like to award full points to you.

Let me know
0
rdpcloudAuthor Commented:
Grey and difficult to clearly focus on the exact problem in this case, this was an analysis of an existing installation with a design strategy and architectural discussion to accompany it. PaciB was able to discern where the weaknesses and possible unnecesary complexities of the submitted configuration lain. Not hearing back after engaging the conversation and submitting more information (as the quantity of information on the configuration was very large) leaves me only able to award a "good" and "partially solved" status to the question, I am happy to re-visit it if PaciB responds again. Thanks so much for the help and insight.
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Windows Server 2008

From novice to tech pro — start learning today.