Join Log in
Score:0
avatar Server

Setting up a trust to an AD environment with DCs on premise and in Azure, how can I limit AD traffic to only the on-premise DCs?

us flag
R C

We are setting up a trust between a stand-alone on-premise domain (DMZ from now on) and a corporate domain which is AD/AAD (synched) (CORP from now on) so that users from CORP can log into servers joined to DMZ. To be clear, they're on separate forests.

My intention is to set up an external, non-transitive trust from DMZ to CORP.

Now, the thing is - the CORP domain has two domain controllers on-premise, and two domain controllers as VMs in Azure... I would like to avoid having to add two firewall rules (one for the on-premise DCs, one for the Azure DCs.) How could I limit any AD traffic from DMZ to CORP to only hit the on-premise CORP DCs, or would that not be desirable for any reason besides redundancy?

I'm guessing if possible this will have to do with the CORP AD configuration under sites and services, in which case I may have a few follow-up questions :)

Thanks in advance and apologies for the noob-ness.

37
0 + 0
cn flag
Greg Askew
I'm not sure why DC's in Azure would be reachable from an on-premises DMZ. If those DC's are for use in Azure, the global DNS records should not be registered (mnemonics).
0
Reply
us flag
R C
This is an inherited setup. The cloud DCs are there for other azure VMs, but also with the stated purpose of improved redundancy... which doesn't make a whole lot of sense to me (it'd only be useful if all our on premise DCs go down, which would be incredibly unlucky)
0
Reply
cn flag
Greg Askew
Any DC may service clients. Typically if there is a branch office/location where a DC should only service local clients, DNS SRV records and same as parent records should not be registered. If they are registered, that is how DC's advertise to any and ALL clients to use them for service. It's possible to influence traffic with site link costs and policy settings, but not control or prevent flow in a vanilla Windows environment without adopting some network control (firewall/IPSEC).
0
Reply
Score:0
4snok avatar Server
es flag
4snok

If AAD you mean Azure AD, then you have nothing to worry about. AD and AAD are two completely different systems, they use an intermediate tool (AD connect) to sync data between them. Basically, your DNZ domain controllers will know nothing about AAD.

0 + 0
us flag
R C
You're absolutely correct - maybe I should remove the mention of AAD for clarity... The problem is that the CORP domain has four domain controllers - two of them on premise, two of them VMs on Azure. I've changed the question and edited the text so that's clearer (before it just said we had DCs on premise and on Azure).
0
Reply
4snok avatar
es flag
4snok
You can control AD trust traffic with DNS SRV records for CORP DCs. https://social.technet.microsoft.com/Forums/en-US/28f8884f-c073-41e0-b2ee-0dbb2dff5a1f/forest-trust-dnsdcs-visibility?forum=winserverDS
0
Reply
us flag
R C
Than you, those links are very useful. Both that and this link, which they led to indirectly, helped answer a few of the background questions I had: https://techcommunity.microsoft.com/t5/ask-the-directory-services-team/domain-locator-across-a-forest-trust/ba-p/395689
0
Reply
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.