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?