Dynamics minimum of 365 required permissions to change the user's role and business unit

I am a Microsoft Dynamics 365 & Power Platform aspects engineer Rayong, Microsoft Most Valuable Professional is the July 2015 to June 2018 for three consecutive years Dynamics CRM / Business Solutions aspects (Microsoft MVP), I welcome the attention of the public micro-channel number MSFTDynamics365erLuoYong, reply or 20,191,218 385 may facilitate access to this article, but you can get the latest information I Bowen issued in the first room, follow me!

My previous blog post to explore Dynamics 365 users to log in using the minimum permission requirements about the minimum permissions need to log into the system, let's configure a role allows users to have this role can change a user's role and business unit.

Before that I've Common Data Service minimum privilege security role solutions introduced me Dynamics 365, the post will have to import a name for the role of min priv apps use.

First, we use a system administrator account to clone out a role, open min priv apps use this role, click [Actions]> [Copy Role] button.

Enter the role name, and then click [OK] button will copy the success, by default, it will open the role.

After some testing, I found the need to be able to change a user's business unit increased role and permissions required are as follows:

All rights Service Management Tab of entities Calendar
Write permissions Business Management Tab of the User entity, the global level, because the default hanging on the root business unit after the user enters the user operates the change is likely to have not hung on the root business unit, and to be able to change the user information need global write permissions
Assign permissions Business Management Tab of Security Role and global level
Business Management Tab 的User Settings实体的写权限，全局级别
Customization Tab 的Activate Real-time Processes权限，全局级别，此权限为杂项权限
Customization Tab 的System Job实体的追加到权限，全局级别
Customization Tab 的System Job实体的分派权限，全局级别
Customization Tab 的System Job实体的读权限，全局级别
Customization Tab 的System Job实体的写权限，全局级别
Customization Tab 的Process Session实体的追加到权限，全局级别
Customization Tab 的Process Session实体的追加权限，全局级别
Customization Tab 的Process Session实体的分派权限，全局级别
Customization Tab 的Process Session实体的创建权限，全局级别
Customization Tab 的Process Session实体的删除权限，全局级别
Customization Tab 的Process Session实体的共享权限，全局级别
Customization Tab 的Process Session实体的写权限，全局级别
Customization Tab 的Process实体的追加权限，全局级别
Customization Tab 的Process实体的分派权限，全局级别
Customization Tab 的Process实体的创建权限，全局级别
Customization Tab 的Process实体的删除权限，全局级别
Customization Tab 的Process实体的共享权限，全局级别
Customization Tab 的Process实体的写权限，全局级别
Core Records Tab 的Report实体的读取权限，全局级别

截图说明如下：

如果要求更改业务部门，除了系统管理员操作外，只能更改为操作者一样的业务部门的话，我这里使用插件来验证，我写了一个名称为PreSystemUserUpdate.cs的类，代码如下：

using Microsoft.Xrm.Sdk;
using Microsoft.Xrm.Sdk.Query;
using System;

namespace PluginDemo
{
    public class PreSystemUserUpdate : IPlugin
    {
        public void Execute(IServiceProvider serviceProvider)
        {
            //获取日志服务
            ITracingService tracingService = (ITracingService)serviceProvider.GetService(typeof(ITracingService));
            //写一些日志，方便跟踪
            tracingService.Trace($"Enter PreSystemUserUpdate on {DateTime.UtcNow.ToString()}");
            IPluginExecutionContext context = (IPluginExecutionContext)serviceProvider.GetService(typeof(IPluginExecutionContext));
            if (context.InputParameters.Contains("Target") && context.InputParameters["Target"] is Entity)
            {
                //插件针对的当前实体记录，对于Pre Update消息来讲，该对象包括了所有设置的字段值，若字段没有设置值，在该对象中会不存在
                Entity currentEntity = (Entity)context.InputParameters["Target"];
                //获取组织服务
                IOrganizationServiceFactory serviceFactory = (IOrganizationServiceFactory)serviceProvider.GetService(typeof(IOrganizationServiceFactory));
                IOrganizationService orgSvc = serviceFactory.CreateOrganizationService(context.UserId);
                //如果更新的字段包括Business Unit
                if (currentEntity.Contains("businessunitid"))
                {
                    tracingService.Trace($"Current user will change Business Unit on {DateTime.UtcNow.ToString()}");
                    //检查当前用户是否具有System Administrator角色
                    string fetchXml = string.Format(@"<fetch version='1.0' mapping='logical' distinct='true' no-lock='true' top='1'>
  <entity name='systemuser'>
    <attribute name='systemuserid' />
    <attribute name='businessunitid' />
    <filter type='and'>
      <condition attribute='systemuserid' operator='eq' value='{0}' />
    </filter>
    <link-entity name='systemuserroles' from='systemuserid' to='systemuserid' visible='false' intersect='true'>
      <link-entity name='role' from='roleid' to='roleid' alias='ac'>
        <filter type='and'>
          <condition attribute='name' operator='eq' value='System Administrator' />
        </filter>
      </link-entity>
    </link-entity>
  </entity>
</fetch>", context.UserId);
                    //不具有System Administrator角色的用户更改用户的业务部门时候，只能更改为与当前用户相同的业务部门
                    if (orgSvc.RetrieveMultiple(new FetchExpression(fetchXml)).Entities.Count == 0)
                    {
                        var currentUserBU = orgSvc.Retrieve("systemuser", context.UserId, new ColumnSet("businessunitid")).GetAttributeValue<EntityReference>("businessunitid");
                        tracingService.Trace($"Current user's business unit name is {currentUserBU.Name}");
                        if (currentEntity.GetAttributeValue<EntityReference>("businessunitid").Id != currentUserBU.Id)
                        {
                            throw new InvalidPluginExecutionException($"你只能更改当前用户的业务部门为你所在的业务部门-{currentUserBU.Name}");
                        }
                    }
                }
            }
            tracingService.Trace($"Leave PreSystemUserUpdate on {DateTime.UtcNow.ToString()}");
        }
    }
}

然后还是注册插件，大部分步骤可以参考我前面的博文 Dynamics 365中开发和注册插件介绍，还是先注册程序集，如下图：

然后右击插件类注册新步骤，如下图：

设置如下图，可以看到是注册到SystemUser实体的Update消息的Pre Operation阶段，注意要筛选字段，我这里筛选字段为 businessunitid，很多人注册Update消息上的插件不筛选字段，那么触发会非常频繁，这是不好的做法。

注册后去测试，如果报错，效果如下：

如果你能授予他人的的角色权限包括了你没有的权限，那就是安全漏洞了。如果你要授予他人的的角色权限包括了你没有的权限系统会报错，下面是一个报错的截图。

至于权限名称，比如prvActivateBusinessProcessFlow 对应界面上的那个项目，可以通过 Security role UI to privilege mapping 来查询。

Dynamics minimum of 365 required permissions to change the user's role and business unit

Guess you like