Use MSAs to Ease the Pain of Administering Service Accounts

As we look at Active Directory (AD) changes in Windows Server 2008 R2, the feature everyone is fired up about is the AD Recycle Bin, a very welcome capability to cleanly restore objects that have been deleted—without the need for authoritative restores or painful tombstone reanimations.

But after organizations actually start using Server 2008 R2, another feature they find more useful than anything else is the managed service account (MSA).

It might not be glamorous, but the MSA feature might very well change the way you administer your service accounts and cure a lot of pains most organizations face today around service accounts.

Why MSAs?
Many services require integration with other network resources and directory services beyond just the local computer, which typically means a service runs as either the built-in Network Service Account, the built-in Local System Account, or a specified domain user account.

While it might seem attractive to use the Network Service Account or Local System Account, both of which communicate with other network resources using the server’s computer account, numerous issues arise when using these built-in accounts. Often services require specific rights and privileges.

Using the built-in accounts, especially the Local System Account, means the service has rights and privileges far in excess of what is actually required on the local machine and possibly the network. This gives the service using the account privileges beyond what it needs, which increases the chances of security problems.

Our goal should always be to give services only the permissions they need to function, nothing more. The problem of excessive privileges with the Local System Account is why the Network Service Account was introduced with Windows Server 2003, as a way to have a built-in account that didn’t have full system privileges on the local machine, while still providing network access as the computer account.

Beyond the problem associated with excessive privileges, when many services use the same account it makes it very hard to audit any actions performed on the server. This brings us to using a specific domain user account for services. Most applications that require services advise you to create a domain user account for the service and grant a specific set of permissions.

Administrators generally try to minimize the number of accounts, and therefore often one domain account is used for multiple services. However, aside from the fact that it’s bad practice from an auditing standpoint to share accounts between different services, the shared account would need the sum of all required permissions for all the services sharing the account, so each individual service would effectively have more permissions than it actually needs.

If you do decide to use a domain user account for each service, the biggest challenge arises: managing the passwords for these domain user accounts. The solution typically falls into one of two camps.

Either you set the password on the domain user account to never expire, which is a large security problem that will cause companies to fail most audits, or the passwords expire per normal domain security policy—which in most companies causes outages to the service as the passwords fail to get updated, causing the service to fail until an administrator manually intervenes and resets the password.

No More Password Hell
MSAs address this password management problem by providing automated password re-generation through the netlogon process, the same way the computer account has its password automatically reset. By default, every 30 days the netlogon process generates a new 240 random-character password and synchronizes it with the domain.

Domain security policies and fine-grained password policies are ignored by computer objects and MSAs, so the password is always 240 characters as opposed to following the guidelines specified in the aforementioned policies, such as eight-character passwords.

To use MSAs, two requirements must be met:
1. The AD forest must have been prepared with the Server 2008 R2 forest prep, adding a new object class, msDS-ManagedServiceAccount, which stores information for the MSA in AD.
2. The machine using the MSA must be running Server 2008 R2 or Windows 7. There are currently no plans to back-port the MSA functionality into earlier versions of Windows.

The good news is you don't need to be running in Server 2008 R2 or even Server 2008 domain mode. However, if you’re running all Server 2008 R2 domain controllers (DCs), you get an extra piece of functionality with MSAs that I’ll cover later.

A new container is created at the root of the domain, Managed Service Accounts, which is the default location of all MSAs, but you can relocate MSAs if you want. To view details about MSAs created in this container, enable the Advanced Features view within Active Directory Users and Computers (ADUC).

However, you can’t manage MSAs by using the GUI—as with lots of the goodies in Server 2008 R2 AD, you need to use PowerShell to manage them. This brings us to actually using an MSA.

To use an MSA for a service, you need to take four steps:
1. Create the MSA in AD using the New-ADServiceAccount PowerShell cmdlet.
2. Associate the MSA with a specific computer account in AD by using the Add-ADComputerServiceAccount PowerShell cmdlet.
3. Install the MSA on the computer by using the Install-ADServiceAccount PowerShell cmdlet.
4. Configure services on the computer to use the MSA, which can be done through the Services MMC snap-in (services.msc) or any other service management interface such as WMI, SC, or PowerShell.

Note that part of this process is to associate the MSA with a specific computer account, which is a restriction of the MSA—the MSA can only be used on a single computer.

