I've not yet perused this entire discussion, but I do want to point out one
thing- recommending that web servers be part of an AD domain does *not*
automatically translate to recommending that they be part of your internal
domain. I'm a proponent of, whenever possible, building a separate forest in
the DMZ to support web farms, outward-facing applications, etc. That forest
itself is separated into multiple protected subnets (DCs, SQL boxes, COM
servers, etc. being more isolated than the web servers). Compromise of that
forest does not compromise the internal environment, and you get the
advantages of more than just group policy. Additionally, if you've worked
with Windows Server 2003, you know that IIS 6 is an _entirely_ different
animal and benefits greatly from Active Directory.
My pennies and pocket lint,
Laura
> -----Original Message-----
> From: Michael Devlin [mailto:Michael.Devlin (at) figleaves (dot) com [email concealed]]
> Sent: Thursday, February 13, 2003 9:37 AM
> To: Erik Birkholz; g0d; Chris W. Parker
> Cc: focus-ms (at) securityfocus (dot) com [email concealed]
> Subject: RE: website inside or outside the domain?
>
>
> Erik,
>
> >I see where you are going, however I think your solution is
> impractical
> >due to manageability and leaves out many variables like the
> increased
> >chance of human error. <SNIP>.
>
> >In my opinion, If you are a large shop, your best option is to use
> >Active Directory's Organizational Units to subdivide your
> web servers
> >into a container that has limited permissions. This will
> allow you to
> >apply web server specific group policy to this OU and minimize the
> >change for human error by reducing the task of individual server
> >configuration.
>
> <SNIP>
>
> >By running your web servers as separate
> >workgroups you increase the human interaction and chance for human
> error
> >as your configure and manage them.
>
> I feel it is the "human error" that you mention that is the
> reason why the webservers *should* be in a stand alone
> workgroup isolated from the domain, with a dedicated admin
> responsible for the security and config of the servers.
> Keeping a domain in a working yet (fully) secure order is a
> (nigh on impossible) 24/7 task, the last thing you need to
> worry about is whether the front facing webservers are going
> to suffer or be compromised due to AD changes (see cockups).
> I feel the same goes for the webservers aswell. (With regards
> the manageability and the task of server config: it is worth
> pointing out that a lot of the GPO auto config functionality
> and security benefit reaped from being in a domain can still
> be obtained on a stand alone 2000 box through the GPEDIT.msc,
> coupled with a bit of scripting!)
>
> Being part of a domain also means you need to open up the
> inner firewall to an assortment of protocols (DS, Kerberos,
> ldap etc etc).... So you have also got to consider that if
> you are unfortunate enough to have your webservers
> compromised (supposedly the tightest part of your
> network) then;
> A: there is a good chance you haven't been doing your
> homework with re: to your domain security aswell as your
> webserver security. or
> B: the attacker *really* knows what he is doing and is going
> to walk straight into your first DC
>
> Having a defaced webserver is bad enough, but direct access
> to the whole network through your webservers..... Nasty!
>
> You also need to look at it from the other side of things....
> If your domain is compromised (that contractor with the
> shifty eyes?) do you really want access to your website so
> the perpetrator can announce to the world how he got in! By
> keeping the webservers "locked up" (both physically and
> virtually) you can make that step as hard (if not harder)
> than approaching it from the front door.
>
> Just my tuppence worth,
>
> Cheers
>
> Michael
>
>
I've not yet perused this entire discussion, but I do want to point out one
thing- recommending that web servers be part of an AD domain does *not*
automatically translate to recommending that they be part of your internal
domain. I'm a proponent of, whenever possible, building a separate forest in
the DMZ to support web farms, outward-facing applications, etc. That forest
itself is separated into multiple protected subnets (DCs, SQL boxes, COM
servers, etc. being more isolated than the web servers). Compromise of that
forest does not compromise the internal environment, and you get the
advantages of more than just group policy. Additionally, if you've worked
with Windows Server 2003, you know that IIS 6 is an _entirely_ different
animal and benefits greatly from Active Directory.
My pennies and pocket lint,
Laura
> -----Original Message-----
> From: Michael Devlin [mailto:Michael.Devlin (at) figleaves (dot) com [email concealed]]
> Sent: Thursday, February 13, 2003 9:37 AM
> To: Erik Birkholz; g0d; Chris W. Parker
> Cc: focus-ms (at) securityfocus (dot) com [email concealed]
> Subject: RE: website inside or outside the domain?
>
>
> Erik,
>
> >I see where you are going, however I think your solution is
> impractical
> >due to manageability and leaves out many variables like the
> increased
> >chance of human error. <SNIP>.
>
> >In my opinion, If you are a large shop, your best option is to use
> >Active Directory's Organizational Units to subdivide your
> web servers
> >into a container that has limited permissions. This will
> allow you to
> >apply web server specific group policy to this OU and minimize the
> >change for human error by reducing the task of individual server
> >configuration.
>
> <SNIP>
>
> >By running your web servers as separate
> >workgroups you increase the human interaction and chance for human
> error
> >as your configure and manage them.
>
> I feel it is the "human error" that you mention that is the
> reason why the webservers *should* be in a stand alone
> workgroup isolated from the domain, with a dedicated admin
> responsible for the security and config of the servers.
> Keeping a domain in a working yet (fully) secure order is a
> (nigh on impossible) 24/7 task, the last thing you need to
> worry about is whether the front facing webservers are going
> to suffer or be compromised due to AD changes (see cockups).
> I feel the same goes for the webservers aswell. (With regards
> the manageability and the task of server config: it is worth
> pointing out that a lot of the GPO auto config functionality
> and security benefit reaped from being in a domain can still
> be obtained on a stand alone 2000 box through the GPEDIT.msc,
> coupled with a bit of scripting!)
>
> Being part of a domain also means you need to open up the
> inner firewall to an assortment of protocols (DS, Kerberos,
> ldap etc etc).... So you have also got to consider that if
> you are unfortunate enough to have your webservers
> compromised (supposedly the tightest part of your
> network) then;
> A: there is a good chance you haven't been doing your
> homework with re: to your domain security aswell as your
> webserver security. or
> B: the attacker *really* knows what he is doing and is going
> to walk straight into your first DC
>
> Having a defaced webserver is bad enough, but direct access
> to the whole network through your webservers..... Nasty!
>
> You also need to look at it from the other side of things....
> If your domain is compromised (that contractor with the
> shifty eyes?) do you really want access to your website so
> the perpetrator can announce to the world how he got in! By
> keeping the webservers "locked up" (both physically and
> virtually) you can make that step as hard (if not harder)
> than approaching it from the front door.
>
> Just my tuppence worth,
>
> Cheers
>
> Michael
>
>
[ reply ]