0

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.

Zach Bonham
  • 210
  • 1
  • 3
  • 10
  • 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. –  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
  • @Randolph *you* can provision the account in seconds (awesome, btw!) but the experience in two small to medium enterprises is that the team in charge of provisioning is not nearly as agile as you are. It can take as long as 1 week to get an account provisioned, then we still need to manage the credential for the account. One enterprise left that to each application team, the other has kept those credentials w/ops team. Trying to eliminate any manual steps during our deployments without having passwords floating around in some form if possible? – Zach Bonham 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
  • @JamesRyan - totally agree with the red tape! I am ignorant as to why that red tape exists or is as difficult as it can be. It seems that it shouldn't be this way. I'm hoping you guys can help me figure out how to eliminate the red tape (either via automation, or some special sauce) to streamline this process. This is by no means the only rock in the road, but it seems we trip over this one more often than not. – Zach Bonham Dec 31 '10 at 16:22
  • @JamesRyan Delegation to the app team would work, but we would still need to manage the actual credential/password. Maybe thats the better question - how do I manage the password in such a way that it can be used in our automated deployment process? I can describe how we've done this in the past, but I was hoping to eliminate the need alltogether? – Zach Bonham Dec 31 '10 at 16:26
  • updated post to describe one way we managed passwords, maybe that is the more direct question is how to better manage them? Though, I'd like to eliminate the need altogether if at all possible? – Zach Bonham Dec 31 '10 at 16:33
  • @JamesRyan I am trying to change the policy because I absolutely do not want to violate them, or circumvent them. I didn't mean to give that impression! I'm concerned that I'm too ignorant of **why** that policy of domain level service account exists and to date have gotten a 'because thats how its always been done answer'. If we can eliminate the password management, then I was thinking that was a win for everyone. The reading I've done seems that it would be possible to eliminate them, but nothing indicates what dangers there would be if we did. – Zach Bonham Dec 31 '10 at 16:36
  • Keep in mind that if service accounts are done the easy way, it typically isn't secure. – mrdenny Jan 02 '11 at 11:45

2 Answers2

2

@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.

Zach Bonham
  • 210
  • 1
  • 3
  • 10
1

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.

SpacemanSpiff
  • 8,753
  • 1
  • 24
  • 35
  • +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