----- Original Message -----
From: "David LeBlanc" <dleblanc@mindspring.com>
To: "'Jim Stagg'" <jstagg@sprich.com>; "'Focus-MS'"
<focus-ms@securityfocus.com>
Sent: Sunday, October 30, 2005 3:20 PM
Subject: RE: Active Directory and IIS on production servers, and clustering
Next, consider the possibility of trusts to the internal domain. In most
cases, unless there is some pressing business need to make a trust, I
would
_not_ establish a trust between the DMZ domain and the internal domain,
but
if I did, I'd make sure and use Win2k3 DCs and make it a limited trust.
Additionally, if I had to create a trust out into the DMZ, I'd strongly
consider making 2 DMZs so that I could watch the one with the trust very,
very carefully.
Just to elaborate, if one *did* decide to implement such a trust model
(Which, I too would *not* recommend doing) it should be an external, one
way, nontransitive trust to a domain in a separate forest. I'm sure that's
what you had in mind, but I think it's important to be specific about these
things, particularly when discussing trusts between a DMZ domain and an
internal domain.
The logical boundary might be the domain, but the true security boundary is
the forest. I know you know that, but we need to say it.
I'm all up for a separate forest/domain for the DMZ- It is standard practice
for me. But I can't honestly think of a good reason to go through all the
trouble of a trust, even if external, between the internal and DMZ domains.
Yikes- it gives me the shivers just considering such a thing... The needed
firewall ruleset alone is too much exposure if you asked me... When you can
securely administer the DMZ via RDP and do so with no static rules (outbound
only 3389 or whatever) and an isolated AD, why risk it??
t
---------------------------------------------------------------------------
---------------------------------------------------------------------------
