Sorry about chiming in very late - I don't check this list
often. There's a couple of things to think about here - first
is that there's always exceptions. For example, if there are
more than two or three systems in the DMZ, it makes sense to
have a DMZ domain just in order to be able to easily push
policy and manage accounts. I'd suggest doing some serious
hardening on the DC, but the drawbacks of not having the
management outweigh the drawbacks of having a domain. So I
disagree - unless the DMZ is trivially small, I'd recommend
making them domain members, just not members of the internal domain.
Actually, that's a really good logistical point, and it's not one I meant to
dismiss entirely. DMZ domain isn't necessarily a bad idea, depending on how
you expect those hosts to interact. There may be other ways to get the same
basic effect (synchronized accounts/passwords on the DMZ systems, consistent
security policy application). But, depending on the way the application uses
it's authentication bits, it may make sense to consider a DMZ domain. There
are performance advantages to having them in a common Kerberos realm (2000
or better, of course).
In our case, we've made the decision that bastion hosts aren't members of
any domain. But, our Windows DMZ systems can be counted on one hand, and
that does have a big impact on our decision to leave them. We had, in past
discussions, considered a DMZ domain. As always, YMMV.
--
Jim Stagg, Systems Administrator, S.P. Richards Co.,
770-803-5724 or jstagg@sprich.com,
6300 Highlands Pkwy., Smyrna GA 30081
-----Original Message-----
From: David LeBlanc [mailto:dleblanc@mindspring.com]
Sent: Sunday, October 30, 2005 6:21 PM
To: Jim Stagg; 'Focus-MS'
Subject: RE: Active Directory and IIS on production servers,
and clustering
-----Original Message-----
From: Jim Stagg [mailto:jstagg@sprich.com]
Our design has always been that public bastion hosts are NOT domain
members... ever. Our MS Services guy blessed that as the
Microsoft-supported position (DB in the secured network
with minimal
access from the DMZ-based IIS server, which in turn has
only minimal
access allowed from a less-trusted network). Microsoft also
specifically advises against a private namespace being
accessible from
a public network.
Sorry about chiming in very late - I don't check this list
often. There's a couple of things to think about here - first
is that there's always exceptions. For example, if there are
more than two or three systems in the DMZ, it makes sense to
have a DMZ domain just in order to be able to easily push
policy and manage accounts. I'd suggest doing some serious
hardening on the DC, but the drawbacks of not having the
management outweigh the drawbacks of having a domain. So I
disagree - unless the DMZ is trivially small, I'd recommend
making them domain members, just not members of the internal domain.
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.
WRT putting IIS and a DC together, back in IIS 5.0 days, yes,
that was a Very Bad Idea. IIS 6, OTOH, has been quite secure,
and I'd say there's limited risk to pairing them. I would not
under any circumstances make a publicly exposed IIS system a
DC, but on my home network, I run IIS on my DC so I can run
WSUS - so all this depends on the business case and the size
of the network.
We security people often get ourselves in trouble by tending
towards absolutes and failing to consider the business case.
--------------------------------------------------------------
---------
Insisting on perfect safety is for people who don't have the
balls to live in the real world. Mary Shafer
David LeBlanc - dleblanc(at)mindspring.com
---------------------------------------------------------------------------
---------------------------------------------------------------------------
