Service Accounts Step-by-Step Guide
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.
Application programming interfaces (APIs) for managed service 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:
- Run adprep /forestprep at the forest level.
Note
For more information, see Adprep.
Run adprep /domainprep in every domain where you want to create and use managed service accounts.
Deploy a domain controller running one of the following operating systems in the domain:
Windows Server 2008 R2
Windows Server 2008 with the Active Directory Management Gateway Service
Windows Server 2003 with the Active Directory Management Gateway Service
Note
The Active Directory Management Gateway Service allows administrators with domain controllers running Windows Server 2003 or Windows Server 2008 to use Windows PowerShell cmdlets to manage managed service accounts. For more information about the Active Directory Management Gateway Service, see Active Directory Management Gateway Service (Active Directory Web Service for Windows Server 2003 and Windows Server 2008) in the Microsoft Download Center (https://go.microsoft.com/fwlink/?LinkId=164543) and What's New in AD DS: Active Directory Web Services.
For more information about managing SPNs, see Service Principal Names.
The tools in the following table are needed to configure and administer managed service accounts.
| Tool | Where available |
|---|---|
Windows PowerShell command-line interface |
Windows Server 2008 R2 and Windows 7 |
Managed service account cmdlets |
Windows Server 2008 R2 and Windows 7 |
Dsacls.exe |
Windows Server 2008 R2 and Windows 7 |
Installutil.exe |
Windows Server 2008 R2 and Windows 7 |
Sc.exe command-line tool and the Service Control Manager UI |
Windows Server 2008 R2 and Windows 7 |
Services snap-in console |
Windows Server 2008 R2 and Windows 7 |
SetSPN.exe |
Download from https://go.microsoft.com/fwlink/?LinkID=44321 |
NTRights.exe |
Download from https://go.microsoft.com/fwlink/?LinkId=130308 |
Important
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.
Click Next, and then click Install.
Expand Remote Server Administration Tools and AD DS and AD LDS Tools, and then select Active Directory PowerShell Snap-in.
Click Next, and then click Install.
When the installation is complete, close the Add Features Wizard.
To install the .NET Framework and the Active Directory module for Windows PowerShell on a computer running Windows 7
Open a Web browser, and download the Remote Server Administration Tools from https://go.microsoft.com/fwlink/?LinkId=153874 to a location on your hard disk.
Double-click the file that you downloaded, and follow the instructions to install the Remote Server Administration Tools.
Click Start, and then click Control Panel.
Click Programs, click Programs and Features, and then in the left pane, click Turn Windows features on or off.
Confirm that Microsoft .NET Framework 3.5.1 is selected. If it is not, select it.
Expand Remote Server Administration Tools and AD DS and AD LDS Tools, and then select Active Directory PowerShell Snap-in.
Click OK.
Note
If you had to enable the .NET Framework, you will be asked to restart your computer.
For more information, see Windows PowerShell Cmdlet Help.
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
Click Start, click All Programs, click Windows PowerShell 2.0, and then click the Windows PowerShell icon.
Run the following command: Import-Module ActiveDirectory.
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.
Click Start, click All Programs, click Windows PowerShell 2.0, and then click the Windows PowerShell icon.
Run the following command: New-ADServiceAccount [-SAMAccountName <String>] [-Path <String>].
Associate the new MSA to the computer account by running the following command: Add-ADComputerServiceAccount [-Identity] <ADComputer> <ADServiceAccount[]>
See Add-ADComputerServiceAccount for the complete syntax.
Note
Optional parameters are indicated with square brackets [], and placeholder values are indicated with angle brackets <>.
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:
[-OtherAttributes <Hashtable>]
[-Instance <ADService>]
[-Server <String>] [-Credential <PSCredential>]
[-PassThru]
[-Name <String>] [-Description <String>] [-DisplayName <String>][-Enabled <Nullable`1>]
[-ServicePrincipalNames <String[]>]
[-AccountExpirationDate <Nullable`1>] [-AccountNotDelegated <Nullable`1>] [-AccountPassword <SecureString>]
[-AllowReversiblePasswordEncryption <Nullable`1>] [-CannotChangePassword <Nullable`1>] [-Certificates <String[]>]
[-ChangePasswordAtLogon <Nullable`1>] [-HomePage <String>] [-PasswordNeverExpires <Nullable`1>]
[-PasswordNotRequired <Nullable`1>] [-PermittedLogonTime <String>] [-PrimaryGroup <String>]
After one or more managed service accounts have been created, it may be necessary to obtain information about these accounts.
To get managed service account information in AD DS
Click Start, click All Programs, click Windows PowerShell 2.0, and then click the Windows PowerShell icon.
Run the following command: Get-ADServiceAccount [-Identity] <ADServiceAccount> [-Server <String>] [-Credential <PSCredential>] [-LDAPFilter <String>] [-Filter <String>] [-WhatIf] [Common PowerShell Parameters].
If the service account already exists in AD DS, you can use the following cmdlet to modify the service account as a managed service account.
To set properties on an existing managed service account
Click Start, click All Programs, click Windows PowerShell 2.0, and then click the Windows PowerShell icon.
Run the following command: Set-ADServiceAccount [-Identity] <ADServiceAccount>.
If a managed service account will no longer be used, you may want to remove the account from AD DS.
To remove a managed service account from AD DS
Click Start, click All Programs, click Windows PowerShell 2.0, and then click the Windows PowerShell icon.
Run the following command: Remove-ADServiceAccount [-Identity] <ADServiceAccount> [-Partition <String>] [-Confirm] [-WhatIf] [-PassThru] [-Server <String>] [-Credential <PSCredential>] [Common PowerShell Parameters].
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.
To install a managed service account on a local computer
Click Start, click All Programs, click Windows PowerShell 2.0, and then click the Windows PowerShell icon.
Run the following command: Install-ADServiceAccount [-Identity] <ADServiceAccount> [-Confirm] [-WhatIf] [-Credential <PSCredential>].
Warning
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.
To uninstall a managed service account from a local computer
Click Start, click All Programs, click Windows PowerShell 2.0, and then click the Windows PowerShell icon.
Run the following command: Uninstall-ADServiceAccount [-Identity] <ADServiceAccount> [-Confirm] [-WhatIf] [-Credential <PSCredential>].
Although managed service account passwords are reset on a regular basis based on the password reset requirements of the domain, a local administrator can still reset the password manually, if needed.
Configure a service account for Internet Information Services
Organizations that want to enhance the isolation of IIS applications can configure IIS application pools to run managed service accounts.
To use the Internet Information Services (IIS) Manager snap-in to configure a service to use a managed service account
Click Start, point to Administrative Tools, and then click Internet Information Services (IIS) Manager.
Double-click <Computer name>, double-click Application Pools, right-click <Pool Name>, and click Advanced Settings.
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.
To delegate management of a service account in AD DS
Open a command prompt window.
Run the following Dsacls script (replacing corpnet and contoso with your own network names): dsacls "CN=svcacc1,CN=Managed Service Accounts,DC=<corpnet>,DC=<contoso>,DC=<com>" /G "<Corpnet>\ServiceAdmin:SDRCLCRPLOCA" "<Corpnet>\ServiceAdmin:WP;Logon Information" "<Corpnet>\ServiceAdmin:WP;Description" "<Corpnet>\ServiceAdmin:WP;DisplayName" "<Corpnet>\ServiceAdmin:WP;Account Restrictions" "<Corpnet>\ServiceAdmin:WS;Validated write to DNS host name" "<Corpnet>\ServiceAdmin:WS;Validated write to service principal name".
Note
For more information, see Dsacls.
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.
For more information about creating and managing OUs, see Managing Organizational Units.
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.
For more information, see Delegate Control of an Organizational Unit.
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.
The service administrator configures the access control lists on the service resources for the service management account. For more information, see Checklist: Setting Access Controls on Objects.
Migrating from one managed service account to another managed service account
This scenario is similar to the previous scenario but involves two managed service accounts rather than a managed service account and a user account.
Resetting a password for a managed service account
Even with automatic password management, at times it may be necessary to reset the password for a managed service account manually.
To reset the password for a managed service account
Click Start, click All Programs, click Windows PowerShell 2.0, and then click the Windows PowerShell icon.
Run the following command: Reset-ADServiceAccountPassword [-Identity] <ADServiceAccount> [-Credential <PSCredential>] [-Server <String>].
Important
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.
To configure an IIS application pool to use a virtual account
Click Start, point to Administrative Tools, and then click Internet Information Services (IIS) Manager.
Double-click <Computer name>, double-click Application Pools, right-click <Pool Name>, and click Advanced Settings.
In the Identity box, click ApplicationPoolIdentity.
Note
In Windows Server 2008 R2 and Windows 7, IIS application pools run under ApplicationPoolIdentity by default.
- Under Application Pool Tasks, click Stop, and then click Start.
APIs for managed service accounts
The following are the publicly available APIs for managed service accounts and their behavior. You must be a member of the local Administrators group to use these APIs.
NetAddServiceAccount
The NetAddServiceAccount API is used to create a managed service account.
Syntax
NTSTATUS WINAPI NetAddServiceAccount(
__in_opt LPWSTR ServerName,
__in LPWSTR AccountName,
__in LPWSTR Reserved,
__in DWORD Flags
);
Parameters
The following parameters are available.
| Parameter | Description |
|---|---|
ServerName [in, optional] |
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.
Syntax
NTSTATUS WINAPI NetRemoveServiceAccount(
__in_opt LPWSTR ServerName,
__in LPWSTR AccountName,
__in DWORD Flags
);
Parameters
The following parameters are available.
| Parameter | Description |
|---|---|
ServerName [in, optional] |
This API is currently local only. The parameter should always be NULL. |
AccountName [in] |
The name of the account to be deleted. |
Flags [in] |
SERVICE_ACCOUNT_FLAG_UNLINK_FROM_HOST_ONLY 0x00000001L The service account object is removed from the local computer, and the secret stored in the LSA is deleted. The service account object is not deleted from the Active Directory database. |
Return value
If the function succeeds, it returns STATUS_SUCCESS.
If the function fails, it returns an error code.
NetIsServiceAccount
The function tests whether the specified service account exists in the Netlogon store on the specified server.
Syntax
NTSTATUS WINAPI NetIsServiceAccount(
__in_opt LPWSTR ServerName,
__in LPWSTR AccountName,
__out BOOL *IsService
);
Parameters
The following parameters are available.
| Parameter | Description |
|---|---|
ServerName [in, optional] |
This API is currently local only. The parameter should always be NULL. |
AccountName [in] |
The name of the account to be tested. |
IsService [out] |
TRUE if the specified service account exists on the specified server; otherwise, FALSE. |
Return value
If the function succeeds, it returns STATUS_SUCCESS.
If the function fails, it returns an error code.
NetEnumerateServiceAccounts
This function enumerates the server accounts on the specified server.
Syntax
NTSTATUS WINAPI NetEnumerateServiceAccounts(
__in_opt LPWSTR ServerName,
__in DWORD Flags,
__out DWORD *AccountsCount,
__out PZPWSTR *Accounts
);
Parameters
The following parameters are available.
| Parameter | Description |
|---|---|
ServerName [in, optional] |
This API is currently local only. The parameter should always be NULL. |
Flags [in] |
Reserved. Do not use. This value must be 0. |
AccountsCount [out] |
The number of elements in the Accounts array. |
Accounts [out] |
A pointer to an array of the names of the service accounts on the specified server. The caller must use NetAPIBufferFree to free the buffer. |
Return value
If the function succeeds, it returns STATUS_SUCCESS.
If the function fails, it returns an error code.
Troubleshooting managed service accounts
If the service does not start with a managed service account, use the following steps to troubleshoot the problem.
To correct problems that prevent a service associated with a managed service account from starting
Run the following Windows PowerShell command to confirm that the managed service account exists and is enabled in AD DS: Get-ADServiceAccount [-Identity] <ADServiceAccount> [-Server <String>] [-Credential <PSCredential>] [-LDAPFilter <String>] [-Filter <String> ] [-WhatIf] [Common PowerShell Parameters].
Confirm that the service account name ends with a dollar sign ($).
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>.