In this article

Service Accounts Step-by-Step Guide

07/02/2012

21 minutes to read

In this article

Applies To: Windows 7, Windows Server 2008 R2

Managed service accounts and virtual accounts are two new types of accounts introduced in Windows Server® 2008 R2 and Windows® 7 to enhance the service isolation and manageability of network applications such as Microsoft Exchange and Internet Information Services (IIS).

This step-by-step guide provides detailed information about how to set up and administer managed service accounts and virtual accounts on client computers running Windows Server 2008 R2 and Windows 7. This document includes:

Managed service account and virtual account concepts.

Client and domain controller support requirements for managed service accounts and virtual accounts.

Tools needed to configure and administer managed service accounts and virtual accounts.

Steps for configuring and administering managed service accounts and virtual accounts.

Using virtual accounts.

Troubleshooting problems with managed service accounts and virtual accounts.

Managed service account and virtual account concepts

One of the security challenges for crucial network applications such as Exchange and IIS is selecting the appropriate type of account for the application to use.

On a local computer, an administrator can configure the application to run as Local Service, Network Service, or Local System. These service accounts are simple to configure and use but are typically shared among multiple applications and services and cannot be managed on a domain level.

If you configure the application to use a domain account, you can isolate the privileges for the application, but you need to manually manage passwords or create a custom solution for managing these passwords. Many server applications use this strategy to enhance security, but this strategy requires additional administration and complexity.

In these deployments, service administrators spend a considerable amount of time on maintenance tasks such as managing service passwords and service principal names (SPNs), which are required for Kerberos authentication. In addition, these maintenance tasks can disrupt service.

Two new types of accounts available in Windows Server 2008 R2 and Windows 7—the managed service account and the virtual account—are designed to provide crucial applications such as Exchange or IIS with the isolation of their own accounts, while eliminating the need for an administrator to manually administer the SPN and credentials for these accounts.

Managed service accounts in Windows Server 2008 R2 and Windows 7 are managed domain accounts that provide the following features to simplify service administration:

Automatic password management.

Simplified SPN management, including delegation of management to other administrators. Additional automatic SPN management is available at the Windows Server 2008 R2 domain functional level. For more information, see "Requirements for using managed service accounts and virtual accounts" in this document.

Virtual accounts in Windows Server 2008 R2 and Windows 7 are "managed local accounts" that provide the following features to simplify service administration:

No password management is required.

The ability to access the network with a computer identity in a domain environment.

Requirements for using managed service accounts and virtual accounts

To use managed service accounts and virtual accounts, the client computer on which the application or service is installed must be running Windows Server 2008 R2 or Windows 7. In addition, the hot fix as described in KB 2494158: “Managed service account authentication fails after its password is changed in Windows 7 or in Windows Server 2008 R2 must be applied to the computer where the managed service account exists.

In Windows Server 2008 R2 and Windows 7, one managed service account can be used for services on a single computer. Managed service accounts cannot be shared between multiple computers and cannot be used in server clusters where a service is replicated on multiple cluster nodes.

Domains at the Windows Server 2008 R2 functional level provide native support for both automatic password management and SPN management. If the domain is running at the Windows Server 2003 functional level or the Windows Server 2008 functional level, additional configuration steps will be needed to support managed service accounts. This means that:

If the domain is at the Windows Server 2008 R2 functional level, the SPN management of managed service accounts is simplified. Specifically, the DNS part of the managed service account SPN is changed from oldname.domain-dns-suffix.com to newname.domain-dns-suffix.com for all managed service accounts installed on the computer in the following four situations:

The samaccountname property of the computer is changed.

The DNS name property of the computer is changed.

A samaccountname property is added for the computer.

A dns-host-name property is added for the computer.

If the domain controller is on a computer running Windows Server 2008 or Windows Server 2003 but the Active Directory schema has been updated to Windows Server 2008 R2 in order to support this feature, managed service accounts can be used and service account passwords will be managed automatically. However, the domain administrator using these server operating systems will still need to manually configure SPN data for managed service accounts.

To use managed service accounts in Windows Server 2008, Windows Server 2003, or mixed-mode domain environments, you must complete the following tasks:

Although some versions of the Active Directory Users and Computers snap-in allow an administrator to create a new msDS-ManagedServiceAccount object, managed service accounts created by using this snap-in will be missing essential attributes. Therefore, you should not use this option to create managed service accounts. Only Windows PowerShell should be used to create managed service accounts.

