Managed Service Accounts GUI

June 27, 2012 — 29 Comments

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):

  1. 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.
  2. 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.
  3. 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:

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.

29 responses to Managed Service Accounts GUI

    Joseph Worrall August 27, 2012 at 02:39

    Looks like this fails in Windows 2012 Server (as you documented). Any chance of an update? Thanks.


    Hi, very great tools ! We are beginning our migration to WS2012 and i wait your tool with impatience. I hope this will be soon.
    Excellent work !


    I’m having some issues getting the MSA’s to install on remote computers. I am running the app from my Win7 worrkstation. The MSA creates in AD correctly, but the Install process is failing.
    The Failures take multiple forms, here are a few of them:
    1. Error creating required directories or files on remote computer: Access to the path “\\\c$\Program Files\Cjwdev\MSA Installer” is denied.
    2. Files and directories created successfully but the service could not be installed and started due to the following error: Unable to create Service. The last error reported was: Overlapped I/O operation is in process.

    Can you help shed any light on what I may be doing wrong?
    The account I am using for creation and install is a member of the Domain Admins group in AD and has Local Admin rights on the machines in question.

    Thank you for your time.



      Hi Mike, sorry I didn’t reply sooner but I’ve only just seen your comment (didn’t get the email for some reason).

      I’m afraid I can’t really explain why you would get an access denied error other than if you don’t have permission to create folders in that location… That error message is being generated by Windows and my application is just echoing it back, and generally if Windows says access denied then it simply means you don’t have the required permissions. Can you manually connect to the PC via that same UNC path and create the folders or do you also see an access denied message then?

      As for the second error message, I’ve never come across that and if I’m honest I can’t really explain how or why that would happen. How often is it doing that and is it happening on multiple remote computers or just one in particular?


        Michael Toombs October 12, 2012 at 21:56

        Thank you for getting back to me on this.
        As it turns out, it was a log-on account issue.
        I was running the app as my non-admin user 🙂
        After changing the user to my Admin user it worked better.
        As to the second error, it was due to the fact that the system I was running against was Windows 2003 not 2008 (oops).

        The app is working just fine, now that I have those two issues dealt with.



        Ah that’s good to hear 🙂 thanks for the update


    Really nice tool! I am wating for the w2k12 update…


    Hi there – I’ve been trying to use the MS directions for creating an MSA in Win12. Works fine until attempting install-adserviceaccount -identity where it returns an Access Denied message. I am logged on to an administrative AD module for PS and am domain admin, enterprise, admin, schema admin so perms should not be a problem. I suspect that because Win12 allows multiple computers to use the same MSA, that this cmdlet is not necessary. I just added the created MSA to the Log On tab of a service (but haven’t tested beyond that.) What do you think?


      I haven’t had chance to test on Server 2012 yet so can’t say I’m afraid, but I would say the easiest way is to just boot up a test VM and set any service to run as that GMSA account and see if it works


        I’ve gotten it to work on an application pool in IIS. It looks as if the Install-ADServiceAccount is unnecessary now. Thanks for the response.


        you’ve done better than me then – I’ve spent the entire day trying to get a Group Managed Service Account to actually work. I’ve created it and assigned it to a 2012 server but when I try to run a service as that account it just says logon failure. If I try run the Install-ADServiceAccount cmdlet it just says unspecified error. Tried completely wiping everything from AD and starting again with a new GMSA on a different server but get the same thing. Rather frustrating…


    Actually, the success I had worked only once! I tried to duplicate and for baffling reasons, it wouldn’t work again. It worked as an Identity in an application pool once and after a day of trying, could not get it to work again. Beginning to wonder if it was just my imagination.


    Hi, on which ports are the msa gui communicate?

    great tool … btw


      Hi Danny. It uses Named Pipes to communicate so that it will work against any machine that has the “allow file and printer sharing” exception added in Windows Firewall (which most people allow so that you can browse the C$ share remotely etc). I think the actual TCP ports named pipes use are port 139 and port 445


    I wanted to create a Group MSA on a 2012R2. Your app stopped creating it with a time out. When I now try to create a new one with the same name I can’t and get an error “the account already exists”. I cannot see that account in you tool and not in my AD Container “Managed Service Accounts”.
    Where can I find this existing account?


      Hi Dirk,

      That is rather strange. The program uses the standard MSA powershell cmdlets to actually create the accounts, so I’m surprised there was any issue there. As for where the account would be – it will only create it in the Managed Service Accounts container, there is nowhere else that the program tries to create it (unless you specify your own custom OU that you want it to be stored in). Perhaps you could perform an LDAP search for any objects where the username (LDAP attribute “SAMAccountName”) has the value you are trying to use, then you should find the MSA. If you don’t find it like that, try the search again with a $ symbol at the end of the username.



    Thanks Chris,
    I think I found out what happend but I need some more time to test and to be sure before I will post it here.

    Another question to discuss:
    I need to access folders with services that runs unter those MGAs. It would be a horrible job to change all folder permissions with this newöly created MGA so I think about putting the MGA in a group with domain admin rights. What do you think, will it break the security?

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s