CRM 2011 Installing User/Service Account Permissions

Posted on Updated on

I’ve been asked a few times now from clients’ IT departments, what are the requirements/permissions needed for the Dynamics CRM installing user, as well as permissions needed for accounts running any of the installed CRM services.

The CRM 2011 planning guide is quite large and can be arduous to read through.  I’ve extracted out the important information into the following points below:

Microsoft Dynamics CRM Server Setup

The user account used to run Microsoft Dynamics CRM Server Setup that includes the creation of databases requires the following minimum permissions:

  • Be a member of the Active Directory Domain Users group. By default, Active Directory Users and Computers adds new users to the Domain Users group.
  • Be a member of the Administrators group on the local computer where Setup is running.
  • Have Local Program Files folder read and write permission.
  • Be a member of the Administrators group on the local computer where the instance of SQL Server is located that will be used to store the Microsoft Dynamics CRM databases.
  • Have sysadmin membership on the instance of SQL Server that will be used to store the Microsoft Dynamics CRM databases.
  • Have organization and security group creation permission in Active Directory service (ADDS).
  • If Microsoft SQL Server Reporting Services is installed on a different server, you must add the Content Manager role at the root level for the installing user account. You must also add the System Administrator role at the site-wide level for the installing user account.

Services and CRMAppPool IIS Application Pool Identity Permissions

The user account that is used for the Microsoft Dynamics CRM services and IIS application pools must meet the following criteria:

  • Microsoft Dynamics CRM services and application pool identity accounts must not be configured as a Microsoft Dynamics CRM user. Doing so can cause authentication issues and unexpected behavior in the application for all Microsoft Dynamics CRM users.
  • Managed service accounts, introduced in Windows Server 2008 R2, are not supported for running Microsoft Dynamics CRM services.

Microsoft Dynamics CRM Sandbox Processing Service

Sandbox Processing Service server role enables an isolated environment to allow for the execution of custom code, such as plug-ins.

  • Domain User membership.
  • That account must be granted the Logon as service permission in the Local Security Policy.
  • Folder read and write permission on the \Trace, by default located under \Program Files\Microsoft Dynamics CRM\Trace, and user account %AppData% folders on the local computer.
  • Read permission to the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSCRM subkey in the Windows Registry.
  • The service account may need an SPN (server principal name) for the URL used to access the Web site that is associated with it. To set the SPN for the Sandbox Processing Service account, run the following command at a command prompt on the computer where the service is running.
  • SETSPN –a MSCRMSandboxService/<ComputerName> <service account>

Services and CRMAppPool IIS Application Pool Identity Permissions

The user account that is used for the Microsoft Dynamics CRM services and IIS application pools must meet the following criteria:

  • Microsoft Dynamics CRM services and application pool identity accounts must not be configured as a Microsoft Dynamics CRM user. Doing so can cause authentication issues and unexpected behavior in the application for all Microsoft Dynamics CRM users.
  • Managed service accounts, introduced in Windows Server 2008 R2, are not supported for running Microsoft Dynamics CRM services.

Microsoft Dynamics CRM Sandbox Processing Service

  • Domain User membership.
  • That account must be granted the Logon as service permission in the Local Security Policy.
  • Folder read and write permission on the \Trace, by default located under \Program Files\Microsoft Dynamics CRM\Trace, and user account %AppData% folders on the local computer.
  • Read permission to the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSCRM subkey in the Windows Registry.
  • The service account may need an SPN for the URL used to access the Web site that is associated with it. To set the SPN for the Sandbox Processing Service account, run the following command at a command prompt on the computer where the service is running.
  • SETSPN –a MSCRMSandboxService/<ComputerName> <service account>

Microsoft Dynamics CRM Asynchronous Processing Service

  • Domain User membership.
  • Performance Log Users membership.
  • That account must be granted the Logon as service permission in the Local Security Policy.
  • Folder read and write permission on the Trace folder, by default located under \Program Files\Microsoft Dynamics CRM\, and user account %AppData% folder on the local computer.
  • Read and write permission to the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSCRM and HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\MSCRMSandboxService subkeys in the Windows Registry.
  • The service account may need an SPN for the URL used to access the Web site that is associated with it.

