Re: Protected Forest with One Child domain

"santa''s helper" <santashelper@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:06106C16-27FB-42DC-B95F-1801889BD060@xxxxxxxxxxxxxxxx
Thanks for all the info.
All servers are Win2K3. The forest is in native mode. The domains are in
native mode.
I have setup my child domains to conditionally forward to the forest
domain
and have delegated at the root down to the child domains. So I think(?)
that
I have set all that up correctly.

Ok, so (sanity check) your child DNS servers can resolve both their
"own zones" AND find everything else through the conditional forwarding
to the top of the DNS hierarchy at the "root AD domain", right?

The Root Domain DNS of course knows ITS OWN zone and can find
all of the others through the DELEGATION, correct?

Test this with specific NSLookup commands....

nslookup name.child.domain.com IP.of.Child.DNS
nslookup name.domain.com IP.of.PARENT.DNS
nslookup name.EachOtherChild.domain.com IP.of.Child.DNS
nslookup name.EachOtherChild.domain.com IP.of.Parent.DNS

All should work.

However,
A couple more questions (for now):
I have read that the '_msdcs...' folder in the forest should also exist on
the child dns servers too.

That is a good idea. It can be reached through the conditional forwarding,
but is small so there is no good reason not to just hold a secondary
(or Forest Wide AD-integrated) copy of it locally on EVER DNS server.

Remember that technically you could do this for all zones -- and
that is pretty much what is needed in Win2000 DNS which doesn't
have "Forest Wide AD replication", Stub Zones, NOR Conditional
Forwarding.


First, is this correct (or do I have it backwards)

No, it sounds right IF you can get a successful test.

Also test EVERY DC with DCDiag and fix all FAIL, WARN,
and ERROR indications.

and Second, I'm not sure how to do it if it is 'best practice' to do it.
Help!!

Best practices really aren't that helpful here since it varies by size
of the domain and size of the overall forest but for most people pretty
much ANYTHING that resolves all names correct is fine.

They key is to GET THAT RESOLUTION, then worry about optimizing
the performance and the WAN usage.

Probably the best for almost all medium size forests is to put every
INTERNAL zone on every DNS server using AD-Integrated Forest
Wide Replication (but notice this may get obnoxious for those people
with many domains and very many DNS servers.)

In your case it would not be too tedious (only six DNS servers) but
might not help much over what you have above indicated.

Second - Setting up a new tree within the forest.:
At the forest level, I can click on the root of the forest (in dns) and
then
select 'new delegation' to delegate the child to the child dns servers.
Ok, I
have done this and it makes sense, etc...

And of course you have those delegated DNS servers up and running
correctly. (We always DELEGATE TO a "set of DNS servers".)


I can't delegate a new tree (at a root level on the forest dns servers) --
so basically, I just don't understand where the new tree is placed within
DNS
at the forest level so the forest can know about the tree. Does the
question
make sense??

No, I don't understand completely.

My suspicion is that you have a "DNS Root" (i.e., a "." or DOT) zone
defined.

This is an artifact of a BUG/feature in the DNS setup and should almost
always be deleted.

Although I have never tried, you SHOULD be able to delegate from the
"."-root zone to a different tree (e.g., com vs. edu) but maybe you mean
something else by the above paragraph....

So --- lets say I have forest1.com (this is the forest). Within the forest
I
have delegated the 'child1' domain to child1.forest1.com.

No, that is the DOMAIN you DELEGATED, you would DELEGATE TO
some DNS server, such as dns1.child1.forest.com or even
Weirdname.atStupiddomain.local. (The latter doesn't make much sense
but is technically legal as long as that is the DNS server which holds
the required zone: child1.forest.com)


And the dns servers
(3) in the child1 domain conditionally forward back to forest1.com.

So that forest.com names (and all those BELOW it other than child1)
are resolvable too.

Make sense? (It MUST make sense if you are going to maintain this stuff.)


Now --- lets say my new tree is called Tree1.net. How do I set it up in
dns
at the forest root?

If you don't have the ".net" zone (which you should NOT have) then you
would just "conditionally forward" from that server too.

The only other choice is (or rather choices are) actually holding a copy
of "tree1.net" on that DNS server.

Again, does this make sense?

A server EITHER MUST:

1) Hold a zone (primary, secondary, AD-integrated, or stub)
2) Delegate to the zone DNS servers (only for child zones)
3) Conditionally forward to that specific zone (or a parent of it)
4) Physically recurse by going to the DNS root ("." dot) zone
and working down through all of the names in the namespace
5) Forward unconditionally to SOME OTHER DNS server
which can do one of these.


The list above is VERY IMPORTANT to be able to THINK THROUGH
(not necessarily to memorize unless you wish to teach) so that you can
ALWAYS figure out the options.

And I am assuming that I still will conditionally forward
from the Tree1.net dns servers back to Forest1.com. Is this correct?

Ok, but it has to work the other way too.

WARNING: Mutual conditional forwarding is FINE and very commonly
required but you must NEVER use "MUTUAL unconditional forwarding"
since this causes an Infinite Loop (1->2 and 2->1 since neither holds the
missing zones).

BTW: Here are my reasons for creating the Tree and the reasons I think it
makes sense to make the tree within Forest1 (please feel free to guide me
on
this too):
Tree1 is a new division with the company that (eventually) will either be
spun off as a new, independant company or sold off completely.

That latter TENDS to argue for a SEPARATE FOREST -- this is not
ideal if the companies will remain as one, but there is no supported way
to "Prune" (i.e., spin off) a domain or tree from an AD Forest without
re-installing everything in that domain/tree.

If the separation is fully expected then I would likely make it a separate
forest.

What reasons do you have for a single forest (sharing of resources, etc?)

As this
division grows, employees that are hired specifically within that division
will probably have email accounts, etc. that are different than those of
Forest1. I also have read that setting Exchange 2003 to work with multiple
Forest is very difficult, if not impossible.

It is certainly more complicated and you may need two Exchange server
sets running (semi) independently....but that is going to be required after
any spin-off anyway probably.

And lastly, I want to have a
Protected Forest design and standardize all security across all domains
without additional considerations of another forest. (Again, feel free to
educate me if I am approaching this incorrectly).

Since Group Policy doesn't flow or inherit down DOMAIN hierarchies
you still need to link and apply it separately for every domain.

You are going to end up copy/recreating these GPO objects to each domain
ANYWAY and need it to work once separated so perhaps your level of
"without additional consideration" is going to be merely setting up
standards
and perhaps providing master copies of such GPOs and Security Templates,
plus auditing the results.


Thanks again for your help - much, much, much appreciation!!!!! :>

We try. You are very welcome....

One further recommendation: You have a fairly complex setup and set
of requirements so it is NOT going to be 'enough' for your to merely take
someone else's "best practices" (in most cases) but rather that you learn
and (we help you) understand what the relative benefits and issues really
mean to YOU and your business (multiple businesses really which may
have different needs and concerns.)

--
Herb Martin, MCSE, MVP
Accelerated MCSE
http://www.LearnQuick.Com
[phone number on web site]





"Herb Martin" wrote:

"santa's helper" <santa's helper@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in
message
news:83E91456-BB8F-4354-AEA0-A8C5409BEAA3@xxxxxxxxxxxxxxxx
Hello all --- ok, here's the question -- actually several....
I am setting up a new forest (for security, etc..) and a child domain.
The forest has 3 DCs (already setup -- working great!).
The child domain will have 3 DCs (currently only 1 has been setup).

Then presumably the forest has SIX DCs, right?

The basics I have, but how to do the DNS stuff has me stumped.
When promoting the first child dc (cDC1)....
A. should I install DNS on him? i think so, but then...

Probably but it is NOT an actual requirement.

The actual requirement is that each domain have a corresponding
Dynamic DNS ZONE to support that domain.

Usually this zone is held on the servers of that domain but technically
can be held ANYWHERE that meets the requirements.

B. what is/are his DNS pointer(s) (primary, sec) pointing to? does
it
point to the forest? if it does...

A DNS server is either a Primary or a Secondary (or AD Primary).
He doesn't "point" to these unless a Secondary in which case the
Secondary may point to ANY other DNS server holding that zone
(primary, Secondary, or AD-Primary.)

IF you mean, where should the DNS CLIENT settings for that DNS/DC
server point then the answer is USUALLY to the servers for his own
zone (e.g., himself) but this is again not a technical requirement just
a common practice, and due to performance a generally good idea.

[This concept has NOTHING to do with Primary/Secondary (clients
don't much care about such server side distinctions) but rather
PREFERRED and ALTERNATE DNS servers.]

During DCPromo this may be different than afterwards since the
"new DC to be" must be able to find the DCs from the parent domain
AND his (new) zone.

The real key is that the DNS CLIENT settings must be able to find
ANY record that client will need (even if that client is really a server
itself.)

So it would be common to point to the existing (parent domain) DNS
during DCPromo, and to himself (holding the new zone) afterwards.

BUT that alone is insufficient since the NEW DNS server must still
be able to resolve the ENTIRE forest as a DNS SERVER.

C. what about after the promo ?... he does not carry info about his
own
domain. his _msdcs info has now been placed in the forest domain under
the
root's _msdcs domain.

A DNS-DC almost always points to 'himself' as PREFERRED,
other DNS server(s) holding his zone as Alternate(s).

E. assuming I am doing all this incorrectly thus far , after all is
said
and done, how should I configure all 3cDCs (actually all 6) relatative
to
DNS?

No trivial answer for Win2003 since there are so many choices, but
there are several good ones.

Parent zone is usually set to "delegate" to the child zone.

Child zone SERVER is usually set to either "conditionally
forward" (Win2003 only) to parent or top of DNS hierarchy (and any
other 'sister' DNS trees.

The key is that every DNS server must be able to answer ANY
question asked by ANY of it's DNS clients.

In Windows 2000, the new methods don't exist so generally the
child DNS servers hold a Secondary for the top of the parent
DNS hierarchy, and another for each sibling/other DNS hierarchy
within the company. (I call this "cross secondaries" since it is
commonly mutual.)

There are other choices in Win2003, but commonly the best if you have
NO Win2000 DCs is to use "AD Integrated DNS" with FOREST wide
replication to all DNS-DCs in the forest. (This may or may not make
sense in GIANT zones/domains but for even medium size companies
it is usually correct without much concern.)

Notice now that we have separated the issue of "where to point"
stuff, from getting the DNS servers themselves (AS SERVERS) to
be able to resolve EVERYTHING the DNS clients will need.

Now, the DCs are "just DNS Clients" and so point to the DNS
servers that can do what they need.

Since they are usually DNS servers themselves, they tend to
point to themselves as being both correct AND the most efficient
(speed, net traffic etc.)

1. 1st, 2nd, 3rd DNS pointers (round robin just like we have the
forest?)?

That doens't make much sense as written and doesn't seem
relevant to your other questions without some clarification.

2. forwarders?

You cannot usually use your GENERAL forwarding setting
for these issues since most/much of the time you also need
to forward (generally) to the Internet for "all other DNS names".

So in Win2003, the answer to #2 is yes, but we use CONDITIONAL
FORWARDING.

3. delegation?

This only works from PARENT down to child and is very common.

This is the traditional choice for Parent domains, even
prior to Win2000 or for other OSes.

4. etc...

Technically there is also "Stub Zones" in Win2003 but they are
virtually identical to Conditional Forwarding in effect (with a
very minor distinction that practically no one knows or ever
needs to consider.)

[And of course AD-Integrated with Forest wide DNS-DC
replicaton, covered able. As well as "cross secondaries"
for Windows 2000 where the new features just don't exist.]

D. lastly, is it possible to have 'short name' sign in for both the
forest (ent admin accounts) and at the child level or will the ent
admin
have
to use name@xxxxxxxxxxxxxxxx to login directly on that child domain?

Everyone must log into their OWN account, wherever that account
may be.

This generally means using the user name and domain name to FULLY
qualify the account name. (Accounts are domain specific.)

So we use either the older NetBIOS form: Domain\User (or fill out
both boxes at Ctrl-Alt-Del) OR we use the newer UPN.

The User Principal Name (UPN) is as you suggest similar to an
email address for the user.

Everyone in the entire forest CAN (be setup to) use the same
UPN suffix IF you take action to define their UPN that way instead
of in the form "User@xxxxxxxxxxxxxxxx" -- that is you setup all the
UPNs as "User@xxxxxxxxxxxxxx".

Technically these suffixes could be a domain suffix that doesn't
even really exist -- the classic example is the company that uses
a private domain name (e.g., .local) for the forest domain zone
names, but uses the public version (e.g., .com) for all of the UPNs
so that users email address and UPN are literally the same.

Your choice but there is a little extra work to make the standardized
UPN work -- also every user name must be unique across the forest
and not just each domain (which is a good idea anyway but not
actually required in the simpler case.)

Here is what I think I know .... I want the child domain to have its
own
DNS
for its domain. (there will be a total of 3 DCs in this domain.) but I
am
open to best practice recommendations!!!

Why not just run all DCs as DNS server, and have all of them hold
a copy of every zone, and use Forest wide DNS-DC replication
(assuming you are running all Win2003 DCs)???

Thanks in advance for your help .. pretty pictures would be AWESOME!!
:>

Pictures won't help nearly as much as you being able to think
through how each DNS server will resolve things it does NOT
know directly....

This is THE KEY to DNS architecture and design.

--
Herb Martin, MCSE, MVP
Accelerated MCSE
http://www.LearnQuick.Com
[phone number on web site]








.