5

I'd say the question is self-explanatory, but to give a bit of context to the sort of environment I'm talking about.

The scenario is that your webservers are being joined to the domain to make administration easier. Then, if we run the website as a domain user, we gain the ability to run define the connectionstrings as SSPI. Is it then valid (or more specifically, encourage/discouraged) to run the application pool as a domain user simply so that SSPI for the connection string will function.

Obviously, there are a few things that we would do here, such as reduced access to the domain user beyond the machine it's running on (non-interactive etc.), strong passwords, etc.

I appreciate that this doesn't really solve many security issues, it's just a question that came up and I've always considered it to be the wrong way. I'm looking for specific reasons why this shouldn't be done as it solves some of the issues we have (e.g. we cannot easily encrypt connection strings).

3

It's not ideal, in that it is better to not use a domain account where a local account will suffice, but I wouldn't say that it would generally be considered falling to level of a bad practice. It certainly can as you note, make administration easier, particularly in scenarios where you have multiple web servers for an application which these days, is more common than not, or need access to a range of domain resources.

You must of course, as you've noted in your question, follow the generally recommended practices you've already identified for service-type accounts, but ultimately, properly managed and limited, a application service account should not expose you to much more attack surface area that machine accounts configured to have access to the same network resources.

  • Any comment on the use of SSPI if we're not using it for Passthrough authentication of logged in users? – Martin Mar 1 '16 at 19:05
  • @Martin It's definitely recommended. Specifically the configuration security recommendations suggest that Windows authentication be required for client connections and of course in this case Windows authentication and SSPI are the same thing. I generally don't even enable SQL Authentication on SQL Servers I'm setting up, unless I have an application that specifically requires it for some reason. – Xander Mar 1 '16 at 20:13

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.