However, the MSA can be used by multiple services on that computer (though you still shouldn't share accounts because of auditing and excessive permissions reasons), and one computer can have multiple MSAs. Because of the inability to span multiple machines, you can't use the MSA for any purpose that spans multiple machines; for example you can't use an MSA on cluster nodes nor in any kind of load-balancing that uses Kerberos authentication.

Creating and Using MSAs
Let's dig a little deeper and actually create an MSA, install it on a server, then configure a service to use the MSA. In all cases where you run any of the PowerShell cmdlets, you need to have installed the Active Directory Module for Windows PowerShell, which is part of the Remote Server Administration Tools (RSAT) feature and can be found in the Active Directory Domain Services (AD DS) and Active Directory Light Directory Services (AD LDS) Tools section, shown in Figure 1.

These cmdlets need to be on both the computer you're managing the MSA from and the servers that are using the MSA. Next, open a PowerShell window to import the module, called ActiveDirectory, which will enable access to the AD cmdlets. You need to import this anytime you start a new PowerShell instance and want to use the AD cmdlets. To import the module, type

Import-Module ActiveDirectory

We can now create a new MSA. It's a good idea to have a naming standard for your MSAs, and as they are tied to a specific computer, using the target computer name as part of the name might help. First, I create an MSA named msa_ts01_purgesvc, which I'm going to use on server savdalts01:

New-ADServiceAccount -name msa_ts  01_purgesvc -enabled 
  $true

Next, I link the MSA to server savdalts01:

Add-ADComputerServiceAccount -identity  savdalts01 
  -serviceaccount msa_ts01  _purgesvc

Then I log on to the server that will use the MSA, in my case savdalts01. After I log on, I make sure I have installed the AD module for PowerShell. Then I start a PowerShell window and import the AD module. I then install the MSA:

Install-ADServiceAccount -identity  msa_ts01_purgesvc

At this point the account msa_ts01_purgesvc$ (e.g., savilltechmsa_ts01_purgesvc) is available for use by any service on the server. Note the dollar sign at the end of the name and the AD domain name at the start.

I use the services MMC snap-in (services.msc) and enter the name of the MSA and make sure both password fields are blank in the Log On tab, which Figure 2 shows, then start the service. The MSA is now being used, and you never have to worry about resetting a password on it again.

We can grant permissions to MSAs and add MSAs to groups just like any other account. We can also use Active Directory Users and Computers, PowerShell cmdlets such as Add-ADGroupMember, or any of the normal group manipulation utilities. If you ever need to force a reset of the MSA password, use the command

Reset-ADServiceAccountPassword -identity  [MSA name]

although there shouldn’t be many instances where this would be necessary. If you decide you no longer want to use a specific MSA, you need to update the service(s) using the MSA to log on as an alternate account, then run the command

Remove-ADServiceAccount -identity  [MSA name]

to remove the MSA from the server.

Service Principal Name Delegation
MSAs also address another pain of service accounts, Kerberos Service Principal Name (SPN) management. SPNs are registered by services in AD.

Clients search by them to find the user or computer account used by the service to facilitate mutual authentication. The SPN is part of either a computer or user object. Normally SPNs can only be updated by domain administrators. However, sometimes the service can update the SPN if the service is running as the Local System account.

MSAs let you delegate SPN management to service administrators after you enable the MSA for delegation. Use the command

Set-ADServiceAccount –TrustedForDelegation  $true 
  -identity [MSA name]

which allows delegation and lets the target of delegation manipulate the SPNs for the object. SPN management for MSAs is simpler; however, the domain must be at Server 2008 R2 domain mode, which means all DCs need to be running Server 2008 R2.

Assuming you’re running in Server 2008 R2 mode domain, you now have automatic SPN updating in the following scenarios, (which means no manual updates are required):

• Renaming the computer account
• Changing dnshostname attribute of the computer account
• Changing additionaldnshostname attribute of the computer account
• Changing additionalsamaccountname attribute of the computer account

Virtual Accounts
If access to a specific domain-level account isn’t required and the computer’s account is what you need, a spin-off of the MSA feature is available. A virtual account acts like a unique instance of the Network Service account on the local computer and lets you avoid using the generic Network Service account and the associated audit problems around sharing accounts.

Because a virtual account acts like a unique clone of the built-in Network Service account, when the service communicates with other resources on the network it does so as the computer object account. You must be a local administrator to configure virtual accounts.

Like MSAs, virtual accounts are available only on Server 2008 R2 and Windows 7 machines; however, there are no domain or schema requirements and you don’t create or manage virtual accounts. T

o use a virtual account, type "NT SERVICE\[service name]" in the Log On tab of the service and ensure both password fields are blank. That's it. The service name you type as the account name must match exactly the service name of the service (and not the long display name).

In Figure 3, I have configured the Visual Studio (VS) remote debugger to use a virtual account by using account NT Servicemsvsmon90 with blank passwords. When I hit Apply, the password fields are automatically populated.

You can get the short name of a service through numerous means: browse HKEY_LOCAL_MACHINESYSTEMCurrentControlSetservices; run the SC QUERY command; or the simplest way, just look at the Service name value that’s shown in the General tab of a services properties.

Support MSAS 
Some applications ask during installation time for the account and password that will be used. In these instances, after the installation, you can modify the service and copy any rights and privileges to the MSA. However, some applications might not allow this, preventing you from using an MSA with that application.

Email the application vendor and demand it support MSAs in the next version or via a patch. Many applications and features do support MSAs, including IIS 7.5 application pool identities. I hope in Windows 8 we’ll see MSAs support multi-computer scenarios to support cluster and NLB configurations. Regardless, the MSA is still an awesome feature that’s going to ease a lot of pain related to service accounts.