Re: [ActiveDir] what to do with DMZ servers

[Glenn Corbett]

Option 4, Create a DMZ AD forest with NO ties (trust or otherwise) to the production AD. Option 5, Create "proxy" applications to access certain aspects of the production AD from the DMZ, but control information flow and access.   An AD is required for some systems (such as clustering which requires a domain to function), and other systems (such as MOM) "recommend" an AD environment.  I've deployed MOM in a no-domain config (the core MOM servers still require AD, but the agent clients dont), and frankly its a complete PITA.   Our current environment doesnt have any Domains (AD or otherwise), and each server is effectively standalone.  One problem with this is that each server requires a number of local accounts on each server (so they can be administered), and you end up with a bit of a security issue with all these additional accounts running around.    Our new environment will be running AD (had been some discussion on here recently about some of the ways to do various things with replication and authentication), primarily to support things like MOM, clustering, centralisation of management, and client databases.   If you are going to look into AD for your DMZ, I would recommend against joining it to your prod AD system unless there is a VERY compelling reason to do so.  With a channel opened up between the DMZ and prod you have the potential problem of usernames and passwords being harvested from your internal systems (not to mention all those other cool AD fields like home phone numbers, addresses, employee numbers etc.....*shudder*)   MS are going down the path of requiring AD for systems to function, and a number of them already do (like Exchange, Clustering, MOM, SPS etc)   MS have some documentation on their Internet Data Centre design (a veriant of which we are looking at).  As some have mentioned, there are some fairly relaxed security configurations, primarily to help "bodgy" applications or systems function correctly (path of least resitence).  We have locked down the design a fair bit, and are confident that it will provide some measure of security.   If you do require access to the internal AD system (depends of course on what you are trying to achieve), products such as ADAM may allow partial synchronisation of your internal AD database (excluding all those scary fields for example) into the DMZ for some levels of functionality.  You can also look at creating custom applications that proxy AD queries into the production network, and locking down access to this host from specific DMZ hosts and (optionally) from specific accounts.  You can then control the types of information that is returned, and refuse certain query types.  There are a bunch of ways to allow prod AD access from the DMZ (depending on requirements) without setting up a Trust and turning your DMZ -> prod FW into swiss cheese   Glenn   ----- Original Message ----- From: Pelle, Joe To: ActiveDir ([EMAIL PROTECTED]) Sent: Thursday, July 10, 2003 10:58 PM Subject: [ActiveDir] what to do with DMZ servers Please help:   My company is currently migrating from an NT domain structure to AD...  I have some questions regarding how some of you went about hooking in your DMZ web servers to AD securely...  What DID YOU DO?!!!!!!  What are the recommended best practices?   The options we have discussed so far are: Option1:  Join DMZ servers to AD domain, open a half dozen ports on each server (Kerberos, LDAP, NetBios, etc) and lose the purpose of having a DMZ altogether. Option2:  Create a separate forest for the DMZ servers and create a one-way trust between our two forests.  Option3:  Stand alone DMZ servers not joined to any domain. All other options: ??????????????????????????????   Your suggestions are greatly appreciated!   Is there even a need to hook DMZ into AD?  I've heard MS talk about needing AD for apps like Sharepoint Portal...     Joe Pelle Systems Analyst Information Technology Valassis / Targeted Print & Media Solutions 35955 Schoolcraft Rd.   Livonia, MI  48150 Tel 734.632.3753      Fax 734.632.6240 [EMAIL PROTECTED] http://www.valassis.com/   This message may have included proprietary or protected information.  This message and the information contained herein are not to be further communicated without my express written consent.