Rolling with the System Administrator Role

I recently had a customer that wanted to run the Email Router as a user other than the System Administrator, offhand this seemed like an easy task.  The customer setup a new “Service User” and created a special “Service Role” that only had access to email related privileges.  Here is what the Implementation Guide says:

“If you did not specify an incoming e-mail server during Microsoft Dynamics CRM Server Setup, you must manually add the service account running the E-mail Router service to the PrivUserGroup security group. The PrivUserGroup is created during Microsoft Dynamics CRM Server Setup. For steps on how to add members to this group, see the "Troubleshooting" section later in this section.”

The trick was that they did not want to add this user to the PrivUserGroup, but instead wanted to have this user be relatively low privilege. Unfortunately, this was not straightforward so I had to do some digging.  First thing I did was to enable CRM tracing to work through all the failed “Privilege Checks”, adding the needed privilege to the service role on after another.  Unfortunately, after we added all the privileges we ended up with this error:

MessageProcessor fail to process message 'GetDecryptionKey' for 'email'.

[2009-06-04 00:33:21.0] Process: w3wp |Organization:6f10d233-a921-4185-a303-7ae7d2fcffbc |Thread:    9 |Category: Platform.Sdk |User: 25d8907f-f84a-de11-80a2-00110aa06f20 |Level: Error | CompositeSoapExtensionExceptionHandler.Handle

CrmSoapExtension detected CrmException:

System.Web.Services.Protocols.SoapException: Server was unable to process request. ---> System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> Microsoft.Crm.CrmException: Access is denied.

at Microsoft.Crm.ObjectModel.EmailService.GetDecryptionKey(ExecutionContext context)

This obviously required a little more digging.  That digging determined that CRM actually requires this user to have System Administrator role.  We granted the user this role and all was well.  But why was this required and is there anything we can learn from this?  The answer is “of course”, so read on. J

The System Administrator role in Microsoft Dynamics CRM is “special”, which is to be expected as it is basically the root security role that is granted to the setup user and users that have total access to things within the system.  Grant a user this role, make them a Deployment Administrator, and give them the corresponding required AD permissions and the user has total control over the CRM system.  But for today, I want to focus on the System Administrator Role and provide a bit of details behind it, some obvious and some not so obvious.

First, what is the System Administrator role?  Well obviously it is the role with the name System Administrator, but let’s be more specific.  If you create a new role via the Role Editor and grant it all privileges and call it “System Administrator” it will just be a role with a lot of privileges, but it won’t be the System Administrator role.  Here is why.  To CRM, the System Administrator Role is any role whose Role Template ID is that of the known System Administrator Role Template.  The GUID (627090FF-40A3-4053-8790-584EDC5BE201) of this template is well known and the template is created when you install CRM.

Now let’s take a look at the difference between the privileges of the role you created with “everything”.  We will use the following query:

-- Set these to the two roles you are trying to compare

-- This script is provided “AS IS” with no warranties, and confers no rights

DECLARE @SystemAdminRoleId uniqueidentifier

DECLARE @EverythingAdminRoleId uniqueidentifier

SET @SystemAdminRoleId = '66b89fc2-64b2-dc11-b25e-0003ffb8057d'

SET @EverythingAdminRoleId = '7057625a-4f6a-de11-bfd3-0003ff6e9d4e'

SELECT pb.privilegeid, pb.name FROM

       RolePrivileges rp JOIN PrivilegeBase pb ON rp.privilegeId = pb.privilegeid

       WHERE RoleId = @SystemAdminRoleId

       AND rp.PrivilegeId NOT IN (SELECT privilegeid FROM RolePrivileges WHERE Roleid = @EverythingAdminRoleId)

       ORDER BY [name]

Here is a list of privileges that are missing from the “everything” role:

As you can see, there are 69 missing privileges from your “everything” role.

Why is there a difference?  Well, this is because the CRM Role Editor UI does not allow you to set every privilege.

To get around this you should use the “Copy Role” feature to make an exact copy of the role.

So what if you manually (via the platform) add all the missing privileges to your role?  Unfortunately for some scenarios, this still isn’t good enough.  In CRM, there are some very specialized messages like GetDecryptionKey that actually have a check to see if the user has the System Administrator role:

if (service.IsSystemAdministratorRole(guid, context))

{

     flag = true;

     break;

}

Here is a breakdown of what worked and what did not:

This message is used by the Email Router Service and as such, the account that the email router is running as must have the System Administrator role.  Unfortunately, there is no supported way around this, as even making a “copy” of the System Administrator role via the UI does not yield the desired results as the Template ID of the copied role is NULL.  You also can’t set the Role Template ID in a supported manner either as this attribute is marked as not valid for CREATE or UPDATE. The only other operation I could find that appears to require the System Administrator role is registering your CRM installation.

Special thanks to James Dulin and Ross Lotharius for helping with some background research on this post.

Cheers,

CRM MVP Aaron Elder