One of the biggest problems we have in automating application deployments is the idea that running IIS AppPools and Windows Services under domain service accounts is a 'best practice'. Unfortunately, this best practice sometimes causes deployment headaches in that either we need to provision a new domain level service account quickly, or once we have the account, we now need to manage the account credentials.

I had a great conversation about not making domain level service accounts a requirement and effectively taking one of two approaches:

  • Secure at the node level using machine account(domain\machine$) and add the node to appropriate ActiveDirectory/Sql groups/roles
  • Create local app specific accounts on each machine (machine\myapp) and add that account to appropriate ActiveDirectory/Sql groups/roles (the password here can change per deployment, it doesn't need to be stored)

In both cases, it seems that its easier to manage either adding an account to appropriate group/role, or even stand up new, local account, than it is to have to provision a new domain level account and manage those credentials.

This would hopefully ease the management burden on ActiveDirectory, Sql Server and Operations teams as there would be no more password management.

We've not actually been able to implement this in practice yet. I am coming from a development background, so I'm curious as to how many ways this approach could go wrong? Can we really get rid of domain level service accounts with this direction?

I'd appreciate any thoughts from anyone who has taken this path!




Previously, since the application teams did not want to store passwords for service accounts, and we really didn't care what they were (should we?), we provided our ActiveDirectory team with a utility that created a hash of the password. So, when we needed a service account, we'd submit the request and they would respond with the hashed password.

In our deployment scripts (which the app team owned) any where we used a password, we actually used the hash. The deployment framework knew how to decode that hash on the fly when creating assets.

  • 2
    How are app specific accounts on a single machine any better than domain accounts? Seems like more work to me, though work you could potentially perform vs. a domain admin. How big is your domain (users/computers)? – Goyuix Dec 31 '10 at 16:04
  • I'm with @Goyuix. It's at least the same amount of work, if not more. Since I can provision a domain account with a command line in 10 seconds, I am not convinced it's a "burden", even on a large domain. I receive a ticket to create the account, and then it's done. If it's a service account, it's set to never expire, and that's all she wrote. – user3914 Dec 31 '10 at 16:12
  • @Goyuix, the only real difference (I think) is that we are not managing passwords for the local accounts as they are possibly set with each application deployment including updating application pools and windows services account info. I don't know how many users in our domain (4k?) and we have several hundred servers total across all environments. The not managing passwords is where I was hoping to get a win, and I'm not sure its possible in all situations, just trying to see if in general situation it could work. Does that help clarify? thanks! – Zach Bonham Dec 31 '10 at 16:13
  • How does a domain password require any more 'management' than a local account? All it will do is move them out of sight where they can become a security hole without anyone noticing because they are more unmanageble. It seems to me that the problem might be your company's red tape not a technical one. – JamesRyan Dec 31 '10 at 16:18
  • 2
    Since service accounts can be in their own OUs in AD, the number of other user accounts is irrelevant as they can be kept seperate. Additionally delegation could be used to allow app teams to add those accounts directly. Avoiding your companies security policies is not really the right answer. Go with them or change them to be more appropriate. – JamesRyan Dec 31 '10 at 16:19

@Tom pointed me in the right direction, I think. Windows Server 2008 R2 introduced the idea of Managed Service Accounts and Virtual Service Accounts. This feature appears to be what I was looking for in eliminating the management of passwords.

Check out Scott Forsythe's post Managed Service Accounts (MSA) and Virtual Accounts and TechNet's Service Accounts: Step by Step Guide for more information.

Here is a side by side comparison of Managed Service Accounts vs. Virtual Accounts.

The Achilles heel of Managed Service Accounts is that they are limited to 1 computer for some reason? This doesn't allow me to scale out and forces me back into the traditional service account model where I am responsible for the service account. If I have to do that, then adding local accounts (with random passwords, or even machine account) to a particular AD group and map that to Sql Roles still seems to work? I really would like to have someone with ops experience help me understand why that is bad.

I don't understand the implication of not allowing the machine account network access as long as I am securing that node via other means. E.g. allowing only outbound service calls to known endpoints via firewall, or some other means?

Otherwise, Managed Service Accounts and Virtual Accounts seem to be functionally the equivalent of what I was looking for.

  • Note to readers : Windows Server 2012 introduces Group Managed Service Accounts that aren't limited to only one computer. – Julien Lebosquain Nov 3 '14 at 0:10

I believe Server 2008 provided a mechanism for managing service accounts and automatically rotating their passwords.

Edit: This may have some with 2008 R2 specifically. I seem to remember reading this when learning about the schema enhancements.

  • +1 for giving me enough context to apply some google-fu! I should probably mark this as an answer, and post my answer as another question (as there are more questions than answers!) :) How does that normally work? – Zach Bonham Dec 31 '10 at 18:46

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.