Before the managed service account cmdlets can be used, the .NET Framework 3.5x and the Active Directory module for Windows PowerShell need to be installed on the client computer or server.

To install the .NET Framework and the Active Directory module for Windows PowerShell on a computer running Windows Server 2008 R2

Click Start, point to Administrative Tools, and then click Server Manager.

Under Features, click Add Features.

On the Select Features page of the Add Features Wizard, expand NET Framework 3.5.1 Features, and then select .NET Framework 3.5.1.

Configuring and administering managed service accounts overview

The following sections provide procedures for configuring and using managed service accounts. These procedures include:

Create and use managed service accounts with the default Managed Service Account container.

Move service accounts to another computer.

Migrate from a user account to a managed service account.

Reset a password for a managed service account.

These scenarios assume two administrative roles:

The domain administrator can create, administer, and delegate management for managed service accounts in Active Directory Domain Services (AD DS). In addition, any user with Create/Delete msDS-ManagedServiceAccount permissions can also administer these managed service accounts.

The service administrator installs and manages these accounts on a computer running Windows Server 2008 R2 or Windows 7, where these computers are used for running an application or service. A user in this role needs to be a member of the local Administrators group on the computer.

Windows Server 2008 R2 includes all of the Windows PowerShell cmdlets needed to provision and administer managed service accounts.

Windows PowerShell cmdlets can be used to create, read, update, and delete managed service accounts on a domain controller. There is no user interface for creating and managing these accounts in Windows Server 2008 R2 and Windows 7.

Service administrators can use Windows PowerShell cmdlets to install and uninstall these accounts and to reset passwords for these accounts on a computer running Windows Server 2008 R2 or Windows 7. After a managed service account has been installed, service administrators can configure a service or application to use this account; they no longer have to specify or change passwords for these services because these account passwords will be automatically maintained by the computer. The service administrator will be able to configure the SPN on the service account without requiring domain administrator privileges.

Creating and using managed service accounts

The following procedures can be used to create and administer managed service accounts.

To import the Active Directory module for Windows PowerShell

To create a new managed service account

On the domain controller, click Start, and then click Run. In the Open box, type dsa.msc, and then click OK to open the Active Directory Users and Computers snap-in. Confirm that the Managed Service Account container exists.

You can use the OtherAttributes parameter to set additional properties on the new object. By using the Instance parameter, you can also create new objects based on a defined template. The following additional parameters can be used with this cmdlet:

The following cmdlets must be run by a local administrator or service administrator on the computer running Windows Server 2008 R2 or Windows 7 hosting the application. The first cmdlet installs the managed service account.

The account name attribute must match the account name in the Security Account Manager (SAM) database. If the account name attribute does not match the corresponding SAM account name, the installation will fail with error 0xC0000225.

The following steps describe how to configure the service to run with the managed service account. You can complete this task by using the Services snap-in console (Services.msc) or by using the CreateService API.

To use the Services snap-in console to configure a service to use a managed service account

Click Start, point to Administrative Tools, and then click Services.

When prompted for permissions, click Continue.

Right-click the name of the service that you want to use, and click Properties.

Click the Log On tab, click This account, and type the name of the managed service account in the format domainname\accountname or click Browse to search for the account. Confirm that the password field is blank, and then click OK.

Select the name of the service, and click Start the service or Restart the service. Confirm that the newly configured account name appears in the Log On As column for the service.

Important

There must be a dollar sign ($) at the end of the account name in the Services snap-in console. When you use the Services snap-in console, the SeServiceLogonRight logon right is automatically assigned to the account. If you use the Sc.exe tool or APIs to configure the account, the account has to be explicitly granted this right by using tools such as the Security Policy snap-in, Secedit.exe, or NTRights.exe.

If a managed service account is no longer being used on this computer, a local administrator may want to uninstall the account from the local computer.

In the Identity box, click …, click Custom Account, and then click Set.

Type the name of the managed service account in the format domainname\accountname.

Important

Leave the password blank, and ensure that the account name has a dollar sign ($) at the end.

Under Application Pool Tasks, click Stop, and then click Start.

Note

If the application pool is configured to be used as a MSA, the feature that tests the connection before saving changes - Test Connection – is unsupported due to the design of the MSA.

Delegating managed service account management

A domain administrator may want to delegate management of service accounts to a service administrator. There is no Windows PowerShell cmdlet for delegation management in AD DS. Therefore, you can use a tool such as Dsacls.exe to delegate management of service accounts to a service administrator.

