In terms of security and manageability - What is best practice?

Should web servers

  • Be added to and managed from an Active Directory domain


  • Be part of a 'web server' workgroup that is separate from the 'resource server' active directory?

There is no a requirement for there to be user accounts on the web servers, only management accounts (server management, system reporting, content deployment etc.)

  • Are these webservers in a Colo or in a DMZ at your office?
    – Rob Bergin
    Jun 1 '09 at 20:10
  • Good point to raise. Servers are within our own control in our own server room. Jun 2 '09 at 8:33

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.


Internal use, absolutely. That way they get managed by GPO, patching isn't as difficult, and monitoring can be accomplished without a bunch of workarounds.

In the DMZ, generally I'd advise no, they should not be on the DMZ. If they are on the domain and in the DMZ, the issue that you run into is that the web server must have certain connectivity back to at least one DC. Therefore, if an external attacker compromises the web server, he or she can now directly launch attacks against one of the DCs. Own the DC, own the domain. Own the domain, own the forest.

  • Thanks KB and Rob. Creation of another AD in the perimeter network is one answer but I can't justify me having to buy another server just to be the host of a AD for web servers. Urg. Another complication is that the webservers must have SOME traffic allowed into the internal 'trusted' network (for example SQL) and that SQL traffic is secured using a trusted network connection. I guess we have to be talking about two ADs and a trust between the two? Jun 1 '09 at 13:37
  • That's the safest route, yes. You have a forest for the DMZ based servers and it has a one way trust back to the internal forest. However, I would look at allowing SQL Server based authentication first. Jun 1 '09 at 14:04
  • I agree, this is the way to go.
    – squillman
    Jun 1 '09 at 14:37

Why not have a Webserver's Domain in the DMZ?

It could be a separate forest with a one way trust relationship to administer the domain from your main domain without giving any permission to the WS's domain for your main domain.

All the joys of AD/WSUS/GPO - especially useful if you have a whole farm of them - and if it's compromised it's not your main network.

  • 1
    That's the safest route to go if you have to use a domain. However, you're still talking about getting a direct attack on a DC. And in the scenario you give, if I get that DC, unless you've taken out cached credentials, I can still pull those and have credentials to use against the primary domain/forest. Jun 1 '09 at 14:23
  • KB, Out of interest, can you describe 'cached credentials' Jun 1 '09 at 16:02
  • 1
    Unless you turn it off, a Windows system will cache the password credentials (actually a hash of a hash) when you log on. This is what permits you to have a laptop and log on with your domain logon when away from the corporate network. Extract that, use rainbow tables, you get the idea. Jun 1 '09 at 16:22
  • 3
    If the trust is only one, way cached credentials are irrelevant as the DMZ server will never authenticate against the primary domain. Jun 1 '09 at 22:30

If the webserver is on the same network as the Domain Controller(s), then I would definitely add it to the domain - as this obviously adds a great deal of manageability. However, I would usually strive to put webservers in a DMZ to increase security - which makes access to the domain impossible without pinholes (and that's a very bad idea!)


As others have mentioned, if these are public facing and do not require authenticating users against the directory, then do not put them in the domain.

However, should you require some sort of authentication or lookup of information from AD, possibly look into running Active Directory Application Mode (ADAM) in the DMZ. You may need to replicate the relavent information from AD into the Applicaton Partition as ADAM does not synchronize the standard AD partitions.

If you are just looking for management features though, ADAM does not apply.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.