本文為機器翻譯文章。如需檢視英文版,請選取 [原文] 核取方塊。您也可以將滑鼠指標移到文字上,即可在快顯視窗顯示英文原文。
譯文
原文

Contoso Corporation 的身分識別

 

上次修改主題的時間:2017-09-12

摘要︰ 了解如何利用 IDaaS Contoso,並提供地理位置分散變得多餘的和驗證其使用者。

Microsoft 會提供跨及其雲端方案以服務 (IDaaS) 的身分識別。若要採用雲端 (含) 的基礎結構,Contoso 的 IDaaS 解決方案必須運用其內部部署身分識別提供者及包含使用其現有的受信任、 協力廠商身分識別提供者同盟的驗證。

Contoso 會使用單一 Windows Server Active Directory (AD) 樹系與另一個適用於每個地區的全球的七個網域 contoso.com。Headquarters、 區域 hub 辦公室和衛星辦公室包含本機驗證和授權的網域控制站。

圖 1: Contoso 的樹系及網域組成的全球

Contoso 的 Windows Server AD 樹系和世界各地的網域

圖 1 顯示與區域不同組件的全球包含區域的集線器網域 Contoso 樹系。

Contoso 想要使用的帳戶和群組 contoso.com 樹系中的工作負載其雲端應用程式的驗證與授權。

Contoso 可讓:

  • 客戶使用其 Microsoft、 Facebook 或 Google Mail 帳戶登入其公用網站。

  • 廠商與協力廠商使用其 LinkedIn、 Salesforce 或 Google Mail 帳戶登入網路之協力廠商。

圖 2: Contoso 的驗證支援的同盟的客戶與合作夥伴

Contoso 現有的基礎結構,用以支援客戶和合作夥伴同盟驗證

圖 2 顯示包含公用網站、 外部網路是合作夥伴與一組的 AD FS 伺服器 Contoso DMZ。DMZ 被連線至網際網路包含客戶和合作夥伴與網際網路服務。

中 DMZ active Directory Federation Services (AD FS) 伺服器進行驗證客戶認證以存取公用網站與協力廠商認證合作夥伴外部存取。

當 Contoso 轉換至 Azure Web 應用程式與合作夥伴外部 Dynamics 365 其公用網站時,他們想要繼續使用其客戶和合作夥伴這些協力廠商身分識別提供者。 這會藉由設定 Contoso Azure AD 租用戶與這些協力廠商身分識別提供者之間的同盟。

Contoso 已部署在其 Paris 資料中心伺服器的叢集上 「 Azure AD 連線工具。Azure AD 連線會變更為 contoso.com Windows Server AD 樹系同步處理與共用 Contoso 的 Office 365、 EMS、 動態 365 和 Azure 訂閱 Azure AD 租用。如需訂閱、 授權、 使用者帳戶及承租人的詳細資訊,請參閱 < 訂閱、 授權及使用者帳戶為 Contoso Corporation

圖 3: Contoso 的 directory 同步處理的基礎結構

Contoso 的目錄同步處理基礎結構

圖 3 是執行使用 Azure AD 租用戶同步處理 Contoso Windows Server AD 樹系的 Azure AD 連線的伺服器叢集。

Contoso 已設定的同盟的驗證,Contoso 的工作者提供單一登入。當已登入 contoso.com Windows Server AD 樹系的使用者存取 Microsoft SaaS 或 PaaS 雲端資源時,他們便不會提示密碼。

若要更妥善地支援其行動電話和遠端工作團隊,Contoso 已部署在其區域辦公室驗證伺服器的設定。此基礎結構的負載分散每個和存取 Microsoft cloud 方案使用一般的 Azure AD 租用戶的使用者認證進行驗證時提供備援和更高的效能。

若要將驗證要求的負載,Contoso 已設定 Azure 流量管理員具有設定檔使用路由方法,這是指地域最接近的一組驗證伺服器驗證的用戶端的效能。

圖 4: 地區分公司的驗證流量的地理位置分布

地區辦公室 Contoso 驗證流量的地理分配

圖 4 顯示區域辦公室的用戶端電腦、 Azure 流量管理員和驗證伺服器層級。每個區域的 office 會使用 web proxy 伺服器和 AD FS 伺服器來驗證使用者與 Windows Server AD 網域控制站的認證。

驗證程序範例:

  1. 用戶端電腦起始通訊網頁與 Office 365 租用中的歐洲 (例如 sharepoint.contoso.com)。

  2. Office 365 傳送回傳送概念的驗證要求。要求包含連絡人進行驗證的 URL。

  3. 用戶端電腦嘗試在 URL 中的 DNS 名稱解析為 IP 位址。

  4. Azure 流量管理員收到 DNS 查詢和回應在用戶端電腦最接近地區性 office web 應用程式 proxy 伺服器的 IP 位址與用戶端電腦。

  5. 用戶端電腦將驗證要求傳送至轉寄至 AD FS 伺服器要求的 web 應用程式 proxy 伺服器。

  6. AD FS 伺服器要求用戶端電腦的使用者認證。

  7. 用戶端電腦而不提示使用者傳送使用者認證。

  8. AD FS 伺服器會驗證認證地區 office 中的 Windows Server AD 網域控制站和用戶端電腦傳回安全性 token。

  9. 用戶端電腦將安全性權杖傳送至 Office 365。

  10. 成功驗證之後 Office 365 的安全性權杖快取及傳送要求用戶端電腦的步驟 1 中的網頁。

若要提供包含 15000 工作者 Paris headquarters 遠端和行動工作者備援,Contoso 已分別部署 application proxy 及 AD FS 伺服器中的 Azure IaaS 第二組。

圖 5: 在 Azure IaaS 的備援的驗證基礎結構

巴黎總部 Azure IaaS 中的備援驗證基礎結構

圖 5 顯示 web proxy 伺服器和 AD FS 伺服器 DMZ 以及跨部署 Azure 中的每個其他設定虛擬網路。

主要驗證伺服器中的 headquarters DMZ 變成無法使用,IT 人員切換部署在 Azure IaaS 備援集。後續的驗證要求從 Paris office 電腦會使用組中 Azure IaaS 直到更正可用性問題。

切換和回、 交換器 Contoso 更新要用於 web 應用程式 proxy 的一組不同的 IP 位址的 Paris 區域的 Azure 流量管理員設定檔:

  • DMZ 驗證伺服器可用、 DMZ 中使用之伺服器的 IP 位址。

  • 未提供 DMZ 驗證伺服器時,用於 Azure IaaS 伺服器的 IP 位址。

https://technet.microsoft.com/zh-tw/library/dn919927.aspx
顯示: