Re: emtpy root domain
From: Al Mulnick (amulnick_No_SPAM_at_ncDOTrr.com)
Date: 11/18/04
- Next message: Tim::..: "Newbie Problem withAD and OU users!"
- Previous message: andespoint: "Re: More Password Complexity Requirements?"
- In reply to: John M: "Re: emtpy root domain"
- Next in thread: John M: "Re: emtpy root domain"
- Reply: John M: "Re: emtpy root domain"
- Messages sorted by: [ date ] [ thread ]
Date: Thu, 18 Nov 2004 08:18:10 -0500
I see. Best practice from Microsoft is NOT to use the internal forest in
the DMZ. The best practice is to use separate forests for the internal and
externally facing resources. You may want to check out the planning docs
and see what pops out at you in that regard.
>From the sounds of it, you may want to follow a few ideas:
1) you need three separate forests. One internal, one external and at least
one for testing. Testing should mirror production and be a true
representation in order that you can accurately test and therefore reduce
your risk of introducing problems via change. In your case, four forests
total might actually be better. Virtual Machine technology is a great way
to get what you need in this case (major hint).
2) DNS is totally separate in this case. I would suggest thinking of it
that architecture prior to your Active Directory forest architecture. DNS
came first and Active Directory is designed to be deployed into existing
environments. It can be done pretty easily. If you need further
information on that, check out the concepts of disjointed namespaces.
3) remember that only the forest is a security boundary. The rest is not
for anyone that understands what they're doing even a little or has access
to google.com :)
4) This one has me confused as to what you're after. What VPN? "> then my
next issue is how does one span this across multiple geographic
> sites. do the vpns go from (internal - internal) or external-external
> domain "
Spanning for Active Directory is done via site concept. Site links etc.
You can use all kinds of transport from IP to SMTP if you want. VPN is
really lower in the stack in most implementations. Can you clarify?
al
"John M" <JohnM@discussions.microsoft.com> wrote in message
news:76E11C3D-E031-4B9F-B620-CA7766D1EE1F@microsoft.com...
> well I dont really have any requirements, other than this,
>
> 1. need split dns.
> 2. would like a dmz area dont care what its called. this would have
> limited
> file access to the main (internal) domain. will also be the mail / smtp
> gateway for the (internal) domain as well.
> 3. be nice to be able to have a test domain or area which has semi
> connectivity to prod domain or area.
> 4. have a test AD area to test migrations / scripting into AD.
>
> the suggestion of empty root keeps popping up everywhere i look. so I did
> a
> couple of vmware / testing type builds and noticed the security enterprise
> groups were in the external domain.
>
> my thoughts were this wasnt that secure particularly if the external
> domain
> was in the DMZ. my reasoning was that if the DMZ was compromised for some
> reason being that the enterprise groups were in the DMZ you may as well
> say
> the (internal) domain was also compromised.
>
> this leads me to believe that most dmz's would actually house a separate
> forest. or not even a domain.
>
> then my next issue is how does one span this across multiple geographic
> sites. do the vpns go from (internal - internal) or external-external
> domain
>
> note: this is all hypothetical general best practice sort of stuff.
>
>
>
>
> "Al Mulnick" wrote:
>
>> The only true security delineation is the forest. That said, you may
>> have
>> better luck if you look at this in a different way. Look at it as DNS
>> only
>> and as Active Directory only. Two separate problems to be solved vs. just
>> one big jumble. It may make more sense to you that way.
>>
>> Empty root is good for some restrictions and especially policy
>> differences,
>> but since the domain is not a true security boundary (but more like a DNS
>> boundary although not quite that simple) it really only makes sense if
>> you
>> want to use different policy for enterprise admins than you do for the
>> rest
>> of the population. Otherwise, I don't see a huge advantage. It's about
>> control not namespace. You can have disjointed namespaces in the same
>> forest, and you can have split-brain dns in the same network if that's
>> what
>> you need.
>>
>> Can you expand a little on what the end solution needs to be?
>>
>>
>> "John M" <John M@discussions.microsoft.com> wrote in message
>> news:558AD8A2-00F1-40CC-B0BF-102B90646532@microsoft.com...
>> >I have been messing around with AD structures mainly for the sake of
>> >finding
>> > a good model.
>> >
>> > I have been looking it the empty root model which has some appeal.
>> > However
>> > I
>> > did notice that the following happened.
>> >
>> > domainName.com = empty root
>> > internal.domainName.com = child of empty root.
>> >
>> > now my theory was that the domainName.com would be in the DMZ, which
>> > would
>> > mean that if that domain was compromised then so would the internal
>> > domain.
>> >
>> > being that the enterprise accounts are in the empty root ?
>> >
>> > am i correct in saying that the empty root model really needs another
>> > domain
>> > in a dmz ?
>> >
>> > i have also read that trends are moving away from this model, however i
>> > dont
>> > know to what they are going too ? the reason the empty root appeals is
>> > it
>> > would make it simple to create this type of scenario.
>> >
>> > domainName.com
>> > internal.domainName.com
>> > test.domainName.com
>> >
>> > etc etc
>> >
>> > how can this be done and have a good security model as well ?
>> >
>> > am i missing something here ?
>>
>>
>>
- Next message: Tim::..: "Newbie Problem withAD and OU users!"
- Previous message: andespoint: "Re: More Password Complexity Requirements?"
- In reply to: John M: "Re: emtpy root domain"
- Next in thread: John M: "Re: emtpy root domain"
- Reply: John M: "Re: emtpy root domain"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
