Managed Service Accounts

There used to be a time that I would get an itch to deploy Managed Service Accounts, but as soon as I started to implement them, I would remember why I always leave my services as basic user accounts. For some reason, creating MSA's through ADUC just isn't a reliable option so we are left to configuring these MSA's through Powershell. Most of us are not experts in Powershell and rely on the documentation that Microsoft provides us, but for some reason there are instances the explanations are so vague that you end up more confused than before you started.   To add to the confusion there are only a small number of walkthrough's dedicated to this seemingly simple task, that not only add to confusion as they do not explain any of the switches  or what they are doing. Hopefully this post will help clarify some of your questions so you can get your MSA's up and running. This post will apply to Windows Server 2012R2, and possibly any other after that but I have not tested it on those yet. Just to help the simple minded people like myself understand a bit better, we will assume we are simply creating a MSA for some service called "SwelcherFTP" and the MSA account name will simply be "saftp". We will also assume our DC name is "DC1", and our remote server is "FTP1". To start off with, I'm going to go over the pseudo-code of the process to help you all understand what is needed. Some additional assumptions that will be made are that the service you will be running will be on a remote server (for some reason every tutorial shows creating the MSA on the DC, which just doesn't apply in the real world).

  1. Identify the needs/requirements of the application you are running. More than likely it will require the Service Account to run as Local Administrator, because that appears to be the only way anyone can program an application. (I'll dedicate another post in the future on how to run a service not as a Local Administrator.)
  2. We will create the KDS key, this will generate the passwords for the MSA. Pay special attention to the syntax of this because for some reason Microsoft made it to where after executing this part of the command, you have to wait 10 hours before you can create a MSA, the command that will be posted below will be a work around.
  3. We will create the MSA, this can be on any computer that has the rights to create accounts. Whichever computer you execute this on it will also need the RSAT Powershell Module installed, which is essentially the Active Directory Powershell Module AKA "Import-Module Active Directory."
  4. We will designate the remote server that is allowed to use the MSA.
  5. Then we will need to add the MSA to the remote server by essentially installing the MSA on the remote server. This means that the same RSAT Powershell Module will need to be on the remote server that you are wanting to install the MSA. For whatever reason there is not a switch that allows you to specify which remote computer to install the MSA on, which is a pain because most servers don't have the RSAT Powershell module installed on them, and you have to manually go install it.
  6. After the account has been installed, only then will your remote server be able to use the MSA. Whether the application will start or not is a different story, because as I stated above, you will more than likely have to add the MSA to the Local Administrators group because that seems to be the norm nowadays.

Now here are the Powershell commands to run and an explanation of what each one is doing will follow below.

  1. Execute on DC1: Add-KDSRootKey -EffectiveTime ((get-date).addhours(-10))
  2. Execute on DC1: New-ADServiceAccount -SamAccountName saftp -DNSHostName saftp.local.domain
  3. Execute on DC1: Set-ADServiceAccount -Identity saftp -PrincipalsAllowedtoRetrieveManagedPassword FTP1$
  4. Execute on FTP1: Import-Module ActiveDirectory
  5. Execute on FTP1: Install-ADServiceAccount -Identity saftp
  6. Execute on FTP1: *This isn't a Powershell command" apply the appropriate permissions, which more than likely is just Local Administrator.
  7. Execute on FTP1: *This isn't a Powershell command" add the MSA to the service SwelcherFTP in Services, and remove any password that may have been populated into the password field.
  8. SwelcherFTP should now be running as the MSA saftp.

Why it is that complicated, I do not know, but for some reason Microsoft didn't want us to just right click, add a new MSA, select the servers we want this account to be able to logon as, and be on our way. To clarify a few things, I will explain each Powershell command, which is only steps 1-5.

  1. According to Microsoft the Add-KDSRootKey command generates a new key for the Group Distribution Service, which effectively manages the passwords for your MSA in this instance, which is why we have to execute the command. The -EffectiveTime switch can also be changed to -EffectiveImmediately, but the EffectiveImmediately switch doesn't mean that the KDSRootKey will be effective immediately. It means it will be ready in 10 hours when it has replicated to all the other Domain Controllers. To get around this we pass the -EffectiveTime switch and instead of doing the math ourselves, we simply just call the get-time command and subtract 10 hours from the result of get-time, and we set that as our EffectiveTime for our new KDSRootKey.
  2. New-AdServiceAccount simply creates a new service account. The -Name switch simply names the service account. Here's where things get a bit tricky as Microsoft's documentation doesn't explain what this next switch is that is required, -DNSHostName. The -DNSHostName switch is wanting you to create the actual FQDN for the service account itself. Maybe I've never managed a Domain large enough to where this every changes, but in our instance we just added saftp.local.domain.
  3. This command, Set-ADServiceAccount, allows you to change criteria of the called service account. Again the -Identity switch specifies which MSA we are wanting to alter. The -PrincipalsAllowedtoRetrieveManagedPassword, is wanting you to pass which computer account is allowed to contact the DC to retrieve the password for the MSA, which in our case will be the remote FTP1 server. Notice how the syntax though is FTP1$, you will need to add the $ at the end. This command can actually be passed in the New-ADServiceAccount command in step 2, but for whatever reason I've always had issues if I do not execute the Set-ADServiceAccount command.
  4. Imports the AD powershell module.
  5. Install-ADServiceAccount installs the specified service account on whichever server you are wanting the MSA to be used on.

There really isn't much to it, but the documentation on the process isn't very good, hopefully Microsoft will make this process less painful in the future.