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!
Thanks!
Zach
UPDATE
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.
Best Answer
@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.