Service Accounts

Applies to

• Windows 10
• Windows Server 2016

This topic for the IT professional explains group and standalone managed service accounts, and the computer-specific virtual computer account, and it points to resources about these service accounts.

Overview

A service account is a user account that is created explicitly to provide a security context for services running on Windows Server operating systems. The security context determines the service’s ability to access local and network resources. The Windows operating systems rely on services to run various features. These services can be configured through the applications, the Services snap-in, or Task Manager, or by using Windows PowerShell.

This topic contains information about the following types of service accounts:

Standalone managed service accounts

A managed service account is designed to isolate domain accounts in crucial applications, such as Internet Information Services (IIS), and eliminate the need for an administrator to manually administer the service principal name (SPN) and credentials for the accounts.

To use managed service accounts, the server on which the application or service is installed must be running at least Windows ServerВ 2008В R2. One managed service account can be used for services on a single computer. Managed service accounts cannot be shared between multiple computers, and they cannot be used in server clusters where a service is replicated on multiple cluster nodes. For this scenario, you must use a group managed service account. For more information, see Group Managed Service Accounts Overview.

In addition to the enhanced security that is provided by having individual accounts for critical services, there are four important administrative benefits associated with managed service accounts:

You can create a class of domain accounts that can be used to manage and maintain services on local computers.

Unlike domain accounts in which administrators must reset manually passwords, the network passwords for these accounts are automatically reset.

You do not have to complete complex SPN management tasks to use managed service accounts.

Administrative tasks for managed service accounts can be delegated to non-administrators.

Software requirements

Managed service accounts apply to the Windows operating systems that are designated in the Applies To list at the beginning of this topic.

Group managed service accounts

Group managed service accounts are an extension of the standalone managed service accounts, which were introduced in Windows ServerВ 2008В R2. These are managed domain accounts that provide automatic password management and simplified service principal name (SPN) management, including delegation of management to other administrators.

The group managed service account provides the same functionality as a standalone managed service account within the domain, but it extends that functionality over multiple servers. When connecting to a service that is hosted on a server farm, such as Network Load Balancing, the authentication protocols that support mutual authentication require all instances of the services to use the same principal. When group managed service accounts are used as service principals, the Windows Server operating system manages the password for the account instead of relying on the administrator to manage the password.

The Microsoft Key Distribution Service (kdssvc.dll) provides the mechanism to securely obtain the latest key or a specific key with a key identifier for an Active Directory account. This service was introduced in Windows Server 2012, and it does not run on previous versions of the Windows Server operating system. The Key Distribution Service shares a secret, which is used to create keys for the account. These keys are periodically changed. For a group managed service account, the domain controller computes the password on the key that is provided by the Key Distribution Services, in addition to other attributes of the group managed service account.

Practical applications

Group managed service accounts provide a single identity solution for services running on a server farm, or on systems that use Network Load Balancing. By providing a group managed service account solution, services can be configured for the group managed service account principal, and the password management is handled by the operating system.

By using a group managed service account, services or service administrators do not need to manage password synchronization between service instances. The group managed service account supports hosts that are kept offline for an extended time period and the management of member hosts for all instances of a service. This means that you can deploy a server farm that supports a single identity to which existing client computers can authenticate without knowing the instance of the service to which they are connecting.

Failover clusters do not support group managed service account s. However, services that run on top of the Cluster service can use a group managed service account or a standalone managed service account if they are a Windows service, an App pool, a scheduled task, or if they natively support group managed service account or standalone managed service accounts.

Software requirements

Group managed service accounts can only be configured and administered on computers running at least Windows Server 2012, but they can be deployed as a single service identity solution in domains that still have domain controllers running operating systems earlier than Windows Server 2012. There are no domain or forest functional level requirements.

A 64-bit architecture is required to run the Windows PowerShell commands that are used to administer group managed service accounts.

A managed service account is dependent on encryption types supported by Kerberos. When a client computer authenticates to a server by using Kerberos protocol, the domain controller creates a Kerberos service ticket that is protected with encryption that the domain controller and the server support. The domain controller uses the account’s msDS-SupportedEncryptionTypes attribute to determine what encryption the server supports, and if there is no attribute, it assumes that the client computer does not support stronger encryption types. The Advanced Encryption Standard (AES) should always be explicitly configured for managed service accounts. If computers that host the managed service account are configured to not support RC4, authentication will always fail.

NoteВ В Introduced in WindowsВ ServerВ 2008В R2, the Data Encryption Standard (DES) is disabled by default. For more information about supported encryption types, see Changes in Kerberos Authentication.

Group managed service accounts are not applicable in Windows operating systems prior to Windows Server 2012.

Virtual accounts

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

