A friend posted a link to the latest edition of a document entitled Best Practices for Securing Active Directory from Microsoft IT. Nice document – full of useful tips on the subject. One thing that I noticed was missing, however, was any reference to feature introduced with Windows 2008 R2 and Windows 7 known as the Managed Service Account.
Maybe you have who heard heard of the concept, or maybe like many you haven’t, but let me explain the “problem space” first …
As an Identity Management consultant on the Microsoft platform I’ve found securing service accounts problematic from the start. Here are a couple of anecdotes which may be familiar.
- A customer lodges a support call for an ILM 2007 (Windows Server 2003 platform) solution where an Active Directory Application Mode (ADAM) management agent run profiles has been failing for some time. Investigation finds that while there is a standard in place that all service accounts are assigned a strong password but had the “account never expires” checkbox set, the password for the ADAM service identity is “incorrectly” allowed to expire. Remediation would no doubt be to reset the password and this time set it never to expire.
- A customer maintains a file of all the passwords for the dozen or so service accounts that were created to run a moderately complex FIM solution. While the password strength is strong, the security of these accounts is potentially compromised both by the need to store these passwords somewhere to allow the FIM solution to be supported.
- A FIM customer is required to observe a policy whereby service account passwords are never divulged to a non-system administrator within the company. This causes no end of problem when the FIM consultant is attempting to troubleshoot/test/deploy components of the FIM solution when the sys admin is not available.
If any of the above are issues for you too, as I suspect they will be, then this feature becomes a must have. In a nutshell, this is a facility whereby service accounts are created in AD in a way such that when they are assigned to a service the password is never entered.
Sound too good to be true?
Well yes and no … no because you can set up Exchange and ADLDS this way now and it works. Yes because at the time of writing (June 2011) neither SQL 2008 nor Windows Task Scheduler supported the idea. However, going by this blog post it appears that SQL 2012 finally does! 🙂
How can that possibly work? Well I’ll let you read the posts linked above to find out. There’s not much to it, and it will be well worth the effort. I have yet to try this myself, but in addition to the plethora of service accounts in any FIM deployment, I can’t see why all of the FIM 2010 connector windows identities shouldn’t be able to work this way too. If anyone has an opportunity to try this out before I do, please let me know by posting back here. If it turns out not to be supported, then I’ll be sure to make this a FIM feature request on Connect!
Why don’t you try this for yourself?
IdM for Real 
Note that Managed Service Accounts under 2008R2 / Windows 7 are restricted to being used on a single computer. If the account is needed across multiple computers this can be problematic and the additional overhead caused by creating and managing multiple service accounts might offset the savings in not having to worry about password management.
Windows Server 2012 / Windows 8 allows for Group Managed Service Accounts – now giving you the ability to extend the use of a single MSA across multiple computers.
Of course, this requires you having WS2012 as your platform to leverage this and the time and effort required to upgrade your server fleet for running solutions for this reason alone is probably not worth the savings (though have a look at the other benefits a platform upgrade will bring and the sum looks a lot better).
If you are starting from scratch (or it is time for an upgrade anyway) then definitely have a look.
For more info on MSAs – look at http://blogs.technet.com/b/askds/archive/2009/09/10/managed-service-accounts-understanding-implementing-best-practices-and-troubleshooting.aspx
and Group MSAs (gMSAs) – http://technet.microsoft.com/en-us/library/hh831451.aspx
Thanks for that Peter. In the case of FIM service accounts this already meets the single computer criteria (i.e. accounts are either on the FIM service or the FIM sync service). What remains to be discovered is exactly which services/processes support the idea right now – e.g. only introduced in SQL2012. I am not aware of any doco which might short-circuit the need for the “suck it and see” approach here are you?
nope – not aware of any doco specifically. Application support for sMSAs and gMSAs still needs to happen and hopefully the product teams within MS might have answers here (time to lean on your MVP creds to get access?).
I would expect that with WS2012 platform support that the product teams (should, hopefully) be looking at any changes to best practice in light of new platform features.
I wouldn’t expect anything from the DS team that covers this for specific applications, but that’s just imho.
Thanks for the post block; am I correct to understand that MIM does not support managed service accounts at this stage?
Michael – you will have to try this for yourself – the context is using these accounts for the management agent identities. The question is what would you need to enter in the MA identity password … let me know if this works?
Thanks Bob; will do if/when I get a chance to try it.
My gut feel is that you would need to re-enter the updated MA account password.