Domain Delegation and Active Directory.
Justin Tyme
I'm experimenting with domain delegation.
Is this best used with Active Directory integrated or Primary only.
When used with active directory do you need to setup sub directory domains
as well?
Thanks
Herb Martin
> Is this best used with Active Directory integrated or Primary only.
DNS type is almost complete irrelevant to "Domain delegation" -- in
fact the parent Zone can use one type and the child zone(s) can use the
other or even a mix.
DNS type is a function of one ZONE and issues such as well as placement
of DNS servers should largely be considered in isolotation from OTHER
zones -- even when a DC holds multiple zones you should think of each
zone and it's own issues separately from other zones.
> When used with active directory do you need to setup sub directory domains
> as well?
[sub domains - not subdirectory domains]
The sub-domains are normally setup automatically during the first DCPromo
or upgrade of the domain from NT4 -- if not, then you must ensure they are
setup but generally this is best done by correcting problems and re-starting
NetLogon on the DCs to let the DCs handle it.
--
Herb Martin
Justin Tyme
The company has two offices currently operating using two domains;
company.com and Company-Region.com.
The goal is to consolidate the company domains using one main domain with
each location having control over their local DNS
server.
The proposed solution:
Implement a main domain "company.com" with each location having a domain
"regionA.company.com" and "regionB.company.com"
What I've tried so far:
= Config-1:
Create an AD Integrated company.com Zone. on computer-A
Create an AD integrated regionA.company.com on computer-A
Create an AD integrated regionB.company.com on computer-B
on Computer-A created an AD integrated delegation zone regionA added the
Computer-A NS record.
on Computer-A created an AD integrated delegation zone regionB added the
Computer-B NS record.
Question: because it's integrated I see the regionA & B replicated across
all DNS's
In this configuration is a delegated Zone necessary.
= Config-2:
Create an AD Integrated company.com Zone. on computer-A
Create an standard Primary regionA.company.com on computer-A
Create an standard Primary regionB.company.com on computer-B
on Computer-A create an delegation zone regionA added the Computer-A NS
record.
on Computer-A create an delegation zone regionB added the Computer-B NS
record.
= Config-3:
Create a Standard Primary company.com Zone. on computer-A
Create an standard Primary regionA.company.com on computer-A
Create an standard Primary regionB.company.com on computer-B
on Computer-A create an delegation zone regionA added the Computer-A NS
record.
on Computer-A create an delegation zone regionB added the Computer-B NS
record.
I'm not sure of the pro's and con's of each, and why and when I would use
one over the other.
Any advise is appreciated.
Thanks
"Herb Martin" <ne...@LearnQuick.com> wrote in message
news:%23PFIoKn...@TK2MSFTNGP09.phx.gbl...
Herb Martin
"Justin Tyme" <justi...@aol.com> wrote in message
news:ekX59qne...@TK2MSFTNGP09.phx.gbl...
> Thanks for the Reply:
Sure, happy to help you think it through.
> The goal is to consolidate the company domains using one main domain with
> each location having control over their local DNS server.
Ok, one Win2000 domain.
> The proposed solution:
> Implement a main domain "company.com" with each location having a domain
> "regionA.company.com" and "regionB.company.com"
This conflicts with the previous statement -- if you use "Domains" for
each of these you will have three domains, but the previous statement
indicated consolidation into one domain.
One or three DOMAINS?
Now if it's one domain, do you intend to use "child DNS zones" with one
Domain
(which is what I thought you meant at first)? If so, you will have a
mismatch between
your DNS and Domain architecture (most machines will have two names.)
If you intend consolidation, go with one domain and one zone.
If you intend three domains, then use three zones, i.e., parent and two
child domains.
> What I've tried so far:
>
> = Config-1:
>
> Create an AD Integrated company.com Zone. on computer-A
> Create an AD integrated regionA.company.com on computer-A
> Create an AD integrated regionB.company.com on computer-B
Stop worrying about "AD-integrated" or whatever. Stop worry about
DNS for a minute. Figure out precisely what (win2000) DOMAIN
structure you wish to have.
Match your zone structure to that domain structure (and don't worry
about server/zone type, e.g., AD-integrated as it isn't really that big a
deal
until you have the design.)
> on Computer-A created an AD integrated delegation zone regionA added the
> Computer-A NS record.
> on Computer-A created an AD integrated delegation zone regionB added the
> Computer-B NS record.
>
> Question: because it's integrated I see the regionA & B replicated across
> all DNS's
Don't even worry about such issue until you know where you are going with
this.
Yes, the info replicates across all DCs when you use AD-integrated but it
is "hidden" or "implicit" until you create a DNS AD-zone on each DNS server
that is a DC.
You are apparently worrying about too many details at one time -- simplify,
divide and conquer.
Don't design more than one zone/domain at a time.
Don't worry about zone type until each is designed or even configured.
(You can always change type later -- in fact with WANS it is a good
idea
to always start with Primary/Secondary until you get replication
working.)
--
Herb Martin
Justin Tyme
After thinking it through, I will have one DOMAIN (i.e. company.com) and two
CHILD Domains.
Each location is somewhat autonomus, region-B and region-A share a database
server via a WAN and also a file share located at regionB
Each site is responsible for it's regional DNS with a group responsible for
company.com.
I would like to minimize zone transfer traffic and name resolution across
the WAN.
So I think it should look something like this
company.com
--> regionA.company.com
--> regionB.company.com
The main site (HQ) will host the zone company.com. Which will be more or
less empty except for the following (maybe the shared resources could be
located here) :
The HQ site will host the regionA.company.com zone which is where all its'
local resources (files and print servers, pc's etc) will be located.
The regionB site will host the regionB.company.com zone which is where all
its' local resources will be located.
secondary zones for each region will be located at each local site for
redundancy.
stub zones will be located at each region for the other region, i.e. stub
zone regionA located on regionB, RegionB on RegionA.
Zone transfers will be for the stub zones only.
What do you think? I can send a visio drawing if you'd like.
Best Regards.
====================================
"Herb Martin" <ne...@LearnQuick.com> wrote in message
news:uptXzRqe...@TK2MSFTNGP10.phx.gbl...
Ace Fekay [MVP]
Herb Martin <ne...@LearnQuick.com> posted their thoughts, then I offered mine
<snip>
> Don't even worry about such issue until you know where you are going
> with this.
>
> Yes, the info replicates across all DCs when you use AD-integrated
> but it is "hidden" or "implicit" until you create a DNS AD-zone on
> each DNS server that is a DC.
<snip>
I agree that the worrying is in the wrong spot.
Just to clarify, AD Integrated zones in W2k only replicate between DCs in a
specific domain and not between different domains. W2k3 allows this thru the
use of application partitions to all DCs in a Forest.
--
Regards,
Ace
Please direct all replies to the newsgroup so all can benefit.
Ace Fekay, MCSE 2000, MCSE+I, MCSA, MCT, MVP
Microsoft Windows MVP - Active Directory
--
=================================
Ace Fekay [MVP]
Justin Tyme <justi...@aol.com> posted their thoughts, then I offered mine
That sounds good. For WAN traffic minimization, use DNS delegation of the
child zone from the parent to the child domain's DNS servers. Then in the
child DNS servers, configure a Forwarder back to the parent domain DNS
server(s). Minimal two DNS servers per domain recommended. Use this in
conjunction with stub zones. From the Parent DNS, forward that out to the
ISP. THis will allow all domains to resolve each other and Internet
resolution too.
Cheers!
Herb Martin
> Thanks, Good advice,
>
> After thinking it through, I will have one DOMAIN (i.e. company.com) and
two
> CHILD Domains.
> Each location is somewhat autonomus, region-B and region-A share a
database
> server via a WAN and also a file share located at regionB
>
> Each site is responsible for it's regional DNS with a group responsible
for
> company.com.
> I would like to minimize zone transfer traffic and name resolution across
> the WAN.
>
> So I think it should look something like this
>
> company.com
> --> regionA.company.com
> --> regionB.company.com
Ok, if that is what you want.
If you only wish to control replication traffic efficiently then Sites
(while using
only one Domain) can do the trick for most companies.
If you truly wish to delegate authority and "minimize" replication then
multiple
domains are your choice.
> The main site (HQ) will host the zone company.com. Which will be more or
> less empty except for the following (maybe the shared resources could be
> located here) :
Notice that with multiple Zones you must have some way to deal with the
"common root" problem -- especially if you also wish to resolve Internet
based names.
One way is to hold "secondaries" for each domain on EVERY 'other' domain.
But this defeats your minimize "zone transfer" criteria.
> The HQ site will host the regionA.company.com zone which is where all its'
> local resources (files and print servers, pc's etc) will be located.
>
> The regionB site will host the regionB.company.com zone which is where all
> its' local resources will be located.
>
> secondary zones for each region will be located at each local site for
> redundancy.
If this is all about DNS traffic it isn't worth the trouble -- just use one
domain
and AD-Integrated Zones.
If it is about control, you may have no choice but working out the politics
more sensibly would get my vote.
> stub zones will be located at each region for the other region, i.e. stub
> zone regionA located on regionB, RegionB on RegionA.
This works as long as you stick with Win2003 only DNS - no NT 4 or
Win2000 (BIND is actually ok too.)
> Zone transfers will be for the stub zones only.
Stub zones don't really "transfer", just the NS records are updated.
> What do you think? I can send a visio drawing if you'd like.
Not necessary.
How many servers and clients will you have in each?
If this number is small (a few thousand perhaps), I would still strongly
consider
one domain. If it is large (tens of thousands) then I would lean towards
splitting
it but AD can easily hold hundreds of thousands even millions per domain IF
that makes the most sense in other ways.
--
Herb Martin
stevta [MSFT]
domain.
Create a region A & B OU. Delegate administration to
different groups for each OU.
If you are talking about thousands of users then I see the
need to go for multiple domains.
Make sure that your domain structure is layed out
correctly. Region A and B would most likely benefit from
being different AD Sites if they are in different
locations.
The scale of how large a painting we are drawing would
help.
Steve
>.
>
Justin Tyme
I've learned a lot from your input.
RegionA has about 700 seats and 10 servers.
RegionB has about 450 seats and 8 servers.
The locations are connected via a T1.
Question: What is the "Common Root" problem referred to in the previous
post.
The issues are more of local control then lack of wan resource.
Each region wants to add resources to it's own dns
Overall management wants to have a central point for administration.
They all share a database at the HQ.
hence the solution:
company.com - management of the actual hierarchy, mx records, top level
zones (and/or domains) , access to sub-level domains/zones
regionA.company.com - Local control over their resources (i.e. add and
removing records), except for the actual management of the DNS Hierarchy
regionB.company.com - Local control over their resources (i.e. add and
removing records), except for the actual management of the DNS Hierarchy
regionC.company.com - Local control over their resources (i.e. add and
removing records), except for the actual management of the DNS Hierarchy
etc. etc.
The solution should be a scable as they will be adding other regions over
the coming year.
Each site controls the resources within their location
Each site will have the ability resolve to specific shared resources between
them.
Responsiblity for the company.com hierachy is at HQ.
Summary:
* The overall advice seems to be to take a single domain.
* That delegation is appropriate for much larger installations. For the size
of network that I'm dealing with it's more work then it's worth!
Any comments?
Thanks.
Justin Tyme
So the idea would be to have a forest company.com with a RegionA and RegionB
tree?
Thanks
"stevta [MSFT]" <ste...@online.microsoft.com> wrote in message
news:016901c37afa$ed57c1f0$a401...@phx.gbl...
Herb Martin
> Thanks stevta,
>
> So the idea would be to have a forest company.com with a RegionA and
RegionB
> tree?
No, he and several of us are suggesting you reconsider ONE
DOMAIN in a single tree of the forest with SITES for your
locations.
--
Herb Martin
Ace Fekay [MVP]
Summary:
Single domains are easier to manage. Mutliple domains as shown, have more
overhead. If you need distinct separate administration at the locations,
including user and group account control and/or password or other user
account property distinction, then separate domains would be indicated. This
depends on your needs of the company and the adminstration level. Domains
are security boundaries. They are also logical boundaries, where as Sites
are physical boundaries. A domain can cross mutliple Sites. Sites can
encompass mutliple domains. Depends on your company needs. The empty Root
can be used as a "contiguous namespace" for your company, but don't rely on
it as a security feature to hide the EA. As I said, domain admins in other
domains can change forest data.
Delegation with forwarding back to the "root" DNS is actually alot easier
and probably seems the best answer for your scenario. It's much easier than
having to create secondaries on other servers.
Hope that helps.
Justin Tyme
Thanks all for your input
I'm going to setup a test configuration between the sites and try the ideas
I've learned here. This will take a couple of days. So.. I will return
shortly with my results.
Thanks again.
"Justin Tyme" <justi...@aol.com> wrote in message
news:usZ5sEme...@TK2MSFTNGP09.phx.gbl...