Deployment Web Service (CRMDeploymentServiceAppPool Application Pool identity)

  • Domain User membership
  • That account must be granted the Logon as service permission in the Local Security Policy.
  • Local administrator group membership on the computer where the Deployment Web Service is running.
  • Local administrator group membership on the computer where SQL Server is running.
  • Sysadmin permission on the instance of SQL Server to be used for the configuration and organization databases.
  • Folder read and write permission on the Trace and CRMWeb folders, by default located under \Program Files\Microsoft Dynamics CRM\, and user account %AppData% folder on the local computer.
  • Read and write permission to the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSCRM and HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\MSCRMSandboxService subkeys in the Windows Registry.
  • CRM_WPG group membership.  This group is used for IIS worker processes. The group is created and the membership is added during Microsoft Dynamics CRM Server Setup.
  • The service account may need an SPN for the URL used to access the Web site that is associated with it.

Application Service (CRMAppPool IIS Application Pool identity)

  • Member of the Active Directory Domain Users group.
  • Member of the Active Directory Performance Log Users group.
  • Administrators local group membership on the computer where SQL Server is running.
  • Administrators local group membership on the computer where the Microsoft Dynamics CRM Web site is installed.
  • Folder read and write permission on the Trace and CRMWeb folders, by default located under \Program Files\Microsoft Dynamics CRM\, and user account %AppData% folder on the local computer.
  • Read and write permission to the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSCRM and HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\MSCRMSandboxService subkeys in the Windows Registry.
  • CRM_WPG group membership. This group is used for IIS worker processes. The group is created and the membership is added during Microsoft Dynamics CRM Server Setup.
  • The service account may need an SPN for the URL used to access the Web site that is associated with it.
About these ads

9 thoughts on “CRM 2011 Installing User/Service Account Permissions

    Farhan Syed said:
    September 5, 2011 at 7:48 AM

    Nice article Danny! I personally liked the way you started… “the implementation guide can be arduous to start”

    Thanks again!

    [...] CRM 2011 Installing User/Service Account Permissions (via Danny Varghese’s Blog) Posted on September 5, 2011 by iFarhan I've been asked a few times now from clients' IT departments, what are the requirements/permissions needed for the Dynamics CRM installing user, as well as permissions needed for accounts running any of the installed CRM services. The CRM 2011 planning guide is quite large and can be arduous to read through.  I've extracted out the important information into the following points below: Microsoft Dynamics CRM Server Setup The user account used to … Read More [...]

    Didier said:
    January 17, 2012 at 4:12 AM

    Good synthesis Danny!
    I read the (arduous and tedious) IG and was preparing a summary when I stumbled on your great post.
    Thanks dude!
    :~Didier

    Bjarne said:
    November 20, 2012 at 6:26 AM

    After installation/during normal operation – does the CRM account still have to be member of the SQL Server sysadmin role ?

      ifarhansyed said:
      November 20, 2012 at 10:10 AM

      Hi Bjarne,

      I tried this case in the development environment and it worked fine. However shall not suggest this in the production environment as there are known SPN cases that have occurred.

      But, why would you do that?( unless it’s a group policy)

        Danny Varghese responded:
        November 20, 2012 at 10:52 AM

        Hello, thank you for your quick reply & post! Quick question, when you say issues with SPN have occurred, does that mean in those cases the installation user account is being used to run CRM services? I would highly advise against that, b/c SPN has specifically to do with how services authenticate when communicating across servers. If the installing user account is not running any services (as it should not be doing), then SPN should not come into play.

        Unless you think otherwise? I’m open to feedback =), thanks!

      Danny Varghese responded:
      November 20, 2012 at 10:49 AM

      Hi Bjarne,

      This is a great question and I get this asked a lot by my clients. Just as an FYI about the installing user account:

      1. The permissions needed for the installing user does not need to be configured ahead of time. During the installation process, the privileges are granted.
      2. According to the implementation guide, “During installation, Microsoft Dynamics CRM Server Setup creates a special deployment-wide administrator role and attaches it to the user account that is used to run Setup. The Deployment Administrators role is not a security role and does not appear in the Microsoft Dynamics CRM Web application as such.”

      The installing user account should be a service account that only IT has access to and will not be used in any transactions in Dynamics CRM. Since this account is really used to install CRM and should not be used for anything else in the future, why tinker with the permissions? “If it ain’t broke, why fix it,” comes to mind.

      Another reason why not to change the permission is it’s MS security best practices to limit the number of deployment administrators and system admins. After installation, the only deployment administrator is the installation user account. You can choose to add more, but if you really want to restrict access, you could leave it as is. In that case, you don’t want to remove that permission b/c the deployment administrator will need at least the db_owner role, and since having sysadmin role will cover that requirement, it’s already done for you. Another reason not to fix something that “ain’t broke.”

      Hopefully that helps!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s