Re: Public facing IIS/MSSQL servers in AD?
From: Roger Abell (mvpNOSpam_at_asu.edu)
Date: 05/18/04
- Next message: Roger Abell: "Re: Win 2K3 Serv: NETWORK built in account on UNC share grants EVERYONE permissions"
- Previous message: Eric Chamberlain: "Re: Public facing IIS/MSSQL servers in AD?"
- In reply to: Tim Net: "Public facing IIS/MSSQL servers in AD?"
- Next in thread: S. Pidgorny
: "Re: Public facing IIS/MSSQL servers in AD?" - Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Mon, 17 May 2004 23:38:29 -0700
I am going to respond only to a couple aspects of
your post.
First, you asked about size of an external AD. While
you can build an environment that scales to basically
whatever size you need, it is quite important to design
appropriately. Two reasons to use AD outside are to be
able to leverage its replicated store for availability, and
to use the central management and authentication. When
this is done with, for example, a membership and profiling
system that is large, it is possible to cause a large amount
of replication traffic (depending on the design). In these
cases one can find advantage in segmenting into domains
or into distinct application contexts in order to control the
amount of replication caused by things like a member's
profile change. You can find MS discussions of design
approaches in order to best scale for very large deployments
in its "AD in the outward facing role" papers.
Second, you ask whether it is or is not a good idea at all,
using AD in an exposed stance.
I would suggest it is likely more important how one does
things than what one does. For simplistic example, if you
place an AD deployment (all of it) on the public network
and only require that all AD member machines only "speak
to or listen to" other AD member machines (using IPsec)
does it really matter (beyond a few fine details of IPsec and
IKE) that there is no "firewall" ?? It is of course also then
possible to define the interfaces on the desired machines
that will listen to and speak with the general public, on
precisely which IP and ports, even though otherwise these
machines are subject to the AD based closure.
Again, it is not just (or maybe even not as much) what one
does, but it is how one does it.
It you look at a sizable non-AD external deployment, you
will likely find that for simplification there are certain
"samenesses" defined. An account of the same name, often
with same password, is on them all. Now, does that provide
any risk that differs from using any other technology or strategy
that allows things to me managed more as a unit, such as is one
reason for use of AD ?? If one of those stand-alone external
machines is compromised, would it be that great of an effort to
examine the account base, active connections and their owners,
etc.. In fact, without the shared Kerberos realm one is more
likely to be able to find "tricky" (aka dirty) ways being used to
get the inter-machine communications established automatically
on boot.
IMO the use of screened networks is valuable, but it is also
far too oversold. We know these get breached, and so we
cannot assume they will not be. This means that ideally the
individual host is self-protective, even in the internal network;
and, if this can be fully done there it can be done in the external
environment.
I am not say do not use network screening. not wanting to
discount the value of having controlled, monitorable traffic paths.
I am only saying that the true value of this is driving the available
technologies to evolve in ways that may eventually obviate many
of the believed benefits of having things "behind the firewall".
-- Roger Abell Microsoft MVP (Windows Server System: Security) MCSE (W2k3,W2k,Nt4) MCDBA "Tim Net" <ads@cfapostle.com> wrote in message news:uNbYh%23APEHA.2256@TK2MSFTNGP10.phx.gbl... > The topic is rather common: maintaining IIS and/or MSSQL Windows 200x > servers in or Not in Active Directory. > > I have read plenty of white/black hat that suggests it is a reaaaally bad > idea. > I can think of a plethora of reasons why not to do it: hacked (Domain) admin > accounts, "Get one..get them all..", Trojan ginas, service accounts, port > surface area, etc. Yet, there are still camps that support AD in a public > facing(public internet) environment. > > So, here are my questions should you feel like responding: > How many servers or users can you have in such a configuration? > Is AD a good idea at all for exposed servers? > Is there a good alternative to AD for management? > How many companies put their public internet machines in AD? > Does MSFT really Suggest this? > > As you can guess, I work for a company that does use AD but is unwilling to > consider ever changing their strategy. Despite security threat and > compromise again and again, AD is what they believe in. I want to have > something compelling for me or for management to get us on the right track. > > As a note, I have talked to several AD MSFT people and privately, All of > them said it isn't a good idea. Unfortunately, it is not easy finding a > MSFT article that says 'Public or Untrusted machines should not be in AD!' > or 'To be a bastion host you cannot participate in AD!'. I do support AD > for firewalled or private networks(internal). > > Thanks for any input, > > TN > >
- Next message: Roger Abell: "Re: Win 2K3 Serv: NETWORK built in account on UNC share grants EVERYONE permissions"
- Previous message: Eric Chamberlain: "Re: Public facing IIS/MSSQL servers in AD?"
- In reply to: Tim Net: "Public facing IIS/MSSQL servers in AD?"
- Next in thread: S. Pidgorny
: "Re: Public facing IIS/MSSQL servers in AD?" - Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|