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.