The virtual account is automatically managed.

The virtual account can access the network in a domain environment.

No password management is required. For example, if the default value is used for the service accounts during SQL Server setup on Windows ServerВ 2008В R2, a virtual account that uses the instance name as the service name is established in the format NT SERVICE\ .

Services that run as virtual accounts access network resources by using the credentials of the computer account in the format \ $.

For information about how to configure and use virtual service accounts, see Service Accounts Step-by-Step Guide.

Software requirements

Virtual accounts apply to the Windows operating systems that are designated in the Applies To list at the beginning of this topic.

See also

The following table provides links to additional resources that are related to standalone managed service accounts, group managed service accounts, and virtual accounts.

Getting Started with Group Managed Service Accounts

Applies To: Windows Server (Semi-Annual Channel), Windows Server 2016

This guide provides step-by-step instructions and background information for enabling and using group Managed Service Accounts in Windows Server 2012 .

In this document

This topic includes sample Windows PowerShell cmdlets that you can use to automate some of the procedures described. For more information, see Using Cmdlets.

Prerequisites

Introduction

When a client computer connects to a service which is hosted on a server farm using network load balancing (NLB) or some other method where all the servers appear to be the same service to the client, then authentication protocols supporting mutual authentication such as Kerberos cannot be used unless all the instances of the services use the same principal. This means that each service has to use the same passwords/keys to prove their identity.

Failover clusters do not support gMSAs. However, services that run on top of the Cluster service can use a gMSA or a sMSA if they are a Windows service, an App pool, a scheduled task, or natively support gMSA or sMSA.

Services have the following principals from which to choose, and each has certain limitations.

Principals	Scope	Services supported	Password management
Computer Account of Windows system	Domain	Limited to one domain joined server	Computer manages
Computer Account without Windows system	Domain	Any domain joined server	None
Virtual Account	Local	Limited to one server	Computer manages
Windows 7 standalone Managed Service Account	Domain	Limited to one domain joined server	Computer manages
User Account	Domain	Any domain joined server	None
Group Managed Service Account	Domain	Any Windows Server 2012 domain-joined server	The domain controller manages, and the host retrieves

A Windows computer account, or a Windows 7 standalone Managed Service Account (sMSA), or virtual accounts cannot be shared across multiple systems. If you configure one account for services on server farms to share, you would have to choose a user account or a computer account apart from a Windows system. Either way, these accounts do not have the capability of single-point-of-control password management. This creates problem where each organization needs to create an expensive solution to update keys for the service in Active Directory and then distribute the keys to all instances of those services.

With Windows Server 2012 , services or service administrators do not need to manage password synchronization between service instances when using group Managed Service Accounts (gMSA). You provision the gMSA in AD and then configure the service which supports Managed Service Accounts. You can provision a gMSA using the *-ADServiceAccount cmdlets which are part of the Active Directory module. Service identity configuration on the host is supported by:

Same APIs as sMSA, so products which support sMSA will support gMSA

Services which use Service Control Manager to configure logon identity

Services which use the IIS manager for application pools to configure identity

Tasks using Task Scheduler.

Requirements for group Managed Service Accounts

The following table lists the operating system requirements for Kerberos authentication to work with services using gMSA. The Active Directory requirements are listed after the table.

A 64-bit architecture is required to run the Windows PowerShell commands used to administer group Managed Service Accounts.

Operating system requirements

Element	Requirement	Operating system
Client Application host	RFC compliant Kerberos client	At least Windows XP
User account’s domain DCs	RFC compliant KDC	At least Windows Server 2003
Shared service member hosts	Windows Server 2012
Member host’s domain DCs	RFC compliant KDC	At least Windows Server 2003
gMSA account’s domain DCs	Windows Server 2012 DCs available for host to retrieve the password	Domain with Windows Server 2012 which can have some systems earlier than Windows Server 2012
Backend service host	RFC compliant Kerberos application server	At least Windows Server 2003
Backend service account’s domain DCs	RFC compliant KDC	At least Windows Server 2003
Windows PowerShell for Active Directory	Windows PowerShell for Active Directory installed locally on a computer supporting a 64-bit architecture or on your remote management computer (for example, using the Remote Server Administration Toolkit)	Windows Server 2012

Active Directory Domain Service requirements

The Active Directory schema in the gMSA domain’s forest needs to be updated to Windows Server 2012 to create a gMSA.

You can update the schema by installing a domain controller that runs Windows Server 2012 or by running the version of adprep.exe from a computer running Windows Server 2012 . The object-version attribute value for the object CN=Schema,CN=Configuration,DC=Contoso,DC=Com must be 52.

New gMSA account provisioned

If you are managing the service host permission to use gMSA by group, then new or existing security group

