將應用程式驗證移至 Azure Active Directory
Azure Active Directory (Azure AD) 提供通用身分識別平台，可讓您的員工、合作夥伴和客戶取得單一身分識別來存取應用程式，並且可以從任何平台和裝置共同作業。 Azure AD 有一套完整的身分識別管理功能。 將您的應用程式驗證和授權導入 Azure AD 中，可提供下列優點：
提示
本文是針對開發人員物件撰寫的。 規劃將應用程式移至 Azure AD 的 Project 管理員和系統管理員，應考慮閱讀將應用程式驗證遷移至 Azure AD。
Azure AD 的優點
如果您有包含使用者帳戶的內部部署目錄，您可能有許多應用程式需要使用者驗證。 每個應用程式都設定為讓使用者使用其身分識別進行存取。
使用者也可以直接使用內部部署 Active Directory 進行驗證。 Active Directory 同盟服務 (AD FS) 是以標準為基礎的內部部署身分識別服務。 其擴充了在信任的商業夥伴之間使用單一登入 (SSO) 功能，讓使用者不需要分別登入每個應用程式。 這稱為同盟身分識別。
許多組織都有軟體即服務 (SaaS) 或直接與 AD FS 同盟的自訂企業營運應用程式，以及 Microsoft 365 和 Azure AD 架構的應用程式。
重要
為了提高應用程式安全性，您的目標是在內部部署和雲端環境之間擁有一組存取控制和原則。
移轉的應用程式類型
將您所有應用程式驗證移轉至 Azure AD 是最理想的做法，它提供您單一控制平面來進行身分識別和存取管理。
您的應用程式可使用新式或舊版通訊協定進行驗證。 當您規劃遷移至 Azure AD 時，請考慮先遷移使用新式驗證通訊協定的應用程式 (例如 SAML 和 Open ID 連線)。 重新設定這些應用程式，以透過 Azure App 資源庫中的內建連接器，或藉由在 Azure AD 中註冊應用程式，使用 Azure AD 進行驗證。 使用舊版通訊協定的應用程式可以使用應用程式 Proxy 來整合。
如需詳細資訊，請參閱
- 使用 Azure AD 應用程式 Proxy 來為遠端使用者發佈內部部署應用程式。
- 什麼是應用程式管理？
- 將應用程式遷移至 Azure AD 的 AD FS 應用程式活動報告
- 使用 Azure AD Connect Health 監視 AD FS。
NPS 移轉流程
在將您的應用程式驗證移至 Azure AD 的過程中，測試您的應用程式和設定。 移至生產環境時，建議您繼續使用現有的測試環境進行遷移測試。 如果目前無法使用測試環境，您可以根據應用程式的架構，使用 Azure App Service 或 Azure 虛擬機器設定一個。
您可以選擇設定個別的測試 Azure AD 租用戶，以在開發應用程式組態時使用。
您的遷移流程可能如下所示：
階段 1–目前狀態：生產環境應用程式會使用 AD FS 進行驗證
階段 2– (選擇性) 將應用程式的測試執行個體指向測試 Azure AD 租用戶
更新設定，以將應用程式的測試執行個體指向測試 Azure AD 租用戶，並進行任何必要的變更。 您可以使用測試 Azure AD 租用戶中的使用者測試應用程式。 在開發過程中，您可以使用 Fiddler 之類的工具來比較並驗證要求和回應。
如果您無法設定個別的測試租用戶，請略過此階段，並將應用程式的測試執行個體指向您的生產環境 Azure AD 租用戶，如下面的階段 3 所述。
第 3 階段 – 將應用程式的測試執行個體指向生產環境 Azure AD 租用戶
更新設定，以將應用程式的測試執行個體指向生產環境 Azure AD 租用戶。 您現在可以使用生產環境租用戶中的使用者進行測試。 如有必要，請參閱本文中有關轉換使用者的章節。
階段 4 – 將生產環境應用程式指向生產環境 Azure AD 租用戶
更新生產環境應用程式的設定，以指向您的生產環境 Azure AD 租用戶。
使用 AD FS 進行驗證的應用程式可以使用 Active Directory 群組來取得權限。 在開始進行遷移之前，請使用 Azure AD 連線同步處理，在內部部署環境和 Azure AD 之間同步處理身分識別資料。 在遷移之前，請務必先驗證這些群組和成員資格，讓您可以在應用程式遷移時授與相同使用者的存取權。
企業營運應用程式
您的企業營運應用程式是您的組織所開發的應用程式，或屬於標準封裝產品的應用程式。 範例包括以 Windows Identity Foundation 和 SharePoint 應用程式為基礎的應用程式 (並非 SharePoint Online)。
使用 OAuth 2.0、OpenID Connect 或 WS-同盟的企業營運應用程式，可與 Azure AD 整合為應用程式註冊。 在Azure 入口網站的 [企業應用程式] 頁面上，將使用 SAML 2.0 或 WS-同盟 的自訂應用程式整合為非資源庫應用程式。
SAML 型單一登入
使用 SAML 2.0 進行驗證的應用程式可以設定為 (SSO) 的 SAML 型單一登入。 使用 SAML SSO 時，您可以根據在 SAML 宣告中定義的規則，將使用者對應至特定的應用程式角色。
若要設定 SAML 型 SSO 的 SaaS 應用程式，請參閱 快速入門：設定 SAML 型單一登入。
許多 SaaS 應用程式都有一個 應用程式特定的教學課程，可逐步引導您完成 SAML 型 SSO 的設定。
某些應用程式可以輕鬆地遷移。 具有更複雜需求 (例如自訂宣告) 的應用程式則可能需要在 Azure AD 及/或 Azure AD Connect 中額外進行設定。 如需支援的宣告對應相關資訊，請參閱如何自訂租用戶中特定應用程式的權杖所發出的宣告 (預覽)。
對應屬性時請記住下列限制：
- 並非所有可在 AD FS 中發出的屬性都會在 Azure AD 中顯示為要發出至 SAML 權杖的屬性，即使這些屬性已同步。 當您編輯屬性時，值下拉式清單會顯示 Azure AD 中可用的不同屬性。 檢查 Azure AD Connect 同步設定主題設定，以確保必要屬性 (例如 samAccountName) 會同步處理至 Azure AD。 您可以使用擴充屬性來發出 Azure AD 中不屬於標準使用者架構的任何宣告。
- 在大多數的常見情況下，應用程式只需要 NameID 宣告和其他常見的使用者識別碼宣告。 若要判斷是否需要任何其他宣告，請檢查您正從 AD FS 發出哪些宣告。
- 並非所有宣告都可以發出，因為某些宣告在 Azure AD 中受到保護。
- 使用加密 SAML 權杖的功能現已進入預覽階段。 請參閱做法：針對企業應用程式自訂 SAML 權杖中發出的宣告。
軟體即服務 (SaaS) 應用程式
如果您的使用者登入 SaaS 應用程式 (例如 Salesforce、ServiceNow 或 Workday)，並與 AD FS 整合，則您會使用 SaaS 應用程式的同盟登入。
大部分的 SaaS 應用程式都可以在 Azure AD 中設定。 Microsoft 在 Azure AD 應用程式資源庫中有許多 SaaS 應用程式預先設定的連線，讓您能更輕鬆的轉換。 SAML 2.0 應用程式可以透過 Azure AD 應用程式資源庫來與 Azure AD 整合，或整合為非資源庫應用程式。
使用 OAuth 2.0 或 OpenID Connect 的應用程式可與 Azure AD 整合 (類似於「應用程式註冊」)。 使用舊版通訊協定的應用程式可以使用Azure AD 應用程式 Proxy來向 Azure AD 進行驗證。
針對將 SaaS 應用程式上架的任何問題，您可以聯絡 Saas 應用程式整合支援別名。
適用於 SSO 的 SAML 簽署憑證
簽署憑證是所有 SSO 部署的重要部分。 Azure AD 會建立簽署憑證，以針對您的 SaaS 應用程式建立以 SAML 為基礎的同盟 SSO。 新增資源庫或非資源庫應用程式之後，您將使用同盟 SSO 選項設定新增的應用程式。 請參閱在 Azure Active Directory 中管理同盟單一登入的憑證。
SAML 權杖加密
AD FS 和 Azure AD 都提供權杖加密，也就是加密進入應用程式之 SAML 安全性判斷提示的能力。 判斷提示會使用公開金鑰進行加密，並由具有相符私密金鑰的接收應用程式解密。 設定權杖加密時，您要上傳 x.509 憑證檔案以提供公開金鑰。
如需 Azure AD SAML 權杖加密及如何進行設定的詳細資訊，請參閱如何：設定 Azure AD saml 權杖加密。
注意
權杖加密是 Azure Active Directory (Azure AD) 的高級功能。 若要深入了解 Azure AD 版本、功能及定價，請參閱 Azure AD 定價。
可以立即移動的應用程式和設定
您目前可以輕鬆移動的應用程式包括使用一組標準設定元素和宣告的 SAML 2.0 應用程式。 這些標準項目如下：
- 使用者主體名稱
- 電子郵件地址
- 指定的名稱
- Surname
- 作為 SAML NameID 的替代屬性，包括 Azure AD 郵件屬性、郵件前置詞、員工識別碼、擴充屬性 1-15 或內部部署 SamAccountName 屬性。 如需詳細資訊，請參閱編輯 NameIdentifier 宣告。
- 自訂宣告。
以下項目需要額外的設定步驟，才能遷移至 Azure AD：
- AD FS 中的自訂授權或多重要素驗證 (MFA) 規則。 您可以使用 Azure AD 條件式存取功能來設定這些規則。
- 具有多個回覆 URL 端點的應用程式。 您可以使用 PowerShell 或 Azure 入口網站介面，在 Azure AD 中進行設定。
- WS-同盟應用程式，例如需要 SAML 1.1 版權杖的 SharePoint 應用程式。 您可以使用 PowerShell 以手動方式設定這些應用程式。 您也可以從資源庫新增 SharePoint 和 SAML 1.1 應用程式的預先整合一般範本。 我們支援 SAML 2.0 通訊協定。
- 複雜宣告發行轉換規則。 如需支援的宣告對應相關資訊，請參閱：
Azure AD 目前不支援的應用程式和設定
目前無法遷移需要某些功能的應用程式。
通訊協定功能
目前無法移轉需要下列功能的應用程式：
支援 WS-Trust ActAs 模式
SAML 成品解析
已簽署之 SAML 要求的簽章驗證
注意
已簽署的要求已被接受，但未驗證簽章。
假設 Azure AD 只會將權杖傳回給應用程式中預先設定的端點，在大部分情況下，可能不需要簽章驗證。
權杖中的宣告功能
目前無法移轉需要在下列權杖功能中宣告的應用程式：
- 從 Azure AD 目錄以外的屬性存放區宣告，除非該資料已同步處理到 Azure AD。 如需詳細資訊，請參閱 Azure AD 同步處理 API 概觀。
- 發行目錄多重值屬性。 例如，我們目前無法為 Proxy 位址發出多重值宣告。
將應用程式設定從 AD FS 對應到 Azure AD
移轉需要評估應用程式在內部部署環境中的設定方式，然後將該設定對應至 Azure AD。 AD FS 與 Azure AD 的運作方式相似，所以設定信任、登入及登出 URL 和識別碼的概念適用於兩者。 記錄應用程式的 AD FS 設定，讓您可以在 Azure AD 中輕鬆進行設定。
對應應用程式的組態設定
下表說明 AD FS 信賴憑證者信任與 Azure AD Enterprise 應用程式之間的一些最常見設定對應：
- AD FS-尋找應用程式 AD FS 信賴憑證者信任中的設定。 以滑鼠右鍵按一下信賴憑證者，然後選取 [屬性]。
- Azure AD - 設定是在每個應用程式的 SSO 屬性 Azure 入口網站內進行設定。
| 組態設定 | AD FS | 在 Azure AD 中設定的方式 | SAML 權杖 |
|---|---|---|---|
| 應用程式登入 URL 在服務提供者所起始的 SAML 流程中，使用者用來登入應用程式的 URL (SP)。 |
N/A | 從 SAML 型登入開啟基本 SAML 設定 | N/A |
| 應用程式回覆 URL 以識別提供者 (IdP) 觀點看待的應用程式 URL。 IdP 會在使用者登入 IdP 之後，將使用者和權杖傳送到此處。 這也稱為 SAML 判斷提示取用者端點。 |
選取 [端點] 索引標籤 | 從 SAML 型登入開啟基本 SAML 設定 | SAML 權杖中的 [目的地] 元素。 值範例： https://contoso.my.salesforce.com |
| 應用程式登出 URL 這是使用者登出應用程式時，要將登出清除要求傳送至其中的 URL。 IdP 會傳送要求，以將使用者從其他所有應用程式登出。 |
選取 [端點] 索引標籤 | 從 SAML 型登入開啟基本 SAML 設定 | N/A |
| 應用程式識別碼 這是來自 IdP 觀點的應用程式識別碼。 登入 URL 值經常用於此識別碼 (但並不一定)。 有時候，應用程式會將此稱為「實體識別碼」。 |
按一下 [識別碼] 索引標籤 | 從 SAML 型登入開啟基本 SAML 設定 | 對應到 SAML 權杖中的 [對象] 元素。 |
| 應用程式同盟中繼資料 這是應用程式的同盟中繼資料位置。 IdP 會使用此位置來自動更新特定組態設定，例如端點或加密憑證。 |
選取 [監控] 索引標籤 | N/A。 Azure AD 不支援直接取用應用程式同盟中繼資料。 您可以手動匯入同盟中繼資料。 | N/A |
| 使用者識別碼/名稱識別碼 此屬性用來唯一表示由 Azure AD 或 AD FS 提供給應用程式的使用者識別。 此屬性通常是 UPN 或使用者的電子郵件地址。 |
宣告規則。 在大部分情況下，宣告規則所發出的宣告會具有以 nameidentifier 結尾的類型。 | 您可以在標頭使用者屬性和宣告下找到識別碼。 預設會使用 UPN | 地圖至 SAML 權杖中的 NameID 元素。 |
| 其他宣告 通常會從 IdP 傳送至應用程式的其他宣告資訊範例包括名字、姓氏、電子郵件地址和群組成員資格。 |
在 AD FS 中，您可以在信賴憑證者上的其他宣告規則中找到此項目。 | 您可以在標頭使用者屬性&宣告下找到識別碼。 選取 [檢視] 並編輯所有其他使用者屬性。 | N/A |
對應識別提供者 (IdP) 設定
設定您的應用程式，使其指向 SSO 的 Azure AD 與 AD FS。 在這裡，我們將著重於使用 SAML 通訊協定的 SaaS 應用程式。 不過，此概念也會延伸至自訂的企業營運應用程式。
注意
Azure AD 的設定值會遵循您的 Azure 租使用者識別碼取代 {tenant-id} 的模式，而應用程式識別碼會取代 {application-id}。 您可以在 Azure Active Directory 和屬性下的 Azure 入口網站中找到這項資訊：
- 選取 [目錄識別碼] 以查看您的租用戶識別碼。
- 選取 [應用程式識別碼] 以查看您的應用程式識別碼。
在高階中，將下列重要的 SaaS 應用程式設定元素對應至 Azure AD。
| 元素 | 設定值 |
|---|---|
| 識別提供者簽發者 | https://sts.windows.net/{tenant-id}/ |
| 識別提供者登入 URL | https://login.microsoftonline.com/{tenant-id}/saml2 |
| 識別提供者登出 URL | https://login.microsoftonline.com/{tenant-id}/saml2 |
| 同盟中繼資料位置 | https://login.windows.net/{tenant-id}/federationmetadata/2007-06/federationmetadata.xml?appid={application-id} |
針對 SaaS 應用程式對應 SSO 設定
SaaS 應用程式必須知道傳送驗證要求的位置，以及如何驗證所收到的權杖。 下表說明在應用程式中進行 SSO 設定時所需的元素，以及其在 AD FS 和 Azure AD 中的值或位置。
| 組態設定 | AD FS | 在 Azure AD 中設定的方式 |
|---|---|---|
| IdP 登入 URL 以應用程式觀點看待的 IdP 登入 URL (使用者會被重新導向以便登入)。 |
AD FS 登入 URL 為 AD FS 同盟服務名稱後面加上 "/adfs/ls/"。 例如： |
將 {tenant-id} 取代為您的租用戶識別碼。 針對使用 SAML-P 通訊協定的應用程式：https://login.microsoftonline.com/{tenant-id}/saml2 針對使用 WS-Federation 通訊協定的應用程式：https://login.microsoftonline.com/{tenant-id}/wsfed |
| IdP 登出 URL 以應用程式觀點看待的 IdP 登出 URL (使用者選擇登出應用程式時會被重新導向)。 |
登出 URL 與登入 URL 相同，或是附加 "wa=wsignout1.0" 的相同 URL。 例如：https://fs.contoso.com/adfs/ls/?wa=wsignout1.0 |
將 {tenant-id} 取代為您的租用戶識別碼。 針對使用 SAML-P 通訊協定的應用程式： https://login.microsoftonline.com/{tenant-id}/saml2 針對使用 WS-Federation 通訊協定的應用程式：https://login.microsoftonline.com/common/wsfederation?wa=wsignout1.0 |
| 權杖簽署憑證 IdP 會使用憑證的私密金鑰來簽署已發行的權杖。 它會驗證權杖是否來自應用程式設定要信任的相同 IdP。 |
在 AD FS 管理的 [憑證] 之下可找到 AD FS 權杖簽署憑證。 | 在應用程式的 [單一登入] 屬性的標頭 SAML 簽署憑證底下的 Azure 入口網站中找到。 您可以在該處下載憑證以便上傳至應用程式。 如果應用程式有多個憑證，您可以在同盟中繼資料 XML 檔案中找到所有的憑證。 |
| 識別碼/「簽發者」 以應用程式觀點看待的 IdP 識別碼 (有時稱為「簽發者識別碼」)。 在 SAML 權杖中，此值會顯示為 [簽發者] 元素。 |
AD FS 的識別碼通常是 AD FS 管理中 [服務]> [編輯同盟服務屬性] 之下的同盟服務識別碼。 例如：http://fs.contoso.com/adfs/services/trust |
將 {tenant-id} 取代為您的租用戶識別碼。 https://sts.windows.net/{tenant-id}/ |
| IdP 同盟中繼資料 IdP 的公開可用同盟中繼資料位置。 (有些應用程式會使用同盟中繼資料，作為系統管理員個別設定 URL、識別碼和權杖簽署憑證的替代方式)。 |
在 AD FS 管理的服務>端點>中繼資料>類型：同盟中繼資料下尋找 AD FS 同盟中繼資料 URL。 例如：https://fs.contoso.com/FederationMetadata/2007-06/FederationMetadata.xml |
Azure AD 的對應值會遵循此模式 https://login.microsoftonline.com/{TenantDomainName}/FederationMetadata/2007-06/FederationMetadata.xml。 {TenantDomainName} 的值會取代為您的租用戶名稱，格式為 "contoso.onmicrosoft.com." 如需詳細資訊，請參閱同盟中繼資料。 |
代表 Azure AD 中 AD FS 安全性原則
將您的應用程式驗證移至 Azure AD 時，請從現有的安全性原則建立對應到 Azure AD 中可用的相等或替代變數。 確保這些對應可以完成，同時符合您的應用程式擁有者所需的安全性標準，讓其餘的應用程式遷移作業變得更容易。
在每個規則範例中，我們會顯示規則在 AD FS 中的外觀、AD FS 規則語言對等程式碼，以及這如何對應至 Azure AD。
對應授權規則
以下是 AD FS 中各種授權規則類型的範例，以及如何將其對應至 Azure AD。
範例 1：允許存取所有使用者
允許存取 AD FS 中的所有使用者：
![螢幕擷取畫面：[使用 SAML 設定單一登入] 對話方塊。](media/migrate-adfs-apps-to-azure/permit-access-to-all-users-1.png)
這會以下列其中一種方式對應至 Azure AD：
將 [需要使用者指派] 設定為 [否]。
注意
將 使用者指派 設定為 [是] 需要將使用者指派給應用程式才能取得存取權。 當設定為 [否] 時，所有使用者都有存取權。 此參數不會控制使用者在我的應用程式體驗中看到的內容。
在 [使用者和群組]索引標籤中，將您的應用程式指派給所有使用者自動群組。 您必須在 Azure AD 租使用者中啟用動態群組，才能使用預設的 [所有使用者] 群組。
範例 2：明確允許群組
AD FS 中的明確群組授權：
![螢幕擷取畫面：[允許網域管理員宣告規則] 的 [編輯規則] 對話方塊。](media/migrate-adfs-apps-to-azure/allow-a-group-explicitly-1.png)
若要將此規則對應至 Azure AD：
在 Azure 入口網站中，建立對應至 AD FS 使用者群組的使用者群組。
將應用程式權限指派給群組：
範例 3：授權特定使用者
AD FS 中的明確使用者授權：
![螢幕擷取畫面：[允許具有主要 S D 傳入宣告類型的特定使用者宣告規則] 的 [編輯規則] 對話方塊。](media/migrate-adfs-apps-to-azure/authorize-a-specific-user-1.png)
若要將此規則對應至 Azure AD：
在 Azure 入口網站中，透過應用程式的 [新增指派] 索引標籤，將使用者新增至應用程式，如下所示：
對應多重要素驗證規則
Multi-Factor Authentication (MFA) 的內部部署和 AD FS 在遷移之後仍可運作，因為您已與 AD FS 同盟。 不過，請考慮遷移至 Azure 的內建 MFA 功能，這些功能繫結至 Azure AD 的條件式存取工作流程。
以下是 AD FS 中的 MFA 規則類型範例，以及如何根據不同條件將其對應至 Azure AD。
AD FS 中的 MFA 規則設定：
範例 1：根據使用者/群組強制執行 MFA
使用者/群組選取器是一項規則，可讓您在每個群組的 (群組 SID) 或個別使用者 (主要 SID) 基礎上強制執行 MFA。 除了使用者/群組指派以外，AD FS MFA 設定 UI 中的所有其他核取方塊，都是在強制執行使用者/群組規則之後評估的額外規則。
在 Azure AD 中指定使用者或群組的 MFA 規則：
建立新的條件式存取原則。
選取 [指派] 。 新增您想要強制執行 MFA 的使用者或群組。
設定存取控制選項，如下所示：
![螢幕擷取畫面：您可以授與存取權的 [授與] 窗格。](media/migrate-adfs-apps-to-azure/mfa-users-groups.png)
範例 2：針對未註冊的裝置強制執行 MFA
在 Azure AD 中指定未註冊裝置的 MFA 規則：
建立新的條件式存取原則。
將指派設定為 [所有使用者]。
設定存取控制選項，如下所示：
![螢幕擷取畫面：[授與] 窗格，您可以在其中授與存取權並指定其他限制。](media/migrate-adfs-apps-to-azure/mfa-unregistered-devices.png)
當您將 [針對多個控制項] 選項設定為需要選取其中一個控制項時，就表示如果使用者符合核取方塊所指定的任何一個條件，就會授與使用者應用程式的存取權。
範例 3：根據位置強制執行 MFA
根據使用者在 Azure AD 中的位置指定 MFA 規則：
建立新的條件式存取原則。
將指派設定為 [所有使用者]。
在 Azure 中設定具名位置。 否則，來自公司網路內部的同盟是受信任的。
設定條件規則，以指定您想要強制執行 MFA 的位置。
![螢幕擷取畫面：[條件] 規則的 [位置] 窗格。](media/migrate-adfs-apps-to-azure/mfa-location-1.png)
設定存取控制選項，如下所示：
對應發出屬性作為宣告規則
將屬性發出為 AD FS 中的宣告規則：
![螢幕擷取畫面：[將屬性發出為宣告] 的 [編輯規則] 對話方塊。](media/migrate-adfs-apps-to-azure/map-emit-attributes-as-claims-rule-1.png)
若要將規則對應至 Azure AD：
在 Azure 入口網站中，選取 [Enterprise 應用程式]，然後按一下 [單一登入] 以查看 SAML 型登入設定：
![螢幕擷取畫面：企業應用程式的 [單一登入] 頁面。](media/migrate-adfs-apps-to-azure/map-emit-attributes-as-claims-rule-2.png)
選取 [編輯] (反白顯示) 修改屬性：
對應內建存取控制原則
AD FS 2016 中的內建存取控制原則：
若要在 Azure AD 中執行內建原則，請使用新的條件式存取原則並設定存取控制，或使用 AD FS 2016 中的自訂原則設計工具來設定存取控制原則。 「規則編輯器」有一份完整的「允許」和「例外」選項，可協助您排列所有種類。
在此表中，我們列出了一些實用的「允許」和「例外」選項，以及如何對應至 Azure AD。
| 選項 | 如何在 Azure AD 中設定允許選項？ | 如何在 Azure AD 中設定例外選項？ |
|---|---|---|
| 從特定網路 | 對應至 Azure AD 中的命名位置 | 針對信任的位置使用 [排除] 選項 |
| 從特定群組 | 設定使用者/群組指派 | 在使用者和群組中使用 [排除] 選項 |
| 從具有特定信任層級的裝置 | 從裝置狀態控制項的 [指派- > 條件] 底下進行設定 | 使用 [裝置狀態條件] 下的 [排除] 選項，並包含 所有裝置 |
| 使用要求中的特定宣告 | 此設定無法移轉 | 此設定無法移轉 |
以下範例說明如何在 Azure 入口網站中設定受信任位置的 [排除] 選項：
將使用者從 AD FS 轉換為 Azure AD
同步 Azure AD 中的 AD FS 群組
當您對應授權規則時，使用 AD FS 進行驗證的應用程式可能會使用 Active Directory 群組來取得權限。 在這種情況下，請使用 Azure AD Connect 在遷移應用程式之前，將這些群組與 Azure AD 同步。 在遷移之前，請務必先驗證這些群組和成員資格，讓您可以在應用程式遷移時授與相同使用者的存取權。
如需詳細資訊，請參閱使用從 Active Directory 同步的群組屬性的必要條件。
設定使用者自我佈建
某些 SaaS 應用程式支援在使用者第一次登入應用程式時自行佈建使用者的能力。 在 Azure AD 中，應用程式佈建指的是在雲端中自動建立使用者身分識別和角色 (SaaS) 使用者需要存取的應用程式。 已遷移的使用者在 SaaS 應用程式中已經有一個帳戶。 必須佈建在遷移後新增的任何新使用者。 在應用程式遷移之後，測試 SaaS 應用 程式佈建。
同步處理 Azure AD 中的外部使用者
您可以透過下列兩種方式，在 AD FS 中設定您現有的外部使用者：
- 在您的組織內使用本機帳戶的外部使用者，您可以繼續使用這些帳戶，與您的內部使用者帳戶運作方式相同。 這些外部使用者帳戶在您的組織內有一個主體名稱，雖然帳戶的電子郵件可能指向外部。 進行遷移時，可以透過在有這類身分識別可供使用時，藉由將這些使用者遷移至使用自己的公司身分識別，來利用 Azure AD B2B 提供的優點。 這可簡化登入這些使用者的流程，因為他們通常是使用自己的公司登入。 您組織的管理也比較簡單，而不需要管理外部使用者的帳戶。
- 同盟外部身分識別-如果您目前正在與外部組織同盟，有幾種方法可以採用：
- 在 Azure 入口網站中新增 Azure Active Directory B2B 共同作業使用者。 您可以主動將 B2B 共同作業邀請從 Azure AD 系統管理入口網站傳送給合作夥伴組織，讓個別成員繼續使用他們所用的應用程式和資產。
- 建立自助式 B2B 註冊工作流程，此工作流程 會使用 B2B 邀請 API 來為您的夥伴組織中的個別使用者產生要求。
無論您現有的外部使用者的設定方式為何，他們可能會有與其帳戶相關聯的權限，不論是群組成員資格或特定權限。 評估是否需要遷移或清除這些權限。 您組織內代表外部使用者的帳戶必須在使用者遷移至外部身分識別之後停用。 應與您的商務合作夥伴討論遷移流程，因為流程可能會中斷連線到您資源的功能。
遷移及測試您的應用程式
遵循本文中詳述的遷移流程。 然後移至 Azure 入口網站，以測試遷移是否成功。
遵循下列指示：
- 流覽至[Azure Active Directory>企業應用程式>] [所有應用程式]，然後從清單中尋找您的應用程式。
- 選取 [管理]>[使用者和群組]，將至少一個使用者或群組指派給應用程式。
- 選取 [管理]>[條件式存取]。 檢查您的原則清單，並確保您未使用條件式存取原則來封鎖應用程式的存取。
根據您設定應用程式的方式，確認 SSO 是否正常運作。
| 驗證類型 | 測試 |
|---|---|
| OAuth / OpenID Connect | 選取 [企業應用程式] > [權限]，並確定您已在應用程式的使用者設定中，同意使用該應用程式。 |
| 以 SAML 為基礎的 SSO | 使用 [單一登入] 下的 [測試 SAML 設定] 按鈕。 |
| 密碼式 SSO | 下載並安裝 MyApps 安全登入延伸模組-。 此延伸模組可協助您啟動組織中要求使用 SSO 程序的任何雲端應用程式。 |
| 應用程式 Proxy | 確定您的連接器正在執行，並已指派給您的應用程式。 請造訪應用程式 Proxy 疑難排解指南，以取得進一步的協助。 |
注意
舊 AD FS 環境中的 Cookie 會保存在使用者電腦上。 這些 Cookie 可能會導致遷移問題，因為使用者可以導向至舊的 AD FS 登入環境，而不是新的 Azure AD 登入。 您可能需要手動或使用指令碼來清除使用者瀏覽器 Cookie。 您也可以使用 System Center Configuration Manager 或類似的平台。
疑難排解
如果已遷移的應用程式測試有任何錯誤，可能會先進行疑難排解，再回到現有的 AD FS 信賴憑證者。 請參閱如何偵錯 SAML 型單一登入 Azure Active Directory 中的應用程式
復原移轉
如果遷移失敗，建議您將現有的信賴憑證者保留在 AD FS 伺服器上，並移除對信賴憑證者的存取權。 這可讓您在部署期間視需要快速復原。
員工溝通
雖然規劃的中斷時段本身可能很短，但您仍應將從 AD FS 切換至 Azure AD 的這些時間範圍主動傳達給員工。 確定您的應用程式體驗有意見反應按鈕，或指向技術服務人員的指標。
部署完成後，您可以通知使用者部署成功，並提醒他們必須採取的任何步驟。
- 指示使用者使用我的應用程式來存取所有已遷移的應用程式。
- 提醒使用者可能需要更新其 MFA 設定。
- 如果已部署自助式密碼重設，使用者可能需要更新或驗證其驗證方法。 請參閱 MFA 和 SSPR 終端使用者溝通範本。
外部使用者通訊
此使用者群組通常會在問題發生時受到最嚴重的影響。 如果您的安全性狀態是為外部夥伴指定一組不同的條件式存取規則或風險設定檔，則更是如此。 請確定外部夥伴知道雲端遷移排程，並有時間範圍，建議他們參與試驗部署，以測試外部共同作業的獨特流程。 最後，請確定他們有方法可以連絡您的技術服務人員，以防發生問題。
後續步驟
- 請閱讀將應用程式驗證遷移至 Azure AD。
- 設定條件式存取和 MFA。
- 試用逐步程式碼範例：AD FS Azure AD 開發人員的應用程式遷移劇本。