Sharepoint+SCO实现PAM门户

上一篇微软特权访问管理，咱们讲到了PAM产生的时代背景，PAM的概念，JIT，JEA，安全主体，MIM等落地工具，PAM与Azure PIM的区别，PAM在微软2016安全体系的做用，而且经过最原始的Powershell命令验证明现了JIT 安全主体构建的PAM操做过程模型，感兴趣你们能够去回看或进一步查阅资料。

可是在实际企业应用来讲，企业但愿的不只仅是经过人为审批+人工操做Powershell，最好是有一个门户，用户能够在上面去申请权限，经过在线工做流进行审批，底层是PAM技术工具的支撑，这样更加贴近实际环境，也便于检阅，本篇进阶文章咱们就把PAM的操做部分与报告部分作成门户，实现三个功能

1. 用户在门户申请时效性权限，管理员审批经过，自动加入到本域安全组或安全主体 

2. 申请成功后自动把用户的申请以及审批信息归档作成报告 。

3. 支持在门户上对用户申请记录进行权限回收，变动回收字段，后台自动回收安全组或安全主体权限。

对于微软的产品体系而言，要对接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套件里面的自动化产品，主要功能

1. 支撑微软私有云自助化实现，对接SCSM和底层VMM，将用户的SCSM自助申请，传递到VMM建立生效，

2. 支持混合云场景，支持和Azure IAAS 整合资源申请，和Azure SMA整合混合自动化呼叫。
   

3. 协调数据中心内，系统上不一样组件，或不一样系统之间的自动化协做。

4. 管理员能够经过拖拽的方式设计自动化协做流程，下降自动化门槛。

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的桥梁。

签入签出：当咱们新建一个runbook时，默认它会处于签出状态，当通过runbook tester测试以后，咱们将runbook签入，而后才能够运行runbook，让runbook生效，一条正在运行的runbook是不能被直接修改的，须要中止runbook，将runbook签出，修改完成后再将runbook签入，修改的内容才会生效。

对于本次流程而言，最重要的是要理解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进程里面，老王认为能够分为五个阶段

1. 了解PAM概念，认识到重要性，承认要作PAM
   

2. 在企业里面开始规划PAM，将技术与行政手段并行，如特权帐号必须知足密码复杂度要求，创建管理员组成员登记表，特权帐号在使用者离职后必须修改密码，特权帐号必须和服务帐户隔离，与外包人员签定项目时告知不得将临时帐号用于应用系统帐户，临时分配的管理帐户将被禁用，要求外包人员规范化使用服务帐户和管理帐号，识别权限申请，针对于临时性权限，经过邮件等方式临时授予，到达期限必须删除。针对于应用系统尽可能使用最小化权限。

3. 了解PAM工具技术，如微软AD2016 JIT ，JEA等概念，开始对环境内先有管理员进行梳理，特权组只保留关键功能帐号，密码高度安全，剩余我的管理帐户疏解出特权组，开始经过powershell+人工操做授予试用。

4. 落地PAM应用，使用sharepoint+sco或sco+scsm或mim2016或自开发Web系统构建权限申请，权限审计门户，对于特权权限使用，必须通过申请，必须经过审批，必须经过归档审计，必须能够操做回收，以此实现PAM的操做-审计模型，对于特权帐户保护，若是采用MIM做为安全门户，能够设计在用户申请权限时经过Azure MFA验证才能够获得特权权限，若是使用sharepoint也能够设计在用户登陆sharepoint时候经过Azure MFA或智能卡验证。针对于重要服务器，管理员工做站安装防病毒软件，防窃取软件。

5. 管理与应用分离，完全的将用户我的管理帐户，从现有生产林中剥离出来，构建单独的堡垒林，用于存放管理帐户，当须要执行特权访问的时候，再通过门户进行审批，依此下降生产林管理帐户被破解，横向攻机的风险。

微软特权访问管理一文发出后，也有网友和老王讨论过，关于堡垒林在国内应用的问题，不能否认，这确实是一件大动干戈的事情，要把管理帐户梳理出来，生产林不存在管理帐户，这并非一件容易的事情，必定要对每一个系统作好排查，确认没有使用后再移除。可是到底值不值得就要企业结合自身须要的安全级别去作思考。

我和网友讨论了一个颇有意思的例子，咱们把当前单林单域应用和管理帐户一体的架构称为全火影忍者架构，每一个管理员都是火影忍者，那么恶意的管理员只要掌握一个忍者的特征就能够混进忍者高层，时效访问资格是针对于一些须要临时的任务，由下影通过上影批准后得到临时成为上影的权利，堡垒林的架构是，除了村长和几个必不可少的上影外，其它任何下影所有单独拿出去变为村民，平时和火影忍者没有任何往来，当须要执行任务的时候，临时申请变成忍者(加入安全主体)，任务结束的时候从新变成和和忍者没有任何关系的普通村民

不知道你们是否有理解，所谓的堡垒林架构，其实就是去压缩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不只能够实现本域内时效性组资格申请，也能够作堡垒林架构的跨林阴影主体申请。