上一篇微软特权访问管理，我们讲到了PAM产生的时代背景，PAM的概念，JIT，JEA，安全主体，MIM等落地工具，PAM与Azure PIM的区别，PAM在微软2016安全体系的作用，并且通过最原始的Powershell命令验证实现了JIT 安全主体构建的PAM操作过程模型，感兴趣大家可以去回看或进一步查阅资料。
但是在实际企业应用来说，企业希望的不仅仅是通过人为审批+人工操作Powershell，最好是有一个门户，用户可以在上面去申请权限，通过在线工作流进行审批，底层是PAM技术工具的支撑，这样更加贴近实际环境，也便于检阅，本篇进阶文章我们就把PAM的操作部分与报告部分做成门户，实现三个功能
用户在门户申请时效性权限，管理员审批通过，自动加入到本域安全组或安全主体
申请成功后自动把用户的申请以及审批信息归档做成报告 。
支持在门户上对用户申请记录进行权限回收，变更回收字段，后台自动回收安全组或安全主体权限。
对于微软的产品体系而言，要对接PAM底层的JIT JEA 安全主体技术，实现门户申请，审批，归档，有三种选择，Sharepoint+SCO，SCO+SCSM，MIM2016。
本篇文章我们将主要关注于Sharepoint +SCO实现PAM门户，Sharepoint+SCO+PAM三个部分的流程对接，思维引导，对于PAM概念，PAM技术工具原理，PAM技术配置，本文将不再做复述。
各个组件在流程扮演的作用如下
Sharepoint：创建申请列表，审计报告列表，由管理员定义需要录入的信息，需要注意申请列表的信息要包括：申请域账户，目标申请组，申请时间，等三个基本信息，这三个信息会被SCO监控到，SCO会拿着这三个信息去让AD域执行加入安全组或加入安全主体操作。除此之外Sharepoint还要实现审批工作流，以此作为每条记录的跟踪确认项，用户的申请先要在Sharepoint里面进行人为审批，审批通过后，申请记录工作流状态变为已通过
SCO：对于Sharepoint来说工作流已经结束，但对于下一站SCO来说工作流刚刚开始，SCO捕捉审批状态已通过的项目，将已通过项目的数据通过databus传递到下一站执行脚本，执行脚本活动拿着用户输入的信息，连接到域控服务执行加入安全组或加入到安全主体操作。
可以看到整套流程里面Sharepoint主要扮演申请输入，审批，展示，存放的一方，SCO在做的是对接Sharepoint的信息与PAM，将Sharepoint输入的结果，直接让AD域去执行，让Sharepoint输入的信息从静态变为真正生效。
对于SCO这个产品，老王这里还是简单介绍一下，SCO全称System Center Orchestrator，是微软System Center2012套件里面的自动化产品，主要功能
支撑微软私有云自助化实现，对接SCSM和底层VMM，将用户的SCSM自助申请，传递到VMM创建生效，
支持混合云场景，支持和Azure IAAS 整合资源申请，和Azure SMA整合混合自动化呼叫。
协调数据中心内，系统上不同组件，或不同系统之间的自动化协作。
管理员可以通过拖拽的方式设计自动化协作流程，降低自动化门槛。
SCO产品安装组件
Management Server：负责SCO与数据库的对接，用户导入的集成包，以及写好的runbook会存放在SCO数据库中，SCO会通过Management Server去数据库捞取runbook，集成包数据
Runbook Server：负责Runbook的实际执行
Orchestrator Console and Web service：SCO安装好之后会有一个Web console 供网页查看执行runbook，默认端口82，Web Service供SCSM或其它web程序调用runbook，默认端口81
Runbook Designer：Runbook的可视化设计器，只负责流程设计，流程真正执行是在Runbook Server
各组件可以安装到不同服务器，每个组件支持部署多个，每个Runbook支持指定不同的Runbook Server执行
SCO系统服务
Orchestrator Management Service：Managment Server角色服务，负责接收runbook server请求去数据库捞取资料
Orchestrator Runbook Service：Runbook Server角色服务，负责执行runbook活动流程
Orchestrator Runbook Server Monitor ：Runbook Server角色服务，监控Runbook 执行状态与事件
Orchestrator Remoting Service：Deployment Manager远程部署IP使用
SCO术语介绍
Runbook：描述Orchestrator设计好的一条自动化流程，一条Runbook可以由多个活动组成，将多个活动连接起来形成自动化流程。
IP：Intergration Pack，默认情况下Runbook只能基于默认现有的活动设计流程，可以通过导入不同产品IP让SCO拥有更多活动，完成Runbook的设计。
Deployment Manager：用于部署IP包，每一个IP包需要部署到用于设计的Runbook Designer，还要部署到用于执行的Runbook Server
databus：当我们在runbook中通过连接线把多个活动连接在一起，那么上一个活动监控到的数据或执行完产生的数据，会通过databus传递到下一个活动中，下一个活动中可以通过订阅已发布的数据方式，使用上一个活动产生的数据来完成接下来的自动化活动。单独的一个活动没有databus的概念，当多个活动通过连接线连接，databus将在后面每个活动里面传递。
连接线：通过拖拉的方式将多个活动进行连接 形成流程，连接线可以按照不同结果传递到不同的活动，如上一个操作执行成功传递到下一个活动A，执行失败传递到下一个活动B，可以自定义连接线标签提醒管理员用途，可以自定义上一个活动执行后延迟多久再执行下一个活动，连接线是搭建databus的桥梁。
对于本次流程而言，最重要的是要理解SCO中databus的概念，我们要建立runbook流程，让runbook流程去监控sharepoint填写的数据，监控到工作流已通过后，通过databus把数据传递到下一个活动，不论是本域加入到时效组，或者添加到堡垒林安全主体也好，都是要通过脚本执行，所以监控sharepoint活动的下一个活动一定要接执行脚本的活动，我们要把监控sharepoint活动监控到的数据，传递到执行脚本的活动中，最终执行的脚本其实是sharepoint的输入数据。
下文将开始进行实际的流程设计和演示，通过实验来帮大家加固理解，由于篇幅有限，将不对SCO，Sharepoint的安装，以及基本配置，如列表创建，集成包导入等进行演示，我们将逐步实现目标的三个功能，首先我们将实现在单域时效性组成员资格的场景下，三个功能的PAM门户实现。
当前ABC公司已经升级域控到2016，林域功能级别升级到2016，已经开启了PAM功能，对于特权管理组已经进行梳理准备，只保留必备功能管理员，个人管理员已经被清除，现希望通过门户实现个人管理员时效性成员资格的在线请求，审批，归档，回收。
实验环境介绍
PRIVDC 2016域控 虚拟机1VCPU 2GB内存
Sharepoint 2013 +SCO 2012R2 虚拟机4VCPU 8GB内存
功能1：实现用户在门户申请时效性权限，管理员审批通过，自动加入到本域安全组或安全主体
准备工作：Sharepoint创建权限申请自定义列表，除必备申请域账号，申请目标组，申请时效外，管理员可自行设计所需要的栏目
申请域账号是最终实际要加入到特权组的域账号名称
申请目标组是最终实际要加入到的特权组名称
申请时间是传递到后面脚本执行时的TTL，可以设计为天，小时，分，秒，这里我设计为分钟，随后脚本中也设计TTL为分钟。
申请人信息可以直接使用列表自带创建者修改。
在网站集功能开启工作流功能，随后在列表设置工作流设置中创建审批工作流，在启动选项处勾选 新建项目将启动此工作流
配置工作流审批者，可以规划一个安全组作为分配对象，实验这里我指定每次都由Stat这个人进行审批
在这个功能里面，我们需要Sharepoint做的已经到位了，提供Web申请的表单，提供在线工作流审批，接下来是SCO的表演时间，开场之前不要忘记为SCO Runbook Server和Designer服务器导入AD和Sharepoint的IP包，导入完成后记得在Designer界面上方选项处，配置每个IP包，例如AD包要连接到那个域，Sharepoint要连接到的网站集合是哪个。
这里会遇见第一个坑，一定要注意，配置sharepoint连接里面，有一个Default Monitor Interval Seconds的属性，是sharepoint活动每次去轮询监控sharepoint数据的默认间隔时间，所有sharepoint活动会继承此设置，默认是15秒，你千万自作聪明给它改短，改短后你会发现sharepoint的自动化活动失败。
要想实现这个功能啊，其实也并不是那么容易，也需要SCO活动的支持，设想一下我们有两个传递到下一个活动的先决条件
传递每一个新建的且sharepoint里面工作流审批已通过的记录
传递新建后审批未通过，但是经过一段时间后审批已通过的记录。
从设计上面讲这个是必须要有的合理需求，但是从实现的角度来讲，并不是那么容易，SCO如果要监控某一个具体的txt，某个具体的日志还可以，但是要监控每一条更新的就有点难度，幸好，7.2版本的sharepoint ip里面的Monitor List items活动完美支持我们的需求，可以监控新建的记录，监控变更的记录，并且可以设计满足筛选条件再收数据。
拖拽Monitor List items活动进入设计面板，选择需要监控的申请列表，确保Monitor Interval Seconds为15秒及以上 Monitor New items为true，监控新建项目，Monitor Modifieds items为true，监控变更项目。
Filters里面设计筛选流程审批字段为已通过，实现效果，当新申请接入，只有在sharepoint方工作流已经走完，审批状态已通过，才会监控到这条数据，把这条监控的数据在SCO databus上面传递到下一个活动。除了新建外，变更也一样，假设我们在sharepoint里面，新建了一条记录，但是审批者没有及时审批，流程审批字段状态会是进行中，这时候这条记录就不会经过SCO databus流向下一个活动，过了一会之后审批者审批了这条记录，记录变为已通过，Monitor Interval Seconds时间到达后Monitor List Items同样会感知到这次修改，把修改为已通过的这条数据通过databus流向下一个活动。
添加运行.NET脚本活动，语言类型选择Powershell
在Monitor List Items活动处，绘制连接线，连接到下一个活动，建立databus流
在脚本活动中复制这段脚本
$session = New-PSSession -Computer PRIVDC
Invoke-Command -session $session -ScriptBlock {
Import-Module ActiveDirectory
$TTL = New-TimeSpan -Minutes 10
Add-ADGroupMember -Identity“Domain Admins”-Members “Tony”-MemberTimeToLive $TTL
}
接下来就是有意思的事情了，我们要把sharepoint里面输入的数据，通过databus，传递给脚本去AD执行
在脚本处，点击 -Minutes 删除掉数字10 ，点击右键，选择订阅 - 已发布数据，从databus寻找数据
选择这里的minutes ttl时间，不要使用静态的，而是要使用上一个活动传递过来的申请时间数值
依次替代申请目标组，申请域账户数据为sharepoint传来数值
这就是SCO的神奇之处，它可以在不同系统之间传递数据，你前一个活动系统是sharepoint，后一个活动系统是AD域，没关系，我同样可以通过databus传递到下一个活动，只要你传递的数据，不违反下一个活动执行需要的格式类型就行。
这里有些人会遇见第二个坑，是脚本层面的问题，原来我们执行命令时在-Identity命令后面会有个空格，然后是domain admins静态组，但是被我们替换成从sharepoint传来的数据后，在-identity后面会少一个空格，所以会遇见这个活动执行失败
还有，后面的一个参数也有此问题，TTL参数前面本来是有空格的，前面是静态的要加入到时间资格组的用户，但是被我们替换成sharepoint里面的申请域用户之后，这个空格会消失
所以会导致.NET脚本这个活动执行失败，大家可以把SCO做完sharepoint传递的脚本拿出来到ISE复制就可以看到，回到SCO中把这两个地方的空格处理掉问题可解
至此第一个功能SCO与Sharepoint部分配置完成，下面进行功能验证
用户eric是普通用户，登陆sharepoint门户申请5分钟的domain admins组资格权限
申请得到stat及时审批，流程审批更新为已通过，SCO Monitor List Items感知到新项目建立，监控成功，触发下一个活动，在下方可以看到Runbook的执行记录
查看管理员组时效成员资格，可以看到Eric的TTL时效资格已经生效
Get-ADGroup -Identity “Domain Admins” -Properties * -ShowMemberTimeToLive |fl member
当前Jack用户提交申请，但是未得到stat的及时审批，审批状态为进行中，SCO活动不会被触发
经过一段时间后 stat审批了jack的请求，状态更新为已通过
SCO Monitor List Items感知有已通过项目更新，监控成功，将数据传递到下一个活动执行脚本，可在日志历史纪录查看执行记录。
查看命令可以看到Jack也已经获得了时效性成员组资格。
至此我们完成了第一个申请功能的实现，用户并不知道后台发生的事情，他们只会看到审批通过之后权限就生效了，只有我们知道，其实我们是结合了Sharepoint+SCO实现了很酷的东西，如果企业有Exchange服务器，还可以再添加一个活动，当脚本活动执行成功后，邮件通知用户已获得临时权限。
接下来是第二个审计功能，PAM里面一个主要部分的是要对特权权限的申请记录化，包括申请人，申请原因，申请特权组，审批人，特权生效时间，等等，形成一个可视化的审计报告，Sharepoint在里面发挥的作用是提供SCO自动填充的审计列表，老王在sharepoint自己设计了审计需要的信息栏目，仅供参考
SCO部分对于审计功能，我们的设计思路是添加创建列表项目的第三个活动，让SCO自动去获取Monitor list items活动的数据，当第二个脚本执行成功后，自动把第一个活动的数据填充进来创建列表项目，由于第三个创建项目的活动需要使用第一个活动的数据，因此需要确保三个活动都接入连接线，在同一条databus上面，即是说当一个申请在sharepoint里面审批通过后，进入SCO要经过三个活动 1.获取数据 2.传递到AD执行脚本 3.基于获取数据创建审计数据 ，三个活动执行成功后此条流程结束。
拖拽Create List items活动进入设计面板
进行数据订阅，选择从第一个活动订阅已发布数据
依次将第一个活动中的数据进行填充，有一个特权生效时间，老王建议可以从第二个运行脚本的活动中获取，这个数值取第二个活动执行成功结束时间，这个时间结束后，普通用户就肯定加入到了特权组，所以取这个自动时间一定是最准确的。这也是通过自动化实现的好处，避免了很多人为记忆的偏差。
针对于权限是否回收，老王是在sharepoint里面做成了选项列表，默认设置为未回收
流程现在设置如下
这个功能到这里已经设计完成，下面进行功能验证
用户mike在申请列表提交申请请求
Stat审批通过，流程审批状态变为已通过
SCO活动监控到匹配数据，开始触发活动，三步活动执行成功
查看Mike当前已经获取到了时效权限内的特权组权限
打开创建好的IT权限审计列表可以看到，由SCO自动拿着第一个活动和第二个活动的数据自动创建出来的审计信息
第三个功能：支持在门户上对用户申请记录进行权限回收，用户变更回收字段，后台自动回收安全组或安全主体权限
大家可以看到，我们在第二个功能里面设计了一个权限是否回收的栏，这个对于审计信息而言老王觉得也是需要的，如果不做成自动化流程，那么就需要审计人员去与审批人确认，该权限是否回收，然后更新记录。有了自动化流程之后我们就可以实现，审计人员或者IT管理人员，查看权限审计列表，如果觉得某一个权限应该被回收，只需要变更权限是否回收的字段为需要回收，后台SCO后检测到这个变更，触发一个从安全组或安全主体移除用户的命令，将用户移除权限，然后再更新列表权限是否回收为已回收，更新权限回收时间为从安全组或安全主体移除用户的时间。
这个功能不仅可以适用于我们此次通过申请创建的时效性资格自动更新的审计记录，企业的IT管理员也可以把手动赋予过的权限登记在这里，定期检查是否已经回收，是否需要回收，如需要，自动化完成。
实现起来，这个我们需要单独再做一个runbook流程，因为同一个runbook里面不能做两个监控list活动，这个runbook用于监控IT权限审计列表，监控过滤权限是否回收字段，匹配到需要回收，就把数据传给下一个活动执行脚本，当脚本执行成功后更新回收状态为已回收。
新建一个runbook，添加monitor list items活动，这次选择监控IT权限审计列表
设置Filters，仅收集和传递 权限是否回收 等于 需要回收 的数据
添加运行.NET脚本活动，将要 原本静态从中删除的组 替换成已发布数据 申请特权组 ，这个数值是审计列表而来，审计列表是权限已经赋予了才会生成，所以定不会有错
$session = New-PSSession -Computer PRIVDC
Invoke-Command -session $session -ScriptBlock {
Import-Module ActiveDirectory
$ConfirmPreference = 'none'
Remove-AdGroupMember "Domain Admins" -Members Jack
}
要移除的成员替换为 审计列表 权限申请人，也就是申请时填写的申请域账号，实际被加入到特权组的人。
如果脚本执行失败，不要忘记检查空格，还有-ScriptBlock最后结束的}不要丢失。
添加第三个活动，update list item，选择要更新的项目：权限回收状态，权限回收时间。
权限是否回收更新为已回收，回收时间可以从第二个活动运行.NET脚本，取活动结束时间，需要注意这个数值要勾选下方的显示常用已发布数据才可见。
ID需要从第一个活动中订阅，这是当时那条满足条件传递到第二活动的那条数据的ID。
三个功能到这里都已经设计完成，最后我们来一个整体功能的验证
Jack当前是一个临时为外包人员创建的账号，Jack需要拿着这个账户去给服务器做巡检，临时申请1小时的domain admins权限
Jack提交申请后，甲方管理stat审批，审批通过后流程审批状态更新为已通过，SCO捕捉到数据，传递到后面的活动执行
流程执行成功后，验证账户已经得到临时权限
同时账户的数据被写入到审计列表，权限是否回收为未回收，权限回收时间为空
外包人员通知甲方人员告知已经完成巡检，可以回收权限，甲方人员设置权限为需要回收即可
第二条Runbook流程捕捉到需要回收的数据传入，将监控到的数据传递给下一个脚本活动，脚本活动从AD组中移除用户
第三个活动更新权限是否回收状态为已回收，更新权限回收时间。
至此我们完整实现了所有规划的PAM门户功能，可以看到Sharepoint SCO PAM技术很好的工作在一起，三个组件相依相靠，实现最终可用的方案，在整个功能体系中，管理员需要时刻清楚，这个一个流程操作和下一个流程之间的关系，培养自己这种理解多个系统之间协作的能力，例如sharepoint输入的数据要被传到SCO，最终AD域执行，sharepoint列表如果更新栏名称，需要在SCO进行刷新，SCO要确保数据可以传递到AD正确执行。
通过sharepoint作为门户最大的好处是可以获得灵活，我们可以定制自己需要的栏信息，可以自定义sharepoint里面的工作流，不需要面对复杂的MIM门户部署，也不需要面对复杂的SCSM服务目录堆栈，只需要额外再维护一个SCO即可。通过Sharepoint+SCO+N，将可以实现很多场景的需求，因为SCO和sharepoint的对接好，流程不用太复杂就可以把数据传递到其它系统执行，强烈建议管理员们去了解sharepoint 了解sco，在自己的企业里面实现跨系统的自动化流程，展现自己的价值。
事实上PAM并不是只有微软提出的概念，这是一个安全业界里面公认的一个主要话题，企业在PAM进程里面，老王认为可以分为五个阶段
了解PAM概念，认识到重要性，认可要做PAM
在企业里面开始规划PAM，将技术与行政手段并行，如特权账号必须满足密码复杂度要求，建立管理员组成员登记表，特权账号在使用者离职后必须修改密码，特权账号必须和服务账户隔离，与外包人员签订项目时告知不得将临时账号用于应用系统账户，临时分配的管理账户将被禁用，要求外包人员规范化使用服务账户和管理账号，识别权限申请，针对于临时性权限，通过邮件等方式临时授予，到达期限必须删除。针对于应用系统尽量使用最小化权限。
了解PAM工具技术，如微软AD2016 JIT ，JEA等概念，开始对环境内先有管理员进行梳理，特权组只保留关键功能账号，密码高度安全，剩余个人管理账户疏解出特权组，开始通过powershell+人工操作授予试用。
落地PAM应用，使用sharepoint+sco，sco+scsm，mim2016等产品，构建权限申请，权限审计门户，对于特权权限使用，必须经过申请，必须通过审批，必须通过归档审计，必须可以操作回收，以此实现PAM的操作-审计模型，对于特权账户保护，如果采用MIM作为安全门户，可以设计在用户申请权限时通过Azure MFA验证才可以得到特权权限，如果使用sharepoint也可以设计在用户登录sharepoint时候通过Azure MFA或智能卡验证。针对于重要服务器，管理员工作站安装防病毒软件，防窃取软件。
管理与应用分离，彻底的将用户个人管理账户，从现有生产林中剥离出来，构建单独的堡垒林，用于存放管理账户，当需要执行特权访问的时候，再经过门户进行审批，依此降低生产林管理账户被破解，横向攻机的风险。
微软特权访问管理一文发出后，也有网友和老王讨论过，关于堡垒林在国内应用的问题，不可否认，这确实是一件大动干戈的事情，要把管理账户梳理出来，生产林不存在管理账户，这并不是一件容易的事情，一定要对每个系统做好排查，确认没有使用后再移除。但是到底值不值得就要企业结合自身需要的安全级别去做思考。
我和网友讨论了一个很有意思的例子，我们把当前单林单域应用和管理账户一体的架构称为全火影忍者架构，每个管理员都是火影忍者，那么恶意的管理员只要掌握一个忍者的特征就可以混进忍者高层，时效访问资格是针对于一些需要临时的任务，由下影经过上影批准后获得临时成为上影的权利，堡垒林的架构是，除了村长和几个必不可少的上影外，其它任何下影全部单独拿出去变为村民，平时和火影忍者没有任何往来，当需要执行任务的时候，临时申请变成忍者(加入安全主体)，任务结束的时候重新变成和和忍者没有任何关系的普通村民
不知道大家是否有理解，所谓的堡垒林架构，其实就是去压缩hacker的破解空间，原来你可以去扫描生产林里面100个管理员，现在我生产林里面就只有5个，而且都是高权限，开启了身份保护，当执行管理操作的时候呢，堡垒林的普通用户会申请加入已经创建好的安全主体，当完成管理操作的时候堡垒林用户又变成普通权限。将原来100个管理员，现在变成堡垒林的安全主体，需要的时候临时将堡垒林用户穿透过去执行，生产林是看不到这些堡垒林用户成员的，如果破解堡垒林用户也没有意义，因为堡垒林用户日常就是普通权限，而且不一定每次是由那个堡垒林用户来申请安全主体。
MS有时会说做到第五阶段才叫PAM，老王却以为未必要如此，企业要导入PAM，PAM的成功与否，还是看行政手段+技术手段最后是否有生效，内部管理人员有多大程度上遵循PAM的规则来完成特权账号的获取，申请，审批，使用，记录，操控，特权账户的生命周期有多大程度上是安全可控的。
针对于微软PAM的未来，老王希望，下一步微软能够控制拿到JIT时效资格的管理员只能在有限的服务器上执行管理操作，能够实现回收权限后自动关闭远程拨入和邮箱功能，减少自身MIM门户的部署复杂度，简化JEA的设置步骤允许配置文件实时更新。
文章最后作为彩蛋，我们将实战第五阶段堡垒林，生产林架构下如何利用Sharepoint+SCO，实现门户请求阴影主体角色。
要做阴影主体申请，我们需要变更Sharepoint的列表，把申请目标组变为目标主体角色，可以做成选项菜单，这里菜单的内容需要是已经在堡垒林里面创建好的阴影主体，这里我添加Domain admins，Enterprise admins，以及JEA定义的Automation admins角色。
修改IT权限申请列表如下
制作Runbook流程，第一个活动还是监控Sharepoint列表，监控流程审批为已通过的项目，通过databus传递给下一个活动
第二个活动也还是运行.NET脚本，复制这段脚本进去
$session = New-PSSession -Computer PRIVDC
Invoke-Command -session $session -ScriptBlock {
Import-Module ActiveDirectory
Set-ADObject -Identity "CN=ABC-Domain Admins,CN=Shadow Principal Configuration,CN=Services,CN=Configuration,DC=admin,DC=com" -Add @{'member'="<TTL=600,CN=Mike,OU=ITAccount,DC=admin,DC=com>"}
}
替换三个地方 1.CN=ABC-目标主体角色 2.TTL=申请时间秒 3.CN=堡垒林账户
相信看完整篇文章的朋友都应该知道老王这里在说什么，我就不再放出图片指示，要注意空格问题，以及最后}号问题。
堡垒林用户Mike登录堡垒林Sharepoint，提交目标主体权限申请
Stat审批通过后，Runbook捕捉数据，传递到下一个活动，脚本活动按照预先设置好的跨系统映射执行。
打开堡垒林阴影主体，可以看到，mike用户已经作为生产林domain admins阴影主体的成员，此时堡垒林用户mike通过阴影主体具备生产林domain admins组权限，可以登录到生产林服务器，但将在时效性到达后自动移出阴影主体成员，或做第二个runbook支持管理员门户操作移除权限。由此Sharepoint+SCO不仅可以实现本域内时效性组资格申请，也可以做堡垒林架构的跨林阴影主体申请。
