> 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 [EMAIL PROTECTED], 6300 Highlands Pkwy., Smyrna GA 30081 > -----Original Message----- > From: David LeBlanc [mailto:[EMAIL PROTECTED] > 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:[EMAIL PROTECTED] > > > 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 > --------------------------------------------------------------------------- ---------------------------------------------------------------------------