If managing service access control by group, then new or existing security group

If the first master root key for Active Directory is not deployed in the domain or has not been created, then create it. The result of its creation can be verified in the KdsSvc Operational log, Event ID 4004.

For instructions how to create the key, see Create the Key Distribution Services KDS Root Key. Microsoft Key Distribution Service (kdssvc.dll) the root key for AD.

Lifecycle

The lifecycle of a server farm using the gMSA feature typically involves the following tasks:

Deploying a new server farm

Adding member hosts to an existing server farm

Decommissioning member hosts from an existing server farm

Decommissioning an existing server farm

Removing a compromised member host from a server farm if required.

Deploying a new server farm

When deploying a new server farm, the service administrator will need to determine:

If the service supports using gMSAs

If the service requires inbound or outbound authenticated connections

The computer account names for the member hosts for the service using the gMSA

The NetBIOS name for the service

The DNS host name for the service

The Service Principal Names (SPNs) for the service

The password change interval (default is 30 days).

Step 1: Provisioning group Managed Service Accounts

You can create a gMSA only if the forest schema has been updated to Windows Server 2012 , the master root key for Active Directory has been deployed, and there is at least one Windows Server 2012 DC in the domain in which the gMSA will be created.

Membership in Domain Admins or the ability to create msDS-GroupManagedServiceAccount objects, is the minimum required to complete the following procedures.

A value for the -Name parameter is always required (whether you specify -Name or not), with -DNSHostName, -RestrictToSingleComputer, and -RestrictToOutboundAuthentication being secondary requirements for the three deployment scenarios.

To create a gMSA using the New-ADServiceAccount cmdlet

On the Windows Server 2012 domain controller, run Windows PowerShell from the Taskbar.

At the command prompt for the Windows PowerShell, type the following commands, and then press ENTER. (The Active Directory module will load automatically.)

Parameter	String	Example
Name	Name of the account	ITFarm1
DNSHostName	DNS host name of service	ITFarm1.contoso.com
KerberosEncryptionType	Any encryption types supported by the host servers	None, RC4, AES128, AES256
ManagedPasswordIntervalInDays	Password change interval in days (default is 30 days if not provided)	90
PrincipalsAllowedToRetrieveManagedPassword	The computer accounts of the member hosts or the security group that the member hosts are a member of	ITFarmHosts
SamAccountName	NetBIOS name for the service if not same as Name	ITFarm1
ServicePrincipalNames	Service Principal Names (SPNs) for the service	http/ITFarm1.contoso.com/contoso.com, http/ITFarm1.contoso.com/contoso, http/ITFarm1/contoso.com, http/ITFarm1/contoso, MSSQLSvc/ITFarm1.contoso.com:1433, MSSQLSvc/ITFarm1.contoso.com:INST01

The password change interval can only be set during creation. If you need to change the interval, you must create a new gMSA and set it at creation time.

Example

Enter the command on a single line, even though they might appear word-wrapped across several lines here because of formatting constraints.

Membership in Domain Admins, Account Operators, or ability to create msDS-GroupManagedServiceAccount objects, is the minimum required to complete this procedure. For detailed information about using the appropriate accounts and group memberships, see Local and Domain Default Groups.

To create a gMSA for outbound authentication only using the New-ADServiceAccount cmdlet

On the Windows Server 2012 domain controller, run Windows PowerShell from the Taskbar.

At the command prompt for the Windows PowerShell Active Directory module, type the following commands, and then press ENTER:

New-ADServiceAccount [-Name] -RestrictToOutboundAuthenticationOnly [-ManagedPasswordIntervalInDays ] [-PrincipalsAllowedToRetrieveManagedPassword ]

Parameter	String	Example
Name	Name the account	ITFarm1
ManagedPasswordIntervalInDays	Password change interval in days (default is 30 days if not provided)	75
PrincipalsAllowedToRetrieveManagedPassword	The computer accounts of the member hosts or the security group that the member hosts are a member of	ITFarmHosts

The password change interval can only be set during creation. If you need to change the interval, you must create a new gMSA and set it at creation time.

Example

Step 2: Configuring service identity application service

To configure the services in Windows Server 2012 , see the following feature documentation:

IIS application pool

For more information, see Services.

For more information, see the Task Scheduler Overview.

Other services could support gMSA. See the appropriate product documentation for details on how to configure those services.

Adding member hosts to an existing server farm

If using security groups for managing member hosts, add the computer account for the new member host to the security group (that the gMSA’s member hosts are a member of) using one of the following methods.

Membership in Domain Admins, or the ability to add members to the security group object, is the minimum required to complete these procedures.

Method 1: Active Directory Users and Computers

For procedures how to use this method, see Add a computer account to a group using the command line.

