Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Focus-Microsoft
[Top] [All Lists]

RE: Active Directory and IIS on production servers, and clustering

Subject: RE: Active Directory and IIS on production servers, and clustering
Date: Sun, 30 Oct 2005 15:20:53 -0800
 

-----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


---------------------------------------------------------------------------
---------------------------------------------------------------------------

<Prev in Thread] Current Thread [Next in Thread>