Change a Microsoft Dynamics CRM service account or AppPool identity
Applies To: Dynamics CRM 2013
There are situations in which you may need to change the account that is used to run a Microsoft Dynamics CRM service or IIS application pool identity.
The simplest way to change a service account is to run a repair operation and then specify the new service account during the repair. There may be a short downtime as the services are stopped and files are verified and possibly refreshed as part of the repair. More information: Uninstall, change, or repair Microsoft Dynamics CRM Server 2013
To change the CRMAppPool service account, the appropriate permission must be granted to the domain user account that will be used as the CRMAppPool identity or the application pool won’t start. Additionally, if you’re using claims-based authentication, the CRMAppPool service account must have permission to access the claims-based authentication token-signing certificate.
Additionally, you must make the necessary configuration changes in IIS.
You must add the domain user account to these Active Directory groups:
We strongly recommend that you use a dedicated domain user account that is not used as the identity for any other service or application pool.
If you have more than one Microsoft Dynamics CRM deployment, multiple groups used by Microsoft Dynamics CRM exist in Active Directory. See Determine the groups to update for multiple deployments to determine the groups that you want to update.
Additionally, the following local group membership is required:
Performance Log Users
Use Active Directory Users and Computers to add the Active Directory and local group memberships.
The domain account user must also have the following local policy rights:
Impersonate a client after authentication
Log on as a service
To add these local policy rights, follow these steps:
On the Microsoft Dynamics CRM server, start the Local Security Policy MMC snap-in.
Expand Local Policies, and then click User Rights Assignment.
Right-click Impersonate a client after authentication, and then click Properties.
Click Add User or Group.
You may have to click Location to select the domain instead of the local computer.
In the Group name box, type the name of the user who is running the Microsoft Dynamics CRM application pool, and then click OK two times.
Repeat steps 3 through 5 for the Log on as a service right.
By default, Internet Information Services (IIS) Kernel-Mode Authentication is enabled for web applications and you do not have to remove or set service principal names (SPNs) as described in this section. However, if IIS Kernel-Mode Authentication is disabled by setting Enable Kernel-mode authentication to false, you must configure SPNs for the new service account.
Identify and configure SPNs
Find any existing SPNs and configure the domain user account that will be used as the CRMAppPool identity to use SPNs.
Determine the SPNs that are registered under the current CRMAppPool identity. For example, the current identity is Network Service, which is a local computer system account for the CRMAppServer.contoso.com server. Additionally, the host header CRM is implemented on the Web site.
You can find the SPNs by using Setspn or ADSI Edit. In this example, the expected SPNs related to IIS are listed here. There may be additional SPNs added to the identity account depending on the installed services.
In this example, there are SPNs with two different service classes registered, the default Host SPNs and the HTTP SPNs for the host header. The current HTTP SPNs will need to be removed so they can be added under the new domain user account that will be used as the CRMAppPool identity. The HOST SPNs do not get removed because these will not cause duplicates due to the unique service class. Therefore, in this example the host header SPNs for HTTP/CRM and HTTP/CRM.contoso.com can be removed by using setspn at a command prompt window:
setspn -d HTTP/crm CRMAppServer
setspn -d HTTP/crm.contoso.com CRMAppServer
You must add the following SPNs to the user domain account that you will use as the CRMAppPool identity. In this example, the domain user account name is CRMService and the domain is Contoso. These are the SPNs for the server name and the host header. You’ll need to create additional SPNs if additional host headers are used.
Register the SPNs:
To register the SPNs on crmappserver in the contoso domain, type the following in a command prompt window and press ENTER:
setspn -s HTTP/CRMAppServer contoso\crmservice
Notice that the –s parameter will first check whether the SPN already is registered. If the SPN already exists, you should not have to create a new one.
Repeat the first step for all remaining SPNs.
Trust for delegation
If you have more than one Microsoft Dynamics CRM server and IIS kernel-mode authentication is disabled, you must configure the CRMAppPool application pool security account to be trusted for delegation. To do this, follow these steps:
Log on to the domain controller by using a user account that has domain administrator permissions.
Start Active Directory Users and Computers.
Expand the domain, right-click the domain user account that you will use for the CRMAppPool identity, and then click Properties.
On the Delegation tab, select the Trust this user for delegation to any service (Kerberos only) option.
Set the domain user account as the CRMAppPool identity in IIS.
To change the CRMAppPool identity in IIS, follow these steps:
Start Internet Information Services (IIS) Manager.
Click Application Pools, right-click CRMAppPool, and then click Advanced Settings.
Click the identity account next to Identity and then click the ellipsis (…).
Click Set, type the new identity, such as contoso\crmservice, enter and confirm the password, and then click OK three times to close all dialog boxes.
Close Internet Information Services (IIS) Manager.
Restart Internet Information Services (IIS). To do this, click Start, click Run, type IISRESET, and then click OK.
If you have more than one Microsoft Dynamics CRM deployment, multiple groups used by Microsoft Dynamics CRM exist in Active Directory. Follow these steps determine the object GUID that you can use to locate the correct groups that the deployment is using.
Run the following SQL query against the MSCRM_CONFIG database:
SELECT [PrivilegeReportGroupId] ,[PrivilegeUserGroupId] ,[ReportingGroupId] ,[SqlAccessGroupId] FROM [mscrm_config].[dbo].[ConfigSettings]
Note the Id for the PrivUserGroup and SQLAccessGroup groups. For example, the PrivUserGroupId may appear similar to C8AB1D52-9383-4164-B571-4C80D46674E3. The PrivUserGroupId and the SQLAccessGroupId is the objectGUID that you can use to find the group in Active Directory. For more information about finding objects in Active Directory, see Active Directory Searches Technical Reference.
© 2016 Microsoft Corporation. All rights reserved. Copyright