A delegated service administrator must have the following permissions:

Delete

Read

List contents

Read property

List object

Control access

Write_property for account restrictions

Write_property for logon information

Write_property for description

Write_property for displayName

Write_self for validated write to DNS host name

Write_self for validated write service principal name

The following procedure includes an example Dsacls script that illustrates how you can configure delegated permissions for managed service accounts.

Creating and using managed service accounts in a separate OU

The procedures for creating and using managed service accounts in a separate organization unit (OU) are similar to the first scenario. The difference is that many organizations will want to create a new OU to allow managed service accounts to be managed separately from other user, computer, and special accounts for the domain.

Creating and using managed service accounts in a separate OU and delegating administration of the OU to a service administrator

The procedures for creating and using managed service accounts in a separate OU are similar to the first and second scenarios. The difference is that you may want to delegate management of the new OU before proceeding with the other tasks.

Moving a managed service account to another computer

Applications such as IIS and Exchange are critical to their organizations and users. As a result, many organizations place a high priority on maintaining these services on the most current and reliable hardware available. This means that administrators have to plan carefully for moving these services from one computer to another.

The following steps will help you move critical services that rely on managed service accounts from one computer to a second computer. These steps can all be performed by the service administrator on the local computer.

To move a managed service account from one computer to another computer

On the first computer, click Start, click All Programs, click Windows PowerShell 2.0, and then click the Windows PowerShell icon.

Run the following Windows PowerShell cmdlet: Uninstall-ADServiceAccount.

On the second computer, click Start, click All Programs, click Windows PowerShell 2.0, and then click the Windows PowerShell icon.

Run the following Windows PowerShell cmdlet: Install-ADServiceAccount.

Use the Services snap-in console to configure the service to run with the managed service account.

Migrating a service from a user account to a managed service account

Some organizations will configure an application to use a special user account so they can set restricted access permissions on one or more resource files, such as a database. If you want to move a critical service from this type of user account to a managed service account, you need to update these access control settings as well.

To migrate a service from a user account to a managed service account

If necessary, a domain administrator creates a new managed service account in AD DS by using the Windows PowerShell cmdlet New-ADServiceAccount.

The service administrator installs the managed service account on the local computer by using the Windows PowerShell cmdlet Install-ADServiceAccount.

The service administrator configures the service to run with the managed service account.

You can modify the default password change interval for managed service accounts by using the domain policy Domain Member: Maximum machine account password age under Local Policy\Security Options. However, none of the Group Policy settings under Account Policies\Password Policy can be used to modify managed service account password reset intervals. In addition, although the command NLTEST /SC_CHANGE_PWD:<domain> can be used to reset computer account passwords, it cannot be used to reset managed service account passwords. For more on managing passwords, see the AD DS Fine-Grained Password and Account Lockout Policy Step-by-Step Guide.

Using virtual accounts

Virtual accounts require very little management. They cannot be created or deleted, nor do they require any password management.

You must be a member of the Administrators group on the local computer to perform the following procedures.

To configure a service to use a virtual account

Click Start, point to Administrative Tools, and then click Services.

In the details pane, right-click the service that you want to configure, and then click Properties.

Click the Log On tab, click This account, and then type **NT SERVICE\**ServiceName. When you are finished, click OK.

Restart the service for the change to take effect.

Organizations that want to enhance the service isolation of IIS can configure IIS application pools to run with virtual accounts.

You must be a member of the Administrators group on the local computer to perform the following procedure or procedures.

This API is currently local only. The parameter should always be NULL.

AccountName [in]

The name of the account to be created.

Reserved [in]

Reserved. Do not use.

Flags [in]

SERVICE_ACCOUNT_FLAG_LINK_TO_HOST_ONLY 0x00000001L

No service account is created. If a service account with the specified name exists, it is linked to the local computer.

NetRemoveServiceAccount

This function deletes the specified service account from the Active Directory database. The secret stored in the Local Security Authority (LSA) is deleted, and the state is stored in the Netlogon registry store.

Run the following Windows PowerShell command to confirm that the account is installed on the computer: Install-ADServiceAccount [-Identity] <ADServiceAccount> [-Confirm] [-WhatIf] [-Credential <PSCredential>].

Use NTRights.exe, Secedit.exe, or the Local Security Policy snap-in (secpol.msc) to confirm that the account has the SeServiceLogonRight logon right. The following command shows how to do this with NTRights.exe: NTRights +r SeServiceLogonRight –u <account name>.