A free tool for creating and editing Managed Service Accounts, with no Powershell knowledge required. What is a Managed Service Account? They are a special type of domain account in Windows Server 2008 R2 that can be used to run Windows services, but unlike normal domain accounts you don’t have to keep changing the password to keep things secure – Active Directory will take care of managing the password for you and communicating this with the computer that is using the Managed Service Account (you don’t even have to restart the services for the password change to take effect). Pretty useful, but unfortunately the only way to create and configure these accounts is via Powershell… until now.

Not that there is anything wrong with Powershell, it’s great for scripting and automating things, but in reality I can’t see many people wanting to automate the creation of an MSA (Managed Service Account) as it would not be a very common task. The fact that it is not something you would do very often makes it even more important to have an intuitive simple GUI if you ask me, rather than having to look at the documentation and get familiar with the Powershell syntax for the various commands you need to run (or maybe you’ve never even used Powershell so there would be even more of a learning curve). Wouldn’t it be much better if you could just type in the details for your new MSA and click a button to have it created and associated with a computer?

Enter the new tool I’m developing: Managed Service Accounts GUI. An easy to use tool with a graphical user interface that provides an alternative to using Powershell to create and administer managed service accounts.

EDIT: The first version of this tool is now available and it can be downloaded here.

So first of all lets take a look at what you need to do to make an MSA work using Powershell (there is a separate Powershell cmdlet you need to run for each of these steps):

The first thing you need to do is create the MSA object in the domain and specify its name, username, container, any SPNs you want it to have, expiry date etc etc. The object that gets created in AD is of type “msDS-ManagedServiceAccount” and is actually much closer to being a computer account than a user account, as it is a member of the Domain Computers group by default and has a SAMAccountType attribute that corresponds to a machine account rather than a user account. Once you have created the account you need to associate it with the computer that is going to run services using this MSA. An important point to note here is that each MSA can only be used by one computer – this is one of the biggest drawbacks of MSAs in Server 2008 R2 (something that is addressed in Windows Server 2012, but more on that later). For anyone interested in the technical details, an MSA is “associated” with a computer account by simply updating the msDS-HostServiceAccount attribute on the computer object in AD so that it now holds the path (distinguished name) to the MSA object. So now that you have made the association in AD between the MSA and the computer account, the MSA now has to be installed on the computer that you want to use it on. This is done by running yet another Powershell command on the target computer, which uses the NetAddServiceAccount API to make the computer’s local logon services aware of the way it should handle this particular account.

So once you have completed all of those steps, you can change any Windows service running on that computer to use your MSA username – you won’t have to enter a password for it, it will be handled in the same way as when you set a service to run as Local Service or Network Service. From then on the computer will periodically reset the password and synchronise the new password with the MSA object in Active Directory. This is done in the same way that a computer’s password for its secure connection to AD gets reset every few weeks and updates the related computer account password in AD.

So whilst it is not extremely difficult to setup managed service accounts with Powershell, I think a nice simple GUI would be quite useful and would make this handy new feature easier to use and more accessible to those that are not keen on Powershell. So that is the purpose of my new application, and as well as making it easy to create MSAs it also makes it easy to add them to groups, and makes it possible to install them on remote computers (something that in theory should be possible with Powershell’s remoting capabilities but that doesn’t seem to work for installing MSAs). Here are some early screenshots of the application:

EDIT: Updated screenshots added 07/07/2012

As mentioned earlier, Windows Server 2012 introduces a new type of MSA – a Group Managed Service Account (GMSA for short), as opposed to the Server 2008 R2 / Windows 7 versions which are known as Standalone Managed Service Accounts (SMSA). The main difference is that group managed service accounts can be used on any number of computers rather than being tied to a single one. Microsoft have a table showing some of the differences between SMSAs and GMSAs, along with various other account types, here: http://technet.microsoft.com/en-us/library/jj128431.aspx#BKMK_Intro

So when Server 2012 is officially released I will be updating my GUI tool to work with group managed service accounts as well. Although the Powershell cmdlets on Server 2012 will default to creating GMSAs now, I will still need to make some changes to my program to handle them correctly and to allow configuration of the new features of GMSAs. Although the application does make use of one of the Powershell cmdlets, I tried to avoid just having my .NET application call Powershell behind the scenes for several reasons (mainly performance and ease of development) but this was unavoidable for creating a new MSA, despite me spending hours trying to get a purely .NET version working it seems that is pretty much impossible for anyone outside of Microsoft to do this (which is very annoying considering they push .NET as their development framework of choice). So some areas of the application might still work if you are using the new versions of the Powershell cmdlets from Server 2012 that default to working with GSMAs, but other parts of the program will not work or may produce unexpected results. I could make my application work with GSMAs now based on how they behave in the latest Release Candidate of Server 2012, but as there is a small chance things might change when they actually officially release it I would rather wait until the behaviour and properties of GMSAs are set in stone.

EDIT: The first version of this tool is now available and it can be downloaded here.

I’m hoping to have the tool finished by the 23rd of July at the latest, and it will be completely free! 🙂

As always, keen to hear any feedback people have on it or any suggested features you’d like to see.