• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1109
  • Last Modified:

Active Directory Design with Child domain authenticating to Parent Domain

We are designing Active Directory and had some questions pertaining to authentication and child domains.

Here is the synopsis:

One parent domain, in its own subnet, with one DC
Four child domains, in their own subnets, with their own respective DC.
One DHCP server residing in the parent domain with scopes defined for all 5 subnets and an "IP Helper Address", with the DHCP server's IP address, defined on the Routers Child domain interface.
All five subnets are seperated by routers with Fast Ethernet interfaces (e.g. fa0/0 & fa0/1).

If a "Child Domain's DC" goes offline in any of the child subnets:
1. Can servers & workstations, in the child domain, authenticate with the parent domains DC without any manual intervention by IT Staff?
2. What ports need to be enabled on the routers fa0/0 & fa0/1 interfaces if Number 1 is true?
3. What other issues such as DNS & DHCP might be at risk in this scenario if Number 1 is true?

Thank you,

Tom
0
mcit0331
Asked:
mcit0331
1 Solution
 
Toni UranjekConsultant/TrainerCommented:
Techicaly users are the one being authenticated. If DC for domain is not available, you can not authenticate, but you might still logon with cached credentials. User from child domain can't authenticate on DC in root domain. So the answer to your first question is: No!

HTH

Toni
0
 
stronglineCommented:
below is  just my thought, comments are welcome.

Cached logon will certainly work if a computer is unplug from the corp network, but whether it will be triggered when it's plugged into the network while DC is offline is yet to be tested.

windows clients records it's dns suffix when it last got GPO applied
to determine if it's connected to domain, it compares its current active dns suffixes to what is recorded. if it matches, that it considers itself being connected to a managed network (aka domain)

regardless, the answer to Tom's question will be the same, thought. Parent DC will never authenticate child domain users.
0
 
Jay_Jay70Commented:
Often we come across the implementation of chilfd domains where they are not needed, are you certain that you need 4 child domain> thats pretty serious configuration and unless specifically required, you could make life a lot easier by having a single domain with 5 sites
0
 The Evil-ution of Network Security Threats

What are the hacks that forever changed the security industry? To answer that question, we created an exciting new eBook that takes you on a trip through hacking history. It explores the top hacks from the 80s to 2010s, why they mattered, and how the security industry responded.

 
mcit0331Author Commented:
Hello Jay_Jay70,

Thank you very much for your input.

A Single domain with separate sites, as you mentioned, for the "former" domains was the other option that we were tossing around. However our concern is to keep the other sites/"old domains" from browsing each other's resources such as network printers, shares, accounting servers, etc. and 1 parent domain and 4 child domains satisfied this security requirement as it represented a security boundary.

We know we can inhibit access to these resources with the proper setting of NTFS permissions and ABE "Access Based Enumeration" but what else can you recommend to prevent users from snooping around the other sites?

However, here is the fly in the ointment. Some of our Legacy software, and yes what have already complained to their developers, needs the "Everyone Group" to have "Full Access". Once again and even more important need to prevent users from snooping.

I would love to flatten our hierarchy and make IT's life easier without child domains and fewer servers what can we do?

- Tom
0
 
Jay_Jay70Commented:
I understand your predicament in light of that info i think you have probably made the right decision.

However, for the sake of it lets take a look at

a) what is it you are trying to stop your users looking at? In reality a simple set of NTFS permissions with some group configuration based on a "per" site configu, should pretty much be able to knock out snooping....

b) Your legacy appz that require the everyone group.....fine, lets segment those appz into a folder that can be open to everyone - doing that allows access for the app but also allows us to start locking down all other areas

Are these ideas feasible or are we fighting a futile battle?

James
0
 
mcit0331Author Commented:
James,

I am focusing on item a) above dealing with [NTFS permissions with some group configuration based on a "per" site config].

Our intention is to create a separate site and OU for each "Old Domain" to segment each OU/Site from each other and  move users, workstations, & member servers into their respective OU/Former Domain.

Are you saying that I can create an ACL, similair to a Cisco Router, within each site's properties to explicitly deny the other OU's users.

- Tom
0
 
Jay_Jay70Commented:
not exactly, i was thinking more along the lines of a single group for eash site...say all members of site a belong to group siteA   ..in site A you configure you permissions using the SiteA group and thats it...Site B has a similar config and so do sites C and D
0

Featured Post

VIDEO: THE CONCERTO CLOUD FOR HEALTHCARE

Modern healthcare requires a modern cloud. View this brief video to understand how the Concerto Cloud for Healthcare can help your organization.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now