淺談微軟Office 365 DirSync與ADFS

提到Office 365就必須談論到DirSync及ADFS這兩個技術，這兩種技術都是用來做為地面端(On-Premise)及雲端之間同時存在(Coexistence共存)環境下的身份驗證機制，而大部份的人也都稱他們為Single Sign-On, SSO.

現階段的DirSync版本支援密碼同步技術，在DirSync的Hybrid模式(Rich Coexistence)的定義下：

• 雲端及地面端各有使用者帳號
• 所有雲端及地面端使用者都能檢視同一份GAL
• 可使用相同DNS Namespace做mail routing
• 同步運作為雙向機制

除非同步的是使用者帳號的屬性欄位內容，它們需要以排程來控制，預設為3小時；否則當使用者於變更密碼後同步時間間隔幾乎接近即時，因此它能讓地面端的Active Directory及雲端的Microsoft Azure Active Directory之間的使用者帳號都能同時擁有相同的密碼，在此前題下企業可以因此不需考慮部署AD FS只使用DirSync機制，而潛在的問題會是密碼必須要能無時無刻的被成功同步，且網路管理者需要管理2份密碼原則，一份在雲端一份在企業內部，而一旦企業內部AD架構失敗時，也意味著使用者將無法變更密碼，但使用者尚能使用Office 365在雲端執行身份驗證存取雲端資源，因為DirSync機制下的身份驗證行為於雲端O365執行，這或許可以算是一種優點，因為帳號密碼仍為相同。

其實從技術角度來看，DirSync尚不具備Single Sign-On的條件，充其量也只能稱為"Same Sign-On, SSO"而已。相反的，若是以AD FS做為Single Sign-On驗證機制，因為AD FS機制仍由地面端的AD FS架構來執行身份驗證行為，當AD FS架構出錯時使用者也將無法登入存取雲端資源，但這也極適合某些地面端企業有高度安全考量的運作模式，相對的剛剛所提及DirSync機制會造成網路管理者需要管理2份密碼原則的問題也不會存在，當完成AD FS部署後，所有密碼管理以及密碼原則將統一於地面端企業內部的AD DS當中被執行。

AD FS架構中間必須有一段彼此相互信任的設定，完成信任後的雲端O365被稱為Trust Issuer，地面端的AD FS伺服架構則稱之為Issuer，然而O365不只可以支援微軟自己的Issuer (AD FS)，同時也可以支援如Shibboleth或其它3rd Party Identity Provider所提供的Security Token Service, STS 元件來完成驗證服務，運作流程如下圖說明：

• 左方Notebook (ADFS Client)以Browser連入https://Portal.office.com官方O365入口網頁，對O365提出身份驗證要求。
• 若O365已經與地面端企業AD FS完成信任設定，O365將會重新導向到下方企業所部署的AD FS伺服器，以表單驗證方式輸入使用者帳號及密碼。
• 當AD FS接收帳號驗證需求後，即與內部AD DS完成身份驗證程序。
• 完成驗證後，內部DC通知AD FS驗證成功。
• 由AD FS產生STS(Token)元件並發行給受信任的O365服務，這個Token是該使用者驗證後的宣告(Claim)，裡面包含使用者名稱、群組成員隷屬、UPN、電子郵件、電話等其它欄位屬性值，至於雲端服務會使用哪些欄位，這是由Consuming application (Consuming application = Office 365) 決定的。

當AD FS和DirSync同時被啟用後，通常一個使用者同時擁有兩個帳號各別存在on-premise 的AD DS以及雲端Azure AD之間，但使用者仍不使用on-premise帳號，而是經由AD FS所提供的STS裡的Claim提供驗證。

在部署上，AD FS及DirSync的選擇沒有唯一，更多的企業選擇採雙管齊下的作法，細節無法一一說明，如果需要更多的DirSync及AD FS與雲端的技術訊息或實作，請參考恆逸獨家Office 365官方雲端課程（20346）。

您可在下列課程中了解更多技巧喔！

相關學習資源

【20346/20347】管理Office 365身份驗證及服務