如何使用Sharepoint+SCO實現PAM門戶

這篇文章主要介紹如何使用Sharepoint+SCO實現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不僅可以實現本域內時效性組資格申請，也可以做堡壘林架構的跨林陰影主體申請。

以上是“如何使用Sharepoint+SCO實現PAM門戶”這篇文章的所有內容，感謝各位的閱讀！希望分享的內容對大家有幫助，更多相關知識，歡迎關注億速云行業資訊頻道！