Re: Public facing IIS/MSSQL servers in AD?

From: Keith W. McCammon (km_at_km.com)
Date: 05/17/04 

Date: Mon, 17 May 2004 09:38:39 -0400

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

Yeah, this is a tough argument. On the one hand, there are certain security
concerns related to AD. But on the other hand, some companies simply cannot
afford the management costs associated with trying to manage a large
workgroup. Just as an example, I used to manage a web services environment
that had 90+ systems in the forward-facing environment. In that type of
situation, AD is a very cost-effective management solution.

> So, here are my questions should you feel like responding:
> How many servers or users can you have in such a configuration?

Relative. You can, in theory, have as many as you want. The major caveat
is that the more user accounts you have, the more difficult it becomes to
monitor and continue to trust those accounts.

> Is AD a good idea at all for exposed servers?

Again, relative (see the pattern here?). If you have a tightly managed and
properly designed AD, the risks are probably not much greater than those
associated with non-AD networks. Saying that AD in a DMZ is not secure is
like using the old "you're running IIS, so you're not secure" saying--it's a
load. It can be done "right."

> Is there a good alternative to AD for management?

Things like Hyena and such can reduce pain.

> How many companies put their public internet machines in AD?

You'll probably never get an accurate answer. But in my own experience, not
a lot, but more than I had expected.

> Does MSFT really Suggest this?

There are a number of articles that deal with AD architecture in non-trusted
networks. Dig around on TechNet. The options, in general, are:

- Separate ADs with trusts
- Child domains
- Forest trusts (2003 only)
- Trees

Each has pros and cons. And again, just in my experience, separate ADs with
trusts is the most commonly used, since there untrsuted network has no
inherent rights or relationships within the trusted network.

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

OK. Now we're getting to the bottom of it. If you're experiencing repeated
comprises, I'd be willing to bet my job that those compromises are not
rooted in the fact that you are running AD. I'd guess that they're due
primarly to unpatched systems, poorly configured systems, etc. And I'd
guess that if an untrsuted network account has managed to provide a conduit
into the trusted network, that you have a management problem.

How exactly did AD play a role in some of these compromises? Itemizing this
may help us to determine exactly what the root cause is, and whether AD is
approriate. Remember, migrating from AD to de-centralized management can be
expensive, and you want to be sure that removing AD will correct the issue.
If you have poorly managed systems, removing AD will likely make things
worse, not better. Bad administration is bad administration--AD or no AD.

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

Again, the reason that articles rarely say things as clearly as you'd like
is because it's almost an entirely relative issue. What's good for one is
nor good for all. But that one may reap huge benefits.

Like I said, you need to be very specific in itemizing the risks to your
environment, particularly those related to systems that are prone to attack
and/or compromise. And then you need to figure out what the root cause of
those problems are...

Relevant Pages

  • Re: Down with DHCP!!!!
    ... going to staic IP's would be a management nightmare ... (speaking as someone who managed a static IP network ... Security is always a compromise; ... Computer Emergency Response Teams, and Digital Investigations. ...
    (Security-Basics)
  • RE: Down with DHCP!!!!
    ... Managing/monitoring the DHCP pools as assignments yourself ... -Other management tools as in Asset ... Security Administrator ... Network Operations-ICW Group ...
    (Security-Basics)
  • Re: question about IT budgets
    ... However, I cannot get Management ... company's network with equipment purchased at Staples, ... yeah - get their signature on the revised estimate. ... weekend writing, reading, pondering, strategizing, etc. Basically, I share ...
    (microsoft.public.win2000.active_directory)
  • CFP: DANMS 2008 Co-located with Globecom 2008 - Submission Deadline 15 July
    ... 3rd International Workshop on Distributed Autonomous Network ... Management Systems ... Sidath Handurukande, Ericsson Ireland Research ...
    (comp.org.acm)
  • CFP: DANMS 2008 Co-located with Globecom 2008 - Submission Deadline 15 July
    ... 3rd International Workshop on Distributed Autonomous Network ... Management Systems ... Sidath Handurukande, Ericsson Ireland Research ...
    (comp.org.ieee)