Re: AD in the DMZ - Any thoughts on this scenario?

From: Simon Geary (simon_geary_at_hotmail.com)
Date: 08/03/04 

Date: Tue, 3 Aug 2004 19:26:11 +0100

That consultant gave you poor advice, you should only have an isolated
forest in a DMZ, not one that spans the DMZ and internal network.
You don't mention what you need the directory for, but have you considered
using ADAM in the DMZ instead of full blown AD?

"Trust No OneŽ" <dana.scully@usa.net> wrote in message
news:2n9th3Fu8li2U1@uni-berlin.de...
> Hi Folks,
>
> Appreciate input on this one.
>
> My company recently done a feasibility on implementing Windows 2003 and AD
> in our internet facing DMZ. Basically an external consultant came in and
> produced a report. The report recommended setting up a separate AD forest
> spanning both our DMZ and internal network, with member servers sited in
the
> DMZ subnets and the domain controllers located on the internal network.
The
> appropriate ports are then opened on the corporate firewall to permit
> communication to/from the domain controllers, communications are secured
via
> IPSEC.
>
> The consultant assured us that other corporate run similar configurations,
> the advantage being that administration of the AD and maintenance of the
DCs
> is far easier as you won't need to cross the firewall; the domain
> controllers can be pointed at the internal DNS servers.
>
> Despite the assurances I'm troubled by the recommendation as
>
> a) It introduces the possibility (however small) of an intruder using the
> path to the domain controllers to hop from the DMZ into the internal
network
> should he/she manage to comprise one of the internet facing member
servers.
>
> b) Security rather than ease of administration should surely be the main
> consideration.
>
> c) ISTR RPC requires a significant range of ports to be opened? I know
that
> the range of ports can be locked down to a defined range rather the
default
> of dynamic, but a number of holes still need to be punched in order to
> permit communication to the domain controllers.
>
> I would have thought a completely separate DMZ forest with possibly a one
> way trust to the internal AD forest would be the more secure way to go. I
am
> keeping an open mind at this stage however.
>
> Any thoughts or comments on the consultant's recommendation? Is anyone on
> the group successfully running with a split DMZ/Internal AD forest?
>
> Best Wishes
>
> --
> Peter <X-Files Fan & AD enthusiast :) >
> Please Note: Emailed replies cc'd / bcc'd , containing HTML or attachments
> auto-binned as spam
>
>

Relevant Pages

  • Re: FTP for internal users and external customers.
    ... Secure network architecture and authentication, ... the security boundary in AD is the forest ... Yet there's one thing that's not justified: putting the external user in DMZ ... any connections coming from the internet has to ...
    (microsoft.public.security)
  • Re: DMZ Services, Best Balance Between Security and Functionality, Comments?
    ... It depends where your DMZ is --- between what and what? ... If it's between your intranet and the Internet, ... > internal forest. ... All external users accounts in external ...
    (microsoft.public.win2000.security)
  • Re: AD in the DMZ - Any thoughts on this scenario?
    ... > and AD in our internet facing DMZ. ... > domain controllers, ... > I would have thought a completely separate DMZ forest with possibly a ...
    (microsoft.public.win2000.active_directory)
  • Re: Where to place the DMZ zone?
    ... hypothetically lets say you have no DMZ hosting an email bridgehead ... If a hacker were to compromise one of your email or web servers (they are ... That is, the Internet accessible servers ... that can be compromised are on your internal network, ...
    (microsoft.public.isa)
  • RE: Cracking a server without services
    ... The point is I'll have a linux firwall, connected to that the internet, ... It will however forward some ports to the DMZ ofcourse :-) ... comes from internal network. ... The servers on your DMZ is then, only as secure as how secure your ...
    (Security-Basics)