Method 3: Windows PowerShell Active Directory cmdlet Add-ADPrincipalGroupMembership

For procedures how to use this method, see Add-ADPrincipalGroupMembership.

If using computer accounts, find the existing accounts and then add the new computer account.

Membership in Domain Admins, Account Operators, or ability to manage msDS-GroupManagedServiceAccount objects, is the minimum required to complete this procedure. For detailed information about using the appropriate accounts and group memberships, see Local and Domain Default Groups.

To add member hosts using the Set-ADServiceAccount cmdlet

On the Windows Server 2012 domain controller, run Windows PowerShell from the Taskbar.

At the command prompt for the Windows PowerShell Active Directory module, type the following commands, and then press ENTER:

Get-ADServiceAccount [-Identity] -Properties PrincipalsAllowedToRetrieveManagedPassword

At the command prompt for the Windows PowerShell Active Directory module, type the following commands, and then press ENTER:

Set-ADServiceAccount [-Identity] -PrincipalsAllowedToRetrieveManagedPassword

Parameter	String	Example
Name	Name the account	ITFarm1
PrincipalsAllowedToRetrieveManagedPassword	The computer accounts of the member hosts or the security group that the member hosts are a member of	Host1, Host2, Host3

Example

For example, to add member hosts type the following commands, and then press ENTER.

Updating the group Managed Service Account properties

Membership in Domain Admins, Account Operators, or the ability to write to msDS-GroupManagedServiceAccount objects, is the minimum required to complete these procedures.

Open the Active Directory Module for Windows PowerShell, and set any property by using the Set-ADServiceAccount cmdlet.

For detailed information how to set these properties, see Set-ADServiceAccount in the TechNet Library or by typing Get-Help Set-ADServiceAccount at the Active Directory module for Windows PowerShell command prompt and pressing ENTER.

Decommissioning member hosts from an existing server farm

Membership in Domain Admins, or ability to remove members from the security group object, is the minimum required to complete these procedures.

Step 1: Remove member host from gMSA

If using security groups for managing member hosts, remove the computer account for the decommissioned member host from the security group that the gMSA’s member hosts are a member of using either of the following methods.

Method 1: Active Directory Users and Computers

For procedures how to use this method, see Delete a Computer Account using the command line.

Method 3: Windows PowerShell Active Directory cmdlet Remove-ADPrincipalGroupMembership

For detailed information how to do this, see Remove-ADPrincipalGroupMembership in the TechNet Library or by typing Get-Help Remove-ADPrincipalGroupMembership at the Active Directory module for Windows PowerShell command prompt and pressing ENTER.

If listing computer accounts, retrieve the existing accounts and then add all but the removed computer account.

Membership in Domain Admins, Account Operators, or ability to manage msDS-GroupManagedServiceAccount objects, is the minimum required to complete this procedure. For detailed information about using the appropriate accounts and group memberships, see Local and Domain Default Groups.

To remove member hosts using the Set-ADServiceAccount cmdlet

On the Windows Server 2012 domain controller, run Windows PowerShell from the Taskbar.

At the command prompt for the Windows PowerShell Active Directory module, type the following commands, and then press ENTER:

Get-ADServiceAccount [-Identity] -Properties PrincipalsAllowedToRetrieveManagedPassword

At the command prompt for the Windows PowerShell Active Directory module, type the following commands, and then press ENTER:

Set-ADServiceAccount [-Identity] -PrincipalsAllowedToRetrieveManagedPassword

Parameter	String	Example
Name	Name the account	ITFarm1
PrincipalsAllowedToRetrieveManagedPassword	The computer accounts of the member hosts or the security group that the member hosts are a member of	Host1, Host3

Example

For example, to remove member hosts type the following commands, and then press ENTER.

Step 2: Removing a group Managed Service Account from the system

Remove the cached gMSA credentials from the member host using Uninstall-ADServiceAccount or the NetRemoveServiceAccount API on the host system.

Membership in Administrators, or equivalent, is the minimum required to complete these procedures.

To remove a gMSA using the Uninstall-ADServiceAccount cmdlet

On the Windows Server 2012 domain controller, run Windows PowerShell from the Taskbar.

At the command prompt for the Windows PowerShell Active Directory module, type the following commands, and then press ENTER:

Example

For example, to remove the cached credentials for a gMSA named ITFarm1 type the following command, and then press ENTER:

For more information about the Uninstall-ADServiceAccount cmdlet, at the Active Directory module for Windows PowerShell command prompt, type Get-Help Uninstall-ADServiceAccount, and then press ENTER, or see the information on the TechNet web at Uninstall-ADServiceAccount.

Читайте также:  Edit windows registry from linux