共计 11450 个字符，预计需要花费 29 分钟才能阅读完成。
这篇文章主要介绍如何使用 Sharepoint+SCO 实现 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 的桥梁。
签入签出：当我们新建一个 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 进程里面，老王认为可以分为五个阶段
了解 PAM 概念，认识到重要性，认可要做 PAM
在企业里面开始规划 PAM，将技术与行政手段并行，如特权账号必须满足密码复杂度要求，建立管理员组成员登记表，特权账号在使用者离职后必须修改密码，特权账号必须和服务账户隔离，与外包人员签订项目时告知不得将临时账号用于应用系统账户，临时分配的管理账户将被禁用，要求外包人员规范化使用服务账户和管理账号，识别权限申请，针对于临时性权限，通过邮件等方式临时授予，到达期限必须删除。针对于应用系统尽量使用最小化权限。
了解 PAM 工具技术，如微软 AD2016 JIT，JEA 等概念，开始对环境内先有管理员进行梳理，特权组只保留关键功能账号，密码高度安全，剩余个人管理账户疏解出特权组，开始通过 powershell+ 人工操作授予试用。
落地 PAM 应用，使用 sharepoint+sco 或 sco+scsm 或 mim2016 或自开发 Web 系统构建权限申请，权限审计门户，对于特权权限使用，必须经过申请，必须通过审批，必须通过归档审计，必须可以操作回收，以此实现 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 不仅可以实现本域内时效性组资格申请，也可以做堡垒林架构的跨林阴影主体申请。
以上是“如何使用 Sharepoint+SCO 实现 PAM 门户”这篇文章的所有内容，感谢各位的阅读！希望分享的内容对大家有帮助，更多相关知识，欢迎关注丸趣 TV 行业资讯频道！
