Managed Service Accounts

Managed Service Accounts (MSAs) are a new feature in Windows Server 2008 R2. The concept is that the service account is managed by the server that’s using it. This can be very useful, as administrators will not be required to update passwords on these service accounts, and in some cases, the SPNs will be managed for you as well. To use an MSA, use basically create the service account object in Active Directory and configure the server to use the account. There are a couple of things you need to be aware of when using MSAs:

• MSAs can only be used on servers running Windows Server 2008 R2 or Windows 7.
• You are required to update the AD schema to WS08 R2.
• If using the automatic SPN management feature, your domain must be at Windows Server 2008 R2 domain functional level.
• MSAs can only be used on one server at a time, though you can have one server using multiple MSAs.
• MSAs should only be managed through the AD Module in PowerShell. Do not use the AD GUI tools or edit the directory directly for MSA objects.

Let’s take a deeper look at how MSAs work and how you can use them.

The MSA Object

MSAs are a new object class in AD called msDS-ManagedServiceAccount, which is a subclass of the Computer class. As you probably know the inheritance structure of the Computer class is:

Top > Person > OrganizationalPerson > User > Computer

This means that MSAs inherit the same attribute classes that Computer objects have. But if you look at the object class in the schema, you’ll notice that there are no added mandatory or optional attributes, nor are there any auxiliary classes added. So the difference between msDS-ManagedServiceAccount objects and Computer objects are minimal.

Password Changes

MSAs also don’t adhere to standard user password policies. You can’t set a fine grained password policy or control the complexity of the password for a MSA. It’s a hard-coded 240 character password that’s randomly generated. When an MSA is installed on a server, that server updates the MSA password using the same process that it uses to update its computer account password. Therefore, you can’t set password policies on the service account object itself. The password is reset every 30 days by default. To change this, you must update the policy for machine account password changes. In the registry, this is the following value:

HKLM\SYSTEM\CurrentControlSet\Services\NetLogon\Parameters\MaximumPasswordAge

Or change the setting in the server’s GPO under:

Computer Configuration\Policies\Windows Settings\Security Settings\Security Options\

Domain member: Maximum machine account password age

Using MSAs

There are basically 4 steps to using an MSA on your server.

Step 1: Meet the prerequisites

There are a couple of prerequisites that must be in place before you can use MSAs. First and foremost, your AD schema must be updated to Windows Server 2008 R2. You are not required to have Windows Server 2008 R2 DCs, unless you want to use the automatic SPN functionality. If you do want the automatic SPN functionality, your Domain Functional Level needs to be at WS08 R2.

Also, the server that the MSA will be used on requires the AD PowerShell Module and .Net framework version 3.5.1. To install these features, open PowerShell with the system modules imported and run the following commands:

Add-WindowsFeature RSAT-AD-PowerShell

Add-WindowsFeature NET-Framework-Core

If you don’t have the Add-WindowsFeature cmdlet available, make sure that you opened the PowerShell with the system modules imported. To do this, right-click on the PowerShell icon and select Import System Modules:

Step 2: Create the Managed Service Account

Open PowerShell with the AD module (Start > Administrative Tools > Active Directory Module for Windows PowerShell) and run the New-ADServiceAccount cmdlet. The only parameter that you need to specify is the name of the service account that you are creating. When the account is created, the samAccountName will have a $ appended to the end of it, just like computer accounts.

PS C:\> New-ADServiceAccount svc_app

After you create the account, you can verify it by running the Get-ADServiceAccount cmdlet.

PS C:\> Get-ADServiceAccount svc_app DistinguishedName : CN=svc_app,CN=Managed Service Accounts,DC=contoso,DC=com Enabled : True HostComputers : Name : svc_app ObjectClass : msDS-ManagedServiceAccount ObjectGUID : 7a39e2fa-eb62-4ed9-83be-c974afb493f3 SamAccountName : svc_app$ SID : S-1-5-21-3140640322-4110138197-1547801364-1118 UserPrincipalName :

Step 3: Install the Managed Service Account on the server

Now that the account is created, you can install it on the server that will be using it for a service. Open the AD PowerShell on the server and run the Install-ADServiceAccount cmdlet.

PS C:\> Install-ADServiceAccount svc_app

