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不只能夠實現本域內時效性組資格申請，也能夠作堡壘林架構的跨林陰影主體申請。