Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

We are preparing to deploy a new version of our application. The production environment will be two load balanced app servers connecting to two database servers (configured for mirroring). Now during testing in our office we use one app server and one db server and most of the authentication is done using our domain controller, we have discovered that domain authentication is nice and would like to keep that in production if possible.

When we go into production I am trying to figure out if it makes sense to have my two app servers be domain controllers so that authentication of the services to the SQL servers etc can use domain authentication.

What is the common practice in this sort of situation, should I use Active Directory, or is there a lightweight replacement? Is workgroup mode the accepted way? Is it foolish to have my app servers be domain controllers?

share|improve this question
up vote 2 down vote accepted

I wouldn't do it, for security reasons, if the app tier is going to be exposed to the internet. If so, they should be in a DMZ, and not able to directly contact your internal AD. Imagine if they were cracked and they were DCs. Bad news, right? And imagine if they were not DCs, but cracked, and could be used to mount attacks directly against domain accounts.

If you want auth to your AD, the best practice is to use something like ADAM and AD-replication or some sort of proxying.

If this is an internal-only app and not exposed to the web, then you can do whatever you want.

Edit - Another comment. If you want domain authentication strictly within the application environment (your question is unclear to me on this point), then you can set up a stand-alone AD within your DMZ. If you're clustering SQL, I think you need a domain anyway for that. Allowing the app-tier to use that domain to authenticate to SQL is better than allowing it to connect with your actual internal AD. "Best practice" always has to be weighed against the benefits and risk of what you're trying to do.

share|improve this answer
The Servers will be at our host, and behind the usual firewall etc. Apps are not hosted in IIS, but I hear you wrt to DC's as app servers. Is proxying the sort of thing that could be co-hosted on an app server, or best to just steer clear of that? – David Martin Sep 13 '10 at 23:53
Your goal is to not allow a server, that could potentially be cracked by an external user, to have any rights or access to your internal (trusted) network. You don't want software that can interface directly with your AD running on a server that hosts internet-facing services. – mfinni Sep 14 '10 at 0:41
You guessed correctly, the AD in production would be totally separate from our office AD, and used only by those servers. It seems like the benefit is far outweighed by the extra expense of two additional servers. Mind you the workload would be so small the servers would hardly need to be big... – David Martin Sep 14 '10 at 1:56

Is it foolish to have my app servers be domain controllers?

Sure is. It is never wise to expose a domain controller directly to the Internet. Your app servers should be querying a DC on another machine (virtual or physical). You should also ensure that any traffic between the servers and the DC is encrypted.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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