Now, if you run the Get-ADServiceAccount cmdlet again, you will notice that the service account is tied to a specific computer.

PS C:\> Get-ADServiceAccount svc_app DistinguishedName : CN=svc_app,CN=Managed Service Accounts,DC=contoso,DC=com Enabled : True HostComputers : {CN=CONTOSO-SRVR,CN=Computers,DC=contoso,DC=com} Name : svc_app ObjectClass : msDS-ManagedServiceAccount ObjectGUID : 7a39e2fa-eb62-4ed9-83be-c974afb493f3 SamAccountName : svc_app$ SID : S-1-5-21-3140640322-4110138197-1547801364-1118 UserPrincipalName :

You may be curious about that HostComputers attribute. Where did that come from? I showed earlier that the msDS-ManagedServiceAccount object class didn’t add any additional attributes to the Computer class that it is inherited from. So where is this HostComputers attribute defined?

It’s actually defined in two places - the computer object that the service is installed on and the managed service account object. If you look at the objects in AD, you will see the msDS-HostServiceAccount attribute on the computer object and the msDS-HostServiceAccountBL attribute on the managed service account object. This attribute is a linked attribute, so it has both the forward link (msDS-HostServiceAccount) and the backlink (msDS-HostServiceAccountBL).

So the attribute is obviously defined on the MSA object, but we saw earlier that the MSA object doesn’t contain any additional attributes over the computer object. So that means that these attributes were injected as optional attributes into pre-existing object classes. Namely, the Computer object class and the Top object class.

Step 4: Configure the service that will be using the MSA

The last step to using the MSA is to configure the service to use the account. You can do this through a couple of different ways - but the easiest is just to use the Services snap-in. When you add the account to the service, ensure that the account name has the $ at the end and leave the password blank.

One thing that you may notice is that if you click the Browse button in the service configuration dialog, the Service Accounts option shows up in the object picker.

If you decide to configure the service with the MSA through another means, such as SC.EXE, you need to ensure that you grant the MSA permissions to logon as a service. This is done through the SeServiceLogonRight, which can be applied in the local security policy or through a GPO on the server.

My Thoughts

Managed Service Accounts are an interesting feature and I definitely think there is a need for them. However, much of what I have been seeing about MSAs is focused on how much money they will save you. Whenever something is automated, there is some cost savings (unless the management of the automation process itself is a bigger chore than manually administering the thing that you automated). But I think there is one shortcoming with the way MSAs have been implemented that limits its ability to help you saving money.

This shortcoming is that the account can only be used on one computer. How does this limit cost-savings? First ask yourself how service accounts are costing you bucks. Some might say that your admins waste time updating service account passwords. I think that argument is a red herring. If admins have to update service account passwords across multiple computers every couple of months that may cost you a few bucks. So you can spend some more money and buy some 3rd party software to take care of it for you, or you can take the “cost avoidance” approach. You know what I mean - use the “Password never expires” check box for your service accounts. A lot of people take the route of setting an obscenely large password length policy for your service accounts and not think about changing them. Granted, this offers a false sense of security in many ways, but hey - a longer complex password is harder to guess and takes longer to brute force.

However, if you are using shared service accounts and if you do change the password regularly, I do think there is some cost savings. But it’s not exactly in admin time - rather it’s in the server outages incurred by mistyped passwords or servers that the admin forgot to update the password on. The real damage happens when something causes those services to restart - this could be days or weeks from when you changed the service account password, so you may not immediately realize that the incorrect password is preventing the server from functioning. So I think you can get some cost savings by automating shared service accounts. However, MSAs can’t be shared between servers - therefore, no cost savings in this scenario.

So what’s the benefit, then? I think the benefit lies more with security than with cost savings. There are two primary reasons that I believe this. First, if you have a service running on one server, you can implement an MSA and have the password changed regularly. Changing passwords on a regular basis is one way to increase security. But the second and most impactful reason why MSAs boost security is that admins will no longer be able to logon interactively with service accounts. Sure, you can prevent this with GPOs now, but that process can be circumvented. On the other hand, with MSAs, it’s basically a computer account and the admin doesn’t know the password. I think there is a great benefit with that.

To sum it all up - Managed Service Accounts are good and I am definitely a fan. I do think however, that there could be some improvements that would make them more effective - namely, allowing MSAs to be shared across multiple servers.