What is the best way to manage user accounts for Windows servers in a DMZ? We are expanding our web presence and adding several IIS servers to our DMZ. I would prefer not to manage a bunch of local accounts or, on the other hand, expose our internal Active Directory servers directly to the DMZ either. Is there a standard approach to this problem?
Active Directory in a DMZ – Best Practices
active-directorydmz
Related Solutions
If you want to use Kerberos delegation to build a secure infrastructure (and YOU DO) you will need to join those Web servers to the domain. The web server (or service account) will need the ability to delegate assigned to it in order to allow user impersonation against your SQL server.
You proably want to stay away from using SQL-based authentication on the SQL server if you have any auditing or statutory requirements for tracking data access (HIPAA, SOX, etc.) You should be tracking access through your provisioning process (i.e. who is in what groups, how that was approved, and by whom) and all access to data should be through a user's assigned account.
For DMZ issues related to accessing the AD, you can resolve some of that with Server 2008 using a Read-Only DC (RODC) but there is still risk with deploying into the DMZ. There are also some ways to force a DC to use specific ports to punch through a firewall, but this type of cutomization can make it difficult to troublehsoot authentication problems.
If you have specific needs to allow both Internet and Intranet users access to the same application you might need to look into using one of the Federeated Services products, either the Microsoft offering or something like Ping Federated.
A server placed in a DMZ can't open connection to your network because there is a firewall in the middle (by the very definition of DMZ), so your network will be protected from it, should it ever be compromised by an attacker: in this scenario, the compromised server could not be used as a starting point to launch new attacks against the rest of your network. This is instead not the case if the server is placed inside your network, and you open firewall ports to allow external users to access it using the services it provides. The same succesful external attack (f.e. against a web site) would lead to very different consequences if your server is in a well-guarded DMZ or inside your LAN.
That said, placing a server in a DMZ is really only useful if you can actually filter the traffic between it and your internal network; if it requires domain controller access for authentication, database access for back-end data and mail access for sending out messages (like an Exchange CAS), and you need to open all of those ports between it and internal servers in order for it to actually do anything useful, then there really isn't much of a point in placing it in a DMZ. Domain member servers are the worst offenders here: domain access requires so many open ports between a computer and its domain controllers that it could as well be placed in the same network as them; and a compromised domain member computer is a big security pain, because it can access lots of things in the domain.
Rule of thumb for Windows servers: if it needs to be a domain member, then placing it in a DMZ is A) a pain to get it to work correctly and B) almost useless; keep them in your LAN, but be sure to keep them fully patched, running a good antivirus and protected by a well locked down external firewall. The best approach here is using a reverse proxy, an inbound mail relay, or anything else that can act as an application gateway, and avoid exposing them directly to the Internet.
Best Answer
The Active Directory team at Microsoft has released a guide with best practices for running AD in a DMZ.
Active Directory Domain Services in the Perimeter Network (Windows Server 2008)
The guide covers the following AD models for the perimeter network:
This guide contains direction for determining whether Active Directory Domain Services (AD DS) is appropriate for your perimeter network (also known as the DMZs or extranets), the various models for deploying AD DS in perimeter networks, and planning and deployment information for Read Only Domain Controllers (RODCs) in the perimeter network. Because RODCs provide new capabilities for perimeter networks, most of the content in this guide describes how to plan for and deploy this new Windows Server 2008 feature. However, the other Active Directory models introduced in this guide are also viable solutions for your perimeter network.