Should Production Windows Web Servers (IIS & SQL) be in a domain?

Question

We have a few web servers and a few database servers. To date, they've been standalone machines that are not part of a domain. The web servers don't talk to each other, and the web servers talk to the database servers via SQL Auth.

My concern with putting the machines in a domain together were

1. added complexity - it's one more "thing" running, and doing "things" that could go wrong.
2. risk - if a domain controller fails, am I now putting other machines at risk?

However, in certain scenarios it does seem convenient for them to be on a domain, sharing credentials. For example, if I want to give the "services" control on one machine access to another machine (because Remote Desktop craps out) I need to go in and assign privileges on multiple machines - something that I believe Active Directory and Domain Accounts set to simplify.

My question: I'm sure there are things I'm not considering here. Is there a best practice?

Answer 1

The Powers That Be can clarify things of course, but the entire StackOverflow Network runs on IIS servers with an SQL back end in an Active Directory Domain. I'd say it works well.

• added complexity - it's one more "thing" running, and doing "things" that could go wrong.

Sometimes adding complexity allows you to remove some. Especially if you're worried about scaling out, having a domain can greatly ease the work of adding servers, changing config, and any number of things. Group Policy and centrally administered scripts can do amazing things to ease your life.

• risk - if a domain controller fails, am I now putting other machines at risk?

That's why you have two Domain Controllers, and don't make them reachable from the Internet. If someone penetrates your site, you're pretty much hosed anyway. This is why it's a very good idea to have your AD Domain be just for your application environment, if possible.

And finally, Microsoft designs their environment to work within AD. Inter-server communication is both easier and more secure when AD is involved to arbitrate authentication and encourage secure protocol usage.

Answer 2

Don't just think about the cost of AD, think about what it adds

• centralised account management
• ability to set and enforce consistent security policies
• ability to centralise software deployments
• ability to automate actual operating system installation

All of those things can reduce complexity and improve security in an online site - by centralising stuff you hopefully make it easier to deploy consistently.

Now that isn't the same as deploying correctly/securely of course, but it does mean that once you figure out what correct/secure deployment means you only have to get it right once on your centralised OS image and settings, and it can be consistently pushed out to new servers. Useful for both expanding your systems should you need to do that and for creating test/dev environments that are the same as the production network.

If most of your problems are down to mistakes (and for most of us, they are) then AD makes automation and sharing resources easier to do, reducing the opportunities to make those mistakes.

We have all our servers in a domain where I work, for the reasons I give above (a separate domain from the LAN side of things). There are risks and costs to this approach too of course. You need to consider both sides and make a balanced decision.