精通-Azure-身份和访问管理-全-

精通 Azure 身份和访问管理（全）

原文：annas-archive.org/md5/e9b7ef9cbf1f5ddb8eac8891ecdb6978

译者：飞龙

协议：CC BY-NC-SA 4.0

前言

Mastering Identity and Access Management with Microsoft Azure 是一本简明实用的动手指南，包含了项目场景/插图，专为真正的混合云和纯云挑战量身定制。开发人员、安全专家、IT 顾问和架构师是本书的读者群体。通过本书，您将获得一份完整的伴侣，帮助您通过所有相关的 Microsoft 技术解决身份和访问管理领域的关键主题，并提供实践相关的简洁明了的内容，帮助您将理论付诸实践。本书深入探讨了 Microsoft 365 安全与合规计划以及其他与身份和访问管理相关的 Azure 服务。

本书分为三部分。第一部分涵盖了至关重要的身份管理主题，例如身份同步的整体内容，包括在纯云和混合云环境中的监控和保护主题。第二部分提供了与不同认证方法相关的所有基本知识和深入信息，您可以使用这些方法安全地发布和公开您的应用程序，结合本地技术和 Azure AD 功能集。书的最后一部分完全聚焦于 Microsoft 信息保护技术。另一个亮点是您将获得超过 40 个实用操作手册，通过实际技巧支持学习过程。通过这个丰富的资源包，您还将了解到 Windows 10 和 Windows Server 2016/2019 的功能。

本版与第一版有何不同，为什么会有超过 85%新内容的第二版？

首先，感谢所有读者和我收到的宝贵反馈。我很高兴能倾听大家的声音！

自 2016 年撰写第一版书籍以来，许多功能已经被完全更新、添加、更改，甚至删除。Microsoft Azure 的世界正在快速变化，从单纯的基础设施向面向对象和服务的环境转变。因此，书中需要包含多种开发方面的内容。目前，一些功能正在将其授权完全转移到云端。

然而，目前没有一个整体的解决方案能够满足混合云环境中可持续身份和访问管理的所有不同方面。因此，必须为各个服务制定基础，以确保功能的更好转换。

我决定编写更新版的另一个重要原因是，我从读者和研讨会参与者那里听到他们需要更多技术指导，而非决策管理方面的信息。这促使我采取了一种方法，在书中提供了超过 40 个实用指南，帮助读者以一种实践和引导的方式测试所有相关信息。此外，我们的研讨会参与者和客户发现，很难找到合格且有效的实验室示例，以节省时间和精力。

许多读者和我们的参与者喜欢第一版书中三个场景的结构。然而，我经常收到请求，希望能以技术或主题流的方式提供理论和实践指导，以便更容易跟进，尤其是当你只对某些特定主题感兴趣，或者希望将本书作为一个活跃的参考。

在编写第一版书时，Azure 信息保护技术还没有现在这样完备的实现方式。由于这项技术现在已经成熟，并且是访问管理的核心组成部分，因此我认为，针对这一主题增加章节是绝对必要的。

Windows Server 2019 也可用于操作，因此我更新了本书，使其适配新版本的服务器，主要聚焦于混合云场景。

本书适合人群

本书面向网络安全专家、系统与安全工程师、开发人员以及 IT 顾问/架构师，旨在帮助他们利用 Microsoft Azure 技术规划、设计并实施身份和访问管理解决方案。

如何最大化利用本书

为了高效使用本书，你应该对安全解决方案、Active Directory、访问权限/权限控制以及身份验证方法有所了解。编程知识不是必需的，但如果你希望使用 PowerShell 或通过 API 自定义解决方案，这些知识会有所帮助。阅读第一版书籍并不是跟随本书章节的前提。

在本书中，我们将完全在 Azure 平台上进行操作。唯一的要求是有互联网连接和一台微软或苹果客户端电脑。在我们使用的多个试用版本期间，实验可以免费进行。我们强烈建议你在 Azure 上关闭虚拟机，以节省与实践指导相关的运行时。在第七章，《在 Azure AD 和 ADFS 上部署解决方案》一章中，我们将提供架构概览，并提供所有必要的信息，以帮助进行资源规划以及使用和在章节中提到的不同产品。我们还将指导你使用 Let's Encrypt 创建公共证书。存在一个小的费用要求。如果你想运行所有不同的实验，你需要注册三个公共 DNS 域名，并且有权访问相关的公共 DNS。请记住，这个实验是为了学习和测试功能，而不是表示一个生产环境。按照各章节中的指示安排正确的资源。所有的脚本和示例文件都包含在示例代码文件中，你可以在下载示例代码文件部分的网页上下载它们。

下载示例代码文件

你可以从你在www.packt.com的帐户中下载本书的示例代码文件。如果你是在其他地方购买的此书，你可以访问www.packt.com/support并注册以便将文件直接发送到你的邮箱。

你可以按照以下步骤下载代码文件：

1. 在www.packt.com登录或注册。

2. 选择“支持”选项卡。

3. 点击“代码下载和勘误”。

4. 在搜索框中输入书名，按照屏幕上的指示操作。

文件下载完成后，请确保使用最新版本的工具解压或提取文件夹：

• WinRAR/7-Zip for Windows

• Zipeg/iZip/UnRarX for Mac

• 7-Zip/PeaZip for Linux

本书的代码包也托管在 GitHub 上，地址为github.com/PacktPublishing/Mastering-Identity-and-Access-Management-with-Microsoft-Azure.Second-Edition。如果代码有更新，将会在现有的 GitHub 库中更新。

我们还提供了来自我们丰富书籍和视频目录的其他代码包，地址为github.com/PacktPublishing/。快来看看吧！

下载彩色图像

我们还提供了一份 PDF 文件，其中包含本书中使用的屏幕截图/图表的彩色图像。你可以在此下载：www.packtpub.com/sites/default/files/downloads/9781789132304_ColorImages.pdf

使用的约定

本书中使用了一些文本约定。

CodeInText：表示文本中的代码词、数据库表名、文件夹名、文件名、文件扩展名、路径名、虚拟网址、用户输入和 Twitter 用户名。例如：“打开你的 Visual Studio，并打开名为WebApp-RoleClaims-DotNet.sln的解决方案文件。”

一段代码如下所示：

$ServicePrincipalName="RMSPowerShell"
Connect-AadrmService
$bposTenantID=(Get-AadrmConfiguration).BPOSId
Disconnect-AadrmService
Connect-MsolService
New-MsolServicePrincipal -DisplayName $ServicePrincipalName

当我们希望你注意到代码块中的特定部分时，相关行或项目会以粗体显示：

$cred = Get-Credential
Install-AIPScanner -SqlServerInstance YD1APP01 -ServiceUserCredentials $cred

所有命令行输入或输出如下所示：

$ImportFile = Import-csv "$dirpath\ADUsers.csv"
$TotalImports = $importFile.Count

粗体：表示新术语、重要词汇或屏幕上显示的词汇。例如，菜单或对话框中的词语会以这种方式出现在文本中。示例：“点击添加新规则，并选择入站。”

警告或重要说明如下所示。

提示和技巧如下所示。

联系我们

我们始终欢迎读者的反馈。

一般反馈：如果你对本书的任何方面有疑问，请在邮件主题中提到书名，并通过customercare@packtpub.com联系我们。

勘误表：虽然我们已尽最大努力确保内容的准确性，但错误难免发生。如果你在本书中发现错误，感谢你向我们报告。请访问 www.packt.com/submit-errata，选择你的书籍，点击“勘误表提交表单”链接，并输入相关信息。

盗版：如果你在互联网上发现任何我们作品的非法复制版本，感谢你提供相关的地址或网站名称。请通过copyright@packt.com联系我们，并附上相关材料的链接。

如果你有兴趣成为作者：如果你在某个领域有专长，并且有兴趣撰写或参与撰写书籍，请访问 authors.packtpub.com。

书评

请留下书评。阅读并使用本书后，为什么不在你购买书籍的站点留下书评呢？潜在读者可以看到并参考你的公正意见来做出购买决定，我们在 Packt 可以了解你对我们产品的看法，作者也能看到你对其书籍的反馈。谢谢！

要了解更多关于 Packt 的信息，请访问 packt.com。

第一部分：身份管理与同步

本书的第一部分将带你探索并使用多个 Microsoft 身份和访问管理服务。你还将详细了解身份同步过程。

本节将涵盖以下章节：

• 第一章，构建和管理 Azure Active Directory

• 第二章，理解身份同步

• 第三章，探索高级同步概念

• 第四章，监控你的身份桥接

• 第五章，配置和管理身份保护

第一章：构建和管理 Azure Active Directory

使用多个 软件即服务（SaaS）产品，如 Office 365、Dynamics CRM 或 Visual Studio Online，要求在 Azure Active Directory（AD）中构建良好的身份和访问管理基础结构，这些产品是这些解决方案的核心。作为管理员，您需要提供一个稳定的身份和访问管理平台，以便管理这些服务。

本章解释了如何配置一个合适的 Azure AD 租户，我们将在全书中使用该租户来探索、理解并配置 Microsoft Azure 中身份和访问管理领域的不同功能和特性。我们从仅云组件开始，在后续章节中介绍混合身份和访问管理方法。

本章将直接进入配置，学习如何配置和管理用户、组、角色和管理单元，以提供基于用户和组的应用程序以及自助服务访问，包括审计功能。本章的重点如下：

• 实施场景概览

• 实施一个稳固的 Azure Active Directory

• 创建和管理用户及组

• 分配角色和管理单元

• 保护您的管理账户

• 提供基于用户和组的应用程序访问

• 启用密码重置

• 使用标准安全监控

• 集成 Azure AD 加入 Windows 10 客户端

• 配置自定义域

• 配置 Azure AD 域服务

现在，我们可以介绍实施场景。

实施场景概览

完成接下来的配置任务后，您将看到 Microsoft Azure 在身份和访问管理领域的丰富功能，从云身份开始。您可以在自己的 Microsoft Azure 环境中演示不同的功能。指导将集中在最关键的功能集上，帮助您了解它们的能力。我们将开始使用默认目录，目前我们称之为 domain.onmicrosoft.com，稍后将其更改为自定义域名。域名代表您希望使用的名称，比如 example.com，这也会用于本章中的用户 userPrincipalName，例如 don.hall@doamin.onmicrosoft.com，本章中代表的是我的示例域名 inovitcloudlabs。请注意，这个名称将在不同的应用程序中显示给最终用户，如 SharePoint Online 和 Skype for Business。我们建议使用公司名称而不带公司形式，例如，inovit GmbH 应为 inovit.onmicrosoft.com。为您的测试使用不同的名称，以确保生产环境的域名保持可用。此配置将成为本书所有后续场景的基础。因此，我们使用 Azure、Enterprise Mobility Suite 和 Office 365 订阅，以使用所有可用功能。

下图展示了本章节中我们将重点关注的不同主要领域：

章节场景概览

在下一部分中，我们将开始配置这些场景。

实施稳固的 Azure Active Directory

我们需要采取的第一步是获取一个 Azure AD 租户。有很多方法可以实现这一点。您可以从 Azure 订阅开始，或者使用 Microsoft SaaS 产品组合中的任何其他服务。让您的解决方案处于工作状态的最简单方法是从 Office 365 试用订阅开始。

打开浏览器并访问 bit.ly/1RVpFXe. 订阅免费的 Office 365 企业 E5 计划：

Office 365 E5 试用请求

按照注册流程并定义您的用户 ID，例如 admin@domain.onmicrosoft.com。我们建议使用非个人 ID，如下截图所示。输入您的新用户 ID 和密码。您的默认目录名称将在 @ 后面定义：

创建第一个全球管理员

接下来，您需要通过短信或电话验证身份并输入收到的验证码。然后，您需要点击“创建我的账户”。请记住，配置过程需要几分钟，并应以成功消息结束。

在成功创建了全新的 Azure AD 并关联了 Office 365 E5 计划后，您应该能够使用管理员凭据登录，并看到以下界面：

Office 365 管理门户

在下一步中，我们将为新创建的 Azure AD 租户分配 Enterprise Mobility Suite (EMS) E5 计划。

点击右侧的管理员图标，您应该会在“账单”标签下看到当前分配的订阅：

Office 365 订阅管理

点击“添加订阅”将 EMS E5 试用计划添加到您的 Azure AD 租户：

EM+S E5 试用请求

选择 EMS E5 计划并点击“开始免费试用”，然后按照订阅流程进行操作。订阅成功后，您可以在您的 Azure AD 租户中看到已分配的 Office 365 E5 和 EMS E5 计划。

现在我们已经创建了 Azure AD 租户，接下来需要订阅 Azure 免费试用订阅。此步骤对于使用 Azure 资源（如 Azure AD 域服务或我们将在后续章节中讨论的其他功能）是必要的。

您还可以使用以下方式获取 Azure 订阅：

• 使用全新的 Azure 订阅 (account.azure.com/organization)

• 使用基于协议的 Azure 订阅

• 使用 MSDN Azure 订阅，如下图所示：

Visual Studio 订阅福利

请记住，你只能注册一个 Azure AD 免费试用订阅。

现在让我们配置你的管理工作站和个人 Azure AD 租户。

配置你的管理工作站

首先，我们需要设置一个功能齐全的管理工作站来完成本指南。你需要一台配置为工作组的 Windows 10 企业版客户端机器。我们推荐使用一台新安装的 Windows 10 企业版虚拟机。我们需要一台 Windows 10 设备来在本书稍后使用 Azure AD 加入功能。如果你无法访问批量授权版或 MSDN 版本，你可以使用企业评估版，下载链接是www.microsoft.com/en-gb/evalcenter/evaluate-windows-10-enterprise。

在本章的代码部分，你将找到以下 cmdlet，用于在你的客户端机器上安装所需的管理工具，基本上包括 Azure AD、MSOnline 和 Azure 资源管理器 PowerShell 模块：

1. 安装 Azure Active Directory PowerShell 模块：

Install-Module -Name AzureADPreview

1. 安装MSOnline PowerShell 模块：

Install-Module -Name MSOnline

1. 安装 Azure 资源管理器 PowerShell 模块：

Install-Module AzureRM

1. 使用 PowerShell 连接到MSOnline接口：

Connect-MsolService
# Provide your global administrator credentials
# View your assigned subscriptions
Get-MsolAccountSku
# View all actual users
Get-MsolUser

1. 创建你的第一个测试用户以验证 Azure AD 管理连接：

New-MsolUser -UserPrincipalName "jochen.nickel@inovitcloudlabs.onmicrosoft.com" -DisplayName "Jochen Nickel" -FirstName "Jochen" -LastName "Nickel" -UsageLocation "CH" -LicenseAssignment "inovitlabs:ENTERPRISEPREMIUM","inovitcloudlabs:EMSPREMIUM"

Get-MsolUser -UserPrincipalName jochen.nickel@inovitcloudlabs.onmicrosoft.com | fl

1. 直接连接到 Azure AD 接口，以比较与MSOnline PowerShell 模块的输出和功能：

Connect-AzureAD
Get-AzureADUser -all $true | where userprincipalname -eq jochen.nickel@inovitcloudlabs.onmicrosoft.com | fl

1. 从代码包中解压部署包。C:\Configuration\HRExports目录包含所需的人力资源导入和组创建脚本，用于用一些测试数据配置你的 Azure AD 租户：

示例脚本集

在HRImportToAAD.ps1脚本中，将使用以下重要变量：

$domain = Get-MsolDomain | where {$_.Name -notlike "*mail*"}
$dir = "C:\Configuration\HRExports"

# Also configure your PowerShell Execution Policy to RemoteSigned with the following cmdlet
# More information about this topic can be found under http://bit.ly/1EWLG03
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned

域变量将包含domain.onmicrosoft.com，这是你 Azure AD 默认目录的名称。我们使用这个目录而不是注册的域名来执行不同的步骤。在本章末，我们将切换到自定义域，以便你可以探索所需的任务。如你所见，dir 变量包含脚本路径以及名为NewHire.csv的简单人力资源导出文件。文件中的contoso.com域名将被替换为存储在域变量中的你的域名。

NewHire.csv 文件包含以下示例用户集，将在未来的配置中使用，以演示不同的功能：

userPrincipalName,DisplayName,FirstName,LastName,password
Don.Hall@contoso.com,Don Hall,Don,Hall,Pass@word1
Ellen.Adams@contoso.com,Ellen Adams,Ellen,Adams,Pass@word1
Jeff.Simpson@contoso.com,Jeff Simpson,Jeff,Simpson,Pass@word1
Brian.Cox@contoso.com,Brian Cox,Brian,Cox,Pass@word1
Doris.Sutton@contoso.com,Doris Sutton,Doris,Sutton,Pass@word1
Petro.Mitchell@contoso.com,Petro Mitchell,Petro,Mitchell,Pass@word1

在接下来的步骤中，我们将为我们的全局管理员 admin@domain.onmicrosoft.com 分配 EMS E5 计划许可证。Office 365 E5 许可证已经通过创建过程分配。稍后在本章中，我们将通过动态组成员资格分配许可证，这是一项 Azure AD Premium P2 许可证功能：

许可证分配操作

点击“分配”并将 EMS E5 计划许可证添加到您的全局管理员账户。预期的结果如下：

分配的许可证概述

我们将获得正确的信息，表明该用户 ID 没有分配有效的订阅。接下来，注册一个 Microsoft Azure 订阅。

自定义公司品牌

大多数公司都希望看到如何将企业身份应用到 Azure 服务中。通过几个简单的步骤，您可以展示最重要的功能。要添加自定义品牌，您需要使用 Azure Active Directory Premium 1、Premium 2、Basic 或 Office 365 许可证。通过以下简单的示例，您可以看到可以自定义的内容。您可以用不同的语言提供定制内容，以满足您或您客户的需求。这些配置任务通常是演示或概念验证的良好起点。您可以自由使用自己的图片和设计来进行此设置：

自定义门户示例

我们将要更改的第一项是目录名称，位于属性部分。只需输入您希望的名称。我们使用了 INOVITCLOUDLABS by inovit GmbH。您还可以在登录页面提供您自己的技术和隐私联系人以及相关链接：

Azure AD 租户属性

点击“自定义品牌”，您将看到以下选项。为了帮助您准备图片和品牌，我们总结了 Microsoft TechNet 提供的帮助信息：

Azure AD 门户自定义选项

接下来，您将看到一个配置摘要。

帮助信息的总结和推荐

以下部分为您提供了多个功能，并总结了最重要的企业身份特性，以帮助您定制环境：

• 横幅徽标：从以下选项中选择：

  • 显示在 Azure AD 登录页面和 myapps.microsoft.com 上

  • PNG 或 JPEG

  • 不能高于 36 像素或宽于 245 像素

  • 推荐—图片周围无边距

• 登录页面正文文本：从以下选项中选择：

  • 出现在 Azure AD 登录页面的底部

  • 仅支持 Unicode 文本，最大长度为 256 个字符

  • 用来传达您的帮助台电话号码或包含法律声明

  • 推荐—不要添加链接或 HTML 标签

• 登录页面背景图像：从以下选项中选择：

  • 显示在 Azure AD 登录页面的侧边

  • PNG 或 JPEG

  • 推荐尺寸为 1420 x 1200，支持的文件大小为 300 KB（最大 500 KB）

  • 保持图像的精彩部分在左上角（图像会被调整大小和裁剪）

• 用户名提示：当用户忘记用户名时，显示的提示文本：

  • Unicode，无链接或代码

  • 最多 64 个字符

• 显示保持登录选项：让您的用户在明确退出之前保持登录 Azure AD：

登录体验

你也可以通过以下文章进行一些广泛的自定义：docs.microsoft.com/en-us/azure/active-directory/fundamentals/customize-branding。

你的预期结果应该是这样：

门户自定义效果

现在我们已经提供了基本的公司品牌形象，我们可以开始创建和管理用户和群组。

创建和管理用户及群组

在接下来的步骤中，我们将连接到 Azure AD 并生成测试用户和群组。

启动 Azure AD PowerShell 控制台，并通过执行以下 cmdlet 和脚本连接到 Azure AD：

$msolcred = get-credential
# Enter your global administrator credentials
connect-msolservice -credential $msolcred
C:\Configuration\HRExports\HRImportToAAD.ps1

或者，你也可以直接使用connect-msolservice来连接，而无需使用变量。

启动脚本后，直接使用admin@domain.onmicrosoft.com凭证登录到portal.azure.com。在你的 Azure AD 下选择用户部分。你应该在“所有用户”标签页中找到来自HireUsers.csv文件的用户：

Azure AD 门户用户管理

打开portal.office.com | 管理员 | 活跃用户，你可以看到在 Office 365 中具有有效许可证的用户：

Office 365 用户管理

让我们创建三个示例群组，代表公司组织，使用以下脚本：

C:\Configuration\HRExports\AddOrgGroups.ps1

现在，你将看到创建的群组：

Azure AD 群组管理

测试你的配置，打开myapps.microsoft.com，使用用户Don.Hall@domain.onmicrosoft.com登录，你应该可以在访问面板 UI 中看到 Office 365 SharePoint、Outlook 和许多应用程序。点击 Outlook，你应该能够在无需额外登录信息的情况下打开应用程序并访问你的邮箱：

用户收件箱对话框

在接下来的步骤中，我们将为我们的组织群组提供一个所有者。

为组织群组设置群组所有者

为了提供由部门经理管理的群组管理，我们将以下用户分配为其部门群组的所有者：

• 会计部门：Brian.Cox@domain.onmicrosoft.com

群组 - 用户分配

对以下内容做同样的操作：

• 人力资源：Don.Hall@domain.onmicrosoft.com

• 销售部门：Doris.Sutton@domain.onmicrosoft.com

现在我们已经配置了所有者，接下来我们将开始委派管理权限。

组织群组的委派群组管理

Azure AD 的默认配置允许安全性或 Office 365 群组的所有者根据 Azure AD 访问面板和 Azure 门户中的数据所有者概念来管理群组成员。

此外，你还可以根据需求限制此功能：

Azure AD 中的群组选项

以 Don.Hall@domain.onmicrosoft.com 登录 myapps.microsoft.com。点击 HR 群组并将 Ellen.Adams@domain.onmicrosoft.com 添加到 HR 群组：

Azure AD 访问面板 UI 中的群组视图

查看编辑详细信息下的加入策略。

在接下来的部分中，我们将配置群组自助服务选项。

配置自助服务群组管理

另一个需求可能是用户需要能够创建基于请求的安全组或 Office 365 群组，例如用于项目或分发群组。为此，他们需要具备审批流程的能力。你可以通过在群组管理的一般设置中启用该选项来提供此功能。此功能集需要 Azure Active Directory Premium：

自助服务群组管理选项

Office 365 群组包括分发列表，但也包含以下共享工具：

• 用于群组邮件通讯的收件箱

• 用于安排群组会议和事件的日历

• 用于存储和处理群组文件及文件夹的库

• 用于记录项目和会议笔记的 OneNote 笔记本

• 用于组织和分配任务，以及获取项目进展更新的计划工具

• 嘉宾访问（由管理员设置）

实际提示：使用不同的浏览器或隐身浏览选项来处理不同的用户会话：一个会话在 portal.azure.com 作为 admin@domain.onmicrosoft.com（管理员），另一个会话作为明确的用户（用户）在 myapps.microsoft.com。

将销售内部新闻群组创建为 Office 365（分发群组）

以 Doris.Sutton@domain.onmicrosoft.com 登录 myapps.microsoft.com 并将 Sales Internal News 群组创建为 Office 365 群组。检查群组策略，确保显示“此群组对所有用户开放加入”：

Azure AD 访问面板 UI - 群组创建

查看新创建群组的加入策略：

群组对话框 - Azure AD 访问面板 UI

在你的 Azure AD 中，群组下也会找到新创建的群组：

群组概览 - Azure AD 访问面板 UI

现在，作为群组所有者，我们更改群组设置，要求通过群组策略设置请求经理的审批：

群组编辑对话框

测试新配置，并以 Don.Hall@domain.onmicrosoft.com 登录 myapps.microsoft.com。导航到群组。选择销售内部新闻：

加入群组对话框

加入“销售内部新闻”组并输入业务理由，点击“请求”，然后流程将开始。

以Doris.Sutton@domain.onmicrosoft.com身份登录到myapps.microsoft.com。

检查您的收件箱。您应该已收到加入请求邮件和通知，并显示在访问面板 UI 中。

点击此请求并批准它：

组加入 - 通知

注意：接下来，您将看到“销售内部新闻”组的成员。

以Don.Hall@domain.onmicrosoft.com身份登录到myapps.microsoft.com。

检查您的收件箱，您应该已经收到一条成功审批的消息：

批准消息 - 组成员身份

检查您的组成员身份，您应该是“销售内部新闻”组的成员：

Azure AD 访问面板 UI 中的组管理

接下来，我们将配置动态组成员身份。

配置动态组成员身份

在接下来的部分，我们将配置简单的动态组成员身份，使用部门属性将用户添加到其部门组，并建立动态许可证分配。目前，基于组的许可证不支持包含其他组（嵌套组）的组。

动态组中的每个用户都需要 Azure AD Premium P1 许可证。

启用动态组时，当前的成员身份将丢失。

用户的使用位置需要设置才能分配许可证。

作为admin@domain.onmicrosoft.com，选择会计组，导航到属性，并将成员类型更改为动态用户。

创建一个简单的规则，部门等于（-eq）会计：

动态组成员身份规则配置

将会计用户Brian Cox和Jeff Simpson的部门属性（个人资料部分）设置为会计：

填写动态组使用的用户属性

该成员应自动添加。检查组成员身份并验证两个新成员：

刚计算出的动态组成员身份

接下来，我们将提供自动化的许可证解决方案。

创建以下安全组：

• Office 365 完全功能许可证

• 组描述：自动化 Office 365 完全功能许可证

• 成员类型：动态用户

• 动态查询：userType -eq Member：

组属性对话框

在许可证 | 产品下，分配 Office 365 E5 计划。此时不要选择任何分配选项：

组分配选项

注意：使用分配选项，您可以根据需要启用/禁用功能。

等待直到成员资格已更新，并检查 Don.Hall@domain.onmicrosoft.com 的许可证分配。

您将看到该用户通过直接分配和基于组的分配同时获得许可证：

许可证分配概览

该许可证解决方案为您提供了一个起点。您应当从所有通过组成员资格获取许可证的用户中移除直接分配的许可证。

在下一部分中，我们将配置角色分配给管理单元。

为管理单元分配角色

为了委派任务，我们使用创建 管理单元（AUs）并为特定任务分配角色。在这个配置中，我们创建一个 HR [AU]，并将 HR 部门的经理分配为在此作用域内管理用户账户的角色。

创建管理单元

首先，我们需要通过 PowerShell cmdlet Connect-AzureAD 连接到我们的 Azure AD，使用 admin@domain.onmicrosoft.com 用户。

使用以下 cmdlet 创建 HR [AU]：

New-AzureADAdministrativeUnit -Description "Human Resources Users" -DisplayName "HR"

查看预期输出：

新创建的管理单元

接下来，我们将添加相关用户。

向管理单元添加用户

接下来，我们将 HR 部门的用户添加到 HR [AU]。使用以下 cmdlet 执行此操作：

$HRAU = Get-AzureADAdministrativeUnit -Filter "displayname eq 'HR'"
$initialDomain = (Get-AzureADDomain)[0].Name
$HRUser1 = Get-AzureADUser -Filter "UserPrincipalName eq 'don.hall@$InitialDomain'"
$HRUser2 = Get-AzureADUser -Filter "UserPrincipalName eq 'ellen.adams@$InitialDomain'"
Add-AzureADAdministrativeUnitMember -ObjectId $HRAU.ObjectId -RefObjectId $HRUser1.ObjectId
Add-AzureADAdministrativeUnitMember -ObjectId $HRAU.ObjectId -RefObjectId $HRUser2.ObjectId
Get-AzureADAdministrativeUnitMember -ObjectId $HRAU.ObjectId | Get-AzureADUser 

上述命令的输出如下：

新增用户概览

接下来，我们将使用作用域选项。

限定管理角色的作用域

在下一步中，我们分配用户账户管理员角色。通过以下 cmdlet 验证可用角色：

Get-AzureADDirectoryRoleTemplate

现在，我们使用以下 cmdlet 启用用户账户管理员角色：

Enable-AzureADDirectoryRole -RoleTemplateId fe930be7-5e62-47db-91af-98c3a49a38b1

设置变量并将用户分配给角色：

$admins = Get-AzureADDirectoryRole
foreach($i in $admins) {
 if($i.DisplayName -eq "User Account Administrator") {
 $uaAdmin = $i
 }
 }

$HRUA = Get-AzureADUser -Filter "UserPrincipalName eq 'Don.Hall@$InitialDomain'"
$uaRoleMemberInfo = New-Object -TypeName Microsoft.Open.AzureAD.Model.RoleMemberInfo -Property @{ ObjectId = $HRUA.ObjectId }
Add-AzureADScopedRoleMembership -RoleObjectId $uaAdmin.ObjectId -ObjectId $HRAU.ObjectId -RoleMemberInfo $uaRoleMemberInfo

上述命令的输出如下：

用户账户管理员分配

接下来，我们将测试我们的配置。

测试您的配置

打开新的 PowerShell 并使用 Connect-MsolService 命令连接到 Azure AD，并使用 Don.Hall@domain.onmicrosoft.com 的凭据登录。

修改分配给 HR 管理单元的用户账户：

Set-MsolUser -UserPrincipalName ellen.adams@domain.onmicrosoft.com -Department HR

验证您的修改：

Get-MsolUser -UserPrincipalName ellen.adams@domain.onmicrosoft.com | select Department

接下来，我们将使用 Azure AD Premium P2 的 特权身份管理（PIM）功能来保护管理账户。如果您不想投资 Azure AD Premium P2，我们建议使用 Azure MFA 来保护您的管理账户。

保护您的管理账户

在这一部分中，我们将使用 Azure AD Premium P2 PIM 来保护管理账户，进行简要介绍。

以 admin@domain.onmicrosoft.com 打开 portal.azure.com 开始配置。

单击“所有服务”，然后选择 Azure AD 特权身份管理。

现在，我们需要同意使用 PIM 服务：

特权身份管理 - 启用

您需要验证您的身份并提供您首选的安全验证选项，正如以下截图所示：

Azure MFA 入职

如果您已经在移动设备上使用 Microsoft 身份验证器应用程序，您也可以注册该移动应用程序。

完成验证过程并点击同意—继续：

同意以完成初始化

接下来，我们将在 Azure AD 角色下进行注册，以便用户可以启用 Azure AD 角色。点击“为 Azure AD 角色注册 PIM”以激活该功能：

Azure AD 角色 - PIM 注册

现在功能已启用，我们可以将角色分配给用户。

点击“分配资格”以开始任务：

角色分配程序

点击全局管理员角色，查看实际成员，并将您的测试帐户添加到该角色中：

用户角色分配

查看预期结果：

新的符合条件的用户已分配到角色

让我们通过打开一个 InPrivate 浏览器会话来测试我们的配置；打开 portal.azure.com 并使用您的测试帐户登录。点击“所有服务”并选择 Azure AD 特权身份管理。选择“我的角色”并为您的帐户激活全局管理员角色：

角色激活程序

接下来，您需要验证您的身份。按照流程注册并验证您的帐户。您只需完成注册过程一次：

启动验证过程

注册和验证过程完成后，您可以激活您的角色：

角色激活

提供您角色激活的理由。您会注意到该角色仅限于 1 小时，并且您可以定义自定义的激活时间。稍后在本书中，我们将配置不同的角色和功能：

激活选项，如自定义激活开始时间和激活原因

验证您的角色是否已激活。您已成功请求通过 Azure AD PIM 获取全局管理员角色。这非常有用，因为高权限不会永久分配给您的帐户：

活跃角色概览

我们始终建议您保留一个全局管理员角色，并且不要求使用 Azure MFA 来使用该帐户。如果 Azure AD PIM 或 MFA 服务不可用，请将此帐户用作“Breaking Glass”帐户。

接下来，我们将在 Azure AD 中配置基于用户和组的应用访问权限。

提供基于用户和组的应用访问权限

在这个部分，我们配置一个典型的工作场所，用户可以在访问面板 UI (myapps.microsoft.com) 下访问。我们将应用程序分配给用户和群组，以查看不同的功能。这些步骤不包含所有的单一登录或配置选项。我们将在后续章节中详细讨论这些功能集。

使用全局管理员凭据登录到 portal.azure.com，并在企业应用程序部分的应用程序库中添加若干应用程序。添加应用程序后，我们分配账户，这些账户将获得访问权限。

构建一个如下所示的应用程序列表，并分配所有群组以访问这些应用程序，除了用户配置的群组：

Azure AD 应用程序管理

您将注意到具有和没有用户配置的格式差异。

测试您新配置的工作场所，并作为 don.hall@domain.onmicrosoft.com 登录到 myapps.microsoft.com：

Azure AD 访问面板 UI - 应用程序访问

同时，测试在 Office 365 上的用户体验，并登录为 don.hall@domain.onmicrosoft.com 到 portal.office.com。

接下来，我们将为用户分配应用程序。

将应用程序分配给用户并定义登录信息

在下一步中，我们将为 Don Hall 分配 LinkedIn 应用程序，并使用公司凭据。Don Hall 将无法看到凭据。因此，如果他离开公司，凭据仍然受到保护。

从应用程序库中添加 LinkedIn 应用程序并分配给 Don Hall 访问此应用程序：

应用程序 - 用户和群组分配

接下来，我们提供有效的 LinkedIn 凭据。如果您没有 LinkedIn 账户，请注册一个演示账户：

Azure AD 凭据存储

如果您将应用程序分配给一个群组，您可以决定是否共享凭据：

可用的凭据集工作选项如下：

• 使用共享凭据查看：用户仅需点击应用程序几秒钟后即可查看。请使用 Twitter 应用程序进行测试。

• 无共享凭据查看：用户需要首次添加所需凭据。请使用 Twitter 应用程序进行测试。

如果作为管理员不提供凭据，您将获得相同的行为。

使用用户账户测试此行为，将应用程序分配给群组，并定义登录信息。

将应用程序分配给群组，并定义登录信息。

在接下来的步骤中，我们为 HR 群组等群组执行相同操作，这些群组用于从个人 Twitter 频道获取新闻：

填写 Azure AD 凭据存储以访问应用程序。

从应用程序库中添加 Twitter 应用。分配 HR 组并配置凭证。使用 HR 组的用户在 myapps.microsoft.com 检查应用。

现在，我们可以配置自助服务应用管理。

自助服务应用管理

在这一部分，我们允许用户将应用程序添加到他们的工作场所，访问 myapps.microsoft.com，以享受单点登录功能。在 Azure AD 的配置部分，导航到企业应用。激活此处显示的功能：

企业应用管理选项

作为 Ellen.Adams@domain.onmicrosoft.com 登录 myapps.microsoft.com，点击获取更多应用并添加 MailChimp。添加 MailChimp 后，点击管理应用并选择 MailChimp。

作为 admin@domain.onmicrosoft.com 登录 manage.windowsazure.com，您可以在 Azure AD 的企业应用部分看到新添加的应用。

配置应用，添加一些用户，并进行测试！

密码重置自助服务功能

在这一部分，我们配置 Azure AD 的密码重置功能，以减少支持成本并确保 24/7 可用性。我们对服务没有任何限制，只需要一个验证选项来重置密码：

密码重置 - 属性对话框选择激活选项

为了验证重置，我们使用了几种方法：

密码重置 - 身份验证选项

我们激活的下一个选项将强制用户进行注册：

密码重置 - 注册要求及确认选择

接下来，我们配置相关的通知。

配置通知

在这一部分，我们配置通知选项，以便管理员能够在发生异常登录或管理员密码重置时收到通知：

1. 配置如下所示的通知：

密码重置 - 通知选项

1. 用户将被强制注册进行密码重置，如下图所示：

注册强制

现在，我们将测试新配置的功能，并查看所需的注册场景以及验证选项。接下来，我们将检查密码重置。

测试新配置的设置，并以 Don.Hall@domain.onmicrosoft.com 登录 myapps.microsoft.com。

您将收到一条消息，提醒您需要注册进行密码重置：

验证器应用 - 设置过程

为 Don Hall 添加您首选的方法。您将收到一条短信、电子邮件或其他您定义的响应方式。

管理员用户默认需要两种验证选项。

以admin@domain.onmicrosoft.com身份登录到myapps.microsoft.com，您将看到要求提供两种验证选项。

在接下来的步骤中，我们将验证功能。

测试密码重置过程

在您喜欢的浏览器中打开https://myapps.microsoft.com，并输入Don.Hall@domain.onmicrosoft.com。点击“无法访问您的帐户？”选项，或使用以下链接passwordreset.microsoftonline.com开始密码重置过程。您将进入验证过程，并需要按照任务完成。完成过程后，使用新密码登录。

使用标准的安全监控

在本节中，我们将配置并模拟一些在 Azure AD 监控部分报告的典型事件。

首先，我们配置一个密码保护功能，自定义智能锁定。我们将值设置为10次错误登录：

Azure AD 密码保护功能

如果您错误输入密码 10 次，您应该会收到以下消息：

锁定消息对话框

您可以在监控 | 登录部分查看活动：

Azure AD 监控功能

您还可以使用CyberGhost（www.cyberghostvpn.com/en_us）等模拟软件测试来自不同地理位置的登录。另一种选择是使用 Azure 虚拟机。

使用跨地区的账户登录，比如欧洲和亚洲之间的地区。这需要远程机器，位于不同的时区，并且尽可能紧密地进行登录：

• 从您的本地 PC 登录到myapps.microsoft.com，以Don.Hall@domain.onmicrosoft.com身份登录

• 在不同于原始 PC 时区的机器上，以Don.Hall@domain.onmicrosoft.com身份登录到myapps.microsoft.com。

要配置具有异常登录活动的用户，您可以使用 Tor 浏览器：

• 使用像 Tor 这样的匿名浏览工具

• 从www.torproject.org/download/download-easy.html.en下载安全的 Tor 浏览器

打开 Tor 浏览器，访问myapps.microsoft.com，并以Don.Hall@domain.onmicrosoft.com身份登录。您的用户帐户将被锁定。

在安全监控中，预期会看到以下结果：

安全监控概览 - Azure AD

现在我们已经简要浏览了安全监控选项，我们将把 Windows 10 客户端集成到 Azure AD 中。

为 Windows 10 客户端集成 Azure AD 加入功能

在本章节中，我们将配置 Azure AD 加入功能，并将我们的第一台 Windows 10 客户端加入到 Azure AD。

我们为每个用户配置最多五个设备，并保持其他默认值：

Azure AD - 设备设置

在接下来的章节中，我们将把我们的客户端加入到 Azure AD。

将您的 Windows 10 客户端加入 Azure AD

登录到您刚安装的 Windows 10 客户端机器并进入设置。选择“连接”进入工作或学校访问部分：

Azure AD 加入过程对话框

我们使用 don.hall@domain.onmicrosoft.com 登录，并将 Windows 10 客户端加入 Azure AD：

加入操作概述

按照接下来的步骤点击完成客户端的加入。之后，我们将检查新的状态。预期的结果是连接到您的 Azure AD 名称：

Azure AD 加入客户端消息

接下来，我们将验证 Azure AD 加入过程。

验证新加入的 Windows 10 客户端

使用 don.hall@domain.onmicrosoft.com 的凭据登录 Windows 10 客户端，并点击完成安全策略配置。点击执行这些策略。点击完成 PIN 设置并完成流程，然后测试用户体验：

• 打开邮件应用，您将看到系统识别了您的用户 ID，并提供单点登录功能。

• 此外，如果您打开 myapps.microsoft.com，您将直接登录到访问面板界面：

不同的邮件账户选项

在验证 Azure AD 加入后，我们将配置一个自定义域名。请注意，如果您想测试相关功能，您需要注册一个域名。

配置自定义域名

在 Azure Active Directory | 自定义域名部分，点击“添加自定义域名”，并完成验证过程以证明您是该域名的所有者：

实际配置的域名

将显示的 TXT 记录添加到您的 DNS 区域以验证域名：

域名验证选项

在 Azure 门户中点击验证按钮，验证成功后，新的 DOMAIN NAME 将出现在域名列表中。选择设置为主域名选项：

自定义域名概述与配置选项（设置为主域名或下载 Azure AD Connect 工具）

打开 portal.office.com，在管理员部分完成域名设置过程：

Office 365 设置向导

选择要用于电子邮件地址的自定义域：

登录和邮件选项

我们需要采取的最后一步是将新的 UserPrincipalNames 设置为现有用户。我们使用一个小的示例脚本解决方案来实现：

1. 使用全局管理员凭据连接到你的 Azure AD：

Connect-AzureAD

1. 使用以下 cmdlet 将现有用户导出为 CSV 文件：

Get-AzureADUser -All $True | Where { $_.UserPrincipalName.ToLower().EndsWith("onmicrosoft.com")} | Export-Csv C:\Office365Users.csv

1. 删除所有不需要修改的账户，并使用以下 cmdlet 进行更改：

$domain = "inovitlabs.ch"
Import-Csv 'C:\Office365Users.csv' | ForEach-Object {
$newupn = $_.UserPrincipalName.Split("@")[0] + "@" + $domain
 Write-Host "Changing UPN value from: "$_.UserPrincipalName" to: " $newupn -ForegroundColor Green
 Set-AzureADUser -ObjectId $_.UserPrincipalName -UserPrincipalName $newupn
}

1. 你应该得到类似以下的结果：

活跃用户概览

主电子邮件也将更改为自定义域。

接下来，我们将配置 Azure AD 域服务，以提供一个基于 Kerberos 的应用程序过渡场景，这通常是在本地基础设施中提供的。

配置 Azure AD 域服务

为了将基于 Kerberos 身份验证的传统应用程序集成到 Azure 基础设施即服务（IaaS）场景中，我们配置 Azure AD 域服务。在本节中，我们配置基础服务并集成一个活动示例应用程序：

Azure AD 域服务创建

要开始配置，我们需要指定 DNS 域名、要使用的 Azure 订阅以及资源组的名称：

Azure AD 域服务配置

启用 Azure AD 域服务时，你需要指定使用哪个 Azure 虚拟网络。我们使用 192.168.x.x/20 范围来配置网络：

虚拟网络配置

将管理员账户和测试用户添加为 Azure AD 域服务管理员组成员：

Azure AD 域服务管理员组成员

总结应如下所示：

配置总结

接下来，你将被要求更新 DNS 配置为 Azure AD 域服务提供的 DNS 服务器地址。在我的案例中，这些地址是 192.168.0.4 和 192.168.0.5：

DNS 配置

要使用刚创建的域，你需要完成的最后一个重要步骤是启用密码同步：

同步用户的说明

默认情况下，Azure AD 不会存储 Kerberos 认证所需的凭证哈希。你需要将这些凭证哈希填充到 Azure AD 中，以便用户可以使用它们对域进行身份验证。该过程可以通过更改用户的密码来完成。你可以在 Azure AD 域服务中等待 20 分钟后使用这些账户。

你有两个选择：让所有用户的密码过期，或者指示这些终端用户更改其密码。

用户可以通过 Azure AD 访问面板页面使用 Azure AD 的自助密码更改机制更改密码。

测试并验证您的新 Azure AD 域服务

为了测试域服务，我们完成以下任务：

1. 在您的 Azure IaaS 环境中通过使用部署模板安装虚拟 Windows Server（docs.microsoft.com/en-us/azure/active-directory-domain-services/active-directory-ds-join-windows-vm-template）：

虚拟机部署配置

1. 在新加入的服务器上安装 Active Directory 和 DNS 管理工具：

Install-WindowsFeature RSAT-ADDS,DNS-Server-Tools

1. 连接到 Active Directory 用户和计算机（dsa.msc）以及组策略管理控制台，验证您的配置：

Azure AD 域服务结构，包括同步对象

1. 接下来，我们需要为我们的测试应用创建 DNS 主机（A）记录：

1. 现在，我们可以安装基本的 IIS 配置，用于处理 Kerberos 部分。为此，您需要安装 IIS 组件，选择 Kerberos 身份验证功能，并在默认网站上激活它。只需激活 Windows 身份验证即可：

IIS 身份验证配置用于 Kerberos 示例应用

1. 接下来，我们将安装并配置 Azure AD 应用代理连接器，为用户提供应用。我们使用以下 cmdlet 配置所需的基于资源的 KCD 功能：

# inovitcloudlabs represents the computer name
$ConnectorComputerAccount = Get-ADComputer -Identity inovitcloudlabs
Set-ADComputer inovitcloudlabs -PrincipalsAllowedToDelegateToAccount $ConnectorComputerAccount
setspn -S HTTP/kerb.inovitlabs.ch inovitlabs\inovitcloudlabs

1. 接下来，我们将激活并配置 Azure AD 应用代理。为了简化操作，我们禁用 IE 增强型安全配置，这样就无需提供任何 IE 安全区配置，仅限实验室使用：

服务器管理器 IE 增强型安全配置

1. 接下来，我们需要下载连接器并将其安装到服务器上：

应用代理代理下载与配置

要在服务器上配置连接器，您需要为用户提供全局管理员权限。

1. 安装并配置连接器后，我们将添加我们的示例应用：

Azure AD 应用代理连接器组配置选项

1. 接下来，我们按照以下方式配置我们的示例应用：

Kerberos 示例配置

1. 接下来，我们配置集成 Windows 身份验证（IWA）选项：

应用 IWA 配置

最后，我们分配一些用户或组，并在myapps.microsoft.com上测试应用程序。结果，您应该看到 IIS 测试页面。我们提供了一个基于 Kerberos 的应用程序到 Azure AD 域服务，并使用了 Azure AD 应用代理功能。

总结

完成此实施场景后，您将能够配置和管理一个适合的 Azure AD 租户，处理最重要的任务。您还将能够将 Windows 10 和 Office 365 集成，以便为用户建立一个高效的工作团队，而无需本地基础设施。如果您错过了某些功能，不用担心，这只是热身。

在下一章，我们将讨论启动混合集成所需的身份同步，并为您的需求提供正确的身份同步场景。

第二章：理解身份同步

混合身份和访问管理解决方案的主要组成部分是本地 Active Directory（AD）与 Azure Active Directory（AAD）之间的连接，包括对象和属性的相关同步。微软力图使同步过程简化，管理员无需了解系统内部的所有细节。

在本章中，我们将讨论实现完整的混合身份生命周期管理所需的基本身份同步场景和工具。我们将从Microsoft Identity Manager（MIM）和 Azure AD Connect 工具的概述开始，然后深入探讨身份同步场景。接下来，我们将介绍混合环境中 AD 用户账户清理的不同流程，以及 Azure AD Connect 中身份同步的所有关键部分和步骤。本章最后将提供许多实用提示和使用案例。

我们将涵盖以下基本主题：

• 技术概述

• 同步场景

• 同步术语和流程

在第一部分中，我们将从技术概述开始。

技术概述

Microsoft Identity Manager（MIM）2016 或其他身份管理产品通常用于为云同步准备存储在本地 Active Directory 中的身份。Azure AD Connect 工具通常用于将 AD 身份同步到 Azure AD，以便在连接的软件即服务（SaaS）应用程序或其他功能中使用。MIM 2016 为该解决方案提供的主要优势是，通过工作流支持业务流程，帮助进行域/林整合、属性标准化，以及完整的本地身份管理。

如下图所示，MIM 2016 同样能够与 Azure AD 同步身份。因此，你可能在想，应该使用哪个工具来同步 Azure AD 的身份。

对于常见场景，简短而实际的答案是 Azure AD Connect 工具，因为它支持 Microsoft Azure AD 提供的所有同步功能。

下图展示了两种工具的使用场景示意图：

身份同步架构

Azure AD Connect 不提供活动用户回写。您会发现此选项在 Azure AD Connect 配置中被禁用。要添加此功能，您可以像在 Azure B2B 用户管理中一样，使用 MIM Graph API 连接器，将来宾用户回写到您的 AD 中。要查看工具之间的比较，请访问Hybrid Identity 目录集成工具比较.，并参考混合身份目录集成工具比较。

微软身份管理器（MIM）2016

MIM 2016 是微软的主要身份与访问管理产品，提供了在这一领域所需的所有不同服务器角色和组件。MIM 2016 主要用于在本地环境中提供一个清洁的、集中的身份。在混合架构的上下文中，它在连接任何存储库以管理不同存储库中的身份方面发挥着至关重要的作用。此外，该组件还提供复杂的身份管理场景。这也包括今天市场中 Azure AD 和许多 SaaS 应用程序的管理，您可以在以下图表中看到：

身份管理器功能和对象

以下部分简要概述了 MIM 2016 的关键组件，帮助解决方案架构师/工程师识别设计蓝图中可能的交互或需要包含的元素。我们也在书中提供的实施指南中使用了一些组件，例如在第八章，使用 Azure AD 应用程序代理和 Web 应用程序代理，在其中我们实现了 Azure AD 的企业对企业（B2B）场景。

MIM 2016 提供的主要功能集如下：

• 身份同步，包括提供/撤销权限

• 访问请求和访问策略管理

• 委派管理

• 自助密码重置和账户解锁

• 自助组管理

• 角色管理（RBAC，ABAC，SoD）

• 手动管理的组

• 基于管理者的组

• 基于条件的组（基于属性的访问控制）

• 限时组成员资格

• 证书管理

• 报告与合规性以及访问认证

如果您希望将 MIM 2016 作为您的中央身份管理系统，我们强烈建议您查看工作流活动库（WAL）microsoft.github.io/MIMWAL/。此外，Windows Server 2016 中新集成的特权访问管理解决方案与 MIM 2016 结合使用，为管理和限制行政账户的安全问题提供了一种非常有效的方法。

MIM 同步服务

MIM 同步服务是该产品的核心。您可以在一个中心身份存储中导入和聚合数据，该存储被称为元宇宙（MV）。该服务提供了一个暂存区，用于将连接的目录与元宇宙进行比较。此暂存区称为连接器空间（CS）。与任何存储库的连接是通过特定的连接器进行的，这些连接器也称为管理代理（MAs）。同步服务还负责所有连接存储库的数据完整性，包括对象的配置和撤销配置，以及它们的属性。您可以在 docs.microsoft.com/en-us/microsoft-identity-manager/supported-management-agents 查找可用连接器的概述。如果您需要自定义连接器，MIM 提供了一个开发框架以满足您的需求。

以下截图显示了可以连接的不同目录和系统的示例：

Microsoft 身份管理器同步服务管理器

请参考以下实用的注意事项：

• 默认情况下，MIM 同步服务是基于状态的系统：

  • 导入的数据将与之前导入的数据进行比较；差异表示源数据已被修改

  • 导入的数据将与之前导出的数据进行比较；如果没有差异，表示导出成功

• MIM 不是实时的；它使用可以配置的运行周期

MIM 同步可以通过同步服务扩展实现基于事件的工作方式，详情请参见以下章节。

MIM 同步服务扩展

要扩展 MIM 同步服务的功能，您可以使用 Lithnet AutoSync。Lithnet AutoSync 作为 Windows 服务运行，并与 MIM 同步服务一起工作。该服务使您能够自动执行 MIM 管理代理的运行配置文件。此外，Lithnet AutoSync 使您能够在 MIM 同步引擎检测到更改时自动执行导出和增量同步。现在，您拥有一个基于事件和支持运行周期的同步引擎。以下截图显示了在前面截图中看到的同步引擎配置：

Lithnet Autosync 管理控制台

若要了解更多关于 Lithnet AutoSync 工具的信息，请访问 github.com/lithnet/miis-autosync.

MIM 服务和门户

MIM 服务提供所有必要的策略和工作流功能。所有对象，如组、用户、工作流、请求和 MIM 中使用的其他资源，都存储为 MIM 服务数据库中的对象。这些对象可以通过典型的 CRUD（创建、读取、更新、删除）操作请求来修改，访问 MIM 服务 身份管理（IdM）平台。

使用 MIM 门户，用户通过网页浏览器与系统进行交互。使用方式取决于权限；用户可以被授予执行请求、响应审批请求、取消现有的待处理请求或管理 IdM 系统中的对象的权限：

Microsoft Identity Manager 标准门户

默认的 MIM 门户基于 SharePoint 解决方案，可以高度自定义。你可以在docs.microsoft.com/en-us/microsoft-identity-manager/reference/mim-portal-customizations找到一些示例配置。

MIM 服务扩展

Lithnet Forefront Identity Manager（FIM）/MIM 服务 REST API 是 FIM/MIM 服务的 简单对象访问协议（SOAP）/Windows 通信基础（WCF）端点的包装器，通过一系列标准的 HTTP 调用暴露创建、更新、删除和搜索功能。API 返回 JSON 格式的数据，兼容各种平台和服务。默认情况下，MIM 不提供 REST API 给 MIM 服务。通过这个扩展，你可以为 MIM 2016 添加自己的功能，例如我们所做的自定义门户，或者与 Power BI 和其他技术进行交互以提供定制解决方案。有关 Lithnet REST API for FIM/MIM 服务的更多信息，请访问 github.com/lithnet/resourcemanagement-webservice。

MIM 密码重置与用户账户解锁

MIM 提供两项与密码相关的功能，可以帮助你在本地环境中提供解决方案：

• 密码同步：基于 AD 密码更改或重置，将密码同步到其他存储库

• 密码与账户自助服务：独立门户提供自助密码重置和账户解锁功能

以下截图展示了基于网页的密码重置和账户解锁功能：

Microsoft Identity Manager 自助密码重置对话框

特别是，如果你的环境中有较旧的 Windows 客户端，如 Windows 7 或 Windows 8/8.1，你可以在 Windows 登录界面提供密码重置功能。Azure 中的密码重置功能仅支持 Windows 10 客户端，但提供比 MIM 解决方案更多的验证选项。

请注意，MIM 2016 无法提供类似 Azure AD Connect 在混合场景中的密码哈希同步。

MIM 特权访问管理

MIM 2016 提供了一种特权访问管理（PAM）解决方案，限制现有 AD 环境中的特权访问。

PAM 解决以下两个目标：

• 如果提供一个与恶意攻击隔离的单独堡垒环境，您可以恢复对受损 AD 环境的控制权

• 通过隔离特权账户，您可以限制丧失敏感凭据的风险

PAM 有助于解决以下问题：

• Pass-the-hash 和 Pass-the-ticket 攻击

• Kerberos 妥协或鱼叉式网络钓鱼

• 未经授权的权限提升

• 其他漏洞和攻击

以下截图展示了 MIM PAM 示例门户中的角色激活和用户验证过程，您可以根据需要自定义：

MIM 特权访问管理示例门户

现在您已经了解了 MIM 的标准功能，我们将为您提供我们与合作伙伴公司共同开发的额外解决方案概述。希望它能给您提供一些关于 MIM 的扩展可能性的想法。

额外的解决方案

基于我们多年在身份和访问管理领域的经验以及成功实施的项目，我们决定在我们的解决方案中映射出那些常见需求，以填补我们无法通过 MIM 标准功能满足的空白。

以下五个关键支柱将由我们的解决方案提供，使我们能够实现高度标准化、灵活且可定制的身份和访问管理流程：

Inovit 身份解决方案——构建模块

组织管理及前端的主要功能如下：

• 支持多种云场景和传统 IT 基础设施

• 组织结构的表示（参数化和继承）

• 组织结构管理（手动或同步）

• 允许您构建高效的基于角色的访问控制

• 使您能够提供有利的成本管理

• 用户友好且高度响应的前端

• 单页应用（SPA）架构

• 集成的治理功能

• 不需要安装 SharePoint

• 高度可定制

• 用于本地或仅云部署的单一前端

• 明确的未来投资策略

• 云管理

以下截图示意性地展示了前端：

身份目录 SPA 门户

用户管理的主要功能如下：

• 标准流程（入职、变更、离职）

• 有时间限制的用户账户

• 标准和管理员用户账户管理

• Azure B2B 账户管理

• 自动生成samAccountName和用户

• 为云使用对齐 UPN、电子邮件和 SIP

• 密码重置和账户解锁

以下截图简要显示了前端中的位置和角色分配：

身份管理服务基于职位的访问管理

访问管理的主要特点如下：

• 基于职位、角色和属性的访问管理

• 权限直接分配给用户（如有需要）

• 审批和通知工作流支持

• 特权账户的管理

• 授权的直接视图和报告

• 与 SharePoint 和 Microsoft Teams 等服务的双向接口

服务管理的主要特点如下：

• 系统和服务的自动化和简便适配

• 服务目录的表示

• 基于同步的订单单元

• 基于工作流的订单单元（通知和审批）

• Office 365 和其他云服务的管理

基于身份管理服务的云部署

通过我们的基于 Azure 的下一代 SaaS 集成，您将能够选择从哪里开始实施，无论是基于 MIM 的本地部署还是直接在云端。也将有一个完全支持的云过渡路径。在 Azure 上，我们使用身份管理服务和 Cosmos DB 后端，它提供与您现有的本地 MIM 平台相同的功能和额外的功能。高度响应的前端对用户没有任何变化。

基于 MIM 2016 的本地部署

MIM 2016 代表了微软的本地身份和访问管理解决方案。MIM 2016 为我们的本地部署方法构建了基础平台。借助强大的同步框架和众多接口，如 REST、SOAP、LDAP、SQL、PowerShell 和基于文件的接口，您可以协调 AD 身份与 Azure AD 的同步。MIM 2016 服务提供了一个主导的工作流组件，它基于状态和事件工作，以解决您的业务的身份和访问管理需求。通过 MIM 2016，您可以受益于云就绪身份、强大的用户自助服务和增强的安全性。

现在我们已经快速了解了 MIM，以及用于准备和管理 AD 对象的其他可用扩展和解决方案，我们将继续连接到 Azure AD。

Azure Active Directory Connect

Azure AD Connect 是构建混合云身份和访问管理的身份桥梁的一部分。此工具的主要目的是将本地身份同步到云，并限制回 AD。Azure AD Connect 还能够安装和配置整个身份桥梁。这意味着你还可以使用此工具安装和配置Active Directory 联邦服务（ADFS）基础设施，以进行联邦操作，或者结合无缝的单点登录（SSO）使用通行身份验证，从而提供现代且舒适的身份验证场景。这些工具还能够集成外部联邦工具，如 PingFederate。

以下截图为你提供了 Azure AD Connect 组件的示意图，我们将在本章中解释其实际使用：

Azure AD Connect 同步架构概览，包括管理功能

以下术语在前图中使用：

• 连接的数据源（CD）：可以通过存储库、目录、数据库或包含在平面文件中的数据来表示的数据源。

• 管理代理或称为连接器（MA）：管理代理（MA）是连接到 CD 的连接器，并管理与连接数据源相关的数据。目前，AD 和 Azure AD 是支持的 MAs，如你在这里看到的：docs.microsoft.com/en-us/microsoft-identity-manager/reference/microsoft-identity-manager-2016-connector-version-history。

• 连接器空间 (CS)：表示存储和暂存区。它存储指示 CD 中某一信息是否已更改的状态。每个 CD 在 CS 中都有其逻辑区域。

• 元宇宙： 中央数据存储，包含来自所有连接数据源的已导入和汇总的身份信息。它提供了所有对象和属性的全局视图。

• 暂存： 如果你在 MA 上运行暂存导入操作，如完全/增量导入（仅暂存），数据将从连接目录（CD）导入到 CS 中，但不会应用任何同步规则。因此，暂存导入不会影响元宇宙。

• 导入： 将来自连接数据源的对象和属性移动到连接器空间的过程，包括相关操作，如创建、修改、删除或验证。导入过程可以是完全导入或增量导入。

• 同步： 将所有配置的规则应用于连接器空间中的暂存对象的过程。同步可以分为入站和出站过程。

• 导出： 将同步过程中发生的更改从 CS 写回到连接数据源的过程。

同步场景

在创建新的 Azure AD 租户时，默认情况下，目录信息与本地 AD 林的管理是独立的。因此，基本上，必须在两个目录中创建一个新用户：Azure AD 和本地 AD。除非你经营一个纯云公司，否则你总是需要将本地 AD 的身份同步到你拥有的 Azure AD 租户，以提供单一身份。在同步过程完成后，Azure AD 和 AD 可以视为一个独特的身份服务。接下来的部分为你提供了几种集成场景，包括用户登录选项。我们将这个部分分为以下几种情况：

• 单森林集成

• 多森林集成

• 多 Azure Active Directory 集成

• Azure Active Directory 域服务集成

• 扩展的 Active Directory 到 Azure IaaS

• Azure Active Directory B2B 集成

• Azure Active Directory 和 Microsoft Office 365 同步

• 包括 SSO 选项的身份和密码哈希同步

• 包括 PingFederate 集成的身份同步

• 包括 ADFS 集成的身份和密码哈希同步

• Azure Active Directory Connect 高可用性

让我们从单森林集成开始。

单森林集成

单森林场景是最常用的场景。单一森林可以包含一个或多个域，并且只需一个 Azure AD 实例。Azure AD Connect 的快速设置支持这种场景。我们建议过滤对象，以便服务账户、计算机或其他对象不会同步到云：

Azure AD Connect 单森林集成场景

额外的 Azure AD Connect 服务器连接到相同的 Azure AD 不被支持。排除的是使用 Azure AD Connect 阶段模式的高可用性选项，这将在Azure Active Directory Connect 高可用性一节中解释。

多森林集成

较大的组织或分布式组织通常会有多个本地 AD 环境。它们通常用于账户/资源林，或者通过并购而来。这些规则需要遵循：

• 用户在所有本地 Active Directory Forests 中仅有一个启用的账户

• UserPrincipalName 和源锚点将由森林提供

• 用户只有一个邮箱

• 拥有关联邮箱的用户在不同的森林中也有账户

• 不需要在加入域的服务器上使用 Azure AD Connect

下图展示了账户/资源林场景：

Azure AD Connect 多森林集成场景

记住：一个 Azure AD 上不支持多个林和多个Azure AD Connect工具。唯一的例外是使用暂存服务器。暂存服务器可以为高可用场景（主动/被动）进行配置。在此场景中，暂存服务器不会将信息导出到目标系统。

如果你有多个林，只有一个同步服务器，并且用户仅在一个目录中表示，并且你选择了“用户在所有目录中只表示一次”选项，那么每个林中的每个对象在元宇宙中只表示一次，并且会在目标 Azure AD 租户中聚合：

包括同步映射的 Azure AD Connect 多林集成场景。

如果你有多个林，并且有可选的 GALSync，则应使用“用户身份在多个目录中存在”选项。

如果你使用邮件属性作为匹配标准，身份对象将与邮件属性连接。这将导致以下行为——在一个林中的邮箱用户与其他林中的联系人进行连接：

多林集成场景（邮件属性映射）。

确保对象在 AD 林中是唯一的非常重要。如果每个林中的对象都是唯一的，你就处于一个良好的位置。通过对象匹配和连接，当使用云服务时，你可以提供一个良好的状态。通过连接，优先级的同步规则也会发挥作用。如果你基于邮件地址和特定属性值连接两个对象，其中对象 1 没有填写而对象 2 已填充，则将使用对象 2 的属性值。但如果两个对象都用不同的值填充了该属性呢？这时优先级规则就会生效。

优先级较高的规则会晚于优先级较低的规则执行。

优先级会在将林添加到 Azure AD Connect 时设置。因此，如果对象 1 的林在对象 2 的林之前添加，则对象 1 的值将胜出。前面的图示展示了这个场景。

其他对象是联系人，你会在实现了两个林之间的全局地址列表（GAL）同步的场景中找到这些联系人。Azure AD Connect 提供了以下默认行为：

• 如果 Azure AD 联系人发现联系人与用户匹配，将会进行连接。

• 如果没有用户对象可用，将会创建一个联系人对象。

• 如果找到了一个后续的用户对象与联系人匹配，则会在 AAD 中创建一个用户对象。

• 如果你有一个帐户/资源林场景，并且使用了“用户身份在多个目录中存在”选项。

如果使用 ObjectSID 和 msExchangeMasterAccountSID 属性的匹配标准，预期结果是用户将在此林中被禁用。此外，邮箱将与账户林关联。用户将在 Azure AD 中唯一展示：

账户/资源林集成场景

上图还显示了 Azure AD Connect 在检查 AD 对象是否为链接邮箱之前的行为。它将尝试匹配 msExchMasterAccountSID。这将通过 recipientTypeDetails 属性完成。2 的值表示它是一个链接邮箱。请记住，禁用的用户账户默认也会同步到 Azure AD。停用的账户通常用于 Exchange-资源林部署。账户林持有活动用户账户，资源林持有禁用的用户账户。我们将在 第三章《探索高级同步概念》中讨论规则优先级。

多 Azure Active Directory 集成

有时您需要多个 Azure Active Directory，例如，如果您的组织部分位于中国，或者您需要遵守政府法规。对于每个 Azure AD 目录，您需要进行一次 Azure AD Connect 安装。

在单林过滤场景下，若要连接多个 Azure AD，需要执行以下操作：

• 必须为 Azure AD Connect 配置过滤

• DNS 域注册只能在单个 Azure AD 中进行

• 本地用户的 UPN 必须使用不同的命名空间

• 联邦配置需要自定义

• 一个 Azure AD 目录可以启用与本地 AD 的 Exchange 混合

• 全局地址列表同步需要通过 MIM 2016 执行

• Windows 10 设备只能与一个 Azure AD 租户关联

• 启用密码哈希同步和直通身份验证的 SSO 选项只能与一个 Azure AD 租户一起工作

• 可以实现组和设备的写回场景

下图显示了多个 Azure AD 的情况：

将多个 Azure AD 连接到一个 AD 林

不支持将同一用户同步到多个 Azure AD。

Azure Active Directory 域服务集成

此服务提供在 Azure 中将 AD 域服务作为服务使用的功能。它提供两个域控制器，并具有较小的管理选项。它与您的 Azure AD 直接集成。它是完全迁移到云端的一个优秀选项，适用于您所有的本地使用场景。这为小型公司提供了一个没有本地基础设施的机会。试想一下，主遗留的 LOB 现在可以在 Azure AD 集成场景中使用，并且一切都将在服务条件下管理：

Azure AD 域服务集成场景

该解决方案提供了支持 NTLM/Kerberos 和 LDAP 应用程序的功能。您还可以在打印解决方案的示例中安全地暴露 LDAP。我们在第一章《构建和管理 Azure Active Directory》中使用了这个选项。请注意，您需要在 Azure AD Connect 中启用密码哈希同步选项，以便用户可以在 Azure AD 和 Azure AD 域服务之间成功同步。此外，您还可以享受以下附加功能：

• AD 账户锁定保护—如果在 2 分钟内输入 5 次无效密码，用户将被锁定 30 分钟。账户将在 30 分钟后自动解锁。

• 自定义 组织 单位（OUs）—您可以创建多个 OUs。

• 组策略支持—您可以使用组策略来管理服务器。

将扩展的 Active Directory 迁移到 Azure IaaS

将本地 AD 域服务扩展到 Azure IaaS 为您提供了一个非常灵活的场景，可以在云端使用您的业务应用程序。要使用此集成，您需要建立到 Azure 的 VPN 或 Express Route 连接。

域控制器是非常敏感的角色，关于服务的信任问题是最需要关注的方面。许多替代方案不支持像这种一样无缝的迁移到 Azure：

将您的 Active Directory 扩展到云端

请参考以下注意事项：

• 域控制器 (RW)：这是 IaaS 工作负载的最佳选择，并且会考虑到您的复制要求

• 域控制器 (RO)：通常用于安全性较差的场景，并且不适合 IaaS 工作负载

• 资源林场景：不建议在 IaaS 中使用

在下一节中，我们将详细介绍 Azure AD B2B 集成场景。

Azure Active Directory B2B 集成

Azure AD B2B 允许任何合作伙伴在协作场景中使用他们自己的身份和凭据。关于认证流程和功能，我们将在第八章《使用 Azure AD 应用程序代理和 Web 应用程序代理》和第十章《探索 Azure AD 身份服务》中进行更深入的探讨。现在，我们先简要概述一下同步部分：

Azure AD B2B 本地应用程序访问场景

对于Azure AD B2B 用户使用本地 Kerberos 应用程序，我们需要将来宾用户账户同步回本地 Active Directory。为此，您需要在本地 AD 中提供您的默认 Azure AD 域后缀。在我们的案例中，它是inovitcloudlabs.onmicrosoft.com。您可以在 AD 域和信任控制台中找到该选项：

将你的 Azure AD 租户后缀添加到本地 UPN 后缀

注册新的 UPN 后缀是必要的，因为 Azure AD 应用程序代理会检查本地 AD 是否存在来宾用户 UserPrincipalName，例如 jochen.nickel_inovit.ch#EXT#@inovitcloudlabs.onmicrosoft.com。

微软提供了一个默认的解决方案，用于将来宾用户同步回本地 AD；可以查看bit.ly/2Bor7xy。该解决方案包含了所需的 MIM 2016 配置或脚本来成功部署该解决方案。别担心，稍后我们将在本书中完成默认配置和扩展。

Azure Active Directory 和 Microsoft Office 365 同步

以下场景适用于大多数 Office 365 服务，因为每个服务都会在 Azure AD 内部使用自己的目录来存储和管理身份。特别是对于 SharePoint，我们在用户资料应用程序中需要许多额外的属性，但无法配置 Azure AD 与 SharePoint Online 之间的同步。你可以在support.office.com/zh-cn/article/information-about-user-profile-synchronization-in-sharepoint-online-177eb196-5887-43c9-84c3-b98a43d35129找到所有默认属性。以下图示展示了 SharePoint Online 同步的场景：

Azure AD 到用户资料应用程序同步扩展

其中一个选项是使用微软 Azure AD Graph API 扩展同步部分。在我们的案例中，我们使用了基于 Azure Functions 和 Logic Apps 的完整无服务器解决方案。

身份和密码哈希同步，包括 SSO 选项

通过将身份和关联的密码哈希从本地 AD 同步到 Azure AD，我们可以为不想投资 ADFS 基础设施的小型公司构建一个基本场景。此外，无需 SSO。使用此场景时，可以使用相同的密码来验证用户，无论是在云端还是本地，具体取决于访问的是哪个资源。此外，密码重置和账户解锁功能在拥有 Azure AD Premium 许可证的情况下可用。要求是启用密码哈希同步的 Azure AD Connect。可选的密码写回功能已启用。

对于此过程，存在重新哈希功能，它允许用户在本地 AD 和 Azure AD 中具有两个不同的哈希值。此外，还支持多林同步。

以下图示展示了身份和密码哈希同步场景：

Azure AD Connect 密码哈希同步场景

若要将 SSO 添加到解决方案中，可以在 Azure AD Connect 工具中启用透传认证和无缝 SSO 功能。这是微软最常推荐的选项，用于减少复杂性，并将 Azure AD 作为提供身份验证的中央系统，支持您的 SaaS 和本地 Kerberos/基于声明的应用程序：

启用 PTA 和无缝 SSO

强烈建议启用密码哈希同步，这样在本地服务中断时，用户仍然可以使用云服务。现在，您可以通过docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-pta了解此功能。

包括 PingFederate 集成的身份同步

微软现在直接将非微软产品集成到 Azure AD Connect 中。第一个集成的产品是 PingFederate，市场上非常流行。目录同步没有变化——您启用 PingFederate 作为您的联合提供商，而不是 ADFS：

集成 PingIdentity 进行联合身份认证和基于标头的认证

微软在这次合作中做出的主要决策是，逐步向混合身份管理方式转变，以帮助您快速启用 Microsoft 和其他云服务。

包括 ADFS 集成的身份和密码哈希同步

在实现联合身份认证后，所有认证都保留在本地，所有密码仅存储在本地。所有认证流量都会从 Azure AD 重定向到本地 ADFS，后者将用户认证到受信任的 AD 域。此场景通常适用于不同规模的公司，如果需要 SSO 且出于安全原因禁止密码哈希同步时。

要求是在高度可用的部署中，除了 Azure AD Connect 外，还使用联合服务提供商，如 ADFS。

下图显示了与 ADFS 场景下的身份和密码哈希同步：

将联合身份认证与密码哈希同步结合

您还可以将 ADFS 集成与密码哈希同步结合，以便在本地基础设施出现故障时，用户仍然可以通过已知密码访问云服务。

Azure Active Directory Connect 高可用性

出于高可用性考虑，新的 Azure AD Connect 服务器可以在几个小时内重建并重新同步，适用于小型或中型企业。

请记住，sourceAnchor 属性用于连接本地和云端的对象。同步引擎在重新安装时会再次将这些对象匹配起来。

记录你的配置更改（如特殊过滤或同步规则）非常重要。在开始同步过程之前，你需要重新应用这些设置。你可以使用 Azure AD Connect 文档工具（github.com/Microsoft/AADConnectConfigDocumenter）来保存你的更改。

对于拥有超过 100,000 个用户、组和其他对象的大型组织，重新构建同步会花费更多时间。如果需要更快的恢复时间，可以将 Azure Active Directory Connect 配置为使用专用的 SQL 服务器部署并启用 SQL 高可用性。此选项可以直接提供所需数据。超过 100,000 个用户时，必须使用 SQL 服务器，因为大型组织希望同步服务的恢复时间较短。

提供高冗余系统的另一种方式是使用另一台安装并配置为暂存模式的 Azure Active Directory Connect 服务器。此功能还可以缩短恢复时间。

以下图示显示了暂存模式配置：

启用 HA 的暂存模式

在 Azure AD Connect 版本 1.1.524.0 中，微软添加了 SQL 始终在线可用性（AOA）组支持。SQL 群集在早期版本中已被加入。请注意，在安装 Azure AD Connect 之前需要启用 SQL AOA。

同步术语和过程

在本节中，我们将讨论并实现同步术语和流程的实际应用。我们将理论与实践直接结合。因此，我们将立即在 Azure AD Connect 工具中安装、配置并运行这些流程。为了使用这些指导，你应该部署一台启用域控制器角色的虚拟机。

在 Azure 或本地虚拟化平台上构建虚拟机。一个很好的选择是按照docs.microsoft.com/en-us/office365/enterprise/base-configuration-dev-test-environment上的指南进行操作，使用你免费的 Azure 或 MSDN 订阅。我们为你提供了本书代码包中的完整脚本解决方案，或者你可以按照第七章，在 Azure AD 和 ADFS 上部署解决方案中的说明操作。

我们使用了你在第一章中使用的相同域名，构建和管理 Azure Active Directory。在我们的案例中，我们使用的是域名inovitlabs.ch。因此，你需要根据自己的环境更改脚本。

现在我们已经建立了主要的测试环境，可以开始在域控制器上准备和安装 Azure AD Connect。我们使用这个场景来降低测试环境的成本。请注意，在接下来的章节中，我们将扩展测试环境，以展示本书中讨论的功能。

你准备好了吗？让我们准备域：

1. 使用域管理员凭据登录，并运行以下脚本来创建演示的组织单位结构：

New-ADOrganizationalUnit -Name "Managed Business Objects" -Path "DC=INOVITLABS,DC=CH"

New-ADOrganizationalUnit -Name "Users" -Path "OU=Managed Business Objects,DC=INOVITLABS,DC=CH"

New-ADOrganizationalUnit -Name "Groups" -Path "OU=Managed Business Objects,DC=INOVITLABS,DC=CH"

New-ADOrganizationalUnit -Name "Devices" -Path "OU=Managed Business Objects,DC=INOVITLABS,DC=CH"

New-ADOrganizationalUnit -Name "Managed Service Objects" -Path "DC=INOVITLABS,DC=CH"

New-ADOrganizationalUnit -Name "AAD" -Path "OU=Managed Service Objects,DC=INOVITLABS,DC=CH"

New-ADOrganizationalUnit -Name "Users" -Path "OU=AAD,OU=Managed Service Objects,DC=INOVITLABS,DC=CH"

以下图示显示了预期的结果：

Azure AD 服务组织单位

1. 启用活动目录回收站功能：

Enable-ADOptionalFeature –Identity 'CN=Recycle Bin Feature,CN=Optional Features,CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=inovitlabs,DC=ch' –Scope ForestOrConfigurationSet –Target 'inovitlabs.ch'

1. 创建组管理服务账户（gMSA）来运行 Azure AD Connect 服务。将计算机名称替换为你为测试环境选择的名称：

Add-KdsRootKey -EffectiveTime (Get-Date).AddHours(-10) 
New-ADServiceAccount -Name svcaadconnect -DNSHostname INOLABSADS01 -PrincipalsAllowedToRetrieveManagedPassword INOLABSADS01$

1. 创建活动目录管理代理的服务账户，用于连接并执行同步操作：

New-ADUser -Name "svcaadcadma" -SamAccountName svcaadcadma -UserPrincipalName svcaadcadma@inovitlabs.ch -path "OU=Users,OU=AAD,OU=Managed Service Objects,DC=inovitlabs,DC=ch" -AccountPassword (ConvertTo-SecureString "Pass@word1" -AsPlainText -Force) -Enabled $True 

活动目录管理代理账户需要在域级别配置正确的权限。

1. 配置权限以配置svcaadcadma Azure AD Connect 与活动目录用户和计算机控制台（dsa.msc）。不要忘记在查看选项下启用高级功能，这样你就能看到安全选项卡：

   • 复制目录更改

   • 复制目录更改全部

以下截图显示了预期的结果：

为 Azure AD Connect 活动目录管理代理服务账户分配正确的权限

现在我们已经完成了测试环境中的准备工作，让我们逐步通过以下部分进行理论解释和实际操作。在每个任务中，我们将使用相同的凭据在评估过的 PowerShell 会话中执行。

用户主体名称后缀决策

UserPrincipalName是本地 AD 与Azure AD连接中最相关的用户属性之一。Azure AD Connect 遵循以下规则：

用户主体名称决策路径

如前面的图示所示，AAD Connect 默认使用以下逻辑：

• 如果有 UPN 可用，它将被使用

• 如果 UPN 不可用，它将使用用户的sAMAccountName和连接 AD 域的完全限定域名（FQDN）

• 如果要导出到 Azure AD 的 UPN 未被验证，后缀将被替换为.onmicrosoft.com

记住，用户可以存在于任何已同步的林中，且它们包含UserPrincipalName和sourceAnchor。如果使用了联机邮箱，则会被忽略，因为同步引擎会找到用户的活动和停用账户表示。

活动目录准备

为了准备你的 AD 环境，你可以使用 IdFix 工具，可以从bit.ly/1VnsvVn下载。它会执行身份对象及其属性的发现和修复，准备同步到 Azure AD。IdFix 提供给计划使用 Azure AD Connect 与 Azure AD/Office 365 服务的 AD 管理员。你可以在每种同步场景中使用该工具：

IdFix 工具发现的错误用户账户

为了测试 IdFix 工具，我们将使用以下脚本创建一些错误的测试用户：

New-ADUser -Name "James Meyers" -GivenName J. -Surname Meyers -SamAccountName jmeyers -UserPrincipalName james.meyers@local -path "OU=Users,OU=Managed Business Objects,DC=inovitlabs,DC=ch" -AccountPassword (ConvertTo-SecureString "Pass@word1" -AsPlainText -Force) -Enabled $True

New-ADUser -Name "Adrian Gilbert" -GivenName Adrian -Surname Gilbert -SamAccountName adrian.gilbert -UserPrincipalName "adrian.gilbert @inovitlabs.ch" -path "OU=Users,OU=Managed Business Objects,DC=inovitlabs,DC=ch" -AccountPassword (ConvertTo-SecureString "Pass@word1" -AsPlainText -Force) -Enabled $True

New-ADUser -Name "Wilma Chavez" -GivenName Wilma -Surname Chavez -SamAccountName wilma.chavez -UserPrincipalName "wilma.chavez°@inovitlabs.ch" -path "OU=Users,OU=Managed Business Objects,DC=inovitlabs,DC=ch" -AccountPassword (ConvertTo-SecureString "Pass@word1" -AsPlainText -Force) -Enabled $True

以下截图显示了预期的结果：

损坏用户账户的创建结果

现在我们可以运行 IdFix 工具，检查本地 AD 中是否有用户会在同步过程中出现错误：

在损坏的用户账户中发现的错误

测试完 IdFix 工具后，请删除创建的测试用户账户。

在接下来的步骤中，我们将开始安装 Azure AD Connect 工具：

1. 运行 Azure AD Connect 安装程序。请从www.microsoft.com/en-us/download/details.aspx?id=47594下载实际版本的工具并使用域管理员凭据启动安装。

2. 选择自定义安装选项，以便查看所有必要的配置步骤。我总是使用自定义选项，而不是快速安装选项。

3. 使用在之前步骤中创建的 gMSA 来配置 Azure AD Connect 服务：

服务账户配置

1. 此时，我们未设置任何用户登录选项：

用户登录配置

在下一部分，我们将讨论 Source Anchor 决策过程，所以点击下一步并等待下一部分实验。

Source Anchor 决策

理解 Source Anchor 至关重要，因为它为 AD 域服务用户与 Azure AD 用户之间的关系奠定基础。sourceAnchor属性是不可更改的。请确保你的配置符合预期场景。

该属性为你提供以下功能：

• 支持更快的重建场景

• 支持从云端独立场景迁移到与硬匹配的同步场景

• 在联合身份验证场景中，它使用UserPrincipalName构建声明，以唯一标识用户

选择sourceAnchor属性时需要遵循以下规则：

• 少于 60 个字符

• 不允许使用特殊字符，如{, }, |, ~, <, >, (, ), ' ; : , [, ], ", @, _,, !, #, $, %, &, *, +, /, =, ?, ^, 或 `

• 全球唯一

• 字符串、整数或二进制

• 不应基于用户的名字，且区分大小写

• 在对象创建时分配

Azure AD Connect 使用以下默认设置作为 sourceAnchor 属性：

• Azure AD Connect（版本 1.1.486.0 及之前版本）使用 objectGUID 作为 sourceAnchor 属性

• Azure AD Connect（版本 1.1.524.0 及之后版本）使用 ms-DS-ConsistencyGuid 作为 sourceAnchor 属性

以下截图展示了 Azure AD Connect 安装向导中的配置：

Azure AD Connect 的 sourceAnchor 定义

管理代理用户账户必须被授予对本地 AD 中 ms-DS-ConsistencyGuid 属性的写权限。请记住，只有更新版本的 Azure AD Connect（1.1.552.0 及之后版本）支持将 sourceAnchor 属性从 ObjectGuid 切换到 ms-DS-ConsistencyGuid。

连接目录

来自 Azure AD Connect 的 同步引擎处理来自 AD 和 Azure AD 的身份。每个目录或数据源以其方式组织数据并提供不同的访问方法。与 Azure AD Connect 同步的数据存储库称为连接数据源或 连接目录（CDs）。Azure AD Connect 支持的两个 CD 是 AD 和 Azure AD。您可以连接任何其他存储库，但这在微软不支持的方式下进行。以下图示展示了同步的基本概念：

连接器和连接目录的基本概念

现在，让我们回到 Azure AD Connect 配置并重新登录到您的域控制器。

我们将配置这两个数据源：

1. 提供您的全球管理员凭据来自您的 Azure AD，并点击“下一步”：

将 Azure AD Connect 连接到 Azure AD

1. 连接本地 Active Directory：

连接本地 AD

1. 使用创建的 AD 管理代理账户进行此任务：

配置 AD 管理代理服务账户

1. 找到您的已验证自定义域，在我的例子中是 inovitlabs.ch：

定义登录选项

1. 在域和 OU 筛选页面，选择创建的“管理业务对象”OU。使用以下设置，任何新建的 OU 都不会包含在同步过程中：

OU 筛选选项

1. 使用以下选项，所有在“管理业务对象”下新建的 OU 都将包含在同步过程中：

OU 筛选选项的第二部分

1. 配置我们在 Source Anchor decisions 部分讨论过的 sourceAnchor ms-DS-ConsistencyGuid：

sourceAnchor 定义对话框

1. 在“筛选用户和设备”部分，选择默认选项。您也可以使用组选项进行概念验证：

过滤用户和设备对话框

1. 在可选功能部分，您会看到可用的同步选项，这些选项我们在集成方案中已经讨论过。请记住，您需要正确的权限来让活动目录管理代理帐户回写到本地 AD：

Azure AD Connect 可选功能部分

1. 点击下一步以完成配置。确保不要启用同步过程，因为我们是按步骤进行的。

在完成 Azure AD Connect 安装向导后，这些目录将会被连接，并且可以在连接器下的同步服务管理器中查看：

Azure AD Connect - 连接的目录

安装和配置 Azure AD Connect 工具后，我们可以深入研究同步的详细部分。在即将到来的第三章《探索高级同步概念》中，我们将启用可用的回写、扩展和过滤选项。

导入流程

内部同步引擎包含两个命名空间，用于存储身份信息：CS 和元目录（MV）。CS 用于检测连接数据源中的更改。连接器空间还用于导出过程中对外部更改的处理，以更新连接数据源。

数据可以单向流动，但不能同时双向流动。

简单回顾一下：MV 是一个存储区域，其中包含来自多个连接数据的聚合身份信息。非常重要的是要理解每个同步引擎对象必须具有数据集成的全局唯一标识符（GUID）以及对象之间的关系。

导入过程是在连接的数据源和连接器空间之间完成的。因此，我们提供了有关连接器空间的一些信息。

连接器空间对象具有两个属性：

• 全局唯一标识符（GUID）

• 区分名称（DN）

CS 对象可以是以下之一：

• 一个 CS 对象

• 一个占位符

下图显示了同步引擎的示意图：

同步引擎概述

现在让我们看看导入流程的实际操作。请记住，我们已经在我们的 Azure AD 中有来自第一章《构建和管理 Azure AD》的用户：

1. 登录您的域控制器并打开 Azure AD Connect 同步服务管理器。

2. 在连接的活动目录上运行完整导入：

完整导入配置文件运行

1. 同步引擎将组织结构（占位符）导入 CS：

完成完整导入后的统计信息

1. 您可以看到导入的组织结构：

导入的对象

1. 对连接的 Azure Active Directory 执行完全导入：

Azure AD 完全导入

1. 在 CS 中不会创建对象。请记住，我们已经在 Azure AD 中拥有用户—不支持用户回写：

完全导入 Azure AD 统计信息

此外，在导入流程中与 MV 不会有任何交互。在下一部分，您将进一步了解占位符对象。

占位符对象

占位符对象的一个示例是验证 AD 对象路径的容器。我们还可以谈论一个占位符对象，它是经理属性所引用的对象。通常，我们可以说占位符对象不包含值，并且与 MV 不关联。

运行配置文件—每个森林一个，每个域一个步骤：

• 我们将所有对象导入（暂存）到 CS 中（即使通过连接器筛选器进行过滤）

• 完全导入—所有对象

• 增量导入—仅更改的对象

接下来，我们将进入同步流程部分。

同步流程

同步流程是特定于 CS 和 MV 对象之间的处理流程。通常，我们可以说多个 CS 对象可以链接到一个 MV 对象。这是典型的，因为 MV 代表所有连接系统中的唯一身份对象。另一方面，CS 对象不能与多个 MV 对象链接，如下图所示：

同步流程概览

同步流程是通过同步规则配置的，您可以在 Azure AD Connect 同步规则编辑器中查看这些规则：

同步规则编辑器概览

在第三章，深入探讨高级同步概念，我们将详细讨论同步规则。现在，我们将专注于主要功能和解释。

入站同步

入站同步由一组同步规则定义，并包含以下图示中的术语。如果我们使用入站同步，同步引擎将根据 MV 和 CS 之间的变化进行更新。入站同步发生在使用 CS 中的数据更新 MV 内容时：

入站同步概览

预配的另一个术语是投影，它是出站同步的一部分。我们还可以说，预配是一个对象级操作，因为同步引擎根据 CS 中的对象在 MV 中创建一个新对象，并在它们之间创建链接。加入是一个特殊过程，创建该链接。因此，加入也是一个对象级操作。导入属性流用于同步引擎更新 MV 对象的属性值。我们可以说导入流是基于属性级别的，并且需要 CS 和 MV 对象之间的链接。

让我们来看看我们的 Azure AD Connect：

1. 登录到你的域控制器并打开 Azure AD Connect 同步服务管理器。

2. 在本地 AD 上运行完整同步：

本地 AD 的完整同步运行

1. MV 上没有发生任何变化。你只会找到组织结构的 5 个断开连接的项（占位符）：

完整同步统计信息

让我们创建一个与 Azure AD 中现有用户具有相同UserPrincipalName的测试用户。在我的例子中，我使用的是jochen.nickel@inovitlabs.ch：

New-ADUser -Name "Jochen Nickel" -GivenName Jochen -Surname Nickel -SamAccountName jochen.nickel -UserPrincipalName jochen.nickel@inovitlabs.ch -path "OU=Users,OU=Managed Business Objects,DC=inovitlabs,DC=ch" -AccountPassword (ConvertTo-SecureString "Pass@word1" -AsPlainText -Force) -Enabled $True

1. 在本地 AD 上运行 Delta 导入：

本地 AD 的 Delta 导入统计信息

1. 在本地 AD 上运行 Delta 同步：

本地 AD 上的 Delta 同步统计信息

在实际状态下，我们将在 Azure AD 中对用户进行预配。因此，我们需要在 Azure AD 上运行完整同步，以获取所有更改。此过程可以避免错误的预配，因为我们希望基于UserPrincipalName来加入用户。

1. 在 Azure AD 上运行完整同步：

完整同步统计信息

1. 点击“没有流更新的连接器”并检查更改。

2. 在 Azure AD 上运行导出，这将识别用户将通过UserPrincipalName进行加入。我们通过 Metaverse 搜索来证明这一点：

Metaverse 搜索选项

你已经同步了第一个用户，包括一个加入操作！你可以继续将所有帐户映射。这就是如何将现有的本地帐户与 Azure AD 帐户进行映射。

如果你在 AD 上运行导出，你将收到一个权限问题错误：

导出 AD 统计信息

修改 cmdlet 以适应你的环境，并执行它们以授予 AD 管理帐户写入ms-ds-consistencyGuid的权限：

$accountName = "INOVITLABS\svcaadcadma"
$ForestDN = "OU=Managed Business Objects,DC=inovitlabs,DC=ch"
$cmd = "dsacls '$ForestDN' /I:S /G '`"$accountName`":WP;ms-ds-consistencyGuid;user'"
Invoke-Expression $cmd

再次在 AD 上运行导出，错误将消失。

你也可以使用电子邮件地址或将ImmutableId写入 PowerShell 脚本。你可以使用以下脚本：gallery.technet.microsoft.com/scriptcenter/Convert-between-Immutable-e1e96aa9，或者使用以下过程：

$guid = (Get-ADUser -Identity jochen.nickel).ObjectGUID
$immutableid=[System.Convert]::ToBase64String($guid.tobytearray())
Set-MsolUser -UserPrincipalName jochen.nickel@inovitlabs.ch -ImmutableId $immutableid

在你成功连接所有用户后，可以使用以下 PowerShell 命令运行完整的默认同步周期：

Start-ADSyncSyncCycle -PolicyType Initial

如果你在 Azure AD Connect 的安装和配置向导中启用了同步，那么这种情况将会发生。

默认情况下，Azure AD Connect 同步引擎调度程序在首次运行时会运行以下操作：

• AD—完全导入

• AAD—完全导入

• AD—完全同步

• AAD—完全同步

• AAD—导出

• AD—导出

现在我们完成了实际任务，接下来看一下其余的理论信息。

出站同步

使用出站同步时，当 MV 对象发生更改但未被删除时，你会更新导出的对象。出站同步的主要目的是检查 MV 对象的更改，这些更改需要在 CS 中进行更新。

使用出站同步时，我们使用以下三种过程。如果对 MV 中的对象应用更改，你将获得一个配置过程。去配置过程始终取决于配置过程本身，因为只有配置过程才能启动导出属性流。在导出时，CS 中的对象会被标记为待导出标志，使它们成为导出对象。你可以在下图中看到这个过程：

出站同步概览

如果 MV 对象发生更改，同步引擎可以在配置过程中创建已连接对象。此外，同步引擎还可以重命名已连接对象并解除连接对象。

连接

连接是一个非常好的功能。我们称在 CS 中与 MV 中的对象连接的对象为已连接对象。否则，它就是一个解除连接对象。下图展示了连接的概念：

连接概览

通过同步过程，来自 CS 的对象将成为已连接对象。在这种情况下，相关属性可以流动，属性流是双向的。

解除连接对象的使用方式使得关于对象的必要信息已经被存储，并且它们可以双向转换。通过导入，你总是会创建一个解除连接的对象，同时也会有导出操作。

连接器对象

现在我们已经讨论了连接操作，接下来我们将解释不同的连接器对象，它们被系统用来在连接器空间和元宇宙对象之间建立连接。

有两种类型的连接器对象：

• 连接器

• 显式连接器

连接器是 CS 中的一个对象。该对象与 MV 中的一个对象相连接，因此每个规则都适用于该对象。此外，还存在显式连接器。通过这种类型的连接器，对象与 MV 中的对象相连接。此类型的连接器只能通过 Joiner 功能创建，而该功能在 Azure AD Connect 中不可用。

断开器对象

断开器对象有三种类型：

• 断开器

• 显式断开器

• 过滤断开器

当 CS 中的对象没有与 MV 中的对象链接时，我们称之为断开器。显式断开器也是 MV 中没有链接的对象，只能通过同步引擎的 Joiner 工具集进行连接。此功能在 Azure AD Connect 中不可用。过滤断开器的含义是 CS 中的一个对象，该对象被阻止与 MV 中的对象进行连接或投影。

导出流程

在导出过程中，同步引擎会检查所有在 CS 中标记为待导出的导出对象，并将更新发送到数据源：

导出流程概览

此时，同步引擎只能验证导出是否成功。它需要一个导入来证明导出的值已正确传输到存储库：

导入流程以证明导出

现在，您已经掌握了关于 Azure AD Connect 和同步任务的基本信息，我们将深入探讨同步规则编辑器的详细内容，参见第三章，探索高级同步概念。

总结

本章中，我们讨论了最重要的身份同步工具：Microsoft Identity Manager 和 Azure Active Directory Connect。我们走过了典型的同步场景。现在你能够根据你的需求选择最合适的场景。在同步术语和流程部分，我们深入探讨了同步服务，这样你就能准确了解幕后发生的事情，这将帮助你避免错误并提供更好的同步故障排除。

在下一章中，我们将探索更多的过滤、连接属性、声明式配置选项以及通用连接器的使用。

第三章：探索高级同步概念

在当前的项目和工作坊中，我们经常看到管理员或顾问发现处理 Azure AD Connect 同步引擎非常困难，特别是当向导配置的开箱即用功能在他们的场景中无法按预期工作时。本章将为你提供所需的所有知识，以便你能够处理基本和高级的同步需求。

本章我们将讨论高级同步概念。我们将研究同步规则，并结合实际情况提供信息和实践经验，帮助你解决项目或解决方案中的常见需求。此外，我们将解释声明式配置和表达式的概念，并在实际示例中直接使用它们。本章的另一个主题是连接到额外的不受信任的 Active Directory 林。最后，我们还会向你介绍需要处理的特殊注意事项。

本章的结构包括以下主题：

• 理解声明式配置和表达式

• 同步规则说明

• 高级同步概念中的特殊注意事项

我们将从准备实验环境的步骤开始。

准备实验环境

要按照本章提供的指导进行操作，我们需要安排一些准备工作。你需要提供一个额外的公共 DNS 后缀（在我的案例中是azureid.ch），代表YOURDOMAIN2.COM。我们需要将这个域名作为自定义域添加到第一个 Azure AD 租户（YOURDOMAIN1.ONMICROSOFT.COM）中，这个租户我们在第二章《理解身份同步》中使用过，理解身份同步**：

使用以下步骤开始配置：

1. 打开 Azure 门户：portal.azure.com.

2. 导航到 Azure AD 面板。

3. 点击“自定义域”。

4. 点击“添加自定义域”。

5. 使用你的额外域名：

添加自定义域

1. 配置你的公共 DNS，以代表以下验证条目：

自定义域验证

1. 点击“验证”。

2. 预计的结果如下：

验证域概述

以下图表显示了我们在本书中使用的完整实验环境：

实验环境概述

此外，我们需要配置一个新的 Active Directory 森林，使用新的域名。使用上述规范创建虚拟机以托管域控制器。创建与我们在第二章，理解身份同步中使用的第一个 Active Directory 森林相同的组织结构和用户。您将在本书的代码包中找到所有脚本。别担心——我们将在本章中进行配置，以避免实验室中的错误。在准备好实验环境后，我们可以开始处理本章内容。

本章重点讲解同步过程，以便您可以采用身份验证部分，您可以使用来自第六章，身份验证协议管理，第七章，在 Azure AD 和 ADFS 上部署解决方案，以及第八章，使用 Azure AD 应用程序代理和 Web 应用程序代理的资源。

理解声明式配置和表达式

解释声明式配置的最简单方式如下：对象通过评估如何转换对象及其相关属性，从源连接目录处理到目标源。这由从连接器空间到元宇宙的入站规则以及从元宇宙到连接器空间的出站规则控制。以下图表为您概述了所有组件：

声明式配置选项和组件概览

声明式配置提供以下功能：

• 配置同步引擎的唯一方式

• 配置属性流的函数

• 优先级在 SRs（而不是在连接器）上

• MV—删除规则现在使用声明式配置

• 引入参数，如%Domain.Netbios%

• 通过 PowerShell 配置

属性流表达式语言可以解释如下：

• 编写于Visual Basic for Applications（VBA）

• 更严格的语法：

  • 有助于故障排除的有用错误信息

  • 强类型支持不同的数据类型

• 进化的表达式：

  • [attributename]，%parametername%

  • &H（十六进制值）

  • 常量—CRLF，True，False，NULL

它引入了以下属性流操作符：

• 字符串连接：&

• 数学运算：+，-，*，/

• 比较：=，<，>，<>，<=，>=

• 评估顺序：( )

• 逻辑运算符：&&（与）||（或）

它还为属性流提供了许多功能，如下所示：

转换	CBool``CDate``CGuid``ConvertFromBase64``ConvertToBase64``CNum``CRef``CStr``StringFromGuid``StringFromSid	数学	BitAnd``BitOr``RandomNum
日期/时间	DateAdd``DateFromNum``FormatDateTime``Now``NumFromDate	多值	Contains Count``Item``Join``RemoveDuplicates``Split
目录	DNComponent``DNComponentRev``EscapeDNComponent	程序流程	Error``IIF``Switch
检查	IsBitSet``IsDate``IsEmpty``IsGuid``IsNull``IsNullOrEmpty``IsNumeric``IsPresent``IsString	文本	GUID``InStr``InStrRev``LCase ``Left``Len``LTrim``Mid``PadLeft ``PadRight ``PCase ``Replace ``ReplaceChars``Right``RTrim``Trim``UCase ``Word

在接下来的部分中，我们将详细解释这些组件，以帮助你更好地理解。

同步规则说明

Azure AD Connect 在同步规则编辑器中使用额外的用户界面来管理同步逻辑。在下方的截图中，你可以看到所有的同步规则已经为你的基础配置创建。每一项都是一个同步规则。在“方向”下拉框中，你可以选择两种不同的类型：入站和出站。从实际角度来说，入站和出站同步总是从元宇宙（metaverse）角度来看待。在我的解释中，我将使用入站同步规则，因为我们将在其中找到相关信息。

在下方的截图中，我们可以看到已连接的 Active Directory 林（inovitdemos.ch），并且它没有任何服务，例如 Exchange 或 Skype for Business，并且没有为这些服务创建同步规则：

同步规则概述—入站

通过以下步骤，我们将收集有关工具实际使用的更多信息：

1. 在你的 YD1ADS01 上查看此配置。

2. 点击“开始”，然后导航到 Azure AD Connect。

3. 点击“同步规则编辑器”：

开始菜单—同步规则编辑器

AAD Connect 根据你的配置提供了多个默认同步规则。这些规则的模板可以在C:\Program Files\Microsoft Azure AD Connect\SynchronizationRulesTemplates目录下找到，并且它们是基于 XML 格式的：

同步规则模板概述

同步规则编辑器的截图展示了不同的规则及其优先级。

微软始终生成编号为100的第一个规则，并遍历所有连接器。它们读取该文件中的第一项（按优先级排序）。它有一个规则名称和添加的标准。然后，它们生成编号为100的第一个规则，并遍历所有连接器。如果有多个连接器，则使用whenCreated日期/时间作为裁定标准。

在下方的截图中，我们将深入了解一个同步规则：

入站同步规则详细信息

在这里，我们将找到关于适用规则的连接系统的详细信息。进一步的细节包括元宇宙中的对象类型以及同步引擎的连接空间。如前面示例所示，连接空间中的对象类型称为用户，代表一个活动目录中的用户账户。例如，用户的元宇宙对象类型始终是人。在链接类型下，您可以选择加入、粘性加入和预配。我们已经在第二章中讨论了加入和预配选项，理解身份同步。如果禁止将新对象预配到元宇宙，则可以使用粘性加入选项。此外，规则启用了密码同步。

在下图中，我们探讨了作用范围过滤器的功能。该规则仅在用户在活动目录中启用时应用。我们使用userAccountControl属性来识别用户的状态。该截图显示，值不需要将位2未设置。活动目录中启用用户的值为512，禁用用户为514：

作用范围过滤器选项

在作用范围过滤器中，我们可以看到有组和可以嵌套的子句。要应用规则，必须满足组内所有子句的条件。规则有两种逻辑运算符：逻辑“或”运算符用于组之间，逻辑“与”运算符用于组内。

我们将仔细查看向 AAD 导出—组加入规则，如下图所示。在这里我们可以找到不同组类型的示例，以及它们如何被处理。

以下截图中显示的规则规定了如何以及哪些组会被分配到 Azure AD。此外，还会检查规则中的其他属性：

更多作用范围过滤器选项

在以下示例中，我们查看了从 AD 导入—用户加入规则，在其中我们发现了 ms-DS-ConsistencyGuid 和 objectGuid 处理，涉及将用户从连接空间加入到元宇宙。请记住，加入规则只会检查一次。连接空间与元宇宙对象之间的链接存在，直到同步规则中的条件未被满足。重要的是要知道，当多个加入规则想要应用时，同步引擎会显示错误：

加入规则示例

对于转换类型，可以使用常量、直接流或表达式。如果我们使用常量流，我们可以直接将值写入选定的属性中。使用直接流时，源系统中的属性将用于目标属性。通过Visual Basic for Applications（VBA），我们可以开发扩展配置。属性的语法是方括号，例如公司或部门，如下图所示。请记住，你需要处理区分大小写的函数和属性名称。你还可以在规则中使用嵌套选项。

以下截图显示了In from AD—User common规则的转换：

转换规则示例

我们已经处理了各个同步规则。有时，多个同步规则会应用于一个目标属性。下图中的sourceAnchor可以作为示例。在那里，你可以看到两个规则已应用于该属性。现在，优先级就发挥作用，决定哪个规则将被使用。请查看以下截图以跟随说明：

• In from AD—User AccountEnabled：

AccountEnabled 的表达式示例

• In from AD—User Common：

表达式示例 sourceAnchor

对于sourceAnchor，来自连接的 Active Directory 的启用账户将被填充到 Azure AD 中。如果在任何连接的 Active Directory 中没有启用的账户，则应用In from AD—User Common规则。对于多个连接的 Active Directory，默认行为是In from AD—User Join规则具有最高优先级。因此，系统会遍历所有连接的 Active Directory。

现在我们已经介绍了声明性配置和同步规则的概念，接下来我们将配置一些示例。

高级同步概念中的特别注意事项

在本节中，我们将开始在实际示例中使用我们的知识。首先，我们将探讨一些可以开箱即用的基本功能。在某些环境中，你可能需要一个组织的组织单位（OU）过滤器，其中所有用户都包含在这个 OU 中。但现在你需要将其过滤掉，这些用户不应该同步到 Azure AD。此外，我们还将集成第二个 AD 林，并使用 PowerShell 来配置同步规则。

使用标准过滤器排除用户和组

在本节中，我们将使用标准过滤选项排除不需要同步到元宇宙的用户和组：

1. 以域管理员身份登录到你的 YD1ADS01。

2. 打开 Active Directory 用户和计算机控制台（dsa.msc）。

3. 请确保你处于高级功能视图中：

Active Directory 用户和计算机——高级功能选项

1. 选择你的一个用户并转到属性编辑器标签。

2. 编辑 adminDescription 属性并输入 User_NoSync，其中 User_ 是关键部分：

adminDescription 过滤选项

1. 保存你的设置并最小化控制台。

2. 打开同步规则编辑器。

3. 编辑规则 In from AD - User Common。

4. 点击范围过滤器。

5. 你将看到具有以下条件的范围过滤器：

adminDescription NOTSTARTSWITH User_

以下截图展示了通过填写 adminDescription 属性来配置过滤要同步到 Azure AD 的用户：

规则配置以过滤特定用户

1. 点击取消并最小化同步规则编辑器。

2. 打开同步服务管理器。

3. 点击“连接器”，并开始在你的 Active Directory 连接器上进行增量导入。

4. 你将在同步统计中看到更新：

增量导入同步统计信息

1. 点击更新。

2. 你会注意到你修改的用户账户中添加了内容：

adminDescription 属性流

1. 点击预览。

2. 选择增量同步。

3. 点击生成预览：

同步预览选项

1. 你将在结果中看到对象删除规则已满足：

对象删除规则预览

1. 点击连接器停用：

连接器停用预览

1. 对象将被断开连接。

2. 点击关闭。

3. 点击预览。

4. 选择增量同步。

5. 点击提交预览：

提交预览选项

1. 打开元宇宙搜索：

元宇宙搜索选项

1. 点击搜索。

2. Aaron Painter 在元宇宙中已不存在。

3. 在 Azure AD 连接器上执行导出操作：

在 Azure AD 上执行导出运行配置文件

1. 你将在同步统计中看到删除信息。

2. 点击删除：

Azure AD 上的导出统计信息

1. 点击对象 GUID：

连接器空间验证

1. 你的用户将从 Azure AD 中删除。

2. 你将看到“等待导出确认”。

3. 在 Azure AD 连接器上运行增量导入。

4. 对象将在 Azure AD 连接器的连接器空间中被删除：

在连接器空间中删除对象

1. 在 Azure AD 连接器上运行增量同步以完成更改。

2. 打开 Azure AD 连接器的连接器空间，你将找不到前面的 CN=：

连接器空间搜索和验证选项

使用此选项，你已看到可以通过填充 adminDescription 属性为 User_NoSync 来过滤 OU 中的对象。相同的过程也可以用于筛选具有Group_NoSync的组。例如，你可以找到特定的In from AD—Group Common入站规则，如下图所示：

使用 adminDescription 为组配置

在下一个示例中，我们将构建一个自定义规则。

构建自定义筛选规则

在本示例中，我们将构建自己的规则以按特定部门进行筛选。你可以在同步规则编辑器中使用以下过程：

1. 打开同步规则编辑器。

2. 单击添加新规则并选择入站。

3. 配置描述部分：

入站规则创建过程

1. 构建作用域筛选器：

department EQUAL Human Resources

1. 配置应如下所示：

按部门属性进行范围筛选

1. 保留加入规则。

2. 转到转换并创建转换：

Constant cloudFiltered True

1. 如下图所示：

云筛选选项

1. 保存规则并按照同步管理器中的运行配置步骤执行：

   • 增量导入：AD 连接器

   • 增量同步：AD 连接器

   • 导出：AAD 连接器

   • 增量导入：AAD 连接器

   • 增量同步：AAD 连接器

2. 验证人力资源用户是否已从你的 Azure AD 中删除。

使用以下示例，你可以阻止同步thumbnailPhoto与 Azure AD。此外，配置还将删除其他上传的thumbnailPhotos。

你可以使用以下 PowerShell 脚本配置场景：

$ThumbnailRules = (Get-ADSyncRule | Where-Object {($_.AttributeFlowMappings.Source -eq "thumbnailPhoto") -and ($_.Direction -eq "Inbound")})

foreach($syncrule in $ThumbnailRules) { 

 Write-Host -ForegroundColor Green "Processing Rule $($syncrule.Name)"
 $mapping = $syncrule.AttributeFlowMappings | Where-Object {$_.Source -eq "thumbnailPhoto"}

 Remove-ADSyncAttributeFlowMapping -SynchronizationRule $syncrule -AttributeFlowMappings $mapping -OutVariable rule

 Add-ADSyncAttributeFlowMapping -SynchronizationRule $syncrule -Source @('thumbnailPhoto') -Destination 'thumbnailPhoto' -FlowType 'Expression' -Expression 'AuthoritativeNull' -ValueMergeType 'Update' -OutVariable rule

 Add-ADSyncRule -SynchronizationRule $rule[0]
}

将 Azure AD Connect 连接到第二个森林

现在我们已经了解同步规则如何工作，我们可以将另一个 Active Directory 森林集成到我们的配置中。

执行以下步骤并使用提到的脚本配置你的环境：

1. 创建示例组织结构：

New-ADOrganizationalUnit -Name "Managed Business Objects" -Path "DC=AZUREID,DC=CH"
New-ADOrganizationalUnit -Name "Users" -Path "OU=Managed Business Objects,DC=AZUREID,DC=CH"
New-ADOrganizationalUnit -Name "Groups" -Path "OU=Managed Business Objects,DC=AZUREID,DC=CH"
New-ADOrganizationalUnit -Name "Devices" -Path "OU=Managed Business Objects,DC=AZUREID,DC=CH"
New-ADOrganizationalUnit -Name "Managed Service Objects" -Path "DC=AZUREID,DC=CH"
New-ADOrganizationalUnit -Name "AAD" -Path "OU=Managed Service Objects,DC=AZUREID,DC=CH"
New-ADOrganizationalUnit -Name "Users" -Path "OU=AAD,OU=Managed Service Objects,DC=AZUREID,DC=CH"

1. 创建 Azure AD Connect AD 管理代理服务账户：

New-ADUser -Name "svcaadcadma" -SamAccountName svcaadcadma -UserPrincipalName svcaadcadma@azureid.ch -path "OU=Users,OU=AAD,OU=Managed Service Objects,DC=azureid,DC=ch" -AccountPassword (ConvertTo-SecureString "YOURPASSWORD" -AsPlainText -Force) -Enabled $True

1. 创建组管理服务账户（gMSA）以运行 AAD Connect：

Add-KdsRootKey -EffectiveTime (Get-Date).AddHours(-10)
New-ADServiceAccount -Name svcaadconnect -DNSHostname INOAZUREIDADS01 -PrincipalsAllowedToRetrieveManagedPassword INOAZUREIDADS01$

1. 为 AD 管理代理账户在域级别设置以下权限。

2. 配置 AAD Connect svcaadcadma的权限：

   • 复制目录更改

   • 复制目录更改所有：

Active Directory MA 服务账户权限

1. 启用 AD 回收站功能：

Enable-ADOptionalFeature –Identity 'CN=Recycle Bin Feature,CN=Optional Features,CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=azureid,DC=ch' –Scope ForestOrConfigurationSet –Target 'azureid.ch'

使用以下详细视图脚本创建你的测试用户：

1. 导入 Active Directory 模块：

Import-module activedirectory

1. 脚本部分会自动填充当前使用的域：

$dnsDomain =gc env:USERDNSDOMAIN
 $split = $dnsDomain.split(".")
 if ($split[2] -ne $null) {
 $domain = "DC=$($split[0]),DC=$($split[1]),DC=$($split[2])"
 } else {
 $domain = "DC=$($split[0]),DC=$($split[1])"
 }

1. 声明任何变量：

$dirpath = $pwd.path
 $orgUnit = "OU=Managed Business Objects"
 $dummyPassword = ConvertTo-SecureString -AsPlainText "OnBo@rdInoDemos19!" -Force
 $counter = 0

1. 导入 CSV 文件：

$ImportFile = Import-csv "$dirpath\ADUsers.csv"
 $TotalImports = $importFile.Count

1. 创建用户：

$ImportFile | foreach {
 $counter++
 $progress = int
 $upn = "$($_.GivenName).$($_.Sn)@azureid.ch"
 Write-Progress -Activity "Provisioning User Accounts" -status "Provisioning account $counter of $TotalImports" -perc $progress
 if ($_.Manager -eq "") {
 New-ADUser -SamAccountName $_.SamAccountName -Name $_.Name -Surname $_.Sn -GivenName $_.GivenName -Path "$orgUnit,$domain" -AccountPassword $dummyPassword -Enabled $true -title $_.title -officePhone $_.officePhone -department $_.department -UserPrincipalName $upn -PasswordNeverExpires $false
 } else {
 New-ADUser -SamAccountName $_.SamAccountName -Name $_.Name -Surname $_.Sn -GivenName $_.GivenName -Path "$orgUnit,$domain" -AccountPassword $dummyPassword -Enabled $true -title $_.title -officePhone $_.officePhone -department $_.department -manager "$($_.Manager),$orgUnit,$domain" -UserPrincipalName $upn -PasswordNeverExpires $false
 }
 If (gci "$dirpath\userimages\$($_.name).jpg") {
 $photo = [System.IO.File]::ReadAllBytes("$dirpath\userImages\$($_.name).jpg")
 Set-ADUSER $_.samAccountName -Replace @{thumbnailPhoto=$photo}
 }
 }

使用以下脚本从userPrincipalName创建电子邮件地址：

 Import-Module ActiveDirectory 
 Get-ADUser -LDAPFilter '(userPrincipalName=*)' `
-Properties userPrincipalName,mail | Select-Object * | `
ForEach-Object { Set-ADObject -Identity `
$_.DistinguishedName -Replace `
@{mail=$($_.userPrincipalName)} }

创建指向其他域的 DNS 转发器，因为已建立 Active Directory 信任：

附加林的 DNS 配置

配置 ms-ds-consistencyGuid 权限给 svcaadcadma 服务帐户：

$accountName = "AZUREID\svcaadcadma"
$ForestDN = "DC=AZUREID,DC=CH"
$cmd = "dsacls '$ForestDN' /I:S /G '`"$accountName`":WP;ms-ds-consistencyGuid;user'"
Invoke-Expression $cmd

现在我们已经准备好第二个 Active Directory 林，可以将其添加到 Azure AD Connect 中：

1. 在 YD1ADS01 服务器上打开 Azure AD 配置向导：

开始菜单–Azure AD Connect

1. 点击配置：

Azure AD Connect 配置

1. 点击自定义同步选项：

同步选项自定义

1. 使用全局管理员权限连接到 Azure AD：

提供 Azure AD 连接的全局管理员凭证

1. 连接第二个林：

连接附加的 AD 林

1. 使用另一个林中的服务帐户进行连接：

使用附加林的 AD 管理代理服务帐户

1. 您的列表中应该出现第二个有效的 AD：

有效连接概述

1. 由于我们已经验证了域后缀，因此我们的域后缀可以同步：

登录配置选项

1. 过滤您希望同步的 OU：

过滤相关对象

1. 启用以下功能以查看扩展的同步选项：

可选功能配置——应用和属性过滤、密码哈希同步以及扩展属性

1. 使用此配置，您可以限制同步到 Azure AD 的属性，以适应特定工作负载：

应用过滤选项

1. 选择要导出的属性：

extensionAttribute 限制

1. 选择一些附加属性，但请记住，并非所有服务都会获取这些属性：

目录扩展实现

永远不要直接启动同步——初始加载始终是手动逐步过程，用于避免错误。

1. 我们准备好开始配置，点击配置：

最终配置步骤

1. 关闭配置助手。

2. 让我们开始处理新 Active Directory 林的初始加载，打开同步服务管理器：

已连接目录概述

1. 按照以下步骤启动初始加载——并控制每个步骤：

   1. 对所有 AD 林进行完全导入

   2. 对 AAD 进行完全导入

   3. 对所有 AD 林进行完全同步

   4. 对 Azure AD 进行完全同步

   5. 对 AAD 进行导出

   6. 对所有 AD 林进行导出

太棒了！我们已完全控制并连接了新的林，恭喜！

认证部分将在第七章，在 Azure AD 和 ADFS 上部署解决方案，第八章，使用 Azure AD 应用代理和 Web 应用代理，以及第十章，探索 Azure AD 身份服务中描述。

请留意在第十章中，探索 Azure AD 身份服务的 ADFS B2B 配置与声明提供者信任。

总结

在本章中，你了解了声明式配置和同步规则的工作原理。我们通过实际示例探讨了如何使用标准同步规则以及如何创建我们自己的规则。你还学会了如何使用 PowerShell 配置同步规则和阻止/删除 Azure AD 中的属性。通过集成另一个不受信任的 Active Directory，你看到了执行此操作的标准程序，并且如何定制你的同步选项，以精确定义在你的环境中应该发生的情况。

在下一章，我们将展示如何监控你的同步解决方案。

第四章：监控您的身份桥接

监控您的身份同步流程、Active Directory 健康状态以及 ADFS 和 Web 应用代理身份验证平台的功能对您的组织至关重要。此外，收集性能数据是提供合适基础设施的必要步骤。

在本实践章节中，我们将探索通过 Azure AD Connect 构建的身份桥接的各种监控能力，包括 Active Directory 本身，以及如果使用，还会涉及 ADFS 和 Web 应用代理。我们将研究 Azure AD 监控和日志功能、Azure AD Connect Health 服务，以及 Azure 安全中心，以便深入了解几种使用场景，从而提供高效准确的监控，为连接到 Azure AD 提供稳定合适的身份基础设施。

本章将涵盖以下主题：

• Azure AD Connect Health 的工作原理

• Azure AD 监控和日志

• Azure 安全中心用于监控和分析

Azure AD Connect Health 的工作原理

Azure AD Connect Health 为您提供了监控并深入了解用于将本地身份扩展到 Azure Active Directory 和 Office 365 的身份基础设施的能力。您可以查看警报、性能信息、使用模式和配置设置；它使您能够保持与 Office 365 的可靠连接，以及更多功能。这是通过在目标服务器上安装代理来实现的。

以下图示展示了 Azure AD Connect Health 的通信方式。它还显示了当前支持的组件：

• Active Directory 域服务（ADDS）2008R2 到 2016

• Azure AD Connect 版本 1.0.9125 或更高版本

• Active Directory 联合身份验证服务（ADFS）和 Windows Azure Pack（WAP）2008R2 到 2016

您可以在docs.microsoft.com/en-us/azure/active-directory/hybrid/reference-connect-health-faq找到实际的支持和许可要求。

以下图示展示了解决方案的架构：

若要部署所有 Azure AD Connect Health 代理，您需要完成第八章中的实验任务，在 Azure AD 和 ADFS 上开发解决方案，因为在该实验中，您将安装 ADFS 和 Web 应用代理。

安装是一个非常简单的任务，始终遵循相同的例程。在以下截图中，在“获取工具”下，您将找到所有实际的代理二进制文件。

Azure AD Connect 的健康代理将始终与工具本身一起安装。Azure AD Connect Health 需要 Azure AD Premium P1 许可证。

以下步骤可以用于安装和配置该功能：

1. 下载并在特定服务器上安装二进制文件。

2. 点击配置。

3. 提供全局管理员凭据，以便成功将代理注册到服务。

以下截图显示了起始页面，您可以在此页面下载代理：

使用 Azure AD Connect Health Agent，您将获得有关同步过程的所有洞察，正如我们在 第二章《理解身份同步》中讨论的那样。您将看到来自同步引擎的当前配置信息和警报，包括同步错误。此外，如果您的 Azure AD Connect 管理着数千个用户、组和其他对象，您还将获得与运行配置文件延迟相关的信息。该服务帮助您收集实际性能和数值，为未来规划提供支持，正如以下截图所示：

ADFS 健康代理由 ADFS 和 Web 应用代理角色使用。该代理需要安装在具有这些特定角色的服务器上。该代理提供以下基本功能：

• 对于有错误用户名/密码尝试的前 50 名用户的安全报告

• ADFS 登录的高失败 IP 报告

• 使用带有警报电子邮件通知的监控

• 使用分析，用于 ADFS 登录，带有切换（应用程序、网络位置及其他信息）

• 最近 24 小时内的令牌请求/秒

• 用于容量规划的性能数据趋势

• 证书信息

您可以在以下截图的图表配置中看到指标值：

您可以在 docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-health-adfs 找到实际的功能。

代理安装向导为您提供一个非常快速的设置体验，您只需提供全局管理员凭据即可注册代理。

如果启用了 IE 增强安全性，则必须允许以下网站在要安装代理的服务器上：

• login.microsoftonline.com

• secure.aadcdn.microsoftonline-p.com

• login.windows.net

• IE 本地 Intranet 区域需要包含您的 ADFS 服务器，例如 login.inovitdemos.ch

以下截图显示了代理的安装对话框：

要使用 ADFS 健康代理，您需要在服务器上配置审计设置，使用以下命令：

auditpol.exe /set /subcategory:"Application Generated" /failure:enable /success:enable
Set-AdfsProperties -AuditLevel Verbose

ADFS 服务帐户需要能够生成安全审计，例如，在本地安全策略配置中的 安全设置|本地策略|用户权限分配。

安装 ADFS 健康代理后，你应该能看到以下三个新服务：

• Azure AD Connect Health AD FS 诊断服务

• Azure AD Connect Health AD FS 洞察服务

• Azure AD Connect Health AD FS 监控服务

我们还将获得关于 ADFS 和 Web 应用程序代理基础设施的大量信息。在测试环境中完成配置后，我们期望得到类似于以下截图的结果：

在撰写本文时，有两个新特性是坏密码尝试和风险 IP 特性，它们帮助你保护你的身份验证基础设施免受攻击。在第七章，在 Azure AD 和 ADFS 上部署解决方案中，我们将讨论更多通过 ADFS 在 Windows Server 2019 上提供的安全功能以及即将到来的身份保护领域的新功能：

你可以在docs.microsoft.com/en-us/azure/active-directory/authentication/howto-password-ban-bad-on-premises-troubleshoot和docs.microsoft.com/en-us/azure/active-directory/reports-monitoring/concept-risky-sign-ins找到更多关于 Azure AD 密码保护和风险登录报告的功能信息。

用于 Active Directory 的 Azure AD Connect Health 代理帮助你识别目录服务基础设施中的问题。你可以收集信息，如域控制器的数量、域和站点以及当前持有灵活单主操作（FSMO）角色的人员。一个非常有用的功能是监控部分，允许你获取关于 LDAP 绑定和 Kerberos/NTLM 身份验证的洞察。此外，复制信息也通过该代理提供。代理安装与 ADFS 相同，具体如下图所示：

安装后，你应该能看到两个新的服务，如下图所示。截图中列出的最后两个服务显示了 Azure AD Connect Health 同步服务：

以下截图展示了关于 Active Directory 健康状态的洞察，包括身份验证性能数据：

总结一下，我们来看看在项目中始终需要的一些实用技巧。以下步骤对于根据不同需求配置环境非常有用：

• 代理服务器：

  • 你可以使用以下 cmdlet 导入 IE 设置：

Set-AzureAdConnectHealthProxySettings -ImportFromInternetSettings

1. • 或者你也可以从 WinHTTP 配置中导入代理设置：

Set-AzureAdConnectHealthProxySettings -ImportFromWinHttp

1. • 或者您可以完全手动设置代理：

Set-AzureAdConnectHealthProxySettings -HttpsProxyAddress address:port

• 测试健康代理连接性：

  • 可以使用以下 cmdlet 进行测试：

Test-AzureADConnectHealthConnectivity -Role ADFS

工作配置的输出如下所示：

现在我们已经完成了 Azure AD Connect 健康服务的工作，接下来我们将继续了解 Azure AD 监控和日志功能。

Azure AD 监控和日志

在 Azure 门户中，在 Azure AD 面板和监控部分下，我们还可以获得有关 Azure 平台及其关联的本地身份基础架构的见解。

我们可以查看对多个服务的完整登录情况，以及审核日志、附加日志和诊断信息。以下截图显示了我们环境中的实际登录情况，包括时间、用户、应用程序和状态。此外，您还将看到访问是否受到条件访问规则或 Azure MFA 本身的保护：

通过点击某个条目，您将获得更多详细信息：

若要通过基于 REST 的 API 提供对 Azure Active Directory 数据的编程访问，您可以参考此指南：docs.microsoft.com/zh-cn/azure/active-directory/reports-monitoring/tutorial-access-api-with-certificates。

您还可以通过点击 Power BI 图标来扩展您的报告功能。如果这样做，以下屏幕将出现：

1. 点击“我的组织”，我们将开始通过 Power BI 扩展我们的解决方案。我们可以使用预定义的应用程序来创建一个良好的起点。选择 Azure Active Directory 活动日志应用程序——只需按下“立即获取”。您可以在此处找到有关该包的更多信息：docs.microsoft.com/zh-cn/azure/active-directory/reports-monitoring/howto-power-bi-content-pack。

2. 提供您希望为报告拉取的天数以及您的租户名称。点击“下一步”：

1. 向导将引导您进行连接，然后您需要登录以同意 OAuth2。

我们将在第六章中详细讨论此过程的安全问题，管理身份验证协议。

1. 点击“接受”：

这很简单，对吧？从现在开始，您可以通过精美的报告收集有关整个身份基础架构的详细信息：

请记住，所有信息都以深入钻取的格式构建：

接下来，我们将深入了解审计日志（Audit Logs），在其中可以找到我们的管理任务，举例来说，我们给 Azure AD Power BI 包授权的操作：

请注意，您可以将信息下载为 CSV 格式。此选项要求您启用诊断设置。只需点击“启用诊断”即可：

启用诊断功能后，您将获得三个选项来传输信息：

• 将日志存档到存储帐户，存储帐户需要创建，或者将使用现有的帐户，并会产生额外费用。将日志路由到 Azure 存储帐户使您能够更长时间保留日志。

• 将日志流式传输到事件中心（event hub），您可以从中创建所需的活动。将日志路由到 Azure 事件中心允许您与第三方 SIEM 工具（如 splunk）进行集成。这使您能够将不同的数据（例如，Azure AD 活动和其他安全信息）结合到您的 SIEM 中，从而提供更深入的环境洞察。

• 发送到 Log Analytics，将日志集中收集到您的 SOC 中。Log Analytics 汇总来自各种来源的监控数据，并提供查询语言和分析引擎，为您提供有关应用程序和资源操作的深入见解。

可用的类型如下：

• 审计日志（AuditLogs），包括用户或服务执行的操作和活动信息

• 登录日志（SignInLogs），包括使用的应用程序信息，包含条件访问信息、登录时间和风险等级

若要导出登录数据，您的组织需要 Azure AD P1 或 P2 许可证。

我们将使用以下信息启用 Log Analytics 功能：

• 您可以添加名称为inodemosloganalytics

• 选择“发送到 Log Analytics”，并勾选审计日志（AuditLogs）和登录日志（SignInLogs）：

接下来，跳转到您新创建的 Log Analytics 功能，开始查询您的 Azure AD 中的信息：

如果您想获取有关此主题的更多信息，请查看视频“使用 Azure Monitor 将 Azure AD 日志与 Log Analytics 集成”，视频链接：docs.microsoft.com/en-us/azure/active-directory/reports-monitoring/howto-integrate-activity-logs-with-log-analytics.

此外，我们将在本书的第十六章《Azure 信息保护》中，进一步使用 Log Analytics。

如果您使用的是 Azure AD 部分的日志，激活该服务后，您将看到第一个结果：

现在您对 Azure AD 的功能有所了解，可以开始尝试不同的功能，全面了解您的基础设施。

用于监控和分析的 Azure 安全中心

在本节中，我们将探索 Azure 安全中心在监控身份和访问管理基础设施方面的功能。通过 Azure 安全中心，您能够了解本地环境和云工作负载的安全状态。新的 Azure 资源将自动被发现并加入，您可以在完整的混合环境中应用安全策略，确保符合实际的安全标准。该服务还提供了多个来源的收集、搜索和分析，包括第三方解决方案和防火墙。此外，我们可以通过高级分析机制发现威胁，并能够根据提供的实时安全警报响应和恢复事件。安全事件的导出可以导入到 SIEM 解决方案中进行进一步分析。该服务集成了许多新的威胁检测部分，如行为分析、机器学习和全球智能威胁。

Azure 安全中心可以发现许多不同的攻击，例如以下几种：

• 被攻破的机器

• 利用失败的尝试

• 高级恶意软件

• Web 应用漏洞

• 暴力破解攻击

• 数据外泄

身份和访问监控功能集处于预览阶段。您需要使用 Azure 安全中心的标准层计划来使用此功能。实际上，身份建议功能最多支持 600 个账户。

通过对身份活动的监控，您可以为组织提供更高层次的安全性，因为您可以在事件发生之前采取主动措施。此外，您还可以阻止正在进行的攻击。身份和访问仪表板为您提供了有关订阅的洞察和建议，例如以下内容：

• 为特权账户启用 MFA

• 删除具有写权限的外部账户

• 删除特权外部账户

如果我们从门户开始，我们将看到以下消息：您有尚未完全保护的订阅。升级到标准层以获得更多建议：

通过以下步骤，我们将启用功能集：

1. 升级到 Azure 安全中心标准实例：

1. 启动试用并升级现有的日志分析工作区，预计结果如下：

1. 您可以查看身份基础设施的洞察，并定义不同的时间范围进行分析：

我们还发现，通过日志分析集成，我们能够直接深入探讨监控和日志信息，这可以在门户的顶部使用。我们强烈建议您在本书提供的所有实验室工作期间返回监控门户，查看各个组件的实际操作。

总结

本章中，我们讨论了保持身份基础设施稳定和适当状态的关键监控和日志功能。我们了解了 Azure 门户中 Azure AD 部分提供的功能。此外，我们还看到了 Azure AD Connect Health 的工作原理，以及如何轻松安装和配置环境。我们扩展了我们的解决方案，现在通过 Azure 安全中心，我们能够更广泛地查看整个混合环境的安全状态。您应该能够回答有关身份基础设施监控功能的问题，并为您自己或客户配置合适的监控和日志解决方案。

在下一章中，我们将学习如何使用 Azure 身份保护功能来保护您的云端和本地环境。我们将讨论并配置 Azure AD 特权身份管理功能。

第五章：配置和管理身份保护

在上一章学习了如何配置监控身份管理基础设施后，我们将进入身份保护的讨论。今天，保护身份是安全领域的主要关注点之一，因此你应该能够采取合适的措施来保护组织免受任何攻击。

在我们的身份保护之旅开始时，我们将从微软云服务概述开始，了解哪些服务能在这一领域帮助你。接下来，我们将深入研究多个不同的服务，从理论讲解开始，再通过示例配置来应用这些理论。完成本章学习后，你应该能够识别出符合你现有或未来需求的正确解决方案组件。总结来说，本章涵盖以下内容：

• 微软身份保护解决方案

• Azure ATP 及其使用方法

• Azure AD 身份保护

• 使用 Azure AD 特权身份管理（PIM）来保护管理员权限

让我们从微软身份保护解决方案的介绍开始，以便在不同的攻击阶段最大化问题检测。

微软身份保护解决方案

微软已经在 Azure 和本地环境上开发并建立了大量身份保护功能，帮助组织保护身份并防止敏感数据泄露。虽然有许多独立的服务可用，但预计在不久的将来会推出统一的身份保护解决方案。我们已经看到了许多身份保护服务之间的集成，这些服务能够检测、调查并防止高级攻击、身份泄露和内部威胁——包括数据泄露——从而形成一个广泛而深入的身份调查解决方案，既能在本地环境中使用，也能在云端使用。组织面临的常见攻击包括密码喷洒攻击、泄露或重复使用的凭据、欺骗域名、恶意链接或附件等。下图展示了在不同阶段检测攻击时常用的各类服务：

攻击向量和保护产品概述

正如上图所示，攻击者首先通过后门恶意软件成功地攻击零号病人，目的是建立命令和控制。然后，攻击者通过网络横向移动，获得特权凭证并访问敏感系统。在此阶段，Office 365 高级电子邮件威胁保护、Windows Defender ATP、Azure ATP和Azure AD 身份保护应该都已到位，以保护相关身份。随后，攻击者会尝试通过从本地计算机到域控制器的远程代码执行，获取域管理员账户的访问权限。

在此阶段，Azure ATP 和 Azure AD Privileged Identity Management 至关重要，用于建立正确的控制措施。成功完成此步骤后，攻击者将能够访问敏感数据并将其提取。为了保护您的敏感数据，Microsoft Cloud App Security Broker（MSCASB）和 Cloud App Security 服务可以帮助您扩展敏感数据的保护。

现在我们已经看过了一个潜在的攻击场景和相关的技术，我们可以深入探讨每个相关服务。我们将使用 爬行-行走-运行 的策略开始，如下所示：

• 爬行：首先，通过以下方式保护您的特权用户和主要环境：

  • 为您的管理员帐户启用 Azure MFA，或者更好地，使用 Azure AD PIM

  • 监控您的风险报告并使用身份安全存储功能

  • 启用并配置 Azure ATP 以保护您的主要用户域

• 行走：然后，通过以下方式保护所有用户和域控制器：

  • 阻止传统身份验证并使用条件访问（有关更多信息，请访问：bit.ly/2M3NXzw）

  • 在 Azure AD Connect 中启用密码哈希同步和禁止密码检查（有关更多信息，请访问：docs.microsoft.com/en-us/azure/active-directory/authentication/concept-password-ban-bad）

  • 使用 Azure ATP 保护所有域和森林

  • 监控所有 Azure ATP 警报并调查任何横向移动或域控制主导警报

• 运行：最后，通过以下方式保护所有用户，并将警报集成到您的安全操作流程中：

  • 使用 Azure MFA 为您的最终用户启用登录和用户风险策略

在本章中，我们将重点讨论前述策略中提到的身份保护技术。其他过程将在第十三章，《识别和检测敏感数据》和第八章，《使用 Azure AD 应用代理和 Web 应用代理》中详细讨论。然而，现在，让我们从 Azure ATP 服务开始。

Azure ATP 及其使用方法

Azure ATP 用于检测和调查高级攻击、受损身份和内部威胁。得益于后台的行为分析，它提供了非常快速的威胁检测，并减少了误报的疲劳感。此外，它通过 Azure ATP 攻击时间轴提供集中且重要的信息。Azure ATP 使用简便，其架构也非常容易理解，因为每个服务只有两个组件和一个可下载的传感器，后者直接安装在您的域控制器上，监控本地流量。传感器根据域控制器的负载使用动态资源限制。

另外，还有一种更复杂的部署方式，它使用独立的传感器在专用服务器上，并要求从域控制器配置端口镜像，以接收网络流量。该服务与 Microsoft Intelligent Security Graph 直接集成。你可以在www.microsoft.com/en-us/security/operations/intelligence找到更多关于此功能的信息。

Azure ATP 帮助你检测以下高级攻击：

• 侦察攻击，例如：

  • 账户枚举

  • 用户组成员身份枚举

  • 用户和 IP 枚举

  • 主机和服务器名称枚举（DNS）

• 被泄露的凭证，例如：

  • 暴力破解尝试

  • 可疑的 VPN 连接

  • 可疑的组成员身份修改

  • Honey Token 账户可疑活动

• 横向移动，例如：

  • Pass-the-Ticket

  • Pass-the-Hash

  • Overpass-the-Hash

• 域控制， 如：

  • 黄金票证攻击

  • DC 影像攻击

  • 骨架钥匙攻击

  • 域控制器上的远程代码执行

  • 在域控制器上创建服务

拥有最基本功能的本地产品是 Microsoft 高级威胁分析（ATA），它仍在开发和支持中。而云服务则提供了保护你环境的功能，因此我们推荐使用 Azure ATP 而不是 ATA。

现在我们将看看如何在你的环境中配置 Azure ATP。

你需要完成第一章，构建和管理 Azure Active Directory以及第二章，了解身份同步，才能完成接下来的配置。

那么，让我们开始吧！要配置 Azure ATP，你需要按照以下步骤进行：

1. 在浏览器中打开链接portal.atp.azure.com/，并以全局管理员身份登录。

2. 接下来，创建你的 Azure 高级威胁保护实例，如下图所示：

Azure ATP 创建对话框

1. 在配置 Azure ATP 之前，你需要在本地活动目录中创建一个服务帐户。登录到你的域控制器，打开提升权限的 PowerShell 并执行以下 cmdlet：

New-ADUser -Name "Azure ATP Service Account" -SamAccountName svcaatp -UserPrincipalName svcaatp@inovitdemos.ch -path "OU=Users,OU=AAD,OU=Managed Service Objects,DC=inovitdemos,DC=ch" -AccountPassword (ConvertTo-SecureString "YourPassword" -AsPlainText -Force) -Enabled $True

1. 返回到 Azure AD 门户并按照配置说明进行操作。

2. 现在，使用新创建的服务帐户，如下图所示：

连接目录服务

1. 之后，直接在你的域控制器上部署第一个 Azure ATP 传感器，如下图所示：

部署 Azure ATP 代理

1. 将安装程序下载到你的域控制器并开始安装。

2. 选择你偏好的语言并选择仅传感器部署方式，如下图所示：

选择传感器类型

1. 点击“下一步”，并使用门户的访问密钥配置传感器，如下图所示：

获取传感器代理共享密钥和安装路径

1. 完成安装后，打开 services.msc 管理控制台，查看新安装的服务，应该包括以下两个服务：

新安装的 Azure ATP 服务

1. 接下来，启用传感器作为域同步器，以收集与 Active Directory 相关的信息，如下图所示：

启用同步器角色

1. 下一个配置任务是启用可疑金票使用检测，该任务位于预览部分，如下图所示：

启用金票保护

1. 配置所有相关的计划报告和通知设置，以测试其功能，如下图所示：

报告部分概览

1. 通知设置页面如下图所示：

配置通知

现在您已配置好 Azure ATP 服务，可以使用以下链接提供的指南来创建攻击并在现实场景中测试您的环境：gallery.technet.microsoft.com/ATA-Playbook-ef0a8e38。该文档是为 Microsoft ATA 编写的，但您仍然可以将其用于测试目的。您还可以使用以下 Azure ATP 安全警报指南来验证您的结果：docs.microsoft.com/en-us/azure-advanced-threat-protection/suspicious-activity-guide。在下一部分中，我们将深入探讨 Azure AD 身份保护的功能。

Azure AD 身份保护

Azure AD 身份保护引入了基于风险的自动条件访问，以帮助保护用户免受可疑登录和凭证被盗的威胁。Azure AD 身份保护还提供了基于机器学习的威胁检测的洞察和整合视图。此外，该服务还提供了重要的修复建议，以及对用户及其会话进行的妥协风险计算。该服务需要 Azure AD Premium P2 或等效的许可证。

您将从此服务中获得以下功能：

• 检测：漏洞和风险账户通过以下方式被检测：

  • 突出显示漏洞并提供自定义建议

  • 计算登录和用户风险等级

• 调查：风险事件通过以下方式进行调查和解决：

  • 通知

  • 提供相关且具有上下文的信息

  • 用于跟踪的基本工作流

  • 轻松访问修复操作（例如，密码重置）

• 基于风险的条件访问：包括：

  • 风险缓解措施，如阻止登录或请求多因素认证

  • 阻止或保护有风险的用户账户

  • 要求用户注册 Azure MFA

为了更好地了解此服务，我们需要开始配置它。请作为全局管理员登录 portal.azure.com，并完成以下步骤：

1. 转到 Azure AD 身份保护选项卡，或使用搜索选项查找该服务

2. 通过访问设置中的入职菜单并点击页面底部的“创建”开始入职流程，如下图所示。按照流程完成入职：

Azure AD 身份保护向导

1. 现在直接跳到概览部分，如下图所示：

Azure AD 身份保护门户概览

1. 门户会向你展示面临的相关风险，例如：

   • 未注册 Azure MFA 的用户

   • 不需要 Azure MFA 的 Azure AD 或 Azure 资源角色

   • 分配过多的全局管理员角色

2. 现在，通过使用以下源配置你的第一个场景：docs.microsoft.com/en-us/azure/active-directory/identity-protection/quickstart-sign-in-risk-policy，并使用你的一名用户

3. 接下来，配置警报和每周摘要设置，以获取有关你环境内外活动的信息

4. 服务启用后，你可以使用现有的操作手册来测试 Azure AD 身份保护的功能，操作手册可以在此找到：docs.microsoft.com/en-us/azure/active-directory/identity-protection/playbook。

如你所见，运行 Azure AD 身份保护不需要一些复杂的配置任务。然而，我们建议你基于提供的操作手册进行测试，并尽可能多地积累经验：

身份安全评分信息

如前述截图所示，身份安全评分为你提供了身份安全位置的信息，以及如何改善的建议。该服务会推荐启用某些安全功能，并遵循具体的建议，例如：

• • 启用 Azure MFA 以保护 Azure AD 特权角色

  • 启用自助密码重置

  • 启用登录和用户风险策略

  • 不允许密码过期，或者在混合配置下启用密码哈希同步

  • 确保所有用户都注册了 Azure MFA

  • 不使用超过五个全球管理员

  • 禁用在过去 30 天内未使用的帐户

  • 阻止传统认证方式

  • 不允许用户授权未管理的应用程序

我们将在第六章“管理认证协议”和第十三章“识别和检测敏感数据”中详细讨论身份保护的某些方面。我们还将深入探讨 Cloud App Security 服务，它提供了以下保护能力：

• 恶意内部人员：防范不满的员工

• 恶意软件：一旦恶意软件上传到云存储，即刻进行检测

• 流氓应用程序：识别能够访问敏感数据的流氓应用程序

• 受损帐户：应对利用受损用户凭据的高级攻击者

• 数据泄露：检测组织内外异常的数据流

• 勒索软件：识别使用复杂行为分析技术的勒索软件

现在我们已经讨论了 Azure AD 身份保护，接下来将讨论 Azure AD PIM 服务。

使用 Azure AD PIM 保护管理员权限

Azure Active Directory 特权身份管理（PIM）提供与 Microsoft Identity Manager 类似的功能，包括本地基础设施中的特权访问管理（PAM）。

如果你需要了解更多关于本地 PAM 解决方案的信息，请访问docs.microsoft.com/en-us/microsoft-identity-manager/pam/privileged-identity-management-for-active-directory-domain-services。

使用 Azure AD PIM，你可以管理、控制和监视特权身份和对目录信息及资源的访问。使用 Azure AD PIM 的主要原因是减少攻击面，并启用按需授予管理员访问权限。特权访问通常配置为永久性且未经监控，但使用 Azure AD PIM 可以避免安全漏洞和风险。

该服务允许你通过设置开始和结束日期来分配资源的时间限制访问，并且激活特权角色需要批准。为了保护角色的激活过程，该服务使用 Azure 多重身份验证。例如，在激活过程中，用户可能会被强制说明为什么需要激活该角色。此外，你还可以启用通知，提醒你特权角色被激活。为了审计和合规性要求，你还可以配置并启用访问审查，以确保用户需要特定的角色。你还可以下载内部和外部审计的审计历史记录。

要使用 Azure AD 特权身份管理，你需要拥有 Azure AD Premium P2 许可证，这也是 EMS E5 或 Microsoft 365 E5 计划的一部分，用于保护你想要保护的每个特权账户。如果你没有 Azure AD Premium P2 许可证的访问权限，可以通过多重身份认证保护你的永久特权账户。要这样做，你需要满足许可要求，详细说明请参见docs.microsoft.com/en-us/azure/active-directory/authentication/concept-mfa-licensing。

现在我们已经了解了 Azure AD PIM 的基本功能，让我们从一个示例配置开始。

要完成本实验室，你必须已完成前几章中的实验任务，或者已经创建了自己的用户。

下表展示了许多公司在开始使用云时常见的配置示例：

目录角色	用户
全局管理员	Don.Hall@inovitdemos.ch
全局管理员	Dan.Jump@inovitdemos.ch
全局管理员	Chris.Gray@inovitdemos.ch

请记住，未管理的特权账户会产生一个漏洞，攻击者可以利用该漏洞访问包含敏感数据的关键系统。为每个账户不断随机化凭据—无论是预定的还是针对攻击的直接反应—是第一步。

首先，让我们在测试租户上启用 Azure AD PIM，并使用默认的角色配置。我们需要确保它能够正常工作，并记得实施一个突破玻璃账户。之后，我们将能够收集反馈并根据需要调整配置。

现在，我们将通过启用 PIM 的快速入门向导来开始配置。

1. 首先，用你的全局管理员账户登录到portal.azure.com，并导航到 Azure AD PIM。

Azure AD PIM - 快速入门选项

在我们的案例中，我们使用账户admin@inovitdemos.onmicrosoft.com，它将作为我们的突破玻璃账户：

突破玻璃账户允许你在 Azure AD PIM、多重身份认证服务或联邦服务不可用的情况下修改配置。确保保护该账户，并使用由 Azure AD PIM 管理的账户来管理你的环境。

1. 现在，使用同意 PIM 启用服务，如上图所示。

2. 现在验证你的身份，如下图所示：

身份验证过程

如果之前没有启用 Azure MFA，则会出现需要更多信息的对话框。

1. 填写并完成额外的安全验证对话框。

2. 点击同意继续，如下图所示：

同意激活该功能

1. 接下来，在“管理 | Azure AD 角色”部分下选择“为 Azure AD 角色注册 PIM”，如下图所示：

注册 PIM 过程

1. 点击“注册”以开始行政角色的发现过程。

2. 在门户中查看你自己的活动角色，如下图所示，包括它们的状态：

活动角色的详情

在接下来的任务中，我们将向角色添加用户并测试配置。

1. 现在，返回到 Azure AD 角色页面，并手动将三个全局管理员分配为特定 Azure AD 的合格管理员，如下图所示。请注意，你也可以使用“管理 | 向导”选项修改角色分配：

角色分配的修改

1. 点击“管理 | 角色”，并选择全局管理员角色，如下图所示：

配置全局管理员角色

1. 你应该看到所有成员的存在，包括他们的分配类型，如下图所示：

分配角色概览

1. 现在编辑你的三个测试用户，通过点击用户行末的三个点使他们符合资格，如下图所示：

选择分配类型以使他符合资格

1. 你应该得到如下结果：

变更结果

实用备注：检查角色的描述，了解你可以做什么。

1. 点击“访问审查”以为某个角色创建访问审查。

2. 点击“新建”。

3. 选择并填写以下值，因为最好从月度审查开始：

   • 审查名称：全局管理员角色月度审查

   • 描述：全局管理员角色月度审查

   • 频率：每月

   • 审核角色成员资格：全局管理员

   • 审核人：已选择的用户

   • 选择审核人：使用你的 admin@tenantname.onmicrosoft.com（PIM 角色管理员）

   • 完成设置：

     • 自动应用：启用

     • 审核人未响应：移除访问权限

4. 保留其余默认设置，然后点击“开始”。你应该会得到如下结果：

访问审查概览

1. 现在我们已经将账户从永久性转换为合格，并为全局管理员角色创建了我们的第一个访问审查，我们将使用 Don Hall 来测试我们的配置。

2. 打开一个新的私密浏览器会话，并导航到 portal.azure.com。

3. 使用 don.hall@yourdomain.com 登录。

4. 导航到 Azure AD PIM，或使用搜索选项查找它。

5. 点击“我的角色”。你应该会看到你符合全局管理员角色的资格，如下图所示：

查看你自己的角色

1. 点击激活以使用你的角色。在继续之前，你需要验证你的账户。

2. 点击验证我的身份以完成 Azure MFA 注册。

3. 响应验证过程并点击激活，如下图所示：

激活全局管理员角色

1. 注意，你可以自定义激活时间；默认情况下，角色激活 1 小时。现在，提供激活理由并点击激活。然后，退出账户并尝试首次作为全局管理员登录：

激活证明

1. 就是这样！你已经成功获得了 Azure AD PIM 的特权访问权限。

2. 现在，退出 Don Hall 账户，并使用你的永久管理员账户重新登录，该账户也分配了特权管理员角色。

3. 点击活动 | 目录角色审计历史，找到 Don Hall 的角色激活，如下图所示：

角色审计历史

在 Azure AD 角色部分检查以下功能，获取更多关于如何配置 Azure AD PIM 的体验：

• 前往任务 | 应用访问，验证你的角色分配。

• 前往审核访问，完成审核。

• 如果你已配置角色审批，前往批准请求；你可以在管理 | 设置 | 角色下完成此操作：

邀请者角色分配

现在，我们已经成功启用了 Azure AD PIM 并配置了 Azure AD 角色，分配并测试了我们的第一个角色，创建了角色访问审核，并查看了审计历史，我们离理解 Azure AD 特权身份管理更近了。（请注意，书中本章代码部分还有 Azure 资源和其他功能的附加实验。）

总结来说，你应该为你的 Azure 资源完成以下 Azure AD PIM 任务：

• 启用即时访问到 Azure

• 自动过期访问权限

• 为快速任务或待命日程分配临时访问权限

• 当新用户或新组被分配资源访问权限，或者当符合条件的分配被激活时，获取提醒。

• 使用 Azure AD 登录 Azure 虚拟机

在我们结束关于 PIM 的部分之前，我们需要告诉你，Azure AD PIM 和 Office 365 E5 提供了特权访问管理功能，用于特权任务和工作负载角色：

Office 365 特权身份管理门户

现在我们已经配置了特权身份管理和保护，给我们的组织提供了良好的安全状态。

总结

完成本章后，你应该能够解释保护身份时的主要要求，以及为什么这些要求是你安全解决方案的一部分。在本章中，我们探讨了核心身份保护组件的关键问题，以及如何根据你的需求启用和配置相关服务。如果你想了解更多关于 Windows Defender ATP 服务的信息，可以查看第十三章，识别和检测敏感数据。

在接下来的第六章，管理认证协议中，我们将讨论至关重要的现代协议，包括 OAuth 2.0、OpenID Connect 和 SAML 2.0，它们帮助你为你的组织和客户建立合适的认证设计。

第二部分：身份验证和应用程序发布

本节将帮助你理解并使用最重要的身份验证协议，同时进行故障排除和开发。除此之外，你还将学会如何使用 Azure AD 和 ADFS/Web 应用程序代理功能，安全地发布云服务和本地服务。

本节将涵盖以下章节：

• 第六章，管理身份验证协议

• 第七章，在 Azure AD 和 ADFS 上部署解决方案

• 第八章，使用 Azure AD 应用程序代理和 Web 应用程序代理

• 第九章，在 Azure AD 上部署附加应用程序

• 第十章，探索 Azure AD 身份服务

• 第十一章，在 Azure 中创建身份生命周期管理

第六章：管理身份验证协议

在本章中，我们将为你提供一个关于你需要了解的重要身份验证协议的概述，以帮助你处理在该领域的配置和项目。

我们在项目中看到很多关于身份验证协议的混淆。理解不同的协议非常重要，这样你就可以与应用程序提供商讨论正确的实现任务和要求。我们经常看到，讨论身份验证方法和解决方案耗费了大量时间。显然，不可能将所有关于不同身份验证方法的材料都放在一个章节中，因为那样会填满一本书。在实际情况中，我们决定提供给你一些必要的总结，并附上大量有效的外部示例。我们将在本书的实验中部署多种不同的身份验证方法。你将在接下来的章节中找到一些特定的实验，帮助你适应技术配置的知识：

• 第七章，在 Azure AD 和 ADFS 上部署解决方案

• 第八章，使用 Azure AD 应用程序代理和 Web 应用程序代理

• 第九章，在 Azure AD 上部署额外应用程序

• 第十章，探索 Azure AD 身份服务

本章的重点将是帮助你熟悉一些体验和决策路径，这些内容可以帮助你理解身份验证协议。我们将本章分为以下几个部分：

• Microsoft 身份平台

• 联邦世界中的常见令牌标准

• 安全断言标记语言（SAML）2.0

• WS-Federation

• OAuth 2.0

• OpenID Connect（OIDC）

• 传递式身份验证和无缝的单点登录（SSO）

• 多因素身份验证（MFA）

让我们开始通过这个身份验证参考文献，开启你的学习旅程。

我们强烈建议你完整阅读本章中的所有参考文献。

我们将从 Microsoft 身份平台的概述开始。

Microsoft 身份平台

Microsoft 提供了一个身份平台，包含两个端点 V1.0 和 V2.0，并为这两个端点提供了两套客户端库。这些库包括：Azure AD 身份验证库（ADAL）SDK 和Microsoft 身份验证库（MSAL）。在 Azure AD 门户中，我们将看到如何通过应用注册（预览）将使用 ADAL 或 MSAL 构建的应用程序包含在内，如下图所示：

Microsoft 身份平台概述

以下列表描述了两个端点的主要使用案例：

• V1.0 端点仅允许工作和学校账户登录

• V2.0 端点允许来自 Azure AD 和Microsoft 账户（MSA）的工作和学校账户登录

• v2.0 端点不支持 SAML 或 WS-Federation——仅支持 OIDC 和 OAuth 2.0

• v2.0 端点不支持 SAML 断言授权

• 这两个端点都接受来自来宾用户的登录请求，适用于单租户或多租户应用程序

现在我们已经对可用的端点有了一个概览，接下来我们将讨论令牌格式。

联邦世界中的常见令牌标准

当数字身份在网络中传输时，它仅仅是一组字节。通常将包含身份信息的一组字节称为安全令牌或简称令牌。在基于声明的世界中，令牌包含一个或多个声明，每个声明承载着关于它所识别的用户的一些信息。

如今，令牌有多种不同的格式，包括以下令牌格式：

• 安全断言标记语言（SAML）：

  • 基于 XML

  • 非常具描述性的元数据

• JSON Web Token（JWT）：

  • 易于人类阅读

  • 更小的令牌大小

• 简单网页令牌（SWT）：

  • 表单编码的属性/值对

  • 不太常见

• Kerberos

对于以下协议规范，我们建议具备良好的基于声明的身份验证基础知识。你可以下载《微软基于声明的身份验证手册》来为自己做好准备。使用以下下载链接获取该书：www.microsoft.com/en-us/download/details.aspx?id=28362。

我们将在下一部分讨论 SAML 2.0。

安全断言标记语言（SAML）2.0

SAML 是当前大多数身份联合活动的基础。SAML 2.0 的前身是 SAML 1.0 和 1.1。SAML 1.1 于 2003 年发布，并且只有两种场景（也称为配置文件），这两种都是由 IdP 发起的。Shibboleth 1.3 和 Liberty Alliance—WS-FF 1.2 扩展了 SAML 1.1，SAML 2.0 于 2005 年由 OASIS 发布。

以下表格显示了 SAML 的核心原则：

断言	协议	绑定

| 身份信息包 | 基于请求/响应 | 将消息（协议）与传输（通信机制）关联

机制） |

| 同义令牌 | 定义消息传递要求 | 示例：

• HTTP 重定向

• HTTP POST

• HTTP 工件

• SOAP

|

| 基于 XML | 示例：

• 身份验证请求

• 单点注销

• 工件解析

在下一部分中，我们将讨论 SAML 2.0 协议的关键事实。

SAML 的关键事实

SAML 标准提供了准确的消息，用于请求和断言（声明）的传输。SAML 提供了多种信息传输方式，例如使用 SOAP。SAML 标准将身份信息定义为断言。标准的大部分内容涉及断言和属性配置文件的定义。会话超时不被考虑。在注销时，会尝试达到一个大范围的接收者。SAML 2.0 使用配置文件，描述了断言、协议和绑定如何结合形成一个联合场景。

例如，Web SSO 配置文件将按以下方式使用：

• 身份验证请求协议

• 在 IdP 处的 HTTP 重定向绑定

• SP 处的 HTTP POST 绑定

有许多不同的 SSO 配置文件可以使用，这些配置文件在规范中有定义：

• Web 浏览器 SSO 配置文件

• 增强客户端或代理（ECP）配置文件

• 身份提供者发现配置文件

• 单点注销配置文件

• 名称标识符管理配置文件

• 文档解析配置文件

• 断言查询/请求配置文件

• 名称标识符映射配置文件

对于 Shibboleth 管理员，我们强烈推荐以下资源：bit.ly/2DnG5pQ。

还有一些 SAML 属性配置文件可供使用，如下所示：

• 基本属性配置文件

• X.500/LDAP 属性配置文件

• UUID 属性配置文件

• DCE PAC 属性配置文件

• XACML 属性配置文件

举个例子，我们在以下图示中使用典型的 SAML Web SSO 配置文件：

SAML Web SSO 配置文件

以下描述解释了身份验证过程中的不同步骤：

• Web 应用程序和SAML 发行者之间建立信任

• 用户浏览到 Web 应用程序

• Web 应用程序检测到用户未通过身份验证，并将其重定向到 SAML 发行者

• 用户自动浏览到 SAML 发行者

• 用户向 SAML 发行者进行身份验证

• SAML 发行者构建令牌并将其返回给用户

• 用户将令牌通过 POST 提交到 Web 应用程序

我们强烈推荐你阅读以下 Azure AD SAML 2.0 文章：docs.microsoft.com/en-us/azure/active-directory/develop/single-sign-on-saml-protocol。

对于调试基于 SAML 的 SSO，请按照以下文章进行操作：

• social.technet.microsoft.com/wiki/contents/articles/31247.azure-active-directory-how-to-debug-saml-based-single-sign-on-to-applications.aspx - 如何调试基于 SAML 的应用单点登录

• docs.microsoft.com/en-us/azure/active-directory/develop/howto-v1-debug-saml-sso-issues - 在 Azure Active Directory 中调试基于 SAML 的应用单点登录

总结来说，我们可以说，2005 年由 OASIS 发布的 SAML 2.0 现在在 Web 登录场景中被广泛使用，特别是对于具有 XML 令牌格式的 Web 应用程序。

WS-Federation

WS-Federation 是由一个行业联盟开发的，并于 2006 年 12 月发布，微软是主要贡献者之一。WS-Federation 也是一个更大框架 WS-Security 的一部分，并基于 2005 年 2 月的 WS-Trust 工作，定义了以下两个关键原则：

• 请求/接收安全令牌的协议

• 如何在使用 安全令牌服务（STS）的各方之间建立信任

它还定义了两个配置文件：

• 主动请求者配置文件

• 被动请求者配置文件

WS-* 联邦套件包括：

• WS-Trust

• WS-Federation

• WS-Policy

在下一部分，我们将描述 WS-Federation 规范的关键元素。

关于 WS-Federation 的关键信息

在 WS-Federation 中，与 SAML 相比，令牌可以是任何东西。基本上没有定义的消息被使用。另一方面，建议使用 Web 服务。WS-Federation 标准使用 SOAP，并通过 Web 浏览器使 SOAP 隧道化。该标准的令牌不受任何具体规范的约束。WS-Federation 可以使用作为 SAML 声明的安全令牌。这意味着 WS-Federation 也可以使用来自 SAML 标准的组件。与 SAML 一样，没有会话超时，应用程序必须显式注册以接收注销信息。

也有一些关于 SAML-P 与 WS-Federation 以及被动请求者配置文件的关系，例如：

• 类似于 SAML WebSSO 配置文件

• 以下部分不兼容：

  • 不同的请求和响应消息

  • 没有 IdP 启动的用例

  • 无声明查询配置文件

使用以下来源收集更多关于该主题的信息：

docs.microsoft.com/en-us/azure/active-directory/develop/azure-ad-federation-metadata

通过以下示例，您可以测试并分析与 Azure AD 结合使用的 WS-Federation：

github.com/Azure-Samples/active-directory-dotnet-webapp-wsfederation

总结来说，我们可以说，WS-Federation 于 2006 年建立，现在常用于 Web 登录场景和 .NET Web 应用程序。令牌格式是通用的，像 SAML、JWT 等都可以使用。

OAuth 2.0

简单来说，身份验证是证明你是谁的行为，而授权是确定你可以做什么的行为。OAuth 2.0 关注的是委托授权，而不是身份验证。它不是一个协议，而是在 RFC 6749 中定义的授权框架，OAuth 2.0 授权框架。这可能会让人困惑，因为有很多情况下你使用 OAuth 2.0 登录客户端 web 应用程序。

身份验证过程必须通过识别和验证最终用户的身份来结束，但 OAuth 并没有做到这一点。OAuth 提供基于时间的令牌，可以代表最终用户访问资源，而无需提供任何关于最终用户的身份信息。

OAuth 2.0 是现有的 API 安全标准，是身份委托领域的一项重大突破。

关于 OAuth 2.0 的关键信息

以下是有关 OAuth 2.0 的主要事实：

• 它是一个用于创建和管理应用程序身份的互联网协议/规范

• 它是一个跨平台机制

• 它具有对 API 的委托授权

• 它的主要目的是为客户端获取访问令牌

• 它不是一个身份验证协议

• 它的前身是 OAuth 1.0 和 OAuth Web 资源授权配置文件 (WRAP)

• 这是 Facebook、Google 和 Twitter 使用的互联网标准

OAuth 框架区分两种客户端（应用程序）类型，当代表用户访问服务时。这两种类型的应用程序可以描述如下：

• 公共：在设备上本地运行。无法信任其存储秘密。

• 私有：在防火墙后运行。可以信任其存储秘密。

以下图示展示了 OAuth 框架中的角色示例：

OAuth 框架中的角色

提供的角色列表如下：

• 授权服务器：发放访问令牌

• 资源服务器：验证并接受访问令牌

• 客户端：请求访问令牌的应用程序

• 用户（资源所有者）：是最终用户，授予使用访问令牌访问资源服务器的权限

在以下截图中，你将看到一个同意示例，它与 Cloud App Security 一起使用，要求访问 Salesforce：

典型的 OAuth 2.0 同意页面

你可以在以下链接找到有关 Azure AD 同意框架的更多信息：docs.microsoft.com/en-us/azure/active-directory/develop/consent-framework。

了解 OAuth 2.0 中的流非常重要，这些流定义了获取访问令牌的过程。

OAuth 2.0 流的主要事实

规范中定义了四种流：

• 授权码 流：

  • 为客户端发放一次性代码

  • 客户端兑换代码以获取访问令牌

  • 访问令牌和 ID 令牌

  • 用于服务器端应用程序

  • 带有代码交换证明密钥的授权码流 (PKCE) 用于原生/移动应用程序

• 客户端凭证 流：

  • 认证客户端，而非用户

  • 客户端为自己接收访问令牌

  • 不支持刷新令牌

  • 推荐用于没有最终用户的客户端应用程序（机器对机器通信）

• 资源所有者密码 流：

  • 客户端收集用户的用户名/密码

  • 使用用户名/密码交换访问令牌

  • 如果你控制客户端应用程序和资源，则使用此流

  • 通常用于在线服务，其中在线服务客户端应用程序与自身服务进行通信

• 隐式 流：

  • 客户端不可信（公共）

  • 不发放刷新令牌

  • 推荐用于单页应用程序（SPA）

你可以使用以下资源，在你的本地 ADFS 基础设施中部署多个 OAuth 2.0 示例：

docs.microsoft.com/en-us/windows-server/identity/ad-fs/development/enabling-oauth-confidential-clients-with-ad-fs

docs.microsoft.com/en-us/windows-server/identity/ad-fs/development/native-client-with-ad-fs

通过以下示例使用 Azure AD，深入了解不同的流类型：

• OAuth 2.0 隐式授权流程：docs.microsoft.com/en-us/azure/active-directory/develop/v1-oauth2-implicit-grant-flow

• OAuth 2.0 授权码授权流程：docs.microsoft.com/en-us/azure/active-directory/develop/v1-protocols-oauth-code

• OAuth 2.0 代表授权流程：docs.microsoft.com/en-us/azure/active-directory/develop/v1-oauth2-on-behalf-of-flow

• OAuth 2.0 客户端凭证授权流程：docs.microsoft.com/en-us/azure/active-directory/develop/v1-oauth2-client-creds-grant-flow

下一部分将为您提供关于授权码流程的信息。

授权码流程

此流程的主要概念是客户端首先获得一个授权码，然后使用该授权码兑换访问令牌。推荐用于具有启动浏览器能力的私人客户端（如 Web 应用或原生移动应用）。在这种情况下，私人客户端会与 OAuth 服务器建立一个密钥。该密钥将用于在访问令牌兑换过程中验证客户端。

访问令牌会过期，并需要通过刷新令牌进行更新，每个令牌都有自己的生命周期，可以长期存储。刷新令牌也可以用于稍后兑换新的访问令牌。

下图展示了授权码授权类型的示例：

授权码授权类型流程

流程按照以下顺序进行：

1. 用户点击按钮以提交此购买

2. 客户端将用户重定向到 OAuth 服务器

3. 用户进行认证并授予许可

4. OAuth 服务器将用户重定向到客户端，并携带授权码

5. 客户端向授权服务器请求访问令牌

6. OAuth 服务器将访问令牌返回给客户端

7. 客户端使用访问令牌授权访问资源

客户端凭证流程

此流程的主要概念是应用程序认证，而非用户授权，应用程序会建立一个密钥，应用程序通过该密钥进行身份验证并获得访问令牌。用户不会参与此流程，客户端可以在不涉及用户的情况下执行此流程。

下图展示了客户端凭证授权类型：

客户端凭证授权流程

流程按照以下顺序运行：

1. 用户通过客户端（通过通讯录应用）进行操作

2. 客户端向 OAuth 服务器（Azure AD）进行认证

3. OAuth 服务器向客户端提供访问令牌

4. 客户端将带有访问令牌的请求发送到资源（Web 服务）头部

隐式授权流

在获取访问令牌时，此流程主要由在 Web 浏览器中运行的 JavaScript 客户端使用。还需注意的是，JavaScript 客户端无需进行身份验证。与授权码流的区别在于，访问令牌将直接在授权请求中接收。

下图展示了隐式授权类型的示例。

隐式授权流

主要流程步骤如下：

1. 客户端 应用 打开浏览器将用户发送到 授权服务器

2. 授权提示出现在用户面前，用户批准应用请求

3. 用户的重定向返回到应用，并附带 访问令牌

资源所有者密码凭证流

此流程中的主要概念是资源所有者必须信任客户端应用。这意味着资源所有者必须将其凭据直接提供给客户端应用。

下图展示了资源所有者密码凭证授权类型：

资源所有者密码凭证流

总结来说，我们可以说，OAuth 2.0 规范自 2012 年 10 月发布以来，现已广泛应用于富客户端和现代应用场景中，特别是 RESTful Web API 访问。令牌格式是无关的，但主要使用 JWT。

OpenID Connect（OIDC）

OIDC 作为一个标准，于 2014 年 2 月通过其成员身份建立。OIDC 提供了一个轻量级的框架，以 RESTful 方式进行身份交互。该规范是在 OpenID 基金会下开发的，根植于 OpenID；它深受 OAuth 2.0 的影响，因为 OAuth 2.0 规范本意并不用于身份验证。微软也是 OIDC 规范的共同作者。

关于 OIDC 的关键事实

它在 OAuth 2.0 的基础上定义了以下身份层：

• 它使用两个 OAuth 2.0 流程：

  • 授权码流

  • 隐式授权流

• 向 OAuth 2.0 交换中添加一个 ID 令牌

• 添加通过 OAuth 2.0 访问令牌请求声明的功能

使用了以下角色：

• OpenID Connect 提供者（OP）：授权服务器发放 ID 令牌

• 依赖方：请求 ID 令牌的客户端应用

• ID 令牌：由 OP 发放

• 声明：有关用户的信息

下图展示了 OpenID Connect 流程：

OpenID Connect 流程

流程步骤如下：

1. 客户端在 OP 注册

2. 用户浏览到 Web 应用并启动登录

3. Web 应用将用户重定向到 OP

4. 用户向 OP 进行身份验证，并同意 Web 应用使用他的身份

5. OP 构建授权码

6. OP 将用户重定向回 Web 应用，并附带授权码

7. Web 应用将授权码发送给 OP

8. OP 创建 ID 令牌和访问令牌，并发送回 Web 应用程序

9. Web 应用程序验证 ID 令牌

该规范还使用一个 UserInfo 端点，具有以下特点：

• 返回关于用户的附加声明

• 基于 REST 的端点

• 使用从 OPx 接收到的访问令牌进行身份验证

• 返回的响应为 JSON 格式

关于 OIDC 和 Azure AD 的更多信息，请访问：docs.microsoft.com/en-us/azure/active-directory/develop/v2-protocols-oidc。

使用本地 ADFS 基础设施构建以下示例应用程序：

• 启用 OIDC：docs.microsoft.com/en-us/windows-server/identity/ad-fs/development/enabling-openid-connect-with-ad-fs

• OIDC 单点注销：docs.microsoft.com/en-us/windows-server/identity/ad-fs/development/ad-fs-logout-openid-connect

使用 Azure AD 的示例进一步深入了解 OIDC 实现。相关内容可以在此查看：docs.microsoft.com/en-us/azure/active-directory/develop/sample-v2-code

总结来说，可以说该规范于 2014 年 2 月发布，由微软共同编写，并在需要同意时用于 Web 登录。令牌格式为 JWT。

透传身份验证和无缝 SSO

Azure AD 透传身份验证提供了一种替代 Azure AD 密码哈希同步和本地 ADFS 基础设施的方式，如果所有基于声明的应用程序都连接到 Azure AD。微软通过该服务提供减少 ADFS 本地复杂性和操作的能力。此外，结合密码哈希同步，客户可以获得冗余且灵活的身份验证环境。您还可以为本地 Active Directory 添加密码保护功能。

透传身份验证支持 Azure AD 条件访问策略、Azure MFA 和阻止遗留身份验证，以保护您组织或客户环境的安全。 本地代理与 Azure AD 服务之间的通信通过证书身份验证进行保护。 如果启用了林信任并正确配置了 UPN 后缀路由，该功能可以支持多林基础设施。 结合无缝 SSO，用户获得原生 SSO 体验，并自动登录本地和基于云的应用程序。

用户登录过程中涉及到以下组件：

• Azure AD STS：无状态安全令牌服务（STS）用于处理登录请求和安全令牌颁发

• Azure 服务总线：云与本地之间的通信组件

• Azure AD Connect 身份验证代理：密码验证请求的监听者和响应者

• Azure SQL 数据库：存储与租户相关的身份验证代理

• Active Directory：本地用户帐户和密码的存储库

让我们看一下以下图表，理解如何访问 Outlook Web 应用的功能：

透传身份验证流程

关于该服务的深入信息可以在以下资源中找到：docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-pta-security-deep-dive

流程包括以下步骤：

1. 用户尝试访问 Outlook Web 应用

2. 当用户未登录时，他将被重定向到 Azure AD 登录页面

3. 用户输入用户名，并选择“下一步”

4. 用户输入密码，并选择“登录”

5. Azure AD 接收登录请求，并将使用身份验证代理公钥加密的用户名/密码放入队列中

6. 本地身份验证代理从队列中检索加密的凭证

代理通过预先建立的持久连接检索请求

1. 代理使用私钥解密密码

2. 代理将用户名和凭证与本地 Active Directory 进行验证，例如 ADFS

3. 域控制器评估请求并向代理返回结果

4. 代理响应回 Azure AD

5. Azure AD 验证答案——用户将成功登录，或执行 Azure MFA

6. 如果一切正常，用户将成功登录

要为您的混合身份验证解决方案选择最佳选项，您可以使用以下资源帮助您做出决策 docs.microsoft.com/en-us/azure/security/azure-ad-choose-authn。

多因素身份验证

使用额外身份验证来保护敏感信息或应用程序访问是一个重要任务，不仅仅在本地环境中。在云服务中，这一点尤为重要，尤其是它需要扩展到每个使用的敏感云服务。为提供这种安全性和额外身份验证，有很多变化，例如证书、智能卡或生物识别选项。例如，智能卡依赖于专用硬件来读取智能卡，并且不能在没有限制访问特殊设备或硬件的情况下用于所有场景。以下表格为您提供不同攻击的概述，以及如何通过设计良好且实施的安全解决方案来缓解这些攻击：

攻击者	可能的安全解决方案
密码暴力破解	强密码策略
肩膀窥视键盘或屏幕记录	一次性密码解决方案
钓鱼或植入攻击	服务器身份验证（HTTPS）
中间人攻击 诱饵攻击（社交工程）	双重身份验证 证书或一次性密码解决方案
证书授权机构篡改 跨通道攻击（CSRF）	交易签名与验证 不可否认性

| 浏览器中的中间人键盘记录器 | 安全的 PIN 输入 安全消息传递

浏览器（只读）

推送按钮（令牌）

三重身份验证 |

微软提供的 Azure MFA 功能正是为了应对前表中描述的攻击。通过一次性密码解决方案，你可以构建一个非常强大的安全解决方案，来访问无法使用智能卡作为额外身份验证方法的设备上的信息或应用程序。否则，对于中小型企业组织来说，智能卡部署及其相关管理解决方案将过于昂贵，而 Azure MFA 解决方案可以成为达到预期更高安全级别的良好替代方案。

Azure MFA

Azure MFA 提供了两步验证的安全性。用户可以选择多种方式验证身份，例如电话、短信、带通知的移动应用程序以及生成的代码。此外，OATH 硬件令牌的集成正在实际预览中。要推出此功能，你可以使用以下来源：

docs.microsoft.com/en-us/azure/active-directory/authentication/tutorial-mfa-applications

docs.microsoft.com/en-us/azure/active-directory/authentication/howto-mfa-getstarted

Azure MFA 包括将本地组件与以下两个代理集成的功能：

• Active Directory 联邦服务 (ADFS) 2016 及更高版本

• 网络策略服务器 (NPS)

如果你需要集成旧版本的 ADFS 或第三方 RADIUS 服务器，唯一的选择是部署本地 Azure MFA 服务器。通过此集成，会有一些限制，例如：

• 无法同步注册信息

• 使用两个注册和用户门户

• 需要管理额外的 MFA 基础设施

在接下来的部分，我们将讨论证书认证选项。

证书认证

Azure AD 支持使用基于证书的认证。设备可以使用客户端证书进行连接。此功能消除了在移动设备上访问邮件和 Microsoft 应用程序时输入用户名/密码组合的需要。你可以使用以下两个来源获取更多关于特定平台的信息：

• Android: docs.microsoft.com/en-us/azure/active-directory/authentication/active-directory-certificate-based-authentication-android

• iOS：docs.microsoft.com/en-us/azure/active-directory/authentication/active-directory-certificate-based-authentication-ios

否则，你可以使用设备认证作为替代方法。我们将在下一节中描述设备认证。

设备认证

微软在多因素解决方案框架中包含的另一种方法是设备认证。设备认证可以通过以下设备注册或加入方法使用：

• Azure AD 注册

• Workplace Join

• Azure AD 加入

• 混合 Azure AD 加入

你可以在以下来源找到有关所有不同选项的更多信息：docs.microsoft.com/en-us/azure/active-directory/devices/overview。你可以在本地 ADFS 或 Azure AD 中使用这些状态进行条件访问。

要在你的 ADFS 基础设施上部署本地条件访问，可以参考以下来源：docs.microsoft.com/en-us/windows-server/identity/ad-fs/operations/configure-device-based-conditional-access-on-premises。对于云环境，我们建议以下来源作为开始条件访问之旅的起点：docs.microsoft.com/en-us/azure/active-directory/conditional-access/overview.

生物识别认证

Windows Hello 是另一种使用生物识别用户信息（如指纹、人脸或虹膜识别）的认证解决方案。此功能适用于个人或企业级安全，提供认证服务。你还可以将此功能应用于本地 ADFS 和 Azure AD。使用以下来源规划并在组织中部署Windows Hello：docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-planning-guide.

总结

通过学习本章及给定的参考资料，你已经深入了解了许多最重要的认证协议的各个方面和实际示例。我们尽力为你提供了一张简洁的参考卡片，包含了有关此主题的许多有效附加信息。你应该能够在为客户或自己组织的设计或配置工作中使用 WS-Federation、SAML、OAuth 2.0 和 OIDC。正如本章开头所提到的，我们将在接下来的章节中使用这些知识。

在接下来的第七章，在 Azure AD 和 ADFS 上部署解决方案，我们将直接开始工作！

第七章：在 Azure AD 和 ADFS 上部署解决方案

有什么比直接将理论应用于实践实验活动更好的方法吗？在我们看来，没有。通过学习第六章，管理身份验证协议，你了解了当前环境中使用的不同身份验证方法。现在，我们将开始使用这些知识将多个场景部署到我们的Azure AD和Active Directory Federation Services（ADFS）中。我们将帮助你理解所有配置步骤，以便为你提供一个合适的身份验证环境。

在本章中，你将扩展你当前的实验环境，安装并配置我们要连接的服务，并配置你的身份验证解决方案以处理不同的方法。我们使用这种方法是为了让你从零开始理解所有内容。我们强烈建议在运行本章之前先阅读第六章，管理身份验证协议，它将涵盖以下主题：

• 基本环境安装与配置

• Azure AD 身份验证部署

• ADFS 身份验证部署

• 将 Azure MFA 集成到 ADFS 中

你准备好开始了吗？是的！我们将从准备我们的环境开始。

基本环境安装与配置

在本章中，我们开始扩展我们当前的模拟本地基础设施，添加所需的额外服务器，以展示和配置不同的功能。在下图中，我们展示了在完成书中所有实验后，我们将配置的完整环境：

实验环境概述

在本章中，我们将向环境中添加YD1APP01和YD1URA01。YourDomain1（YD1）用于标识机器所在的正确域。在我们的例子中，我们使用了INODEMOAPP01。你需要根据之前的值来配置这些机器。

你已经在第二章，理解身份同步中部署了YDADS01域控制器。对于所有未来的虚拟服务器，请使用相同的Azure 订阅、相同的资源组以及相同的虚拟网络。将虚拟机加入到现有的 Active Directory 中。对于域控制器的安装，我们使用了inovitlabs.ch作为示例。在接下来的章节中，我们将使用类似的 DNS 后缀。为了明确起见，我们使用inovitdemos.ch作为inovitlabs.ch的延续表示，并将为不同场景添加azureid.ch和leano.ch。

azureid.ch将用于我们使用的第二个域，且不进行任何云集成。

leano.ch将作为一个仅云环境，用于企业对企业的通信。

你可以使用你喜欢的名称。

为了更好地理解，我们展示了一个额外虚拟机的例子，如果你在书的结尾时已经配置了所有虚拟机，你应该得到以下结果：

虚拟机概述

对于 INODEMOSAPP01（YDAPP01），我们使用的是一台标准 B4ms（4 VCPUs，16 GB 内存）虚拟机，运行 Windows Server 2019。这台虚拟机会作为 SQL Server 实例的宿主，承载我们大多数的演示应用程序和 Visual Studio。因此，我们使用这样一台较大的机器：

• 始终使用相同的资源组

• 始终使用相同的订阅

• 使用之前截图中的大小（推荐）

• 始终使用相同的虚拟网络

• 始终为虚拟机配置 DNS 名称

你可以使用“连接”按钮下载 RDP 连接文件：

虚拟机配置选项

为了让实验尽可能简便，我们为每台虚拟机在创建时定义了 RDP 入站规则，并为虚拟机配置了静态内部 IP 地址：

防火墙配置

如果你点击网络接口，你可以配置静态 IP：

静态 IP 配置

接下来，我们需要点击虚拟网络，配置我们的YDADS01域控制器为主要 DNS 服务器：

自定义 DNS 配置

现在我们已经准备好，你可以按照相同的步骤为任何额外的虚拟机进行配置。我们还在书中的代码包中提供了脚本解决方案。

此配置仅用于实验和演示目的，不适用于生产环境。我们强烈建议你在已配置的域控制器上进行相同的配置。

对于本章，特别是 YD1URA01 虚拟机，我们需要配置两个额外的入站端口规则，以便提供外部访问我们的 Web 应用程序代理。我们需要打开端口 80 TCP（HTTP）和端口 443 TCP（HTTPS）。预期的配置应如下所示：

防火墙配置

现在我们已经讨论了虚拟机的设置，你应该部署YD1APP01和YD1URA01服务器，以运行本章中的以下实验。

使用 Let's Encrypt 为你的环境创建证书

为了为我们的任务提供有效的证书，我们需要安装Posh-ACME PowerShell 模块，使用 Let's Encrypt 作为我们的证书提供商。证书有效期为三个月，且无任何费用。如果你想在更长的时间内使用你的环境，只需续期证书即可。

在以下来源中查找模块描述和更多信息：docs.microsoft.com/en-us/office365/enterprise/base-configuration-dev-test-environment

1. 使用以下命令安装模块：

# Install for all users (requires an elevated PowerShell)
Install-Module -Name Posh-ACME

# Install for current user
Install-Module -Name Posh-ACME -Scope CurrentUser

1. 安装 PowerShell 模块后，我们可以请求证书（将 DNS 后缀替换为您的值）：

New-PACertificate '*.inovitdemos.ch','certauth.login.inovitdemos.ch' -AcceptTOS -Contact jochen.nickel@inovit.ch

1. 您将收到一条消息，提示您需要在公共 DNS 服务器中创建TXT条目，以便完成域验证过程：

Let's Encrypt 验证条目

1. 按照以下示例，在您的公共 DNS 中创建值：

_acme-challenge.inovitdemos.ch   TXT   15MIN TTL   OtORHpZ1CruSu2Tb-iZ1oSnU7oMOsiT0fMPq8pDDeVM
_acme-challenge.certauth.login.inovitdemos.ch  TXT  15MIN TTL  5je--CO7tiMYFXdclcFQKu9UwxnbQTVuzV4U8xpIBQs

请记住，激活这些值需要一些时间。创建条目后，您可以按任意键继续。

1. 验证成功后，您将收到一条消息，提示您可以从公共 DNS 中删除这些值：

Let's Encrypt 验证选项的移除说明

1. 您的新证书已创建：

新创建的证书信息

1. 现在，我们需要在环境中的每台服务器上查找并导入证书。使用以下 cmdlet：

Get-PACertificate | fl

上述命令的输出如下：

证书信息

1. 只需键入.\cert.pfx并按Enter，然后按照导入向导进行操作。

2. 选择“本地计算机”作为存储位置：

证书导入向导

1. PowerShell 模块默认使用的密码来保护PFX文件是poshacme。仅当您希望导出文件并使用自己的密码在其他服务器上使用时，才选择将密钥标记为可导出：

证书导入选项

1. 现在，使用certlm.msc命令打开本地计算机存储的证书管理控制台，您可以验证已安装的证书：

证书存储和主题备用名称

我们不会在接下来的每一章中展示此过程，因此请注意，每次在您的环境中新服务器上安装证书时都需要执行此步骤。

现在我们已经完成了所有准备工作，可以为我们的演示应用程序安装ADFS和Web Application Proxy。

在 YDADS01 上安装ADFS农场

在我们的环境中，我们将在域控制器上安装ADFS农场。在生产环境中，这通常不是推荐的选项，但为了节省成本，我们将选择这个选项。让我们开始吧！

1. 为ADFS农场创建内部 DNS 条目：

Add-DnsServerResourceRecord -ZoneName "inovitdemos.ch" -A -Name "login" -IPv4Address "10.0.0.4"

1. 为演示应用程序创建内部 DNS 条目：

Add-DnsServerResourceRecord -ZoneName "inovitdemos.ch" -A -Name "claims" -IPv4Address "10.0.0.6"
Add-DnsServerResourceRecord -ZoneName "inovitdemos.ch" -A -Name "kerb" -IPv4Address "10.0.0.6"
Add-DnsServerResourceRecord -ZoneName "inovitdemos.ch" -A -Name "basic" -IPv4Address "10.0.0.6"
Add-DnsServerResourceRecord -ZoneName "inovitdemos.ch" -A -Name "ntlm" -IPv4Address "10.0.0.6"

1. 创建ADFS 组托管服务账户（gMSA）：

Add-KdsRootKey -EffectiveTime (Get-Date).AddHours(-10)
New-ADServiceAccount svcadfs -DNSHostName login.inovitdemos.ch -ServicePrincipalNames http/login.inovitdemos.ch

1. 安装ADFS农场：

# Get the certificate thumbprint
gci Cert:\LocalMachine\My\ | fl
# Install the ADFS Farm with WID
Install-WindowsFeature ADFS-Federation -IncludeManagementTools
Install-AdfsFarm -CertificateThumbprint 66F1BF8CCD904DF74154A5D24769DE155E874257 -FederationServiceName login.inovitdemos.ch -GroupServiceAccountIdentifier inovitdemos\svcadfs$ -FederationServiceDisplayName "INOVITDEMOS Login"
# Server restart
Restart-Computer

1. 启用IdP Initiated Signon Page：

Set-AdfsProperties -EnableIdPInitiatedSignonPage $true

1. 检查您的ADFS基础架构安装，通过在浏览器中打开提供的链接：

# Check ADFS Metadata
https://login.inovitdemos.ch/adfs/fs/federationserverservice.asmx
# Check IDP Sign In
# Add "login.inovitdemos.ch" to the "Local Intranet" settings in IE
https://login.inovitdemos.ch/adfs/ls/IdpInitiatedSignon.aspx

1. 现在，我们将ADFS连接到我们的 Azure AD 并切换到联合环境。我们使用SupportMultipleDomain选项，为后续演示做准备，其中我们将集成第二个域后缀和额外的 Active Directory 林：

Connect-MsolService
Convert-MsolDomainToFederated -DomainName inovitdemos.ch -SupportMultipleDomain:$true

1. 接下来，我们安装并配置Web 应用程序代理。

在 YD1URA01 上安装 Web 应用程序代理

我们将在YD1URA01上安装Web 应用程序代理，通过以下步骤为我们的ADFS基础架构提供外部访问：

1. 打开一个评估版 PowerShell 实例，并使用以下命令：

# Get the certificate thumbprint
gci Cert:\LocalMachine\My\ | fl

# Install Web Application Proxy
Install-WindowsFeature Web-Application-Proxy -IncludeManagementTools

# Configure Web Application Proxy
$creds = Get-Credential
Install-WebApplicationProxy -FederationServiceName "login.inovitdemos.ch" -FederationServiceTrustCredential $creds -CertificateThumbprint "66F1BF8CCD904DF74154A5D24769DE155E874257"

# Server restart
Restart-Computer

1. 接下来，我们将通过Web 应用程序代理发布 Active Directory Federation Services：

Add-WebApplicationProxyApplication -Name "Federation Services" -BackendServerUrl "https://login.inovitdemos.ch/" -ExternalUrl "https://login.inovitdemos.ch/" -ExternalPreauthentication "PassThrough" -ExternalCertificateThumbprint "66F1BF8CCD904DF74154A5D24769DE155E874257"

1. 现在，我们需要在公共 DNS 中为ADFS和演示应用程序创建条目，在此过程中需要使用您的 DNS 服务器名称：

login.inovitdemos.ch. CNAME 15 MIN inodemosura01.westeurope.cloudapp.azure.com
basic.inovitdemos.ch. CNAME 15 MIN inodemosura01.westeurope.cloudapp.azure.com
kerb.inovitdemos.ch. CNAME 15 MIN inodemosura01.westeurope.cloudapp.azure.com
ntlm.inovitdemos.ch. CNAME 15 MIN inodemosura01.westeurope.cloudapp.azure.com
claims.inovitdemos.ch. CNAME 15 MIN inodemosura01.westeurope.cloudapp.azure.com

1. 接下来，我们将测试外部ADFS功能。

2. 使用您的管理虚拟机或任何其他外部客户端，在浏览器中打开login.inovitdemos.ch/adfs/ls/idpinitiatedsignon.aspx，并使用您的测试用户之一登录。

现在，我们有一个正常运行的ADFS和Web 应用程序代理基础架构。唯一缺少的角色是我们将在YD1APP01服务器上实现的演示应用程序，并订阅多个云服务。

在(YD1APP01)上为 ADFS 安装演示应用程序

对于本章及后续章节中的任务，我们需要在服务器上安装 SQL Server 和管理工具实例。

服务器上还需要安装以下软件：

• Visual Studio (bit.ly/2NzB14g)，并选择以下选项：

Visual Studio 包安装选项

• Visual Studio Code (code.visualstudio.com/)

接下来，我们从Internet 信息服务（IIS）的基本安装开始：

1. 安装 IIS：

Install-WindowsFeature NET-Framework-Core,NET-Framework-45-Features,Web-Mgmt-Console,Web-Asp-Net,Web-Asp-Net45,Web-Basic-Auth,Web-Client-Auth,Web-Digest-Auth,Web-Dir-Browsing,Web-Dyn-Compression,Web-Http-Errors,Web-Http-Logging,Web-Http-Redirect,Web-Http-Tracing,Web-ISAPI-Ext,Web-ISAPI-Filter,Web-Lgcy-Mgmt-Console,Web-Metabase,Web-Mgmt-Console,Web-Mgmt-Service,Web-Net-Ext,Web-Net-Ext45,Web-Request-Monitor,Web-Server,Web-Stat-Compression,Web-Static-Content,Web-Windows-Auth,Web-WMI,Windows-Identity-Foundation

1. 现在，我们安装 SQL 实例。在您的 Active Directory 中创建 SQL 组织单位：

New-ADOrganizationalUnit -Name "SQL" -Path "OU=Managed Service Objects,DC=INOVITDEMOS,DC=CH"
New-ADOrganizationalUnit -Name "Users" -Path "OU=SQL,OU=Managed Service Objects,DC=INOVITDEMOS,DC=CH"

1. 创建服务账户：

# SQL Database engine service account
New-ADUser -Name "svcsqldb" -SamAccountName svcsqldb -UserPrincipalName svcsqldb@inovitdemos.ch -path "OU=Users,OU=SQL,OU=Managed Service Objects,DC=inovitdemos,DC=ch" -AccountPassword (ConvertTo-SecureString "YourPassword" -AsPlainText -Force) -Description "SQL Database Engine" -Enabled $True

# SQL Agent service account
New-ADUser -Name "svcsqldbagent" -SamAccountName svcsqldbagent -UserPrincipalName svcsqldbagent@inovitdemos.ch -path "OU=Users,OU=SQL,OU=Managed Service Objects,DC=inovitdemos,DC=ch" -AccountPassword (ConvertTo-SecureString "YourPassword" -AsPlainText -Force) -Description "SQL Database Engine Agent" -Enabled $True

1. 接下来，我们可以进行 SQL Server 2017（试用版：bit.ly/2FoSE6z ）的标准安装，使用默认实例。您可以根据bit.ly/2lKJ9mi的指南进行安装。

2. 只需使用以下参数进行安装：

   • 一般情况下，使用默认设置

   • 只添加数据库引擎和全文索引作为功能

   • 将当前用户添加为管理员

   • 使用服务账户来管理数据库引擎和 SQL 代理；选择启动类型为自动

   • 下载并安装 SQL 管理工作室

3. 安装完成后，您应该能够使用 SQL 管理工作室连接到新的 SQL 实例：

使用 SQL 管理工作室连接到 SQL 实例

我们使用来自微软博客的测试网站bit.ly/2QDIqQN（致谢：Emmanuel Boersma）来演示不同的身份验证方法。

1. 配置认证演示应用。

   你需要更改加粗的值，以便使用以下值创建所有演示应用：

   • basic

   • kerberos

   • ntlm

2. 使用以下脚本：

New-Item C:\inetpub\basicroot -type Directory
Import-Module Webadministration
cd IIS:
New-Item 'IIS:\Sites\Basic Web Site' -bindings @{protocol="http";bindingInformation=":80:basic.inovitdemos.ch"} -physicalPath 'c:\inetpub\basicroot'

1. 接下来，为每个演示应用添加 HTTPS 绑定：

IIS 演示应用配置概览

1. 为每个应用执行此操作！

配置 IIS 绑定

现在，我们需要处理一些额外的任务。

我们从 Claims 应用开始：

1. 使用代码包中的 claims 演示应用程序包，并执行脚本（执行前请修改为你的值）：

.\deploy-testsite.ps1 -SourcePath
"C:\inovit\deploy" -SiteName "claims Web Site" -SitePhysicalPath C:\inetpub\claimsroot -ADFSServer inodemosads01 -AppFQDN claims.inovitdemos.ch

1. 将 claims 演示应用的 HTTPS 绑定到你的证书。

接下来，我们来处理kerberos应用的任务：

1. 在YD1ADS01上创建并配置一个服务账户来运行名为svckrbapp的应用程序池，并选择“密码永不过期”选项。记下密码，以便在接下来的配置中使用：

New-ADUser -Name "svckrbapp" -SamAccountName svckrbapp -UserPrincipalName svckrbapp@inovitdemos.ch -path "OU=Users,OU=AAD,OU=Managed Service Objects,DC=inovitdemos,DC=ch" -AccountPassword (ConvertTo-SecureString "YourPassword" -AsPlainText -Force) -Description "Kerberos App Pool Account" -Enabled $True

1. 接下来，我们需要为 Kerberos 委派场景配置正确的服务主体名称（SPN）：

setspn -S http/kerb.inovitdemos.ch inovitdemos\svckrbapp

1. 配置YD1APP01和YD1URA01计算机账户的 Kerberos 委派（用于外部访问），使用svckrbapp用户账户：

在 AD 中配置 Kerberos 委派

1. 接下来，我们需要跳转到YD1APP01服务器，配置 Kerberos 应用。

2. 在应用程序池下，点击添加一个新的应用程序池。

3. 将池命名为 Kerberos 网站，并保留其他默认值。

4. 点击高级设置并将身份更改为svckrbapp账户。

5. 点击 Kerberos 网站并点击高级设置。

6. 将应用程序池更改为新创建的池：Kerberos 网站。

7. 在 IIS 认证下，启用 Windows 身份验证并禁用匿名身份验证。

8. 进入 Windows 身份验证 | 高级设置 | 清除启用内核模式。

9. 将authpage文件夹的内容从代码包复制到 Kerberos 根目录C:\inetpub\kerbroot。

接下来，我们将配置ntlm应用：

1. 点击 NTLM 网站并点击高级设置

2. 将应用程序池更改为 Kerberos 网站

3. 在 IIS 认证下，启用 Windows 身份验证并禁用匿名身份验证

4. 进入 Windows 身份验证 | 高级设置 | 清除启用内核模式

5. 进入 Windows 身份验证 | 高级设置 | 提供程序，只保留 NTLM

6. 将authpage文件夹的内容从代码包复制到 NTLM 根目录C:\inetpub\ntlmroot

接下来，我们将配置basic应用：

1. 将authpage文件夹的内容从代码包复制到基本根目录C:\inetpub\basicroot

2. 在 IIS 管理器中，进入basic应用并配置认证，使其仅启用基本身份验证

在继续执行下一步之前，重启你的YD1ADS01、YD1APP01和YD1URA01服务器。

现在我们已经完成了本地演示应用程序的配置，接下来需要注册一些云端演示应用程序。

订阅演示应用程序（Azure AD）

为了完成所有认证和信息保护实验，我们需要注册以下云应用程序：

• 注册*Salesforce 开发者账户：developer.salesforce.com/signup

• 注册 ServiceNow 开发者账户：bit.ly/2FniUOC

• 注册 Dropbox 商务版试用账号：bit.ly/1KYht6o

• 注册 LinkedIn 账号：bit.ly/1k7JbKB

• 注册一个*Twitter 账号：bit.ly/1k7JbKB

• 注册 Google 账号：https://bit.ly/2reCBP3

• 注册 Okta 开发者账户：bit.ly/2IOw3ix

• 注册 Proxyclick 试用账号：bit.ly/2D5BKqV

标记为的应用程序将在本章中使用，另一些将在第八章中使用，使用 Azure AD 应用程序代理和 Web 应用程序代理*以及以下内容。

成功试用或开发者账户后，我们可以开始探索 Azure AD 和 ADFS 的功能。

Azure AD 认证部署

在本节中，我们将为用户构建应用程序，并演示 Azure AD 提供的不同认证机制。我们在本节中进行的所有配置将使用全局管理员权限，并在 Azure 门户portal.azure.com上完成。我们将从 Salesforce 配置开始：

1. 启动 Azure Active Directory 面板并点击企业应用程序。

2. 在所有应用程序下，点击新建应用程序：

新建应用程序上下文

1. 在搜索框中输入Salesforce：

启用 Salesforce

1. 在单点登录下，切换到 SAML 认证：

选择 SAML 作为认证方法

1. 转到 SAML 签名证书部分并点击下载证书（原始）：

下载签名证书

1. 现在，登录到你的 Salesforce 账户并导航到身份 | 单点登录设置。

2. 编辑 SAML 设置并点击启用 SAML：

在 Salesforce 中配置 SAML

1. 接下来，我们将创建新的SAML 单点登录设置；点击新建：

新设置对话框

1. 要收集配置所需的值，你需要返回 Azure 门户并将三个链接复制到记事本：

Salesforce 配置信息关于 Azure AD 端点

1. 在 Salesforce 配置页面上填写以下信息：

Salesforce SAML 配置页面

1. 接下来，我们需要在设置 | 公司设置 | 我的域下配置我们的 Salesforce 域名。

2. 使用你的租户名称并点击“检查可用性”和“注册域名”：

Salesforce 域名注册过程

注册过程大约需要 5-10 分钟。

1. 刷新页面并编辑身份验证配置：

身份验证配置对话框

1. 点击“打开”并从第一章中上传一个 logo，构建和管理 Azure Active Directory。

2. 勾选 AzureADSSO 并保存：

选择身份验证服务 AzureADSSO

1. 点击登录，如果系统提示注册你的手机，点击我不想...。

2. 如果系统提示，使用你的 Salesforce 管理员账户登录。

3. 接下来，在“我的域”部分，点击“部署到用户”并点击确定。

4. 现在，我们切换回 Azure AD 配置。

5. 将“单点登录 URL”和“标识符（实体 ID）”文本框的值设置为你的值，https://<TENANT>-dev-ed.my.salesforce.com：

Azure AD Salesforce SAML 配置

现在我们已经配置了 SAML 身份验证，可以通过以下步骤激活 Salesforce 的用户供应：

1. 在“管理”部分，点击“供应”。

2. 在“供应模式”下拉列表中，设置为自动。

3. 在管理员凭据下，输入用于访问 Salesforce 的管理员用户名和密码。

4. 通过切换到 Salesforce 管理界面获取一个密钥令牌：

供应的密钥令牌创建

1. 点击“重置安全令牌”，你将通过邮件收到新的安全令牌：

获取新的密钥令牌

1. 接下来，我们在 Azure 门户中配置供应设置。使用你邮箱中的令牌并配置通知邮箱地址：

配置供应服务

预期会出现以下消息：

测试连接到 Salesforce 供应端点

1. 要使用新部署的应用程序，我们需要创建并分配一个组到 Salesforce 应用程序。

2. 创建以下组并分配一个来自销售部门的授权用户：

Salesforce 应用程序访问的组分配

1. 使用以下值分配该组：

角色选择

1. 在“管理 | 供应 | 设置”中，将供应状态设置为“开启”，并保留默认范围。

2. 点击“清除当前状态并重新启动同步”复选框，然后点击“保存”。

3. 在重新启动同步窗口中，点击“是”：

同步和配置状态信息

1. 使用你分配的测试用户测试该应用程序，网址为myapps.microsoft.com。

2. 以下结果是预期的，即成功登录：

成功以测试用户身份登录 Salesforce

我们成功将 Salesforce 部署到我们的 Azure AD，包括 SAML 和配置功能。

现在，我们将使用 Azure AD 的另一个功能与 Twitter 配合使用。为此，我们使用基于密码的登录选项：

1. 首先，我们需要从应用程序库中添加 Twitter 应用程序。你已经了解了从 Salesforce 中添加应用程序的过程：

将 Twitter 添加到应用程序目录

1. 接下来，我们在单点登录部分选择基于密码的单点登录模式。

2. 向导会自动将正确的 URL 设置为 Twitter：

选择基于密码的身份验证选项

1. 我们将销售和营销应用程序访问组分配给该应用程序，提供我们要使用的凭据并将其隐藏：

将 Twitter 凭据分配给组

1. 你还可以在分配的组上更新凭据：

更新凭据选项

1. 现在我们已经为销售和营销用户配置了 Twitter 应用程序，你可以通过myapps.microsoft.com与该用户一起测试功能。

2. 你应该拥有单点登录体验。

一些应用程序需要访问应用程序的访问面板（myapps.microsoft.com）。在这种情况下，网站需要一个浏览器扩展：

1. 要为访问面板扩展配置 Microsoft Edge，启动浏览器并导航到myapps.microsoft.com

2. 以测试用户身份登录

3. 点击 Twitter

4. 点击立即安装

5. 完成安装向导以安装“我的应用程序安全登录扩展”

6. 你会收到一个新的扩展通知；点击开启

7. 重新启动浏览器并导航到myapps.microsoft.com

8. 以测试用户身份登录

这是我们对 Azure AD 功能的第一印象。在下一章第八章，使用 Azure AD 应用代理和 Web 应用代理中，我们将深入探讨，并开始在我们的 ADFS 基础设施中配置第一个应用程序。

ADFS 身份验证部署

要使用 WS-Federation 配置基于声明的应用程序，我们可以使用我们的声明演示应用程序。通过这个应用程序，你可以测试 ADFS 在声明身份验证中的许多功能，并以更实际的方式学习。在你的 YD1ADS01 上运行以下配置，稍后我们将配置应用程序以获得更多经验：

1. 转到“服务器管理器”，点击“工具”，并打开 ADFS 管理。

2. 展开“信任关系”，并选择“依赖方信任”。

3. 选择“操作”，添加“依赖方信任”，然后点击“开始”。

4. 在框中输入 https://claims.inovitdemos.ch：

ADFS 依赖方信任配置

1. 点击“下一步”。

2. 输入显示名称为 claims 演示网站，然后点击“下一步”。

3. 选择“我目前不想为此依赖方信任配置多因素身份验证设置”，然后点击“下一步”。

4. 选择“允许所有用户访问此依赖方”，然后点击“下一步 | 下一步”。

5. 清除“当向导关闭时打开此依赖方信任的编辑声明规则对话框”并点击“关闭”。

6. 使用 Internet Explorer 验证新应用，通过输入 https://claims.inovitdemos.ch：

Claims 演示网站

安装脚本会自动将 Token-Signing 证书的指纹放入 Claims Web 应用的 web.config 文件中。如果你更新了 Token-Signing 证书，则需要在应用程序配置中更新指纹。

你可以使用以下命令从我们的 ADFS 实例中获取 Token-Signing 证书：

Invoke-Command -ComputerName INODEMOSADS01 -ScriptBlock {Get-ADFSCertificate}

上述命令的输出将如下所示：

获取 Token-Signing 证书信息

另一个在多个测试场景中非常有用的工具，如 SAML、WS-Federation、OAuth2 和强身份验证方法，是来自微软的Claims X-Ray 工具，你可以在bit.ly/2EqoPOi找到它，并且按照以下步骤进行配置非常简单：

1. 在你的 YD1ADS01 上打开一个评估版 PowerShell 实例，并运行以下脚本：

$authzRules = "=>issue(Type = `"http://schemas.microsoft.com/authorization/claims/permit`", Value = `"true`"); "
$issuanceRules = "@RuleName = `"Issue all claims`"`nx:[]=>issue(claim = x); "
$redirectUrl = "https://adfshelp.microsoft.com/ClaimsXray/TokenResponse"
$samlEndpoint = New-AdfsSamlEndpoint -Binding POST -Protocol SAMLAssertionConsumer -Uri $redirectUrl

Add-ADFSRelyingPartyTrust -Name "ClaimsXray" -Identifier "urn:microsoft:adfs:claimsxray" -IssuanceAuthorizationRules $authzRules -IssuanceTransformRules $issuanceRules -WSFedEndpoint $redirectUrl -SamlEndpoint $samlEndpoint

1. 要使用 OAuth2，我们需要创建所需的 OAuth 客户端：

Add-AdfsClient -Name "ClaimsXrayClient" -ClientId "claimsxrayclient" -RedirectUri https://adfshelp.microsoft.com/ClaimsXray/TokenResponse

if ([System.Environment]::OSVersion.Version.major -gt 6) { Grant-AdfsApplicationPermission -ServerRoleIdentifier urn:microsoft:adfs:claimsxray -AllowAllRegisteredClients -ScopeNames "openid","profile" }

1. 你将获得配置好的 WS-Federation 被动端点、SAML 断言消费者端点和 OAuth2 配置：

1. 打开浏览器并在以下页面上测试基本功能，使用其中一个测试用户：login.inovitdemos.ch/adfs/ls/IdpInitiatedSignon.aspx。

2. 选择 ClaimsXRay，登录，并查看你的令牌响应：

获取你的声明信息

现在我们已经配置了第一个帮助应用程序，我们可以开始试用它们了。你已经能够查看两个使用 WS-Federation、SAML 和 OAuth 的示例实现。

使用 Claims X-Ray 应用程序，我们可以针对我们的 ADFS 实例运行多个测试。为此，我们使用来自 bit.ly/2EqoPOi 的源：

1. 让我们使用以下设置测试我们的 OAuth 配置：

使用 Claims X-Ray 工具测试 OAuth 配置

1. 现在，你可以分析你的响应，你将看到你已经在使用 OAuth2：

查看响应

如果你想将 SAML Token 转换为 Kerberos Token，怎么办：

1. 在 ADFS 中，你可以使用 Non claims aware 选项，该选项会在你添加新的依赖方时出现：

添加 Kerberos 示例应用程序

1. 让我们使用 Kerberos 示例应用程序尝试一下：

提供显示名称

1. 点击 Next 并在依赖方信任标识符中输入 kerb.inovitdemos.ch：

配置标识符

1. 在访问控制策略部分点击 Next，再次点击 Next，直到添加了依赖方。

2. 要测试应用程序，我们需要配置 Web 应用程序代理以将应用程序发布到外部。

3. 登录到 YD1URA01 并在远程访问管理控制台发布 Kerberos 应用程序：

使用 Web 应用程序代理发布 Kerberos 应用程序

1. 点击 Next 并选择 Web 和 MSOFBA 选项。

2. 接下来，选择 Kerberos Demo Web Site 并配置以下设置：

提供外部/后台服务器的 URL 和 SPN

1. 完成配置后，跳转到外部管理员虚拟机或任何其他外部客户端

2. 打开浏览器并访问 Kerberos 网站，kerb.inovitdemos.ch，并成功登录

在我们开始测试更多应用程序之前，我们将从 bit.ly/2eBzw4C 安装 Fiddler 调试工具来分析我们的流量：

1. 启动 Fiddler 调试工具：

使用 Fiddler 进行身份验证分析

1. 配置 HTTPS 捕获选项：

使用 Fiddler 捕获 HTTPS 流量

1. 按 F12 开始调试并打开浏览器，你将看到产生的流量。

集成 Azure MFA（YD1ADS01）

在本节中，我们只是将 Azure MFA 集成到我们的 ADFS 集群中。我们将在 第八章中自定义并使用此选项，使用 Azure AD 应用程序代理和 Web 应用程序代理：

1. 首先，我们需要在每台服务器上使用以下 cmdlet 为 Azure MFA 生成证书：

# Replace the tenant ID to your value
$certbase64 = New-AdfsAzureMfaTenantCertificate -TenantID 181031inovitdemos.onmicrosoft.com

1. 接下来，我们将证书设置为针对 Azure 多因素身份验证客户端的新凭证：

# Connect to the MsolService with your global administrator rights
Connect-MsolService

# Create a new Service Principal Credential the AppPrincipalId is the hardcoded one for Azure MFA
New-MsolServicePrincipalCredential -AppPrincipalId 981f26a1-7f43-403b-a875-f8b09b8cd720 -Type asymmetric -Usage verify -Value $certBase64

1. 现在，我们可以配置 ADFS 集群：

Set-AdfsAzureMfaTenant -TenantId 181031inovitdemos.onmicrosoft.com -ClientId 981f26a1-7f43-403b-a875-f8b09b8cd720

Restart-Service adfssrv

1. 后来，我们可以看到 Azure MFA 作为内部/外部网络使用的主要认证方法：

ADFS 主要认证配置

ADFS 2019 允许您使用其他第三方认证提供商作为主要方法。

通过这种配置，我们已经在我们的 ADFS 环境中成功实现了 Azure MFA。

总结

很多实际工作，希望你喜欢！从我们的角度来看，直接使用你刚学到的认证方法和能力总是最好的。通过这一章节的学习，你将接触 Azure AD 和 ADFS，以提供多种认证方法。我们知道有许多预配置任务，但这有助于你了解应用程序配置并应用正确的认证配置。你将接触到 WS-Federation、SAML 和 OAuth2 方法，包括 Azure AD 的用户配置能力。

在接下来的章节中，我们将进一步深入探讨不同的认证场景，并且还将实现应用程序代理功能。我们很高兴能在第八章中见到你，使用 Azure AD 应用程序代理和 Web 应用程序代理。

第八章：使用 Azure AD 应用代理和 Web 应用代理

作为第七章的继任者，在 Azure AD 和 ADFS 上部署解决方案，我们深入探讨了 Azure AD 和 ADFS 的不同功能。我们已经将 Kerberos 本地应用发布给外部用户。本章我们将使用另一个应用程序来做这个。此外，我们将深入了解 Azure AD 应用代理的功能。本章还将展示条件访问的初步使用示例及其基本功能。我们将在第十章，探索 Azure AD 身份服务，进行更多声明操作和任务自定义，并提供代码包中的示例。通过本章，您将获得所有有关将应用程序集成到 Azure AD 和 ADFS 中的信息。您还将学会使用 Azure AD 或 Web 应用代理发布应用程序。此外，您将能够使用条件访问来保护应用程序访问。

本章分为以下几个部分：

• 配置 Azure AD 和 ADFS 的附加应用

• 使用 Windows 服务器和 Azure AD Web 应用代理进行发布

• 使用条件访问

准备好了吗？我们将从配置 Azure AD 和 ADFS 的附加应用程序开始。

配置 Azure AD 和 ADFS 的附加应用程序

我们将继续部署和配置更多的业务应用程序，以便您测试不同的身份验证机制。为了支持我们，我们将配置 ServiceNow 与 SAML 并启用 Azure AD 到 ServiceNow 的活动用户预配：

1. 转到 Azure Active Directory | 企业应用并添加新应用：

添加新的企业应用

1. 选择 ServiceNow 并从图库中添加该应用：

添加 ServiceNow

1. 添加应用后，我们将配置 SAML 以验证我们的用户：

使用 SAML 作为身份验证方法

1. 在基本 SAML 配置中，我们添加了我们的 ServiceNow 实例信息，如下图所示：

配置 SAML 选项

需要使用以下 URI：

https://.service-now.com/navpage.do
https://.service-now.com

本章我们将使用自动配置方法。

1. 对于手动配置任务，您可以使用 Base64 选项下载证书：

下载签名证书

1. 此外，对于手动配置任务，您可以将以下链接复制到记事本中：

Azure AD 端点概述

1. 接下来，我们将把我们的服务管理应用访问组分配给该应用：

将用户分配到应用

1. 现在，我们可以开始为 ServiceNow 实例配置单点登录。

2. 首先，我们需要激活 Multi-Provider Single Sign-On 安装程序插件：

ServiceNow 中的 Multi-Provider SSO 功能

1. 您将在左侧导航窗格中找到此选项：系统定义 | 插件。

2. 激活以下插件：

在 ServiceNow 中激活 Multi-Provider SSO 功能

1. 点击对话框中的激活按钮：

激活对话框

1. 接下来，我们将在 Multi-Provider SSO | 管理 | 属性下配置插件：

配置新安装的插件

1. 需要激活以下功能：

激活提供程序的自定义属性

1. 如果您想使用手动配置方法，您需要使用记事本中的信息。

2. 我们使用自动配置选项；这是一个稍微隐藏的选项！

3. 您将在以下截图中找到它，位于 SAML 配置部分下的“查看逐步说明”：

ServiceNow SSO 提供程序的自动配置选项

1. 点击该选项，出现以下对话框；输入您的 ServiceNow 管理员凭据：

配置 SAML 连接

1. 点击 立即配置。

2. 接下来，我们可以在 ServiceNow 部分进行其他配置任务。

3. 导航到 Multi-Provider SSO | 身份提供者：

身份提供者配置

1. 您将找到自动生成的身份提供者：

开始配置在 ServiceNow 中新创建的 Azure AD 连接

1. 我们需要移除填充的身份提供者的 SingleLogoutRequest URL。

2. 所有其他字段可以保留其默认设置：

配置 IdP，包括自动重定向选项

1. 非常重要！设置自动重定向 IdP 选项，预期结果如下：

自动重定向 IdP 选项

1. 接下来，我们需要通过导航到 X.509 部分选择正确的证书：

配置正确的证书

1. 保存配置。

现在，我们已经完成了 ServiceNow 的 SAML 配置，接下来将进行用户配置：

1. 导航到 ServiceNow 应用程序的配置部分，并将配置模式更改为自动。

2. 输入以下值：

• • 实例名称

  • 管理员用户名

  • 管理员密码

  • 通知电子邮件（并勾选“发生故障时发送电子邮件通知”）：

配置 SCIM 预配功能

1. 点击“测试连接”，您应该会收到如下示例的通知。测试连接是保存之前的必需步骤：

连接测试

1. 接下来，我们将查看用户和组的同步配置。

2. 点击“同步 Azure Active Directory 用户到 ServiceNow”规则：

配置同步规则

1. 您将找到活动的属性映射。如果您需要处理特殊考虑事项，例如连接到已填充的 ServiceNow 实例，您可以修改映射以满足您的需求：

同步规则设置

1. 您还将获得同步详细信息的实际概览：

用于监控和审计的同步详细信息

1. 通过点击查看“帐户预配”类别，您可以在审计日志中看到完整详细信息，并获得如下截图：

测试用户的实际状态

1. 接下来，我们将切换到您的 ServiceNow 实例中的“组织 | 用户”部分。

2. 搜索您的测试用户，例如Don.Hall@inovitdemos.ch，您将看到自动预配的结果：

验证在 ServiceNow 中同步的测试用户

初始同步所需的时间较长，而后续同步大约每40 分钟进行一次，只要服务在运行。

接下来的场景是使用OpenID Connect和您的本地 ADFS 基础设施。要跟随认证流程，请参考第六章，管理认证协议。

要在您的YD1APP01服务器上配置此场景，我们需要将active-directory-dotnet-webapp-openidconnect文件夹从代码包复制到桌面。

我们在您的域控制器上配置 ADFS 服务器（YD1ADS01），最终将得到以下预期结果——一个完整的 OpenID 认证应用程序：

以下配置步骤的结果

在接下来的步骤中，我们将配置该场景：

1. 我们从创建一个新的应用程序组开始，其中包括一个服务器应用程序（独立应用程序）：

配置新的应用程序组

1. 接下来，生成一个客户端 ID；将该 ID 复制到记事本中。

2. 输入应用程序将运行的重定向 URI，https://localhost:44320/：

提供应用程序属性

1. 点击“下一步”，并勾选生成共享密钥框；将密钥复制到记事本中：

生成共享密钥

1. 完成向导。

2. 接下来，我们通过双击新应用程序组来创建 Web API 配置。

3. 选择添加应用程序：

Web API 配置

1. 使用 Web API 选项：

选择 Web API 选项

1. 接下来，为 API 添加标识符：https://inovitdemos.ch/OpenIDDemo.

2. 在访问控制策略部分点击下一步，然后完成向导的其他部分。

3. 现在，我们切换到 YD1APP01 服务器并打开 Visual Studio。

4. 打开示例代码的解决方案文件：WebApp-OpenIDConnect-DotNet.sln。

5. 在解决方案资源管理器中导航到 web.config 文件：WebApp-OpenIDConnect-DotNet.sln。

6. 修改代码，使其看起来像下面的示例：

   • 从记事本中复制您的客户端 ID。

   • 配置 ida:ADFSDiscoveryDoc 的值，使其包含您的 ADFS FQDN：https://login.inovitdemos.ch。

   • 验证 ida:PostLogoutRedirectUri 的值是否包含 https://localhost:44320/：

 <appSettings>
 <add key="webpages:Version" value="3.0.0.0" />
 <add key="webpages:Enabled" value="false" />
 <add key="ClientValidationEnabled" value="true" />
 <add key="UnobtrusiveJavaScriptEnabled" value="true" /> 
 <add key="ida:ClientId" value="40ef7c28-2172-4e4d-84b5-e9a284b94f75" />
 <add key="ida:ADFSDiscoveryDoc" value="https://login.inovitdemos.ch/adfs/.well-known/openid- configuration" />
 <add key="ida:PostLogoutRedirectUri" value="https://localhost:44320/" />
</appSettings>

1. 接下来，导航到 App_Start 部分和 Startup.Auth.cs 文件。

2. 在 public partial class Startup 下面，代码需要像下面这样调整 OpenID Connect 中间件初始化逻辑：

private static string clientId = ConfigurationManager.AppSettings["ida:ClientId"];
 //private static string aadInstance = ConfigurationManager.AppSettings["ida:AADInstance"];
 //private static string tenant = ConfigurationManager.AppSettings["ida:Tenant"];
private static string metadataAddress = ConfigurationManager.AppSettings["ida:ADFSDiscoveryDoc"];
private static string postLogoutRedirectUri = ConfigurationManager.AppSettings["ida:PostLogoutRedirectUri"];
 //string authority = String.Format(CultureInfo.InvariantCulture, aadInstance, tenant);

我们不需要 Azure AD 配置，所以我们将这一部分注释掉！

1. 接下来，我们需要修改 OpenID Connect 中间件选项：

app.UseOpenIdConnectAuthentication(
new OpenIdConnectAuthenticationOptions 
 { 
 ClientId = clientId, 
 //Authority = authority, 
 MetadataAddress = metadataAddress, 
 RedirectUri = postLogoutRedirectUri, 
 PostLogoutRedirectUri = postLogoutRedirectUri

ADFS 会强制执行请求中的 redirect_uri，而 Azure AD 不会这样做。

1. 现在，我们可以验证应用程序；在 Visual Studio 中按下 F5。要分析流量，您可以使用 Fiddler。请注意，您会在身份验证部分遇到 Fiddler 的问题：

Fiddler 认证结果

1. 做得好，您已经配置了一个使用 OpenID Connect 的应用程序！

使用 Windows 服务器和 Azure AD Web 应用程序代理发布

Azure AD 应用程序代理类似于 Windows Server 2012 R2 开始的本地 Web 应用程序代理角色。通过此服务，您可以启用本地应用程序的外部访问。Azure AD 应用程序代理需要 Azure AD Basic 或 Azure AD Premium 订阅。连接直接与 Azure 建立，并通过代理进入私有网络，在本地 Web 应用程序服务器上安装应用程序代理代理。

让我们运行一个非常常见的用例，将 Kerberos 本地应用程序添加到我们的 Azure AD 访问 UI，myapps.microsoft.com。我们使用现有应用程序来配置这个场景：

1. 登录到 portal.azure.com 并选择 Azure Active Directory 面板。

2. 在应用程序代理下，我们首先需要在 YD1APP01 服务器上下载并安装应用程序代理代理。

您无需直接在应用程序服务器上安装代理。也可以使用任何其他服务器，或者出于冗余要求使用额外的代理。代理需要安装在与应用程序在同一域/森林中或正确信任的域/森林中的服务器上，以支持 Kerberos 受限委派，应用程序的 SPN 需要在每个代理实例上完成。域功能级别至少需要为 Windows Server 2012。同时，其他服务器必须能够访问正确的端口。

1. 将代理下载到服务器并启动安装：

配置 Azure AD 应用程序代理

1. 同意许可条款并点击下一步。

2. 接下来，您需要提供全局管理员凭证以将代理注册到 Azure AD。

3. 识别用于外部代理的通知：

安装应用程序代理连接器

1. 预期结果是激活的代理：

激活代理概览

1. 现在，我们可以开始配置基于 Kerberos 的本地应用程序。

2. 首先，我们创建一个可以分配以授权访问门户的组：

分配所需的测试组

1. 将一个测试用户分配给您的组。

在此示例中，我们使用的是不通过官方公共 FQDN 发布应用程序的选项。在这种情况下，我们不需要打开任何防火墙端口，应用程序的流量通过连接器工作。

1. 接下来，我们将配置应用程序代理配置：

配置本地应用程序属性

1. 如您所见，您可以提供多个附加设置以满足您的需求。

您可以在以下参考文献中找到关于不同选项的更多信息：docs.microsoft.com/en-us/azure/active-directory/manage-apps/application-proxy-add-on-premises-application。

1. 在下一步中，我们将配置应用程序的单点登录选项。

2. 选择 Windows 集成认证选项：

选择 Windows 集成认证选项

如果您需要使用基于头部的认证，与 PingAccess 的集成将是您的好伙伴。您可以在以下来源找到有关此集成的更多信息：docs.microsoft.com/en-us/azure/active-directory/manage-apps/application-proxy-configure-single-sign-on-with-ping-access。

1. 输入您的内部应用程序 SPN 以配置 Kerberos 部分。

2. 请记住，只有 Kerberos 受限委派才有效：

配置应用的 SPN

1. 完成此配置后，我们可以使用已分配的用户来测试应用，并且你应该得到类似于此的结果：

示例应用上成功的 Kerberos 身份验证结果

这种发布方式还允许我们使用公共 FQDN。如果你的应用程序发送带有链接的通知邮件，这个选项会很有用。要实现这种使用场景，你需要更改外部 URL 并提供公共 SSL 证书。你可以使用通配符证书，或使用 Let's Encrypt 颁发一个独立的 SSL 证书。

1. 你将在基本设置下找到该设置：

定义基本应用程序设置

对于证书，你需要使用以下部分。别忘了在你的公共 DNS 中创建 CNAME：

查看 DNS 配置选项

我们可以为云或本地应用（通过 Azure AD Web 应用代理）使用的下一个身份验证方法是基于密码的选项。我们将其用于启用了表单身份验证的应用，这些应用使用自己的身份提供者。

你的凭证将被安全地存储在用户或组对象下。

在接下来的步骤中，我们将添加一个基于密码的应用访问：

1. 添加一个新应用并选择非画廊应用选项。

2. 在单点登录方法下选择基于密码的选项：

选择非画廊应用

1. 为你的应用提供名称，并导航到单点登录配置：

使用基于密码的身份验证方法

1. 提供单点登录 URL 并检测你的应用的登录字段。

2. 有三种方式可以进行此配置：

   • 自动

   • 手动

   • 在高级视图中的自定义配置：

检测应用程序的登录字段

1. 在这个例子中，我们使用了我们公共 DNS 提供商的登录页面。

2. 如果 Azure AD 机制未能获取正确的值，你可以使用任何浏览器和开发者工具查看字段标签，并提供值：

分析代码以查找登录字段/标签

1. 接下来，你需要将用户或组分配给应用：

更新用户/组上的凭证

你可以选择将凭证隐藏给用户或组，或选择凭证在首次访问时保存。

1. 现在，通过更新凭证按钮提供凭证：

更新凭证对话框

1. 现在，你可以使用你的测试用户来测试这个应用。

请记住，用户需要安装访问面板 UI 扩展，否则他将被要求安装。你还可以使用组策略或任何其他软件部署工具将此扩展部署到所有计算机。有关此的更多信息，请访问 docs.microsoft.com/en-us/azure/active-directory/manage-apps/access-panel-extension-problem-installing

1. 为了在本地基础设施中测试相同的功能，我们为你提供了一个小挑战。如果你未能成功运行，请发送电子邮件到 support@inovit.ch，我们将很高兴为你提供答案。

2. 你需要在 YD1APP01 服务器 上按照以下步骤部署测试应用程序。

3. 在你的域控制器（YD1ADS01）上为应用程序创建 DNS 条目 forms.inovitdemos.ch：

Add-DnsServerResourceRecord -ZoneName "inovitdemos.ch" -A -Name "forms" -IPv4Address "10.0.0.6"

1. 在应用服务器上创建应用程序运行所需的服务账户：

New-ADUser -Name "svcformsapp" -SamAccountName svcformsapp -UserPrincipalName svcformsapp@inovitdemos.ch -path "OU=Users,OU=AAD,OU=Managed Service Objects,DC=inovitdemos,DC=ch" -AccountPassword (ConvertTo-SecureString "MIA@me1976ch" -AsPlainText -Force) -Description "Forms App Pool Account" -Enabled $True

1. 在 SQL 管理工作室中连接到你的 SQL Server，位于 YD1APP01：

使用 SQL 管理工作室进行 SQL 连接

1. 在安全性 | 登录 下为你的服务账户创建一个登录：

配置应用程序服务账户的登录

1. 为用户分配 dbcreator 服务器角色：

为服务账户分配 dbcreator 角色

1. 接下来，我们需要在服务器上创建网站：

New-Item C:\inetpub\formsroot -type Directory
Import-Module Webadministration
cd IIS:
New-Item 'IIS:\Sites\forms Web Site' -bindings @{protocol="http";bindingInformation=":80:forms.inovitdemos.ch"} -physicalPath 'c:\inetpub\formsroot'

1. 与其他本地演示应用程序一样，我们将创建 HTTPS 绑定并分配我们的 SSL 证书：

配置应用程序的 IIS 绑定

1. 我们还需要为网站创建一个新的应用程序池，并使用服务账户来运行应用程序：

创建应用程序池

1. 接下来，我们将在高级设置中将新创建的应用程序池分配给我们的网站：

分配新创建的应用程序池

1. 页面身份验证应该按照以下截图进行配置：

IIS 身份验证配置

1. 下一步是将代码包中的 formsapp 文件夹内容复制到 C:\inetpub\formsroot：

应用程序代码

1. 在运行应用程序之前，你需要配置 web.config 文件，以便连接到 SQL Server 实例：

<add name="DefaultConnection" connectionString="Data Source=YD1APP01;Initial Catalog=FormsBasedAuthentication;Integrated Security=True" providerName="System.Data.SqlClient" />

1. 现在，你可以通过注册一个用户并成功登录来测试你的应用程序：

应用程序测试成功

1. 从你的发布场景开始并登录此网站——祝你好运！

在下一个示例中，我们将使用 Windows Server Web 应用程序代理 将基于基本身份验证的应用程序发布到外部用户：

1. 首先，你需要登录到YD1ADS01来配置基础演示应用程序的依赖方。

2. 导航到依赖方信任并添加依赖方信任。

3. 选择非声明感知选项。

4. 填写以下显示名称：Basic Demo Web Site。

5. 使用https://basic.inovitdemos.ch（替换为你的域名）作为依赖方信任标识符，然后点击添加。

别忘了在你的公共 DNS 中配置 FQDN。

1. 一直点击下一步直到向导完成。

2. 登录到你的YD1URA01服务器并打开远程访问管理控制台。

3. 在右侧任务窗格中点击发布：

Web 应用程序代理中的发布向导

1. 指定 ADFS 预身份验证方法：

使用 ADFS 预身份验证方法

1. 选择 HTTP Basic 作为预身份验证类型：

使用 HTTP Basic

1. 选择基础演示网站作为依赖方。

2. 填写以下发布值：

设置应用程序属性

1. 点击下一步，发布，然后关闭：

最终发布设置

1. 现在，你可以测试你刚刚发布的基本身份验证应用程序。

你可以在以下来源找到更多针对多个服务的实际场景，例如 Exchange 和远程桌面服务：docs.microsoft.com/en-us/windows-server/remote/remote-access/web-application-proxy/publishing-applications-using-ad-fs-preauthentication 和 docs.microsoft.com/en-us/windows-server/remote/remote-access/web-application-proxy/publishing-applications-using-ad-fs-preauthentication。

在下一部分中，我们将包括第一个条件访问选项。

使用条件访问

在我们的第一个条件访问场景中，我们将使用 Azure AD 功能，通过 Azure MFA 来保护 Salesforce 的访问：

1. 导航到 portal.azure.com 和 Azure AD 窗格 | 条件访问。

2. 点击新建策略：

创建条件访问策略

1. 将新策略命名为 Salesforce Protection。

2. 在分配下，进入包含 | 所有用户：

用户分配选项

1. 在云应用 | 选择应用中，选择 Salesforce：

选择 Salesforce 应用

1. 在条件 | 选择位置 | 是和任何位置：

选择位置属性

如您所见，当您需要满足附加身份验证或访问控制机制的安全要求时，您可以设置许多条件。您可以在以下来源找到更多信息：docs.microsoft.com/en-us/azure/active-directory/conditional-access/。

1. 在访问控制下，转到授予。

2. 选择授予访问权限 | 需要多因素认证（MFA）：

使用 MFA 来授予访问权限

1. 启用策略并点击创建：

启用策略

1. 现在，您可以使用 Salesforce 分配的用户进行测试，并且 Azure MFA 将是必需的。

在第二个示例中，我们将沿用相同的场景，使用我们的本地 ADFS 基础设施：

1. 登录到您的 ADFS 服务器（YD1ADS01），并打开 ADFS 管理控制台。

2. 我们将为我们的Kerberos 演示网站启用Azure MFA。

3. 右键单击应用程序并选择编辑访问控制策略：

为应用程序配置访问控制策略

1. 接下来，选择允许所有人并要求 MFA：

启用 MFA 选项

1. 应用设置并转到身份验证方法。

2. 选择编辑多因素认证方法。

3. 转到“附加”并选择 Azure MFA：

选择 Azure MFA 方法

1. 应用设置后，您现在可以开始测试应用程序。

您需要使用已注册的 Azure MFA 用户来访问应用程序。在本章的代码包中，您将找到其他用例，包括修改登录网页与用户交互所需的自定义内容。

我们将在接下来的章节中涵盖更多的条件访问用例以及有关 Azure MFA 服务的更多信息：

• 探索 Azure AD 身份服务

• 开发单租户和多租户应用程序

• 配置 Azure 信息保护解决方案

这是为了显示它与特定需求的相关性。

摘要

在本章中，您已经学会了如何使用 Azure AD 和 ADFS 功能配置不同的身份验证场景。有许多可能的组合，我们无法在一章中提供所有的组合。我们为您提供了一个入门介绍，并分享了一些实用的小贴士，帮助您开始并指引您在未来的技术旅程中前进。别担心；在本书的下一章节中，我们将深入探讨更多不同的场景，为您提供尽可能多的帮助。同时，查看本书的代码包，您将找到来自我们项目的额外实践示例。

在下一章节中，我们将探讨更多的 Azure AD 身份服务，例如 Azure AD B2B 和 B2C。

第九章：在 Azure AD 上部署其他应用程序

为你的应用程序提供正确的身份验证至关重要，尤其是当你只希望允许来自Azure Active Directory（Azure AD）的用户或任何其他 Azure AD 的用户进行身份验证时。Azure AD 提供了两个概念来为你的用户提供所需的身份验证。

在本章中，我们将向你介绍单租户和多租户应用程序的概念以及它们之间的不同之处。此外，我们将讨论在将单租户应用程序迁移到多租户应用程序时，角色和声明的不同，你可以测试这两种模型之间的过渡。我们还将部署一个使用 OpenID Connect 的多租户应用程序。在所有不同的实验中，你将学习到你需要的知识，以便从应用程序供应商那里获取信息，将应用程序集成到你的环境中。你将能够提出正确的问题，并将部署引导到正确的方向。

我们将把本章分为以下几个部分：

• 准备你的实验环境

• 定义单租户和多租户应用程序的标准

• 部署单租户应用程序，包括角色和声明

• 将单租户应用程序迁移到多租户场景

• 使用 OpenID Connect 部署多租户应用程序

和往常一样，我们将做很多实际操作。让我们整理一下在演示环境中处理实验所需的前置条件。

准备你的实验环境

在本章中，你可以使用任何安装了 Visual Studio 的机器。在我们的案例中，我们将其安装在YD1APP01服务器上。这应该是你的完美开发环境。在本实验中，你将使用Azure AD1: yourdomain1.onmicrosoft.com，并使用来自另一个租户的一个测试来宾用户和来自任何其他 Azure AD 的测试用户来测试多租户应用程序。此外，你还需要使用代码包中的代码示例，并将其用于 Visual Studio 中配置和运行应用程序：

实验环境概览

在准备好我们的实验环境后，我们可以直接进入本章的第一部分，该部分描述了单租户和多租户应用程序。

定义单租户和多租户应用程序的标准

表面上看，单租户和多租户应用程序有一个简单的解释。我们可以说，单租户应用程序仅在它们注册的租户中可用。另一方面，多租户应用程序可以在你的本地租户以及其他租户的用户中使用：

• 单租户应用程序主要用于当你希望将应用程序与外部隔离，并仅向内部用户提供访问权限时。

• 多租户应用程序用于当你希望将应用程序提供给内部员工、来宾用户以及在协作场景下的微软个人账户用户时，例如。

我们强烈建议查看 docs.microsoft.com/en-us/azure/active-directory/develop/howto-convert-app-to-be-multi-tenant 以了解在两种场景中使用的端点之间的差异。

部署包含角色和声明的单租户应用程序

在本节中，我们将以单租户配置部署 Microsoft 的示例，WebApp-RoleClaims-DotNet.sln。我们从这个设置开始，然后在下一部分将应用程序迁移到多租户应用程序。该追踪应用程序提供了以下应用角色，我们可以用来测试角色/声明主题。首先，我们可以使用管理员角色执行所有操作。使用编写者角色，你可以在应用程序中创建任务。要更改任务的状态，可以分配批准者角色。要查看任务及其相关状态，我们可以映射观察者角色。

通过以下步骤，我们将为我们的应用程序配置 Azure AD：

1. 打开 Azure 门户：portal.azure.com。

2. 导航到 Azure AD 切换板。

3. 点击应用注册。

4. 创建 + 新应用注册：

新应用程序注册

1. 提供名称。

2. 添加登录 URL，https://localhost:44322/：

应用设置对话框

1. 提供应用程序 ID URI，格式为 https://181031inovitdemos.onmicrosoft.com/trackerapp：

额外应用设置对话框

1. 提供登出 URL，https://localhost:44322/Account/EndSession。

2. 将其他设置保持为默认：

登出 URL 配置

1. 检查回复 URL；它们应该像下图一样：

回复 URL 配置

1. 在所需权限下，点击添加：

权限配置

1. 选择 Microsoft Graph API：

选择 Microsoft Graph API

1. 选择以下权限：

   • 登录并读取用户资料

   • 阅读目录数据

你可以使用 Microsoft Graph 权限参考文档 docs.microsoft.com/en-us/graph/permissions-reference 来了解更多关于此主题的信息。

1. 选中的权限应如下所示：

分配所需的两个范围

1. 保存并点击授予权限。

2. 打开应用程序的清单：

配置清单

1. 在 appRoles 部分配置下图中的角色，并使用代码包的配置代码。

2. 清单中的结果应如下所示：

添加应用角色

1. 保存清单。

2. 将应用程序 ID 复制到记事本中。

3. 转到 Azure AD 租户的属性页面。

4. 将目录 ID 复制到记事本：

获取目录 ID

1. 打开 Visual Studio 并加载名为 WebApp-RoleClaims-DotNet.sln 的解决方案文件。

2. 打开解决方案的 web.config 文件并进行以下操作：

   • 在 ida:ClientId 值中输入应用程序 ID

   • 在 ida:TenantId 值中输入目录 ID

3. 预期的结果如下：

修改 web.config 文件

1. 在 Visual Studio 中按 F5 来构建并运行应用程序。

2. 以 Don Hall 用户登录：

测试登录功能

1. 同意应用程序授权。

2. 点击接受：

OAuth 授权

1. 返回 Visual Studio 并检查 TaskController.cs 文件中的角色实现：

审查代码中的角色实现

1. Don Hall 将成功登录。

2. 点击“关于”以查看实际的角色；没有角色被分配：

查看实际的应用程序角色

1. 返回到应用程序并为多个测试用户分配角色。

2. 点击添加用户：

分配用户和组

1. 分配你想要测试的角色：

选择合适的角色

1. 在我的例子中，我使用了两个帐户，如下图所示：

角色分配结果

1. 尝试用你的用户登录；我从 Ye Xu（分配了管理员角色）开始：

测试登录功能

1. 接受用户授权：

检查并批准 OAuth 授权

1. 点击“关于”以查看分配的角色。我们可以看到 Ye Xu 已分配了管理员角色：

检查当前角色

1. 尝试一个不同角色的用户，在我的例子中是 Dan Jump（已分配 Writer 角色）：

使用第二个测试用户进行测试

1. 接受授权：

检查并批准 OAuth 授权

1. 你将看到Writer角色已正确分配：

查看当前角色

1. 尝试用一个不在组织中的用户登录（来自另一个 Azure AD 的用户）：

使用访客用户帐户进行测试

1. 请记住，我们当前使用的是单租户配置。用户会收到错误信息，无法登录：

查看错误信息

我们的演示应用程序正在运行，并且为我们自己 Azure AD 租户的用户分配了角色。来自其他 Azure AD 租户的用户目前无法访问该应用程序。

我们强烈建议按照以下指导，定制 Azure AD 中的声明，以支持其他协议，如 SAML：

• 企业角色应用程序管理：docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-enterprise-app-role-management

• SAML 声明自定义：docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-saml-claims-customization

• 声明映射：docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-claims-mapping

• 配置可选声明：docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-optional-claims

接下来，我们将把应用程序迁移到多租户配置。

将单租户应用程序迁移到多租户场景

在本节中，我们将重新配置应用程序，使其作为多租户应用程序，您可以从其他 Azure AD 租户或 Microsoft 个人账户中使用。通过以下配置，我们将应用程序迁移：

1. 打开解决方案中的 Startup.cs 文件：

   • 注释掉 ConfigureAuth(app) 这一行

   • 取消注释 ConfigureMultitenantAuth(app) 这一行：

修改代码以支持多租户使用

1. 将 ida:TenantId 值更改为我们的 Azure AD 域名：

更改租户 ID

1. 在 Visual Studio 中按 F5 以构建并运行应用程序。

2. 在 Azure AD 中将会有一个新应用程序，但用户尚未分配角色：

检查新创建应用程序的角色分配

1. 将角色重新分配给用户：

重新分配角色

1. 测试使用您的用户登录并检查应用程序。

2. 测试使用来自另一个 Azure AD 或 Microsoft 个人账户的用户进行登录。

3. 您应该能够登录：

检查使用访客用户账户进行登录

您可以在 docs.microsoft.com/en-us/azure/active-directory/develop/howto-convert-app-to-be-multi-tenant[.]（https://bit.ly/2zuyOT6）获取有关此过程的更多信息。

在这一部分，我们重新配置了应用程序，使其作为多租户应用程序正常工作，并且取得了成功！只需注意，你需要邀请 Microsoft 个人帐户作为访客用户，才能与你的应用程序一起使用。接下来，我们将部署另一个使用 OpenID Connect 的多租户应用程序，向你展示另一种实现方式。

使用 OpenID Connect 部署另一个多租户应用程序

在这一部分，我们将安装一个使用 OpenID Connect 作为认证协议的多租户应用程序。通过这个示例，你将学习如何在 Azure AD 内部署正确的应用程序注册，并了解需要在应用程序中配置哪些内容，以使用 Azure AD 作为认证提供者：

1. 打开 Azure 门户：portal.azure.com。

2. 导航到 Azure AD 面板。

3. 点击“应用注册”。

4. 点击 + 新建应用程序注册：

创建一个新的应用程序注册

1. 提供应用程序名称和登录 URL，https://localhost:44302/：

提供应用程序属性

1. 将应用程序 ID 复制到记事本中。

2. 点击“设置”：

获取应用程序配置数据

1. 提供格式为 https://181031inovitdemos.onmicrosoft.com/MTTodoWebApp 的应用程序 ID URI：

添加应用程序 ID URI

1. 提供注销 URL。首页 URL 应该已经填写完毕。

2. 提供格式为 https://localhost:44302/Account/EndSession 的 URL。

3. 点击“多租户：是”，以将应用程序作为多租户应用程序使用：

使用多租户选项

1. 配置应用程序的正确权限。点击“添加”在所需权限部分：

授予所需的权限

1. 选择 Microsoft Graph API：

使用 Microsoft Graph API

1. 分配“登录并读取用户资料”权限：

范围分配

1. 点击“授予权限”以授予权限：

授权权限对话框

1. 生成一个密钥并命名为 Key1，有效期为 2 年。

2. 点击“保存”，并将生成的密钥值复制到记事本中：

秘钥生成

1. 提供回复 URL。

2. 需要配置以下值：

   • https://localhost:44302/

   • https://localhost:44302/Onboarding/ProcessCode

3. 这是配置：

配置回复 URL

1. 打开 Visual Studio 和 WebApp-MultiTenant-OpenIDConnect-DotNet.sln 解决方案文件。

2. 打开解决方案的 web.config 文件。

3. 将 Key1 的值复制到 ida:Password 部分。

4. 将应用程序 ID 复制到 ida:ClientID 部分。

5. 修改后的代码应如下所示：

代码修改结果

1. 测试多租户功能。在 Visual Studio 中按 F5 来构建解决方案。

2. 应用程序应该已启动。

3. 点击注册：

应用程序注册过程

1. 使用用户 Don Hall 注册以查看预期的行为。

2. 您已成功登录，如您所见：

成功登录到应用程序

1. 创建一个测试项以测试应用程序的功能。这里不是关键部分；我们关注的是身份验证：

任务创建对话框

1. 尝试使用 Azure B2B 客户用户注册；您需要作为用户对应用程序进行同意。

2. 在注册过程中使用管理员同意：

检查并接受 OAuth 同意

1. 接受同意，您应该已成功登录：

成功登录到应用程序

1. 使用来自任何 Azure AD 租户的另一个用户测试应用程序，您将获得相同的体验。

做得好！我们也看到在这个多租户应用程序和 OpenID Connect 实现中。

最后的提示：配置 Graph Explorer 以便与您的租户一起使用 Microsoft Graph API，并收集更多关于该主题的信息。访问 developer.microsoft.com/en-us/graph/graph-explorer 并以全局管理员身份登录您的 Azure AD：

Microsoft Graph Explorer 应用程序

凭借这些经验，您现在可以开始分析和扩展解决方案。

摘要

在本章中，您了解了单租户和多租户应用程序及其之间的区别。您已在您的环境中处理了这两种应用程序类型。此外，您还发现了这两种应用程序类型中的角色和声明，因此您现在可以提供基于角色的访问控制（RBAC）场景。通过您部署的所有其他应用程序，您现在了解了不同协议之间的区别，如 SAML2.0、不同流类型的 OAuth2 和 OpenID Connect。您还学习了跨域身份管理系统（SCIM）如何帮助您将用户（同步）从 Azure AD 提供给应用程序。

在下一章中，您将学习如何提供基于云的身份管理生命周期。我们将重点讲解如何为您的用户提供安全且易用的身份验证和身份管理。

第十章：探索 Azure AD 身份服务

在本章中，我们将探索不同的 Azure AD 身份服务以及作为本地身份服务的 AD FS。我们将研究 Azure AD B2B 和 B2C 功能，并解释这些技术背后的主要概念。此外，我们还将查看并扩展在第一章中配置的 Azure AD 域服务，构建和管理 Azure Active Directory。为了获得完整的视图，我们还将查看 Active Directory 联邦服务的不同功能，以及它们如何支持不同的身份验证场景。您将学习如何在您的项目中使用 Azure AD B2B 和 B2C 服务，以便为客户、合作伙伴和内部员工提供适当的访问权限。特别是，您可以将 Azure AD B2C 作为您开发应用程序的完整身份平台。

本章将分为以下几个部分：

• 准备您的实验室环境

• 了解 Azure AD 面向企业（B2B）

• 探索 Azure AD 面向客户（B2C）

• 使用 Azure AD 域服务扩展 Active Directory 解决方案

• AD FS 作为云端的本地身份服务

在第一部分中，我们开始准备我们的实验室环境。

准备您的实验室环境

在本章中，我们将需要一个额外的 Azure AD，并配置 Office 365，以测试不同的功能。您已经知道如何通过第一章中的方法创建此配置，构建和管理 Azure Active Directory。创建此额外租户时只需要最小的配置集。基本上，您只需要验证并注册一个自定义域名，其他没有要求。此外，您还需要在您的管理工作站上安装 Visual Studio 2017 Community，并安装 ASP.NET 和 Web 开发工作负载：

实验室环境概览

若要配置 Azure AD 域服务 LDAPS 使用场景，您需要提供一个公共 SSL 证书。您可以使用第七章中的程序，在 Azure AD 和 AD FS 上部署解决方案，利用 Let's Encrypt 解决方案生成适合您需求的证书。我们将从 Azure AD B2B 功能开始。

了解 Azure AD B2B

Azure AD B2B 解决了业务合作伙伴之间的协作问题。它允许用户在合作伙伴之间共享业务应用程序，而无需通过公司间的联合关系和内部管理的合作伙伴身份。通过 Azure AD B2B，您可以通过邀请和授权来自合作伙伴公司的用户访问您的资源，创建跨公司关系。通过此过程，每个公司与 Azure AD 联合一次，然后每个用户都由一个 Azure AD 账户表示。这个选项还提供了更高的安全性，因为如果用户离开合作伙伴组织，访问权限将被自动禁用。在 Azure AD 内，用户将作为来宾处理，且不能在目录中遍历其他用户。邀请用户的权限将通过正确关联的组成员身份提供。

下图展示了使业务合作伙伴能够访问您的应用程序的过程：

Azure AD B2B 邀请流程

在FLOW 1的情况下，用户接受邀请后，将能够登录到合作伙伴组织。

在FLOW 2的情况下，用户将注册自己的 Azure Active Directory，并将被添加到启动邀请过程的 Azure AD 中。

您可以在docs.microsoft.com/en-us/azure/active-directory/b2b/what-is-b2b找到更多关于该服务的信息。在第十一章中，在 Azure 上创建身份生命周期管理，我们将提供完整的来宾管理生命周期配置任务，包括使用 Azure MFA、条件访问和访问审查的 Azure AD B2B 门户。

为外部合作伙伴提供资源访问（本地部署）

通过以下本地配置，我们可以为外部合作伙伴提供资源访问。您可以使用 AD FS 来执行此任务，以允许员工和客户或合作伙伴访问您的声明感知应用程序。我们可以通过配置联合合作伙伴来实现提供联合 B2B 访问的目标。

设计和流量流程如下面的图所示：

ADFS B2B 配置

Active Directory 联合服务的另一个功能是支持使用WS-Trust规范的活动客户端。这使得您的客户端软件能够与不同的参与者进行交互，而无需依赖浏览器重定向来查找声明提供者、资源提供者或其他相关组件。

流程按以下步骤进行：

1. 请求服务（客户端上的软件）查询目标服务并请求政策要求列表。这包括所需声明的列表和 STS。

2. Requesting Service 查询Relying Party STS的策略。这包括 STS 信任的声明提供程序列表。

3. Requesting Service 查询Claims Provider STS以获取策略列表。这包括所需的身份验证方法和其他信息。

4. Requesting Service 接收所有的策略信息；客户端将向Claims Provider（CP）请求令牌。这是通过SOAP over HTTPS与 CP 的直接连接。

5. CP 进行用户身份验证并返回令牌。

6. Requesting Service 接收令牌；令牌将通过 HTTPS 上的 SOAP 直接向Relying Party（RP）请求。

7. Relying Party Federation 服务器签署令牌并将其发送回用户。

8. Requesting Service 接收由Relying Party STS签发并签名的令牌。它将令牌提交到目标服务并接收响应：

WS-trust 流程

请记住，这个本地扩展始终可以与 Azure 身份和访问管理服务一起支持和使用。

探索 Azure AD B2C

Azure AD B2C 为开发人员构建了一个完整的身份管理框架，并支持通过社交网络（如 Facebook、Google 或 LinkedIn）登录应用程序，还可以为专门为公司应用程序创建使用用户名和密码的账户。同时，还提供自助密码管理和个人资料管理。此外，Azure MFA 通过引入更高等级的安全性，进一步增强了解决方案的安全性。原则上，这项功能允许小型、中型和大型公司将其客户存储在单独的 Azure Active Directory 中，并拥有与企业管理的 Azure Active Directory 相似的所有功能，甚至更多。通过不同的验证选项，您还能够为更敏感的交易提供必要的身份验证保证。Azure AD B2C 为您的开发活动处理所有 IAM 任务。

基本上，使用 Azure AD B2C 的最小架构如下所示。如前所述，Azure AD B2C 为您的应用程序提供身份管理框架：

Azure AD B2C 基本概念

为了更好地理解 Azure AD B2C，我们将构建一个来自 Microsoft 的示例应用程序，它提供一个小型 Web 应用程序，包括一个 Web API。这个应用程序是深入了解 Azure AD B2C 的良好起点。我们强烈建议在您的实验环境中构建该应用程序。该应用程序也可以运行在预定义的演示环境中。您可以在github.com/Azure-Samples/active-directory-b2c-dotnet-webapp-and-webapi#Using-the-demo-environment找到源代码。

在开始实验活动之前，我们建议先学习以下 Azure AD B2C 介绍：docs.microsoft.com/zh-cn/azure/active-directory-b2c/active-directory-b2c-overview

让我们开始旅程，并登录到我们的管理工作站。

我们将在我们创建的第一个完整 Azure AD 上执行所有 Azure AD B2C 任务。

在下一部分中，我们将创建 Azure AD B2C 租户。

Azure AD B2C 租户创建

现在我们了解了 Azure AD B2C 的基本概念，我们将开始为使用 Azure AD B2C 提供身份平台的测试应用程序进行配置：

1. 在 Visual Studio 项目文件夹中打开一个命令行窗口，我的路径是 C:\Users\jochen.nickel\Documents\Visual Studio 2017\Projects，并执行以下命令：

git clone https://github.com/Azure-Samples/active-directory-b2c-dotnet-webapp-and-webapi.git

1. 创建 Azure AD B2C 目录。

2. 使用全局管理员凭据打开 Azure 门户 (portal.azure.com)。

3. 使用搜索选项查找 Azure AD B2C 窗格，以查看我们将要创建的服务：

Azure AD B2C 创建过程

1. 单击 Azure 门户左上角的“创建资源”。

2. 单击“身份”并选择 Azure Active Directory B2C：

选择 Azure AD B2C

1. 单击“创建新的 Azure AD B2C 租户”：

创建新的 Azure AD B2C 租户

1. 使用 YOURDOMAIN1 和 YOURDOMAINB2C 值作为您的演示环境：

Azure AD B2C 属性

1. 将新的 Azure AD B2C 与我们的 Azure 订阅关联：

关联 Azure AD B2C 租户

1. 切换目录以使用新的 Azure AD B2C 租户：

Azure AD 目录切换

1. 使用 Azure AD B2C 目录：

选择新创建的 Azure AD B2C 租户

1. 导航到 Azure AD B2C 窗格：

Azure AD B2C 概述页面

在下一部分中，我们将配置 Azure AD 中的演示应用程序。

演示应用注册

接下来，我们将在应用程序下注册新的 Demo Web App 和 Web AppAPI：

1. 按照以下截图所示添加 Web 应用：

提供应用程序属性

1. 创建应用密钥：

应用密钥生成过程

1. 将密钥值复制到记事本。

2. 将应用 ID 从属性部分复制到记事本。

3. 为 Web App API 注册第二个应用程序。

4. 填写如下截图所示的值：

注册具有属性的第二个应用程序

1. 将应用 ID URI（可选）复制到记事本。

2. 配置 Web API 的发布作用域：

   • Hello.Write | 对 hello 的写访问

   • Hello.Read | 对 hello 的读取访问：

定义作用域

1. 切换到 Web 应用和 API 访问部分。

2. 点击“添加”，选择演示 Web API：

定义应用访问权限

1. 你应该看到以下内容：

API 访问结果

1. 你应该有一个记事本，其中包含以下值：

Web App 
ID d92c671f-c576-45b1-9d53-0510f306bccc
Key WdLrw#+DZ6L#vW7,3(ryS.uP

Web App API
ID 2f73f192-e9c5-4fa8-8429-9aa3fd13293e

现在，我们可以开始在 Azure AD B2C 中创建用户流程。

用户流程创建

在接下来的部分中，我们将配置 Azure AD B2C 中的第一个用户流程，获取用户注册流程并将其引导到演示应用程序。

接下来，我们将创建我们的第一个用户流程：

1. 导航到用户流程（策略），并创建你的第一个流程：

新用户流程创建

1. 使用注册和登录选项：

选择注册和登录选项

1. 对于流程，使用以下值：

定义流程属性

1. 以及以下属性：

选择将被收集并返回声明的属性

1. 点击“创建”。

现在我们已经准备好了注册和登录选项，可以开始修改演示应用程序的代码。

Visual Studio 代码修改

要使用新创建的用户流程，我们需要修改演示应用程序的代码。

修改TaskWebApp项目，内容如下：

1. 打开TaskWebApp中的web.config文件。

2. 找到以下密钥并替换它们：

   • ida:Tenant，使用你的租户名称yourdomainb2c.onmicrosoft.com

   • ida:ClientId，使用记事本中的应用 ID

   • ida:ClientSecret，使用记事本中的密钥

   • ida:SignUpSignInPolicyId，值为b2c_1_SiUpIn

3. 注释掉以下条目：

<!--<add key="api:TaskServiceUrl" value="https://aadb2cplayground.azurewebsites.net/" />-->

1. 取消注释以下条目：

<add key="api:TaskServiceUrl" value="https://localhost:44332/"/> 

1. 将api:ApiIdentifier的键值更改为 API 的应用 ID URI：

<!--<add key="api:ApiIdentifier" value="https://fabrikamb2c.onmicrosoft.com/api/" />—>
<add key="api:ApiIdentifier" value="https://yourdomainb2c.onmicrosoft.com/myAPISample/" />

1. 你的代码应该如下所示：

修改后的代码引用

修改TaskService项目，内容如下：

1. 打开TaskService项目中的Web.config文件。

2. 找到以下密钥并替换它们：

   • ida:Tenant，值为yourdomainb2c.onmicrosoft.com

   • ida:ClientId，使用来自你的 Web API 的应用程序 ID

   • ida:SignUpSignInPolicyId，值为b2c_1_SiUpIn

   • api:ReadScope，使用Hello.Read

   • api:WriteScope，值为Hello.Write

3. 你的代码应该是这样的：

修改后的代码引用

Visual Studio 启动项目修改如下：

1. 转到解决方案资源管理器，右键点击“属性”。

2. 在常规属性下，转到启动项目。

3. 使用以下配置：

配置项目启动选项

1. 在 Visual Studio 中按F5，启动 Web 应用和 Web 应用 API：

启动应用程序视图

1. 点击 Web 应用上的 注册/登录，Azure AD B2C 就会参与进来：

测试用户流程

1. 点击 立即注册。

2. 输入您的信息并点击 发送验证代码：

提供所需的资料

1. 您将收到一封包含验证代码的电子邮件，内容如下：

获取您的验证代码

1. 验证并创建帐户。

2. 现在，Azure MFA 将参与进来；请选择您首选的验证选项：

提供您的验证

1. 您已成功登录，可以查看您的声明：

演示应用程序登录成功，包括提供的声明

好极了！做得好。您可以在 docs.microsoft.com/zh-cn/azure/active-directory-b2c/ 上深入了解 Azure AD B2C。

比较 Azure AD B2B 和 B2C

基本上，这两个 Azure AD 服务都允许您与外部用户协作。Azure AD B2B 专注于简化与合作伙伴的协作流程，通过安全共享信息和资源来实现。它处理组织之间的联合，并允许不同帐户类型（如学校帐户、工作帐户，或仅仅是电子邮件帐户）进行简单的邀请和兑换过程。

Azure AD B2C 专注于创建面向客户的应用程序的开发人员。开发人员为其应用程序提供全功能的身份系统。Azure AD B2C 提供本地存储库和与其他多个身份提供商的登录体验：

Azure AD B2B	Azure AD B2C
来自合作伙伴组织的用户身份验证	移动和 Web 应用程序的客户访问
合作伙伴生命周期 = 主机和邀请组织，包括访问审查	客户生命周期 = 自助服务或应用程序管理
支持工作或学校帐户，或任何电子邮件地址	支持本地用户应用帐户或受支持的身份提供商
支持对所有 Azure AD 连接应用程序的单点登录（SSO）	支持对 Azure AD B2C 租户内客户自有应用程序的单点登录（SSO）
双方组织共同管理安全策略	应用程序管理安全策略
双方组织共同管理品牌	应用程序管理品牌
合作伙伴用户默认包含在同一个 Azure AD 中，用户类型为来宾	与组织或合作伙伴的 Azure AD 分开管理

在接下来的章节中，我们将比较 AD FS 与这两项服务，以为您提供一个全面的视角。

比较 AD FS 与 Azure B2B 和 B2C

在本节中，我们将提供一些有用的信息，以帮助您区分 AD FS 和 Azure AD B2B 以及 B2C 的功能。

我们将从 AD FS 和 Azure B2B 场景之间的主要差异开始。使用 Azure AD B2B，可以邀请来自合作伙伴组织的用户访问你自己 Azure AD 实例中的应用程序。使用 AD FS，你可以通过 CP 信任为任何基于 AD FS 的合作伙伴组织提供相同的功能。

然而，你将遇到以下差异：

• 使用 AD FS，你具有很大的灵活性，可以运行任何自定义的场景。

• 以下要求需要满足：

  • 合作伙伴需要联合服务

  • 证书处理

  • 管理开销

使用Azure AD B2B，有一个简单的邀请流程。该功能免费提供，或者如果使用基本或高级功能，则按5.1 比例计费，合作伙伴无需满足任何要求——可以向 Azure AD 和本地目录用户（包括社交身份）发送邀请。

管理员通过 Azure AD 目录控制对公司应用程序的所有访问。当合作关系终止时，合作伙伴用户可以从你的 Azure AD 中删除，且他们对你应用程序的访问将立即被撤销。可以使用访问审查来管理来宾用户的生命周期。此外，当合作伙伴用户离开合作伙伴组织时，如果该合作伙伴组织使用本地 Azure AD 而非 AdHoc（非托管的 Azure AD 租户），他们的访问权限将自动丧失。

请记住，如果你仍然希望使用 AD FS 进行 B2B，你将需要管理来宾用户账户的整个生命周期。

接下来我们将讨论 AD FS 和 Azure AD B2C 之间的差异。你可以运行两种主要场景。首先，你可以处理客户账户和本地身份存储，身份验证可以由 AD FS 管理。如果你希望在自己的环境中拥有完全的控制权，这个场景会很有用。但你还需要提供多种流程和技术来支持这种场景——这适用于整年。

另一种选择是客户可以使用 Azure AD B2C 注册或带来自己的消费者身份，这样你将获得一个完全可管理的解决方案，具有高可用性，并且大多数常见的流程和支持功能已经实现。

AD FS 提供了一个非常灵活且可定制的解决方案，适用于你自己的环境，但你需要集成社交媒体提供商并建立信任关系，以便用户能够使用他们自己的身份。如前所述，用户管理和自助服务必须构建并提供高可用性。

使用 Azure AD B2C，你将获得一个完整的解决方案，它允许业务应用程序的开发者使用 Azure AD 的整个身份框架和 B2C 扩展。注册页面已准备好使用，或者用户可以使用他们自己的身份（如 Google、Live、Facebook 等），并且你可以启用自助服务选项。

使用 Azure AD 域服务扩展 Active Directory 解决方案

Azure AD 域服务帮助您将依赖于传统身份验证方法（如 Kerberos 和 NTLM）的本地应用程序迁移到云中。此基于云的服务使您能够将 IaaS 虚拟机加入到托管域，而无需在虚拟机上提供域控制器。通过此解决方案，您可以将应用程序直接集成到 Azure Active Directory 服务中，并享受丰富的功能集。随着 Azure AD 用户同步到 Azure AD DS，您可以使用身份进行身份验证和授权。您还可以通过 轻量级目录访问协议 (LDAP/S) 连接到目录服务。

以下图示展示了从安装在 IaaS 虚拟机上的应用程序角度看集成场景：

Azure AD 域服务概述

该服务为您提供一个扁平的组织单位结构和默认的组策略，用于管理加入域的服务器系统。通常来说，将客户端计算机加入此目录并不是一个好主意。

该服务用于帮助您集成以下系统：

• NAS 系统

• 打印解决方案

如果您的本地服务没有启用声明，它也可以将您的本地服务迁移到 Azure。

以下配置展示了如何从 第一章，构建和管理 Azure Active Directory，扩展解决方案，在该章节中我们首次启用了该服务。要配置此解决方案，您需要拥有证书。请参阅 第八章，使用 Azure AD 应用程序代理和 Web 应用程序代理，查找为此目的创建证书的说明。执行以下步骤：

1. 在 Azure AD 域服务面板中导航到 portal.azure.com。

2. 选择“安全 LDAP”并启用该服务：

安全 LDAP 激活程序

1. 启用“允许通过互联网进行安全 LDAP 访问”，并上传证书，包括私钥：

提供证书

1. 在网络安全组中创建一个新的 LDAPS 安全规则。

2. 添加一个规则，包含您的源 IP 和 Azure AD DS 目标网络：

更改防火墙规则以允许 LDAPS

1. 使用您偏好的 LDAP 浏览器连接到 LDAPS 服务：

测试 LDAPS 连接

您可以在 docs.microsoft.com/en-us/azure/active-directory-domain-services/active-directory-ds-admin-guide-configure-secure-ldap 上找到有关 LDAPS 配置的更多信息。

在下一节中，我们将讨论如何将 AD FS 作为云端的本地身份服务使用。

AD FS 作为云端的本地身份服务

在多森林环境中验证用户比在典型的单森林部署中稍微复杂一些。由于前几章节的基础知识，您应该已经了解到不同的身份验证协议和 AD FS。与 Office 365 的集成配置是一个简单的过程；使用Convert-MsolDomainToFederated命令，您可以在 AD FS 配置中创建所需的一切。通过SupportMultipleDomain开关，您可以定义是否使用多森林场景。

接下来，我们将讨论在使用多个森林和 Office 365 的情况下支持的和可能的场景。我们将重点介绍 AD FS 服务器的部署。此外，您始终可以将 AD FS 代理/WAP 附加到这些场景中。

本节将涵盖以下场景：

• 典型的单森林部署

• 两个或更多个运行分开 AD FS 实例的 Active Directory 森林

• 运行单个 AD FS 实例以支持多个受信任的森林

• 支持多个 Active Directory 森林的单个 AD FS 实例，无需 AD 信任关系

• 使用本地 CP 信任支持多个 Active Directory 森林

• 使用共享的 Active Directory 环境

• Microsoft 云解决方案提供商总结

典型的单森林部署

这种情况在中小型组织中非常常见；这是一个单森林场景，使用 AD FS 认证到 Office 365。您可以使用一个或多个与验证过的 UPN 域相关的 UPN：

单森林部署

我们将在下一节详细讨论多个 AD 森林场景。

两个或更多个运行分开 AD FS 实例的 Active Directory 森林

如果没有 Active Directory 信任关系且存在 CP 信任，则通常会使用此场景。每个 Active Directory 森林都拥有自己的 AD FS 服务器，并响应其自己的 UPN。管理员只需配置唯一的 UPN 后缀。Azure AD Connect 将为不同森林进行相关的身份同步：

两个或更多个运行分开 AD FS 实例的 Active Directory 森林

在下一节中，我们将讨论多森林的单实例 ADFS 场景。

运行单个 AD FS 实例以支持多个受信任的森林

许多组织运行多个 Active Directory 森林。如果提供单一的身份验证点，一个选项是使用 Active Directory 信任关系。通过这种设计解决方案，每个森林可以使用一个 AD FS 环境，所有 UPN 都运行在这个环境中：

单个 AD FS 实例以支持多个受信任的森林

接下来，我们将讨论没有信任关系的多个林使用一个 ADFS 实例的方式。

一个 AD FS 实例支持多个 Active Directory 林，且没有 AD 信任

支持多个林的另一个选项是使用 CP 信任，如果无法使用 Active Directory 信任关系。在此场景中，AD FS 服务器默认情况下会与其自己的 Active Directory 林一起工作。AD FS 服务器还将被配置为向另一个 AD FS 请求特定的 UPN：

一个 AD FS 实例支持多个 Active Directory 林，且没有 AD 信任

在接下来的步骤中，我们将讨论如何使用本地声明提供程序信任连接多个 AD 林。

使用本地 CP 信任来支持多个 Active Directory 林

从 AD FS 2016 开始，您可以选择使用本地 CP 信任来集成额外的林。唯一需要知道的是，您将失去对内部用户的自动主域发现功能。您只能提供自定义解决方案来为您完成此操作：

使用本地 CP 信任来支持多个 Active Directory 林

您可以按照以下步骤配置该场景：

1. 设置服务账户的凭据：

$credential = Get-Credential

1. 将HostName更改为您的域控制器，并且如果已配置安全连接，则使用端口636：

# Example: $vendorDirectory = New-AdfsLdapServerConnection -
HostName leanads01.leano.ch -Port 636 -SslMode None -
AuthenticationMethod basic -Credential $credential
$vendorDirectory = New-AdfsLdapServerConnection -HostName 
yourhostname-Port 636 -SslMode None -AuthenticationMethod basic -
Credential $credential
$Name = New-AdfsLdapAttributeToClaimMapping -LdapAttribute 
sAMAccountName -ClaimType "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"
$Mail = New-AdfsLdapAttributeToClaimMapping -LdapAttribute mail -ClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"
# Example: $AdditionalAttribute = New-AdfsLdapAttributeToClaimMapping -LdapAttribute mail -ClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" 

1. 配置您自己的标识符，例如urn:example，并定义您的根用户容器，例如DC=EXAMPLE,DC=COM：

# Choose your preferred display name in the Forms-Based Authentication with the -Name parameter
# Example: Add-AdfsLocalClaimsProviderTrust -Name "Partners" -Identifier "urn:leano" -Type Ldap -LdapServerConnection $vendorDirectory -UserObjectClass user -UserContainer "DC=leano,DC=CH" -LdapAuthenticationMethod basic -AnchorClaimLdapAttribute //userPrincipalName -AnchorClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn" -LdapAttributeToClaimMapping @($Name, $Mail) -AcceptanceTransformRules "c:[] => issue(claim=c);" -Enabled $true

Add-AdfsLocalClaimsProviderTrust -Name "External" -Identifier "urn:dev" -Type Ldap -LdapServerConnection $vendorDirectory -UserObjectClass user -UserContainer "DC=EXAMPLE,DC=COM" -LdapAuthenticationMethod basic -AnchorClaimLdapAttribute userPrincipalName -AnchorClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn" -LdapAttributeToClaimMapping @($Name, $Mail) -AcceptanceTransformRules "c:[] => issue(claim=c);" -Enabled $true 

1. 配置额外的声明规则：

# Build a .txt file with the specific Claim rules - in my case 
ruleset.txt
# Change the samAccountName - Domain Suffix to your needs
@RuleName = "Pass through UPN"
c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"]
=> issue(claim = c);
@RuleName = "Pass through Mail"
c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"]
=> issue(claim = c);
@RuleName = "Pass through sAMAccountName"
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"]
=> issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Value = "Partners\" + c.Value);

1. 设置新定义的声明规则：

# Be aware to use the same name as you have chosen under Add-AdfsLocalClaimsProviderTrust -Name "Partners" $ruleset = New-AdfsClaimRuleSet -ClaimRuleFile .\ruleset.txt
Set-AdfsLocalClaimsProviderTrust -TargetName "Partners" -AcceptanceTransformRules $ruleset.ClaimRulesString 

Configure the HRD Cookie Lifetime to save the chosen IDP and to avoid further clicks for the user # In your case we would recommend a Lifetime of 1825 days = 5 years
Set-AdfsWebConfig -HRDCookieLifetime 90 -HRDCookieEnabled:$true 

Add the additional IDP to your Relying Party Trust configuration 
# TargetName = your RP you want to configure; and the ClaimsProviderName = Your defined name 

Set-AdfsRelyingPartyTrust -TargetName "ClaimsXRay" -ClaimsProviderName @("Active Directory","Partners") 

1. 修改 Active Directory 身份提供者的显示名称：

// Insert the following code to the end of your onload.js script and define your own display name // Update your custom theme with the provided Theme Customization Scripts 
if ( document.getElementById("hrdArea") ) { 
 var strADCPName = "Partners" ; 
 //Create an array of all claim provider trust section in the page 
 var listAllSpanForIdp = document.getElementsByClassName("idpDescription float") ; 
 var inc; 
 for (inc = 0; inc < listAllSpanForIdp.length; inc++) { 
 if ( listAllSpanForIdp[ inc ].innerHTML == "<span class=\"largeTextNoWrap indentNonCollapsible\">Active Directory</span>" ) { 
 //Change the HTML content of the matching section to the value specified in the strADCPName variable 
 listAllSpanForIdp[ inc ].innerHTML = "<span class=\"largeTextNoWrap indentNonCollapsible\">"+ strADCPName +"</span>" ; 
 } 
 } 
} 

1. 配置依赖方声明发布策略：

# Sends all configured claim definitions from the local AD and the additional IDP (urn:example) 
Claim Issuance Rule 1 
c:[Issuer =~ "^(SELF AUTHORITY|LOCAL AUTHORITY|urn:dev)$"]
 => issue(claim = c); 
# Removes the domain suffix in the NameID claim 
Claim Issuance Rule 2 
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"]
 => issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = RegExReplace(c.Value, ".+?\\", ""), ValueType = c.ValueType, Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"] = "urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"); 
# Restart ADFS Service 
Restart-service ADFSsrv

在接下来的部分，我们将讨论如何使用共享的 AD 环境。

使用共享的 Active Directory 环境

最近几个月，我们讨论了如何使用单一林环境来支持两个 Azure Active Directory 租户，包括 Office 365 服务以及 AD FS 和 Web 应用代理的组合。如果组织希望使用由 21Vianet 或服务提供商运营的独立 Office 365 租户，或者服务提供商希望为小型客户使用共享的 Active Directory 基础设施，我们经常收到这些问题。

以下解决方案设计基于以下支持的 AAD Connect 拓扑结构：

使用共享的 Active Directory 环境

您只能在 AD FS 或等效产品中使用此选项。通行身份验证在此用例中无法使用。

在此拓扑结构中，AAD Connect 实例配置为一组互斥的对象；例如，一个组织单位或域。此外，需要为此场景使用不同的域和用户主体名称，如下所示：

• 一个 DNS 名称只能在一个 Azure Active Directory 中注册（自定义域）

• 一个 Azure AD Connect 同步服务器与一个 Azure Active Directory 之间的一对一关系

• Azure Active Directory 实例在设计上是隔离的。

对于互斥对象集的要求同样适用于写回。一些写回功能在此拓扑结构下不受支持，包括以下内容：

• 使用默认配置的组写回

• 设备写回

该解决方案的设计基于以下关键特性：

• 一个单一的 Active Directory 森林，组织单元根据地区或客户进行划分。

• 组织单元中的用户已配置相关的用户主体名称（UPN）；例如，OU APAC使用@apac.inovitdemos.ch UPN 后缀，或者特定客户后缀，如@azureid.ch。

• 配置了基于组织单元的容器筛选器的两个 Azure AD Connect 实例。

• 一个 AD FS 和 Web 应用程序代理的组合，使用login.inovit.ch的 STS 名称。

• 一个 Azure Active Directory 租户，配备 Office 365 服务，称为客户租户 1，并注册了以下自定义域名：inovitdemos.ch。

• 一个 Azure Active Directory 租户，配备 Office 365 服务，称为客户租户 2，并且注册了apac.inovitdemos.ch或azureid.ch自定义域名：

联合配置概述

以下描述提供了在您的环境中实现此场景的主要配置步骤：

• 客户租户 1 的联合信任配置：此任务非常常见，因为只需在 AD FS 服务器上打开一个已评估的 PowerShell 并输入以下命令：

Connect-MsolService #Enter your global administrator credentials
Convert-MsolDomainToFederated -DomainName inovit.ch -SupportMultipleDomain

• 客户租户 2 的联合信任配置：您不能使用相同的 PowerShell 命令来配置第二个租户。如果尝试这样做，您将完全更改配置为第二个租户。在这种情况下，我们需要使用Set-MsolDomainAuthentication命令来配置信任到第二个租户。

Set-MsolDomainAuthentication通常用于配置与其他身份提供者的联合信任。

要配置第二个联合信任，您需要从 AD FS 农场配置中导出 AD FS 令牌签名证书。您可以使用 AD FS 管理控制台或以下 PowerShell 命令来完成此操作：

$certTS=Get-AdfsCertificate -CertificateType Token-Signing
$certInf=$certTS[0].Certificate.Export([System.Security.Cryptography.X509Certificates.X509ContentType]::Cert)
[System.IO.File]::WriteAllBytes("c:\temp\inovit-ts.cer", $certBytes)

现在我们已导出令牌签名证书，可以开始配置客户租户 2的联合信任：

$crt = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("c:\temp\inovit-ts.cer ")
$certData = [system.convert]::tobase64string($cert.rawdata)
$customdomain="azureid.ch"
#customdomain="apac.inovitdemos.ch"
$url="https://login.inovitdemos.ch/adfs/ls/"
$uri="http://login.inovitdemos.ch /adfs/services/trust/"
$ura="https://login.inovitdemos.ch/adfs/services/trust/2005/usernamemixed"
$logouturl="https://login.inovitdemos.ch/adfs/ls/"
$metadata="https://login.inovitdemos.ch/adfs/services/trust/mex"

Set-MsolDomainAuthentication -DomainName $customdomain -Authentication Federated -ActiveLogOnUri $ura -PassiveLogOnUri $url -MetadataExchangeUri $metadata -SigningCertificate $certData -IssuerUri $uri -LogOffUri $logouturl -PreferredAuthenticationProtocol WsFed

通过此解决方案，您还可以解决其他具有相同要求的场景。

微软云解决方案提供商总结

下图提供了集成和连接微软云服务提供商云服务的最佳方式概览。最受支持的方式是为客户使用一个 Active Directory，并连接一个 Azure AD 租户，或者将小型客户迁移到完全基于云的场景。Azure AD DS 在这种场景下可以非常有帮助：

微软云解决方案提供商概述

共享本地 Active Directory 场景仍然可以使用，但需要付出很大努力。

总结

在本章中，你已经了解了不同的 Azure AD 身份服务，例如 Azure AD B2B/B2C 和域服务。你还探索了将 AD FS 作为身份服务的不同选项，以便全面了解混合身份和访问管理的世界。

在下一章，我们将深入探讨不同的应用类型和部署方法，包括更多关于条件访问和我们可以使用的其他功能的详细信息。

第十一章：在 Azure 中创建身份生命周期管理

在云服务中处理身份生命周期是一个高度需求的话题；尤其是我们关注的是如何处理 Azure Active Directory 中的来宾用户，如何为云端和本地应用程序提供访问权限，包括在典型协作场景中共享信息。正因为如此，我们将讨论如何在环境中安全地处理来宾用户的多种用例，并为用户提供良好的应用程序和数据访问体验。我们还将考虑一些有用的工具和服务，以自动化身份生命周期管理。我们只能在本章中提供一些小范围的想法和参考，因为这个领域涉及许多任务和解决方案。

本章将按以下章节组织：

• 实验环境准备情况

• 处理来宾用户生命周期

• 自动化的 Azure 服务

我们将在不同的主题上进行实际操作，因此我们需要在测试环境中准备一些前提条件。

实验环境准备情况

对于本章，我们需要配置一个第二个 Azure AD，并在其中添加一些测试用户。这些用户需要具有 Office 365 E3 或 E5 许可证。租户和关联的公共 DNS 配置需要完成，以便用户可以发送和接收电子邮件。第一章，构建和管理 Azure Active Directory，为您提供了本章所需的技术参考，以准备好使用实验配置。使用 Azure AD 应用程序代理测试功能需要您完成第一章，构建和管理 Azure Active Directory，或第九章，在 Azure AD 上部署附加应用程序，特别是 Kerberos 应用程序发布。我们将进行配置，以为来宾用户提供对 YD1APP01 虚拟机上的本地应用程序的外部访问，如下图所示：

实验环境概述

除了基础设施要求之外，我们还将介绍不同邀请流程的测试用户集，以更好地理解所有相关的身份生命周期任务。为了明确哪些用户基于哪些基础设施，我们为以下内容提供了简要说明：

• Marie Lee：在混合云 Office 365 合作伙伴基础设施/租户中创建（inovit.ch）

• Jochen Nickel：在 Google 中测试用户；如果没有，创建一个供测试使用（Google）

• Jenny Green：在仅云 Office 365 合作伙伴环境中创建（yourdomain3.onmicrosoft.com/leano.ch）

• Don Hall：内部用户和 yourdomain1.onmicrosoft.com 租户的邀请人（inovitdemos.ch）

• Susi Delgado：创建一个外部电子邮件账户（identityplus.ch），不进行 Azure AD 集成

这在下图中进行了总结：

针对不同 Azure B2B 场景的测试用户

现在我们已经准备好了基础设施和测试用户设置，可以开始处理外部用户的生命周期。

处理外部用户生命周期

在接下来的部分，我们将处理外部用户的不同身份生命周期任务。我们将按以下用例组织该部分：

• 用例 1：探索不同用户类型的邀请流程

• 用例 2：使用 Azure AD B2B 门户

• 用例 3：为外部用户提供访问本地应用的权限

现在，我们将从第一个用例开始。

用例 1 – 探索不同用户类型的邀请流程

在接下来的用例中，我们将探索不同用户类型的邀请流程。我们将使用全局管理员邀请以下用户：

• Maria Lee

• Jochen Nickel

• Jenny Green

• Susi Delgado

用户名需要替换为你的名字。

在接下来的步骤中，我们将开始配置：

1. 打开 Azure 门户，portal.azure.com，以全局管理员身份登录，然后导航至 Azure AD 面板。

2. 导航到 用户 | 所有用户，如下所示：

Azure AD 门户中的外部用户创建过程

1. 点击“新建外部用户”，并邀请所有四个测试外部用户，并提供一条简短的个人消息，如 欢迎加入团队！

2. 你也可以通过 CSV 文件进行批量导入。

3. 文件的基本结构应该如下所示：

姓名	被邀请用户邮箱地址
Maria Lee	maria.lee@inovit.ch
Jochen Nickel	jochen.nickel@gmail.com
Jenny Green	jenny.green@leano.ch
Susi Delgado	susi.delgado@identityplus.ch

1. 之后，你可以运行以下命令。

2. 连接到你的 Azure AD 租户，如下所示：

Connect-AzureAD -TenantDomain "YOURDOMAIN1.onmicrosoft.com"

1. 执行邀请，如下所示：

$invitations = import-csv <Path to your invitation CSV file>
$messageInfo = New-Object Microsoft.Open.MSGraph.Model.InvitedUserMessageInfo
$messageInfo.customizedMessageBody = "Welcome to the team!"
foreach ($email in $invitations) 
 {New-AzureADMSInvitation `
 -InvitedUserEmailAddress $email.InvitedUserEmailAddress `
 -InvitedUserDisplayName $email.Name `
 -InviteRedirectUrl https://myapps.azure.com `
 -InvitedUserMessageInfo $messageInfo `
 -SendInvitationMessage $true
 }

1. 检查新创建的外部用户，如下所示：

Get-AzureADUser -Filter "UserType eq 'Guest'"

1. 接下来，我们将按以下顺序接受所有邀请：

   • Marie Lee

   • Jenny Green

   • Jochen Nickel

   • Susi Delgado

2. 登录每个邮箱以接受邀请（使用不同的浏览器或 InPrivate 会话）。

3. 你应该在每个账户上收到如下消息：

Azure AD 外部用户邀请消息

1. 点击“以 Maria 身份开始”，你将被重定向到 YOURDOMAIN1.ONMICROSOFT.COM 的同意页面，如下所示：

权限同意

这是 Azure AD 基于用户的默认行为，并且与 Jenny Green 相同。

1. 接受权限后，你将自动登录到 YOURDOMAIN1 的访问面板 UI，如下所示：

Azure AD 访问面板界面

通过此过程，你将没有预先分配的应用程序和组。

1. 注销并对 Jenny Green 执行相同操作，你将体验到相同的行为。

2. 接下来，你需要用你的 Gmail 账户进行相同的操作；在我的例子中是jochen.nickel@gmail.com。

3. 你会注意到你被重定向到 login.live.com，并且需要使用你的 Gmail 账户凭证登录，如下所示：

Gmail 账户登录 live.com 的体验

这是 Gmail 和其他联合身份提供者向 Azure AD 验证的典型行为。

1. 其他步骤与现有 Azure AD 用户相同。

2. 注销并对外部非 Azure AD 电子邮件账户（在我的例子中是 Susi Delgado）执行此过程，如下所示：

访客邀请的电子邮件账户行为

1. 你会注意到需要创建一个微软账户，如下所示：

微软账户设置

如果用户在任何 Azure AD 中不存在，这是默认行为。

你会在地址栏看到以下链接：invitations.microsoft.com/signup?tenant=7709ca2b-3be8-4d92-89d7-dc1e274b4d0e

1. 你将收到一封发送到你账户的验证邮件。

2. 输入验证码并点击“完成”，如下所示：

验证过程

1. 接受出现的同意条款。从技术上讲，你现在是你自己 Azure AD 租户的所有者。

2. 你可以通过打开 Azure 门户 portal.azure.com，并以 Susi Delgado 的身份登录来验证这一点。

3. 导航到 Azure AD 切片并检查现有用户，如下所示：

Azure AD 用户管理

1. 检查自定义域名，你会发现你的后缀被标记为已验证，如下所示：

自定义域概览

按照以下程序，你可以接管 Azure AD 租户 docs.microsoft.com/en-us/azure/active-directory/users-groups-roles/domains-admin-takeover.

你会看到所有访客用户，源类型各不相同，如下截图所示：

Azure AD 用户管理——仅限访客用户筛选

总结目前的邀请过程：如果用户已经在合作伙伴的 Azure AD 中管理，则没有特殊行为，除了接受邀请和权限同意。来自 Gmail 或任何其他联合身份提供商的用户将被视为特殊的 live.com 目录中的用户。此外，任何未在任何 Azure AD 中存在的用户，将在非管理的 Azure AD 中创建。请注意，没有自动撤销过程，用户将需要使用额外的凭据集。

使用以下配置切换，您可以限制用户访问 Azure 门户。如果您运行 Azure AD 特权身份管理场景，以下选项将不是最佳选择：

限制访问 Azure AD 门户的选项

此外，您应该重新配置外部协作的默认设置，以确保访客无法邀请其他访客，如下所示：

Azure AD 访客用户处理选项

另一个有用的提示是如何将访客用户转换为内部成员。可以通过以下 cmdlets 实现：

1. 提供全局管理员凭据，如下所示：

Connect-AzureAD

1. 按照以下步骤转换用户：

Get-AzureADUser -SearchString UserPrincipalName@YOURDOMAIN1.COM | Set-AzureADUser -UserType member

接下来要注意的重点是加强“所有用户”组（如果启用了该选项）。为此，请执行以下步骤：

1. 您可以在 Azure AD 切片 | 组 | 常规下找到该设置，如下图所示：

所有用户选项

1. 对“所有用户”组执行以下强化配置：

会员用户类型的动态组成员资格规则

1. 创建另一个动态组成员资格的组，如“所有访客用户”，如下所示：

访客用户的动态组成员资格规则

1. 您还可以为所有访客用户启用 Azure 多重身份验证（MFA），以访问 Azure 门户，portal.microsoft.com。

2. 导航到条件访问（Azure AD Premium P2）。

3. 单击“新建策略”，如下所示：

Salesforce 的条件访问管理策略

1. 定义名称并选择“所有访客用户”，如下所示：

访客用户选择

1. 选择 Microsoft Azure 管理应用程序，如下所示：

保护 Azure 门户访问

1. 在访问控制下，选择“要求多重身份验证”，如下所示：

MFA 要求

1. 启用该策略。

2. 使用其中一个访客用户测试该功能。

在完成前面的过程后，我们可以通过 Azure AD B2B 门户扩展解决方案，以提供更多功能。

使用 Azure AD B2B 门户和使用案例

邀请 API 提供了许多功能，可以自定义来宾用户的入职工作流。你可以包含诸如自我注册、为来宾用户分配经理、更新用户个人资料以及自动为来宾用户分配群组或应用等流程。我们将使用 Microsoft 示例项目来展示你在环境中的不同功能。你可以在github.com/Azure/active-directory-dotnet-graphapi-b2bportal-web找到示例项目。

安装和配置

最开始，我们需要提供两个 Azure Active Directory 应用，这些应用将用于授权正确的权限给 Azure B2B 示例门户。为此，请执行以下步骤：

1. 访问你的 Azure 门户，portal.azure.com，以及 Azure AD 窗格。

2. 点击“属性”并将目录 ID 复制到记事本中，如下所示：

获取目录 ID

1. 点击“应用注册”并添加一个新的应用，如下所示：

配置应用属性

1. 点击新创建应用的“设置”。

2. 进入“所需权限”。

3. 点击“添加”并选择 Microsoft Graph。

4. 点击“选择权限”，并启用以下权限：

   • 应用程序权限：

     • 读取和写入目录数据

     • 读取和写入所有用户的完整个人资料

   • 委托权限：

     • 登录并读取用户个人资料，如下所示：

配置所需权限

1. 在你添加 Microsoft Graph API 并配置权限后，点击“授予权限”，如下所示：

权限授予过程

1. 进入“密钥”部分。

2. 提供密钥描述并选择 2 年后过期。

3. 点击“保存”并将密钥值复制到记事本中，如下所示：

密钥生成

1. 接下来，将应用程序 ID 复制到记事本中，如下所示：

应用程序 ID 收集

1. 现在，我们可以为预认证创建第二个应用。

2. 使用以下值：

预认证应用配置

1. 在设置 | 属性下，选择“多租户”为“是”，如下所示：

启用多租户选项

1. 点击“所需权限”并添加 Microsoft Graph API。

2. 分配以下权限：

   • 委托权限：登录并读取用户个人资料

3. 不要忘记点击“授予权限”按钮。

4. 接下来，我们需要为第二个应用生成一个应用密钥，就像我们为第一个应用做的那样。

5. 将密钥值复制到记事本中。

6. 将应用程序 ID 复制到记事本中。

7. 点击“清单”，如下所示：

高级主题的应用清单配置选项

1. 我们需要将 oauth2AllowImplicitFlow 值更改为 true，如下所示：

OAuth 流程选项

1. 现在，我们可以开始将我们的 web 应用部署到 Azure。

2. 点击“部署到 Azure”，如下所示：

Azure 门户部署示例

1. 使用记事本中的值并按如下方式填写：

Azure AD B2B 门户部署选项

1. 等待部署过程完成。

2. 在 Azure 门户中导航到应用服务部分。

3. 复制 B2B 门户应用的 URL，如下所示：

应用部署结果

1. 编辑每个 Azure AD 应用并更改首页和回复 URL。

完成了。现在我们可以开始使用门户并构建一些示例流程。

门户使用

Azure AD B2B 门户提供了许多流程来展示邀请 API 的强大功能。首次访问你全新的站点时，你需要登录并配置基本参数。为此，请按照以下步骤操作：

1. 打开你的门户链接，并使用全局管理员凭据登录到 Azure AD B2B 门户，如下所示：

Azure AD B2B 门户基础配置

1. 在接下来的配置步骤中，你可以配置网页的企业身份，包括通信模板，如下所示：

Azure AD B2B 示例门户站点配置

1. 输入站点名称和邀请组织，包括简短的欢迎信息。

2. 输入邀请者电子邮件地址并点击保存。

3. 接下来，我们将在你的合作伙伴 Azure AD 租户中创建另外三个用户帐户，yourdomain3.onmicrosoft.com（leano.ch）。

4. 为用户分配 Office 365 E3/E5 许可证，以提供邮箱。

5. 只需按如下所示命名它们：

   • guest.user1@leano.ch

   • guest.user2@leano.ch

   • guest.user3@leano.ch

6. 现在，我们可以看到提供自定义邮件模板以用于邀请过程的功能。

7. 点击管理员 | 管理邮件模板，如下所示：

管理选项

1. 已经有一个默认模板，以下截图演示了这一点：

邀请模板配置

1. 点击 + 新建 创建一个额外的模板，如下所示：

自定义邮件模板配置

1. 如果你想使用 SMTP，你的 web 应用需要配置一个 SMTP 服务器。

2. 点击保存。

3. 接下来，我们将看到域管理。

4. 在此部分，你可以配置主要流程部分，具体如下：

   • 定义预批准的组织。

   • 定义用户类型，访客或成员。

   • 你可以根据组织使用预定义的邮件模板。

   • 你可以将被邀请的用户直接加入所需的组，如下所示：

自动组分配和访问管理选项

1. 输入 yourdomain3.onmicrosoft (leano.ch) 组织域。

2. 将 Kerberos 演示应用程序访问组分配给该用户。

3. 您会注意到，应用程序可以直接检查组织是否基于 Azure AD，如下所示：

后缀验证与 Azure AD 列表对比

1. 点击保存：

预批准域配置

1. 现在，我们可以使用我们的第一个访客用户来测试功能。

2. 打开 B2B 门户，如下所示：

Azure AD B2B 示例应用程序注册页面

1. 使用 guest.user1@leano.ch 注册，并点击请求访问。

2. 您将收到以下消息以识别您的请求：

注册，包括请求 ID

1. 接下来，请以管理员身份登录 B2B 门户。

2. 您将看到来自该用户的请求，如下所示：

访客批准流程

1. 访客用户尚未在组织中创建。

2. 批准请求并保存，如下所示：

请求审批

1. 以访客用户 1 身份登录 myapps.microsoft.com。

2. 您应该会收到关于邀请的通知，您可以执行入职流程。

3. 如果邀请了用户，但他未接受邀请，访客用户将处于以下状态：

用户类型和状态

1. 用户接受后，状态将会改变。

2. 以下应为预期结果。

3. 用户已分配至应用组，如下所示：

组分配

1. 用户是组织的成员。点击他的用户图标，在 myapps.microsoft.com，如下所示：

组织关联

1. 如果您点击齿轮图标，您将能够退出组织（与通用数据保护条例 GDPR 相关的功能），如下图所示：

离开组织选项

1. 如果您更改了组织，Kerberos 演示网站应用程序应当会显示，如下所示：

分配的应用程序在 Azure AD 访问面板 UI 上显示

1. 目前，如果您点击应用程序，您将收到错误信息；我们将在本章后面处理这个问题。

2. 当您点击“组”时，您将成为以下组的成员，如下所示：

组分配自助服务和概览

1. B2B 门户支持的下一个流程是对您已知的组织进行自动批准。

2. 如果你决定将邀请流程委派给 Azure AD 门户或 B2B 门户上的内部或外部员工，你可以使用 Azure AD PIM AD 客户邀请者角色，如下所示：

客户邀请者角色的委派

在这个使用案例中，你已经看到了邀请 API 的强大功能。你可以绕过它并构建你自己的场景。

特别注意事项

在这一小节中，我们将查看 B2B 流程中的一些特殊部分。让我们从用户结婚并更改姓名的情景开始，包括电子邮件地址和 userPrincipalName。按照以下步骤操作：

1. 为了查看结果，我们将对 guest.user1@leano.ch 执行此操作。

2. 打开 portal.office.com 并在 yourdomain3.onmicrosoft.com 租户中选择该用户，如下所示：

客户用户修改选项和结果

1. 点击 管理用户 并将其称为 jeff.barnes@leano.ch。

2. 导航到 Exchange 管理中心，如下所示：

Exchange 管理中心访问

1. 导航到 收件人 | 邮箱。

2. 编辑客户用户 1 为新的 Jeff Barnes，预期结果如下：

客户用户的电子邮件地址更改

1. 转到电子邮件地址。

2. 将以下所有内容更改为 Jeff Barnes，如下所示：

更改用户属性

1. 你的用户现在应该在 Azure AD 中显示如下：

更改结果

1. 接下来，我们将在 myapps.microsoft.com 上测试 Jeff Barnes（客户用户 1）的行为。

2. 你的用户应该看起来像这样：

在 Azure AD 访问面板 UI 中查看更改

1. 现在，将其更改为 INOVITDEMOS 组织。

2. 你应该和以前有相同的体验，因为后台的映射是通过 GUID 完成的。

3. 然而，你应该注意到，如下所示，用户仍然被称为客户用户 1：

在 Azure AD 访问面板 UI 中查看更改（外部组织）

1. 两个组织之间没有同步工作。

2. 你可以通过更改用户信息来改变其体验，如下所示：

属性更改选项

1. 你还需要注意有关客户用户的更多事项，如下所示：

   • 他们不能获得 Exchange Online 许可证

   • 他们不能更改 Office 365 中的租户（例如对于启用 PIM 的外部支持者）

   • 如果你的登录被阻止，你将无法离开组织

你可以在docs.microsoft.com/en-us/azure/active-directory/b2b/user-properties阅读更多关于特殊考虑事项的信息，包括如何使用访问审查来管理 Azure AD B2B 访客用户。

访客用户的本地应用程序访问

在本节中，我们将说明如何为访客用户提供本地应用程序访问权限。我们已经通过 Azure AD 应用程序代理发布了 Kerberos 演示 Web 应用程序，并且你已作为访客用户在 Azure AD 访问面板 UI 中看到该应用程序。

通过 Web 应用程序代理和 Azure AD 应用程序代理的集成，你将获得以下功能和能力：

1. 终端用户门户：myapps.microsoft.com上的 Azure 访问面板。

2. Azure AD 认证功能如下：

   • 从本地 AD DS 同步的用户名和密码

   • 联合登录到本地或其他联合服务器

   • 多因素认证（MFA）

   • 定制的登录页面

   • 基于用户或组的授权

   • 单点登录到 Office 365、成千上万的 SaaS 应用程序以及所有与 Azure AD 集成的应用程序。

3. 报告、审计和安全监控基于大数据和机器学习。

4. 所有 HTTPS 流量都在云端终止，阻止了大多数 HTTP 级别的攻击。

5. 未经身份验证的流量在云端被过滤，不会到达本地。

6. 企业网络没有传入连接——只有到 Azure AD 应用程序代理服务的传出连接。

7. 面向互联网的服务始终保持最新的安全补丁和服务器升级。

8. Azure AD 提供登录异常检测、报告和审计功能。

9. 从 Azure AD 到本地应用程序提供单点登录体验。

10. 连接器使用 Azure AD 令牌数据通过Kerberos 受限委托（KCD）以用户身份冒充访问后端应用程序。

11. 支持任何使用集成 Windows 认证（IWA）的应用程序，如 SharePoint、Outlook Web Access 和 Microsoft Dynamics CRM。

12. 无需更改后端应用程序。

13. 无需在后端应用程序上安装代理。

14. 无需直接将本地应用程序暴露到互联网。

以下图表显示了架构：

Azure AD 应用程序代理架构

在访客用户访问的情况下，Azure AD 应用程序代理仅检查userPrincipalName是否存在于本地 Active Directory 中。

要配置访客用户的访问权限，我们将使用以下步骤：

1. 以域管理员身份登录到你的域控制器YD1ADS01。

2. 打开 PowerShell 并连接到你的Azure AD，如下所示：

Connect-AzureAD

1. 获取所有访客用户，如下所示：

Get-AzureADUser -Filter "UserType eq 'Guest'"

1. 以下截图显示了输出：

租户的所有访客用户

1. 现在，我们需要将 UPN-suffix @yourdomain1.onmicrosoft.onmicrosoft.com 添加到你的 Active Directory 环境的 UPN 后缀中。

2. 使用 domain.msc 控制台；右键单击“Active Directory 域和信任”，选择“属性”。

3. 添加你的后缀，如下所示：

Azure AD 后缀到 UPN 后缀的分配

1. 接下来，我们需要在本地 Active Directory 中创建我们的访客用户。

2. 打开 dsa.msc 控制台中的 Active Directory 用户和计算机。

3. 创建一个名为“Managed External Business Objects”的组织单位，如下所示：

Active Directory 中的外部对象 OU

1. 创建用户，如下所示：

   • jenny.green_leano.ch#EXT#

   • @181031inovitdemos.onmicrosoft.com

   • BG00001：

用户属性

1. 你无需记住密码，因为它不需要。

2. Azure AD 将验证用户身份。

3. 现在，将用户分配到 Azure AD 中的 Kerberos Demo Web App Access 组，如下所示：

应用访问组成员

1. 现在，你可以在 myapps.microsoft.com 测试该解决方案。

2. 将组织更改为 INOVITDEMOS。

3. 点击 Kerberos 应用。

4. 你应该会看到成功的登录，如下所示：

Kerberos 示例网页供访客用户使用

为了自动化并扩展此解决方案，你可以使用 Microsoft Identity Manager 2016 或提供的 PowerShell 解决方案。你可以通过以下来源了解有关 Azure AD B2B 协作与 Microsoft Identity Manager（MIM）2016 SP1 和 Azure 应用代理的更多信息：

• docs.microsoft.com/en-us/microsoft-identity-manager/microsoft-identity-manager-2016-graph-b2b-scenario#b2b-end-to-end-deployment-example-scenarios

• www.microsoft.com/en-us/download/details.aspx?id=51495

在这一部分中，我们处理了多种用例，以为访客用户提供身份生命周期管理。在接下来的部分中，我们将提供一些提示，帮助你更轻松地适应你的环境。

自动化的 Azure 服务

今年，在 Microsoft Ignite 大会上，Mark Wahl 展示了一组新特性。这组特性被称为 Azure AD 身份治理，目前处于私有预览阶段。我将向你介绍一些公开的信息。

身份是控制面板，它将用户体验、业务需求和安全需求结合在一起。您需要确保正确的用户在任何时候都能获得正确的访问权限，访问正确且所需的资源。Azure AD 身份治理提供了一套功能，帮助您定义访问策略并监控您的身份。微软正在为 Azure AD 开发一整套治理功能，包括两个强大的新功能：权限管理和我的访问。

管理员将能够为资源（例如组、应用程序和站点）创建策略，借助即将推出的权限管理功能。这将提供一个自动化的过程，以便为员工和合作伙伴授予访问权限。我的访问门户使员工和合作伙伴能够请求访问这些权限，包括请求审批，正如下图所示：

Azure 身份治理权限管理选项

首先，必须指定资源并将其与权限关联。在这个例子中，您可以看到两个应用程序，一个用户组和一个 SharePoint 站点。您可以添加更多的资源。正如下图所示，角色也包含在这个概念中：

权限的资源分配

如下图所示，通过新的功能，您可以定义权限策略以推动您的安全需求：

权限策略选项

另一个您需要注意的事实是，Azure 提供了许多不同的功能，您可以利用这些功能来管理基于云的身份和访问管理。我们建议您阅读关于以下技术的文章：bit.ly/2u3LcZG：

• Microsoft Flow

• Azure 逻辑应用

• Azure 函数

• Azure 应用服务 WebJobs

社区中已经有很多示例展示了这些功能的强大，其中一些如下：

• Martina Grom，关于使用 Azure 函数配置 Office 365 组：blog.atwork.at/post/2017/10/01/Provisioning-an-Office-365-group-with-an-approval-flow-and-Azure-functions-part-2

• Asish Padhy，关于相同主题：asishpadhy.com/2018/05/01/automation-and-creation-of-office-365-groups-using-flow-microsoft-graph-and-azure-function-part-1/

• Microsoft Docs，关于 Azure 函数的 Microsoft Graph 绑定：docs.microsoft.com/en-us/azure/azure-functions/functions-bindings-microsoft-graph

• 微软，介绍 Azure Functions：docs.microsoft.com/en-us/azure/azure-functions/functions-overview

我们强烈推荐尝试使用这些技术，因为它们将是未来为客户提供实施解决方案的关键。

总结

通过本章的学习，你了解了如何构建一个包含身份生命周期的丰富 Azure B2B 解决方案，包括为访客提供的本地应用程序访问权限。此外，你还得到了对可能的使用案例和存在的漏洞的精彩介绍。我们还提供了微软正在开发的即将推出的身份治理功能的概述，以及它们将在这个领域带来的强大功能；例如，基于角色和相关策略的资源分配。

在下一章中，我们将把单租户和多租户应用程序部署到你的环境中，并介绍这些概念。

第三部分：数据分类与信息保护

在本书的最后一节中，您将学习如何理解安全文化和数据分类的关键原则。此外，您将学习如何规划、实施、故障排除以及在当前的微软信息保护技术上开发解决方案，例如 Azure 信息保护、云应用安全和 Windows Defender ATP。

本节将涵盖以下章节：

• 第十二章，创建安全文化

• 第十三章，识别和检测敏感数据

• 第十四章，理解加密密钥管理策略

• 第十五章，配置 Azure 信息保护解决方案

• 第十六章，Azure 信息保护开发

第十二章：建立安全文化

组织需要建立安全文化，以提供合适的信息保护解决方案。在本章中，您将概述安全文化的四个主要支柱，它们分别是领导支持、有效培训、持续测试以及与整个组织及其合作伙伴的持续沟通。如果没有建立安全文化，您将很难在信息保护战略的各个环节中取得成功，因为每个员工都需要知道哪些信息需要被保护。此外，如果安全措施的引入没有得到充分规划且未获得管理层的支持，可能会导致高昂的成本。

本章的另一个重点是数据分类，因为信息的分类为大多数安全机制提供了基础。信息分类为触发安全政策并实施适当保护级别的因素提供了背景。同时，我们还将解释如何通过应用安全文化的四个主要部分来支持数据分类的引入。最后，我们将首次接触微软的分类和保护解决方案，为接下来章节中的实际应用做介绍。

本章涵盖以下内容：

• 为什么我们需要安全文化？

• 良好安全文化的四个主要支柱

• 数据分类概述

• Azure 信息保护 (AIP) 概述

为什么我们需要安全文化？

一群人的思想、责任和行为会影响他们的安全，可能将他们置于风险之中，因此需要安全文化。在专业领域，安全文化用来描述组织希望在员工中看到的行为类型，涵盖网络安全、物理安全和个人安全等方面。安全培训和同事行为的改变，以适应企业的安全指南是必要的。安全文化的主要关注点是防止入侵者或其他潜在危害方的渗透。在我们的案例中，我们将重点关注数据安全相关性，因为处理完整的安全领域超出了本书的范围和重点。那么，让我们看看这对我们意味着什么。

数字化转型已经重塑了我们的工作方式。数据已成为商业的新货币。诸如开发成果、拟定的公司收购、销售账户信息、个人或财务数据以及安全信息等信息在组织中具有非常高的价值。大量由系统创建或导出的信息和数据流入并通过组织，进入云端，穿越物联网。越来越多的数据在流动，这也带来了越来越多的风险。这个事实促使组织在数据安全上进行大量投资，以保护其知识产权和客户的信任。

单靠技术并不能解决数据安全领域的问题。此外，如果你认为数据安全仅仅是 IT 的任务，那么你将继续受到用户行为引发的安全漏洞的威胁。许多安全专家仍然过于专注于流程和技术，或者仅仅关注技术。这种情况使得组织处于一种不平衡且脆弱的状态。我们需要将所有员工纳入我们的战略之中，因为如果不这样做，我们将使组织面临当前网络安全世界中近一半的安全漏洞的攻击因素。在企业中，元素、人员、流程和技术必须保持和谐，才能为正确的安全文化、成功的数据安全战略和数字化转型奠定坚实的基础。

在拥有正确安全文化的组织中，员工清楚地了解什么是对的，什么是错的，他们应该报告什么类型的活动，以及如何联系正确的团队。另一方面，在安全文化薄弱的组织中，安全责任往往推给别人。有效安全文化的一个重要特点是拥有共同的责任感。

因此，理解需要让员工参与并教育他们做出更好的信息处理决策是至关重要的。通过促使用户停下来，考虑他们所拥有和控制的业务信息的价值，你可以赋予他们以一种不会将公司数据置于风险中的方式来使用这些信息的能力。数据分类的使用使员工能够正确地处理敏感内容。

在信息创建过程中，或者在保存时，员工应该正确地分类信息并触发适当的保护措施。此外，员工还会学会更好地评估安全需求及信息对公司未来的价值，并根据组织的指导方针调整对敏感内容的处理方式。数据分类还提供了安全报告所需的关键因素，并会在合适的时机触发安全功能的执行，确保业务保持在安全状态。

你可以投入大量资金和精力来改善你的安全流程和技术控制。如果不将组织中的最终用户纳入其中，数据泄露的风险仍然很高。你需要处理的最重要任务是教育和赋能你的用户，使他们能够在处理日常工作中的信息时做出合格的决策。为了提供适当的安全解决方案，你需要在用户的日常工作中为他们提供自然的流程，并应用和执行政策，以避免违反安全规则。

通过帮助用户分类和评估他们创建的信息的价值，他们将成为数据保护和安全的积极参与者。

在下一节中，我们将讨论安全文化的四大支柱。

良好安全文化的支柱

现在我们已经强调了安全文化的必要性，接下来我们将探讨其四个主要组成部分。正如我们在引言中提到的，我们将讨论以下四个领域，它们是健康和可持续安全文化的基石：

• 领导支持

• 培训

• 测试

• 持续沟通

你将获得一个概述和一些建议，帮助你在组织中建立一个高质量的安全文化。请记住，组织的安全文化是任何安全控制的基础，应该得到信息保护战略的支持。在本节的下一部分，我们将首先讨论你需要的领导支持，以支持信息保护战略。

领导支持

信息保护战略及其相关的安全文化必须从高层管理人员和董事会成员开始。这将为开发、实施和维护信息保护战略提供必要的资源资金，其中包括安全文化。

让安全成为每个人职责的一部分是建立活跃的安全文化和可靠数据安全的关键。例如，如果一个数据分类项目在没有管理支持的情况下启动，那么该项目失败的可能性很高。原因通常是缺乏必要的资源，或者是流程和业务对接发生了变化。

你的高层赞助人应该不断了解进展情况，因为他们将准备好解决任何重大阻碍。解决方案和倡议应始终与业务目标和组织流程对齐。此外，你应该吸引并建立部门/团队冠军，使他们理解并支持你的战略，并在非常早期的阶段实施它。他们还将是反馈的优秀资源，帮助改善你的解决方案。

我们常看到，制定和实施信息保护战略及安全文化的努力常常落入 IT 部门的手中。正如我们所知，这并非纯粹的技术解决方案。成功的关键在于组织中的用户及其活动。最后，不要忘记，高管应该以身作则，因为其他员工会以他们为榜样。这意味着高管应积极参与试点项目，并遵守新的战略和文化。在实施过程中，注意他们需要特别的支持。

培训

正如我们在为什么我们需要安全文化？部分中提到的那样，教育员工做出更好的信息处理决策至关重要。适当的数据分类软件可以帮助您推动员工的参与和教育。以下是一些有效的培训策略，以解决关键问题：

• 教育用户并沟通您要分类和保护的内容。

• 提供帮助用户更好理解正确与错误的信息。

• 使用辅导方法而不是惩罚方法。

• 使用简洁自然的语言。

• 确保您的反馈循环到位。

• 根据用户的角色和相关风险来决定培训需求，例如员工离职或错误处理信息时可能导致的公司数据或图像丢失。

• 您的信息收集不必完美，但尽量做到接近 100%。

• 在改进过程中采用迭代方法。

此外，您需要将培训需求与相关风险对齐，例如特定用户组的数据丢失。例如，数据分类是每个人都应接受培训的典型通用主题。假设我们谈论一名工程师，他们应接受中级培训，了解如何处理自己的工作成果。管理整个工程师成果的管理员应该接受深入的培训，因为他们在维护组织的所有重要资产。因此，他们需要确切了解如何确保信息安全。

本质上，数据分类将显著帮助您的组织提高信息安全意识文化。因此，投资于支持和培训您的用户。收集用户反馈，倾听他们的意见，并不断改进您的培训材料。

以下培训方法可以使用：

• 提供参考海报或备忘单，用户可以将其放在桌面上。

• 将培训视频放在用户经常使用的内部门户上。

• 与高管共同制作一部关于信息保护战略和安全文化重要性的企业视频，展示以身作则的方法

• 企业内部使用的在线论坛或知识系统。

请记住，用户根据他们在组织中的角色，可能以不同的方式消化和使用培训材料。在下一部分，我们将描述安全文化中的测试需求以及信息保护解决方案的实施。

测试

对信息保护战略进行积极测试和监控对于保持安全文化的活力至关重要。在数据分类的情况下，主要目标是实现用户对你定义的数据分类标签和政策的接受，以确保用户不会作弊。为了确保你朝着正确的方向前进，你需要定义与关键成功因素对齐的具体测试场景，以验证并满足数据分类和政策的重大业务与功能需求。

还应注意，通常你传达给接收者的信息中，只有一小部分会被清晰理解。基于此，至关重要的是在小范围的测试小组中检查全球沟通，如果有必要，可以进行调整。此外，要建立信息保护活动的积极监控，并将其与信息的背景参考起来，这样你就可以测试数据的准确分类和应用保护。你的技术解决方案应该为你提供一个有用的工具包，以实现这一目标。

持续沟通

转变用户行为的一个关键工具是持续沟通，这从你开始改变组织文化时就应当开始。一开始，有必要将你的使命传达给所有用户。通过清晰的沟通，一切都能与组织的核心价值观和企业承诺对齐，并且信息保护战略与安全文化如何坚持这些承诺—用户可以看到安全投资的更大图景，并且能将自己视为整个解决方案中的重要部分。

我们还需要讨论“这对我有什么好处？”这一因素。例如，员工需要确保自己的工作与他们在入职第一天签署的信息安全政策保持一致。为了实现积极而蓬勃的沟通过程，确保你是平易近人的，并且分享你从用户反馈中得到的改进是至关重要的。

数据分类概述

在我们描述安全文化的必要性及其四个核心要素之后，我们将讨论数据分类，以为信息保护领域的成功解决方案奠定基础。正如前面所提到的，数据分类提供了正确使用保护措施所需的信息和工具。让我们从数据分类的基本定义开始。数据分类是一个持续的过程，基于特定的预定义标准对信息进行一致的分类，以便数据可以高效地验证、有效地识别并得到保护。这就是为什么数据分类是数据安全的基础。

成功的数据分类需要广泛的组织需求意识，并深入理解数据资产的存储位置以及数据或信息的生成方式。因此，查找和识别各种终端上的现有数据（例如网络共享、数据库或云服务）与分类密切相关。即使是在创建新数据时，分类也始终会进行。

除了数据通常存在的不同终端外，数据可以处于三种基本状态：空闲状态、处理状态和传输状态。这三种状态都需要数据分类的技术解决方案。然而，使用的原则对于这三种状态是相同的。不幸的是，数据分类必须在创建过程中进行。例如，关于所有三种状态的机密数据必须以机密方式处理。此外，还需要区分结构化数据和非结构化数据。在典型的分类过程中，数据库或表格中的结构化数据比文档、源代码或电子邮件等非结构化数据更为简单。

总的来说，根据数据的敏感级别管理结构化和非结构化数据至关重要。正确实施数据分类解决方案有助于在适当的前瞻性下创建敏感和机密数据。这样可以决定是否可以将信息公开发布。

在与客户的讨论中，我们常常听到他们对于采用数据分类解决方案的抵触情绪。然而，这类评论往往能够很快被反驳。以下三个例子展示了数据分类的关键方面：

• 数据分类太复杂：事实上，许多数据分类项目失败或停滞不前，是因为分类方案过于复杂。数据分类架构为信息提供不同的标签，用以应用分类。例如，“机密”标签用于标记那些不应被未授权用户访问的敏感信息。我们常常会遇到一些使用用户无法理解的标签，或者标签之间存在冲突。因此，建议从一个迭代过程开始，并仅选择必要的选项。

• 数据分类只是我需要采取的另一个步骤，它让我变得更慢：数据分类可以简化数据保护。了解哪些信息是机密的，可以让你选择合适的位置存储数据或采取保护措施。了解数据为何以及如何被保护是很重要的。此外，数据分类的一个优点是，数据可以更容易找到，员工也可以通过正确分类信息并应用适当的保护措施来保护自己。

• 数据分类只有在长时间后才能见效：自动化分类可以从第一天开始提供洞察。上下文和内容两个领域的自动化可以按一定顺序快速且轻松地创建，并且可以获得额外的信息以推动安全性改进。你将在数据分类方法部分了解更多关于不同分类方法的信息。

现在我们已经建立了数据分类的基本定义，接下来让我们讨论不同的数据分类方法。

数据分类方法

在本节中，我们将介绍不同的数据分类方法，解释每个过程，并提供方法的基本论据，包括对分类信息的获取内容。为了理解这些方法，至关重要的是你能够定义正确且最有效的分类系统方法。数据分类有两种基本方法：通过与用户的交互手动进行，和通过基于一组规则的分类软件自动进行。

对于数据分类，通常使用以下四种方法：

• 基于用户选择（手动）：

  • 专注于用户的手动选择

  • 应该与基于内容和上下文的自动化过程结合，推荐适当的分类

  • 重新分类应该受到控制和监控

  • 基于用户在创建、编辑或审查敏感信息时的知识

获取的信息：文档的内容和上下文是什么？

• 基于内容（手动/自动）：

  • 专注于使用正则表达式、元数据或其他选项检查和解释敏感内容

获取的信息：文档的内容是什么？

• 根据上下文（手动/自动）：

  • 重点放在应用程序、位置或创建者以及敏感信息的其他变量和指标

获得的信息：谁访问？数据何时访问？数据移动到何处？数据如何使用？

• 基于机器学习的支持（手动/自动）：

  • 重点放在通过与比较集和训练进行比较来自动分类的文档类别周围

获得的信息：系统学习将进一步选项集成到分类中或增加对某些信息的识别。

不同分类方法的结合结合了各个方法的不同正面特性，如下：

• 基于元数据的分类允许异常高的速度

• 对于可以使用正则表达式识别的分类标准，模式匹配快速且安全。

• 使用语言统计方法进行机器学习通常是适用的，并且在模糊标准下提供非常好的结果。

• 特殊的分类器，如图像识别，可以是另一种方法

这些方法的结合和持续使用会导致成功。

现在我们了解了不同的分类方法，我们可以解决组织面临的挑战，数据分类可以支持信息管理和安全技术有效使用的根本改善。

数据分类和非结构化数据

数据分类之所以必要的一个关键方面是公司内部产生的信息量。信息量通常是难以管理和使用的。非结构化数据的管理仍然是存储技术中较大的未解决问题之一。然而，大约 80%的存储数据可能是非结构化的，这超出了经济和可持续信息管理过程的能力。然而，过程感知分配的关键挑战存在于结构化和非结构化数据中。

此外，当前的数据量不会显示任何有关内容和预期用途的外部可见信息。如果我们使用几个简单的关键词进行分类扫描或分析元数据，可以更透明地显示不同类型数据的结果。这些结果是公司信息管理中的缺口，应通过以下特征进行识别：

• 需要特殊保护的敏感信息

• 需要归档的重要和/或受管制信息

• 很少需要的被动信息

• 可能可以删除的多余信息

• 具有特殊处理的技术日志信息

因此，创建分类的推荐方式是创建关于公司相关信息内容的必要透明度。

此外，数据分类还带来以下优势：

• 分类：允许公司在其各个业务职能之间一致地对数据进行分组，无论数据的格式或交付系统如何。

• 存储优化：介绍了一种存储分类概念（分层存储模型）。

• 数据价值：这使得数据可以根据其对公司的价值进行区分。

• 归档：为更好的信息检索引入归档。

• 透明性：信息类型和相关属性从外部是可见的。

• 协同效应：用户和应用可以使用这些信息。

• 安全性：可以控制有效且可持续的保护机制。

• 效率：处理过程和组中的信息证明。

• 统一性：通过遵循相同的原则，在公司或组织内实现一致性。

现在我们已经看到了数据分类在非结构化数据领域的优势，我们可以查看数据泄露和丢失预防的用例。

数据分类与数据泄露/丢失预防

数据泄露/丢失预防（DLP）是用于指代旨在防止公司信息不受控制泄露的解决方案的术语。DLP 是风险管理中的一种 IT 措施。如今的 DLP 解决方案仅能发挥其潜力的一部分，因为基于文件结构和其他技术属性定义权限和访问防止规则十分复杂。由于当前的解决方案通常缺乏集成专业页面的适当方法，专业部门往往不感到有责任。因此，DLP 在许多情况下仍然是打击未经授权信息泄漏的钝剑。

随着所有文件的手动和自动分类的引入，DLP 可以基于分类进行操作，而不需要通过文件结构进行繁琐的管理。关于不同分类方法的信息可以在数据分类方法部分找到。这在频繁变化的文件系统结构中是可见的。规则定义本质上对整个企业都有用，且管理开销大幅下降。分类和文档类别的概念使得集成专业页面变得更加容易。

在风险管理中，已经建立的解决方案（例如 DLP 领域的解决方案）通过使用分类可以大幅提升效率。

接下来，我们将重点关注数据分类和合规性方面。

数据分类与合规性

档案管理是满足许多合规要求的关键。如今，许多从合规角度需要归档的重要信息依然没有被归档，因为系统或流程没有将其识别为需要归档。例如，许多与合同相关的文件最终存储在文件系统中。特别是文件服务器上大量的数据存储对于许多公司来说是一个“黑匣子”，其中对于特定合规问题的相关性仅部分被了解。通过对公司内所有文件的自动化分类，可以识别出相关信息并通过分类进行归档。通过跨公司方法和自动化，能够显著提高完成度。

接下来，我们将讨论数据分类如何帮助优化您的存储使用。

存储优化

层级存储管理或分层存储是通过使用不同的性能等级来减少高成本存储系统的使用，从而优化存储成本。文件根据不同的选择标准，从成本高昂的系统迁移到成本较低的系统，而用户或应用程序不会察觉到这一变化。

传统的解决方案通常仅依赖技术属性，如文件类型或文件的年龄，来决定文件是否可以迁移到更便宜的存储系统。它们通常提供的选择标准过于粗略，在实际应用中效率不高。此外，缺乏一种合适的方法来获取文件库存的交换能力信息。

专业的文件分类和文档类别的分配，如发票、雇佣合同或建筑计划，提供了一种更好的制定外包规则的方式。此外，这些规则完全独立于文件服务器上的实际结构，因此更易于管理。

分类使得存储管理更加高效，通过根据文件对业务的价值来管理文件。

以往的访问保护机制是基于文件结构，如文件夹和共享，来实现的。因此，不能显示不同的视图。在一方面有着高管理工作量，另一方面又有着明确的保护需求之间存在冲突。此外，这种方法完全依赖用户的正确操作；如果他们错放信息，信息就会暴露给未授权的人。因此，现如今文件的保护仍然不足。

现在，我们已经通过几个数据分类有帮助的使用案例，接下来我们将讨论有关数据分类与访问控制机制之间关系的相关信息。

数据访问控制

在数据分类及后续信息保护方面，用户认证是上游过程。用户认证通常由两部分组成——用户名或 ID 用于识别用户，密码用于确认用户的凭证有效性。认证并不授予用户访问信息或服务的权限，它仅仅是验证用户是否为其所声明的人。

用户认证完成后，授权是指赋予已认证的用户访问应用程序或信息的权限。将已认证用户访问信息的权限分配给他们时，需要关注数据分类。由于认证是上游过程，因此在信息泄露的情况下，必须更好地了解哪些敏感数据可能受到影响。以下是一些可能受到影响的关键数据示例：

• 用户凭证和密码

• 特权用户的凭证和密码

• 客户的可识别个人信息

• 客户的财务数据

• 知识产权

• 人事/员工数据

• 公司的财务数据

• 医疗信息

• 物联网 (IoT) 或传感器相关数据及元数据

• 工业控制系统 (ICS) 命令与控制数据

攻击一个组织的最重大影响在于企业信任、法律问题以及品牌声誉。以下列表提供了可能受到影响的组织关键领域：

• 企业客户信任

• 品牌声誉

• 销售直接损失

• 法律

• 保护控制的改进（成本）

• 财务损失

• 监管罚款（合规性）

数据分类可能由多种因素要求，如特定的法规，通用数据保护条例 (GDPR), 《联邦数据保护法》 DSG，健康保险流动性与问责法 (HIPAA), 以及支付卡行业数据安全标准 (PCI DSS)，或知识产权保护。

以下是更多的示例及其相关领域：

领域	法规
合规性	PCI DSS, HIPAA/ 健康信息技术促进经济与临床健康法 (HITECH), 格雷姆-利奇-布莱利法案 (GLBA), 国际标准化组织 (ISO) 27001, 个人信息保护与电子文档法 (PIPEDA), GDPR
数据保护	个人可识别信息 (PII), 受保护健康信息 (PHI)
知识产权	版权、商业机密、专利申请文件、专利附带文件，非知识产权
出口合规性	国际武器贸易条例 (ITAR), 出口管理条例 (EAR)
部门	法务、人力资源、财务、工程、销售
项目	新产品及其他项目的代号
法律/可追溯性	特权、保留
维护	保留时间

现在我们已经讨论了与访问控制和常规相关的数据分类信息，接下来我们将查看一个示例分类方案和政策。

分类方案和政策示例

以下部分描述了一个示例分类方案及相关指南，以澄清数据分类中涉及的活动和流程。以下分类方案代表了根据敏感性进行分级，并提供了有关期望影响和任何必要加密的信息。

要成功实现信息保护部署的目标，基本要求是选择标准化良好的标签，并使用一个通用语言与数据安全特定术语进行连接。

以下表格展示了示例分类方案，左侧为数据的敏感性等级，随后是分类标签以及示例描述，附带对公司影响和标签使用场景：

	分类	描述和使用
低敏感性	非机密	没有组织价值或敏感性的资料。
	个人	非业务数据，仅限个人使用。公司不进行监控。如果用户被允许创建/发送个人和业务信息，特别需要此标签。

| 低敏感性 | 公开 | 不会在组织外部暴露时对组织造成威胁的信息。已批准公开使用：

• 影响：无关

• 关键性：无关

• 加密：无

|

| 低敏感性 | 一般 | 不打算公开发布的业务数据。然而，根据需要，可以与外部合作伙伴共享：

• 影响：低，最高$25,000

• 关键性：低

• 加密：如有需要

|

| 中等敏感性 | 内部 | 可以在组织内部自由分发的敏感信息，但不得离开组织边界：

• 影响：低，最高$100,000

• 关键性：低

• 加密：如有需要

标签应与一般标签一起使用，或者被其替代，因为现代组织通常与外包部门合作。 |

| 中等敏感性 | 机密 | 必须保持在组织边界内的敏感信息，只有在必要时才应与有限的内部人员共享：

• 影响：高且重要，最高$1,000,000

• 关键性：中等和高

• 加密：强烈推荐

|

| 高敏感性 | 机密 | 高度敏感的信息，如果在组织外部或不小心对内部员工透露，可能会对组织造成重大风险：

• 影响：非常高，> $10,000,000

• 关键性：非常高

• 加密：是

高机密或受限信息有时也用作“机密”的替代词。有时“受限”一词并不完全清晰，容易混淆标签的顺序：机密和受限或反之亦然。

现在我们已经概览了分类方案，让我们通过分类标签来查看更多细节与受影响信息的示例。

分类方案描述

以下分类标签及相关指南解释了前一节中的示例分类方案，分类方案与政策示例：

• 公开—一般信息：公司明确批准公开的信息。

  • 示例：营销材料、发布的季度结果。

  • 根据公司沟通政策，分类应在授权之前进行。直到获得批准，信息将被分类为机密、机密或内部。公开信息没有其他信息安全限制。

• 内部—内部信息：可以在企业内部共享，但不能在公司外部发布的信息。通常是公司信息的标准分类。

  • 示例：部门公告、项目报告、员工联系方式。

  • 内部信息只能与员工、承包商或商业伙伴共享。访问应通过专有的 IT 系统，使用企业批准的应用程序和服务进行。

• 普通—一般商业信息：不打算公开的商业数据。

  • 示例：公司的内部电话簿、组织结构图、内部标准以及大部分内部通信。

  • 然而，这些信息可以在需要时与外部合作伙伴共享。

• 机密—机密信息：如果泄露，可能会损害公司的利益或对公司及其员工造成重大干扰或尴尬的信息。因此，访问仅限于授权人员或小组。

  • 示例：个人数据、合同谈判、交易策略、上游技术数据。

  • 以下限制适用于机密信息：

    • 必须在每页或每个幻灯片的页眉或页脚清楚地标明分类。

    • 在有保密协议的情况下，承包商和商业伙伴必须知道并实施“知情需求”实践。

    • 将信息存储在公司 IT 系统中，并且只能通过企业批准的应用程序和服务访问该信息。

    • 便携设备或可移动介质上的存储仅在启用加密的情况下进行。

    • 在发送电子邮件或外部交换时加密信息，因为加密电子邮件是一个良好的安全实践。

    • 机密信息只能在业务协作应用程序中共享或存储，该应用程序的访问权限仅限于授权人员或小组。

请记住，每个人应该有一套通用的标签。不要使其过于复杂。如果您有特殊需求，例如绝密项目、收购或并购，可以将标签的范围限定在正确的用户组中。

• 机密—机密信息：具有高价值或敏感性的资讯，泄露可能对公司造成严重损害。因此，访问权限仅限于少数高信任度的个人。

  • 示例：收购计划、未公开的公司结果、经济敏感的勘探机会的初步评估。

  • 以下限制适用于机密信息：

    • 在每个页面或幻灯片的页眉或页脚，或在电子邮件的第一行显示分类信息（但不在主题行中）。在第一页或幻灯片上显示信息所有者的姓名和职位，以及“机密”免责声明。

    • 仅在存在“知情需要”时共享信息，最重要的是仅与信息所有者管理的“知情人员”名单上的受信任人员共享。

    • 仅在企业 IT 系统中存储信息，并通过使用允许处理机密信息的应用程序进行访问。例如，这些应用程序具有多因素认证和加密功能。

    • 应该避免在发送给外部人员的电子邮件中包含机密信息，除非该信息已得到适当加密。相反，应该发送包含保存文件链接的电子邮件，链接指向一个授权系统中的文件。

    • 机密信息只能通过链接共享给内部人员，链接指向授权 IT 系统中存储的文件。如果无法共享，可以使用加密邮件在内部进行传输。

现在我们已经讨论了不同的分类标签及其使用，我们可以根据示例分类方案进行一些视觉标记示例的操作。

基于分类标签的视觉标记和规则

以下表格展示了根据分类方案和安全信息应用的信息指南。文件和消息被细分为不同的类别。

在这里，您可以看到基于分类方案的文件和消息中的不同视觉标记和规则：

受影响标签	视觉标记	视觉标记和规则详细信息
所有	应用分类元数据。	应用分类元数据。消息不能包含敏感度高于消息本身的分类附件。
未分类	无视觉标记。	无视觉标记。消息或附件不得包含敏感文本。
个人	无视觉标记。	无视觉标记。消息或附件不得包含敏感文本。
公共	无视觉标记。	无视觉标记。消息或附件不得包含敏感文本。
一般	页眉/页脚中用 Arial 12 号字、加粗、居中、浅灰色显示一般字样。	页眉中显示分类：一般，并以蓝色显示。消息包含敏感信息或文本。
内部	标头/页脚包含Internal字样，字体为 Arial 12 号，粗体，居中，浅灰色。	标头包含Classification: Internal字样，字体为绿色。接收者只能位于@inovit.ch域。消息或附件不得包含敏感文本。
机密	标头/页脚包含Confidential字样，字体为 Arial 12 号，粗体，居中，浅灰色。	标头包含Classification: Confidential字样，字体为橙色。消息必须使用 Microsoft Azure RMS 进行加密。页脚包含以下文本：此信息被视为 inovit 的机密信息。必须进行适当处理并限制分发。有关更多信息，请参见公司网站的政策.
秘密	标头/页脚包含Secret字样，字体为 Arial 12 号，粗体，居中，红色。禁止降低分类。	标头包含Classification: Secret字样，字体为粗体和红色。页脚包含以下文本：此信息被视为 inovit 的秘密信息。必须进行适当处理并限制分发。有关更多信息，请参见公司网站的政策。接收者只能属于 Active Directory 组 inovit Executives。消息必须使用 Microsoft Azure RMS 进行加密。禁止降低分类。

现在我们已经看过视觉标记和规则示例，让我们继续跟进一个通用的期望行为示例。

通用期望行为示例

本节展示了在文档和消息子部分中的一些示例通用行为：

文档	消息
文档具有与用户组相关的标准分类。对于大多数用户，这可以是“General”，而对于特殊组（如 HR、法律或财务），则可以是“Confidential”。	所有消息都有与相关用户组对应的标准分类。对于大多数用户，这可以是“General”，而对于特殊组（如 HR、法律或财务），则可以是“Confidential”。
用户在保存或打印文档之前必须显式选择分类。	在发送消息之前，应该要求用户确认分类。
应通知用户，他们需要将分类更改为通过自动分类方法推荐的标签，该方法会检查文档中的特定模式或关键字。	用户可以在发送消息之前更改分类。

现在我们已经处理了一个示例分类方案，包括标签、规则和视觉标记，我们可以讨论处理和管理数据的不同角色。

定义数据处理角色

设置必要的管理角色和权限非常重要。下表列出了不同的数据拥有者角色及其相应的权限：

角色	创建	修改/删除	委托	读取	归档/恢复
拥有者	X	X	X	X	X
管理员			X
管理员					X
用户		X		X

以下任务可以由每个角色执行：

• 数据所有者：信息的所有者是数据的原始创建者，可以将所有权委托或将管理工作委托给数据管理员。当文件创建时，所有者应该能够分配一个分类。因此，他们必须理解分类方案和相关的指南，或者在分类过程中得到支持，以便能够设置正确的分类。最后，数据所有者决定信息的访问权限。

• 数据管理员：数据管理员根据数据所有者的指示管理信息。他们根据数据所有者的指示，并考虑适用的指南和要求来管理信息。

• 管理员：管理员代表的是负责确保和维护数据完整性的用户。管理员不是数据所有者。管理员角色包括备份和恢复数据以及管理记录。

• 用户：包括任何被授予访问数据或文件权限的人。用户只有用户权限，其他权限没有。

最后，在讨论处理和管理数据所需的不同角色后，我们将在接下来的部分中简要介绍数据分类标签的变化。

分类变更

对信息项进行重新分类或更改其分类状态，必须由用户执行，或者系统判断对象的重要性或风险级别发生了变化。这项工作对于确保分类状态保持当前和有效至关重要。未手动分类的内容可以自动调整，或者根据数据所有者或数据管理员的使用情况进行调整。

在本节中，我们已概述了数据分类的一般情况，接下来我们将在第十三章，识别和检测敏感数据，以及第十五章，配置 Azure 信息保护解决方案中使用该概述。为了提供我们将使用的关键技术概览，我们将在下一节中介绍Azure 信息保护（AIP）。

Azure 信息保护（AIP）概述

微软开发了一个完整的数据分类和数据保护解决方案，以满足客户和合作伙伴当前及未来的需求。AIP 的设计基于以下形式因素：

• 根据敏感性对数据进行分类

• 始终保护您的数据

• 为用户和管理员提供可见性和控制

• 支持更安全的协作方式

• 易于使用的工具集

• 高部署和管理能力

下图展示了 AIP 的高级架构及相关安全服务。在接下来的章节中，我们将深入探讨每个组件，并构建一个示例解决方案配置：

AIP 提供以下好处：

• 策略设置：AIP 的管理员提供了一组最常见的默认标签，这些标签可以根据您的要求和需求进行修改。

以下示例展示了通过 Microsoft 365 安全与合规中心 实现的新统一标签功能，该功能融合了 Office 365 和 Azure 信息保护标签系统：

• 分类：数据可以根据内容、上下文和来源进行分类，用户可以自动或手动分类，或者结合使用。

  • 示例：推荐结合手动和自动分类。它将如下所示呈现给用户：

• 标签：标签将作为元数据添加到文档中。这些标签以清晰的文本形式包含，以便其他系统能够读取其值，例如 Microsoft 的云访问安全代理——自己的云应用安全解决方案。

以下示例展示了已分类文档的元数据：

MSIP_Label_193d509a-931b-427b-bd10-45fa5a9ba362_Enabled True
 MSIP_Label_193d509a-931b-427b-bd10-45fa5a9ba362_SiteId 44b1e89f-e859-4a9b-8168-3438aea2529a
 MSIP_Label_193d509a-931b-427b-bd10-45fa5a9ba362_Owner jochen.nickel@emslabs.ch
 MSIP_Label_193d509a-931b-427b-bd10-45fa5a9ba362_SetDate 2018-11-12T14:53:49.6671922Z
 MSIP_Label_193d509a-931b-427b-bd10-45fa5a9ba362_Name General
 MSIP_Label_193d509a-931b-427b-bd10-45fa5a9ba362_Application Microsoft Azure Information Protection
 MSIP_Label_193d509a-931b-427b-bd10-45fa5a9ba362_Extended_MSFT_Method Manual
 Sensitivity General

• 保护：文档的加密和身份验证要求由现有的 Azure 权限管理服务或 Active Directory 权限管理服务解决，这些服务允许您在受保护的信息上定义细粒度的权限。

  • 示例：在这里，您可以看到 Microsoft 365 安全与合规中心中的自定义保护设置：

• 监控、追踪和日志记录：用户可以跟踪共享信息上的活动，并可以立即撤销访问权限。管理员还能够监控和记录有关管理任务、分类和保护事件的信息。

  • 示例：撤销文档访问：

以下图表展示了在信息生命周期的主要路径上保护信息的主要交互：

我们还可以看到，AIP 解决方案是 Microsoft 网络安全架构（信息保护）的一部分。您可以通过 bit.ly/2Sh1zN2 了解更多关于 Microsoft 网络安全架构的信息。

AIP 提供了一个适合数据分类的框架。该产品仍有许多限制。通过其他供应商（如 TITUS），您可以填补这些空白并提供合适的解决方案。您可以在 bit.ly/2Gbu0Wq 获取更多信息。

现在我们已经简要了解了 AIP，在接下来的章节中，我们将深入探讨这项技术。

概述

在这一章中，我们了解了为什么组织需要建立安全文化，以及它如何与信息保护战略相互关联并得到支持。接着，我们讨论了数据分类的含义以及为什么它是每个数据安全解决方案的基础。在对数据分类的总体概述中，我们考察了数据分类方案及相关政策的相关性。最后，我们看到了 Microsoft AIP 解决方案概述，它为我们将在接下来的章节中创建的信息保护解决方案构建了技术基础。运用你在本章中获得的知识，你将能够定义自己的分类方案、规则和政策。此外，你还会了解哪些领域在安全文化中至关重要，并能够将适当的任务纳入你的项目中。

在下一章中，我们将深入探讨我们与 AIP 的第一次实践经验：识别和检测敏感数据。

第十三章：识别并检测敏感数据

识别和检测敏感数据是信息保护解决方案中的一个非常重要的过程。你需要能够使用适当的匹配标准来识别环境中的敏感信息，并提供相关的分类和保护控制结果。这对确保正确的访问权限和提升安全标准非常重要。微软在这个领域进行了大量投资，提供了多种本地集成的解决方案。这些解决方案为静态数据、传输中的数据以及动态数据提供了不同的保护功能。在本章中，我们将提供一个实际的概述，帮助你了解这些信息，供你组织或客户使用：

• 扩展你的实验室环境

• 理解并使用 AIP 功能来保护动态数据

• 理解并使用 AIP 功能来保护静态数据

在本章的第一部分，我们将扩展你的实验室环境。

扩展你的实验室环境

首先，我们需要扩展你的实验室环境，以测试不同的功能，并在你阅读本书中的各章节时，给你机会扩展场景。

我们将添加两台 Windows 10 测试客户端和YD1INF01服务器。使用以下图表来获取正确的虚拟机配置、尺寸以及虚拟机的域成员资格：

实验室环境概述

Windows 10 客户端需要加入到YOURDOMAIN1.COM域，并且你需要将示例数据文件从代码包复制到两台客户端的任意目录中：

1. 将域用户添加到本地管理员组，以便轻松访问虚拟机：

用户对虚拟机的访问

1. 若要使用单点登录，请将*.yourdomain1.com添加到 Internet Explorer 配置中的本地 Intranet 区域：

IE 本地 Intranet 区域配置

1. 在两台虚拟机上安装Office 套件和Azure 信息保护客户端。

2. 使用你的Office 365 授权管理员用户打开 portal.office.com：

安装 Office 64 位版本

1. 在客户端安装 Office 64 位版本。

2. 在客户端下载并安装 Azure 信息保护客户端。你可以在aka.ms/aipclient找到安装程序。

3. 选择AzInfoProtection_PREVIEW_1.45.32.0.exe二进制文件并在没有演示策略的情况下安装它。

此外，我们将在YD1INF01服务器上安装一个 SharePoint 单一农场，用于测试本地的发现功能：

1. 访问 bit.ly/2QFfBZ0 来安装 SharePoint。

2. 预期结果是我们拥有一个演示的 SharePoint 基础架构，其中包含一个简单的文档库：

用于测试文件的 SharePoint 库

我们在YD1INF01服务器上配置了一个示例文件结构，用于在传统文件服务器解决方案中发现敏感数据：

New-Item -ItemType directory -Path 'C:\Shares\Marketing'
New-Item -ItemType directory -Path 'C:\Shares\Finance'
New-Item -ItemType directory -Path 'C:\Shares\Production'
New-Item -ItemType directory -Path 'C:\Shares\Sales'
New-Item -ItemType directory -Path 'C:\Shares\Executives'
New-Item -ItemType directory -Path 'C:\Shares\HumanResources'
New-Item -ItemType directory -Path 'C:\Shares\ResearchDevelopment'
New-SmbShare -Name Marketing -Path 'C:\Shares\Marketing' -FullAccess Everyone
New-SmbShare -Name Production -Path 'C:\Shares\Production' -FullAccess Everyone
New-SmbShare -Name Sales -Path 'C:\Shares\Sales' -FullAccess Everyone
New-SmbShare -Name HumanResources -Path 'C:\Shares\HumanResources' -FullAccess Everyone
New-SmbShare -Name ResearchDevelopment -Path 'C:\Shares\ResearchDevelopment' -FullAccess Everyone
New-SmbShare -Name Finance -Path 'C:\Shares\Finance' -FullAccess Everyone
New-SmbShare -Name Executives -Path 'C:\Shares\Executives' -FullAccess Everyone

在“理解和使用 AIP 数据流动功能”部分的相关配置步骤中，我们将复制数据。完成实验环境的扩展后，让我们识别和检测数据流动。

理解和使用 AIP 数据流动功能

数据流动或传输的含义是信息正在从环境中的一个位置主动移动到另一个位置，或通过互联网移动到外部。通常，过程始于创建文档、演示文稿或电子表格，或从源系统（如 HR、CRM 或其他系统）导出信息。最佳的做法是在这些过程中直接包含分类和保护过程。否则，您需要能够从客户端计算机和服务器上检测和识别敏感数据。另一个重要的事情是，您需要了解敏感、受保护或未受保护的信息在何处交换和存储。假设您需要一种能够监控客户端计算机、本地服务器和云端敏感数据的解决方案。微软遵循这一战略，并提供以下技术来满足这些要求，主动监控数据流动中的敏感数据：

• Azure 信息保护：包括文档跟踪的分类和保护监控。

• Windows Defender ATP：在客户端计算机上监控分类和保护活动。

• 云应用安全：对您启用的云生态系统进行主动监控，包括数据泄露防护、分类和保护功能。

• Office 365：在 Office 365 服务中进行监控、数据泄露防护、分类和保护功能。

让我们更深入地探讨这些技术的不同功能。

场景 1 - 使用 Azure 信息保护

Azure 信息保护客户端为您提供了对多种格式信息进行分类和保护的功能。在我们的示例中，我们将使用手动分类，并对文档应用保护。我们将使用来自代码包的Q3_Product_Strategy.docx文档作为示例：

1. 使用don.hall@yourdomain1.com登录到其中一台测试客户端。Don Hall 是一名战略顾问。

2. 打开Q3_Product_Strategy.docx文档。

3. 由于内容敏感，Don 将该文档分类为机密|所有员工，以对其组织外的人员进行分类和保护，具体如下图所示：

所有员工 AIP 标签

1. 保存文件并将其发送到你任何个人电子邮件地址，以及发送给我们的示例公司 CEO dan.jump@yourdomain1.com（确保他已经分配了 Microsoft 365 E5 许可证）：

包括外部联系人的测试邮件

1. 尝试在你的私人账户中打开邮件附件——你将无法访问！

2. 使用dan.jump@yourdomain1.com用户登录到第二台 Windows 10 客户端。

3. 打开 Outlook，打开附件，然后点击“查看权限...”：

具有相关权限的受保护文档

现在我们已经对文档进行了处理，并进行了分类和保护，包括与内部员工和外部账户交换信息，我们可以通过以下步骤查看 Azure 信息保护的监控功能：

1. 返回到 Don Hall 客户端，重新打开受保护的文档Q3_Product_Strategy.docx。

2. 单击 Azure 信息保护的“保护”按钮，然后选择“跟踪和撤销”，如下图所示：

RMS 跟踪和撤销功能

1. 你将被重定向到 Azure RMS 跟踪网站：track.azurerms.com/。

2. 使用don.hall@yourdomain1.com进行登录。

3. 你将获得关于你的受保护文档的所有信息，如下图所示：

受保护文档的跟踪报告

1. 查看你作为用户在“概览 | 列表 | 时间轴 | 地图”和“设置”下拥有的所有功能。

接下来，我们将查看 Azure 信息保护的管理门户面板：

1. 在“活动日志”部分，你将能够查看所有关于Q3_Product_Strategy.docx的活动：

AIP 操作的活动日志

正如我们在第五章中已经配置了Azure 日志分析，配置和管理身份保护，我们可以在“配置分析（预览）”部分使用相同的日志分析工作区来查看我们的 Azure 信息保护数据。确保启用了“启用文档内容匹配功能...”复选框：

日志分析存储

1. 在“活动日志（预览）”下，你会找到“日志分析”按钮——点击它！

2. 我们将看到关于我们的分类和保护任务的更多详细信息，涉及don.hall@yourdomain1.com：

在 Azure 日志分析中的详细日志

1. 你还可以直接在“使用情况报告（预览）”部分进行深入查看，以下图演示：

标签使用概述

1. 点击“日志分析”图标查看生成的查询和结果：

文档的具体日志结果

为了识别和分类更多信息，我们将使用几种方法，如关键字，或者在第十五章，配置 Azure 信息保护解决方案中准备的敏感信息集。您可以返回监控部分并查看结果。

现在我们已经看到 Azure 信息保护为用户和管理员发现敏感信息提供的标准功能，我们可以查看 Windows Defender ATP 的功能。

场景 2 – 使用 Windows Defender ATP 进行监控

Windows Defender 高级威胁防护基本上是为了防止、检测、调查并响应高级威胁。我们还可以使用它来检测和识别敏感信息，特别是在客户端系统上。

要使用此功能，我们需要进行配置并将两个测试客户端加入：

1. 访问 securitycenter.windows.com/ 并以全局管理员身份登录，开始按照此处图片中的配置：

   • 点击下一步：

Windows 安全中心门户

• • 根据您的需求选择存储位置：

数据存储配置

• • 选择数据保留策略。

保留时间配置

1. 选择您的组织规模、行业和预览体验。

2. 将两个测试客户端加入：

   • 下载包并安装它。

   • 在两个客户端上运行检测测试脚本：

加入测试脚本

1. 在设置 | 常规 | 高级功能下，激活包括 Azure 信息保护和 Microsoft Cloud App Security 在内的高级功能：

已连接的服务配置

1. 两个演示客户端将出现在机器列表下：

机器列表

在成功激活并将两个客户端机器加入Windows Defender ATP之后，我们可以开始测试敏感数据发现功能：

1. 使用dan.jump@yourdomain1.com登录到其中一个测试客户端。Dan Jump 是 CEO。

2. 打开Employee Details.xlsx电子表格。

3. 将文档分类为“高度机密 | 所有员工”。

在第十五章，配置 Azure 信息保护解决方案中，我们将提供与特定用例相关的分类和标签。目前，重要的是生成、修改并使用敏感数据。

1. 等待几分钟，以便在 Azure 信息保护的“数据发现（预览）”部分接收结果：

来自客户端的标签报告

1. 点击客户端端点：

客户端端点信息

太棒了！不同服务之间的集成将让您发现您环境中的敏感数据处理。通过 Windows Defender ATP、Azure ATP 和 Azure 信息保护，您可以将三个最重要的元素关联起来：

• 身份，包括认证信息

• 与身份本身相关的数据处理

• 针对计算机、服务器、身份提供商以及最终的敏感信息的攻击

在下一部分，我们将深入探讨云应用安全功能集，以识别您云生态系统中的敏感数据。

场景 3 – 在您的云生态系统中识别敏感信息

Microsoft Cloud App Security 是一个云访问安全代理（CASB），它为您提供所需的洞察力，以了解您的云应用和服务生态系统。通过此服务，您可以控制数据的流动方式，并能够识别和防范网络威胁。在本节中，我们将更详细地了解如何在我们的演示环境中发现敏感信息。

首先，我们需要启用云应用安全并将我们的云应用连接到监控我们的云生态系统。我们还需要配置 Azure 信息保护集成，以结合这些服务。

访问portal.cloudappsecurity.com并使用全局管理员凭据登录。

如果您正在按照本书中的所有实验进行操作，您的总览仪表板将如下所示：

云应用安全仪表板

通过以下步骤，我们开始配置：

1. 将我们在前几章中配置的应用程序连接到云应用安全框架：

   • Office 365

   • Salesforce

   • Dropbox

   • Microsoft Azure

2. 这可以通过启动向导完成—点击“连接应用”：

将其他应用连接到云应用安全

1. 使用 + 下拉菜单连接这些应用。

2. 提供相关的管理员凭据以连接应用：

云应用连接器

为了给您一个例子，我们将使用 Salesforce 演示此过程：

1. 提供您的 Salesforce 实例名称：

连接 Salesforce

1. 请点击链接以连接应用并授权所需权限：

权限分配

1. 提供您的管理员凭据：

提供管理员凭据

1. 您将被要求同意—点击允许：

检查并接受 OAuth 同意

1. 云应用安全将开始扫描用户、数据和活动：

云应用安全启动发现过程

1. 您将收到“已连接”状态：

Salesforce 连接状态

使用向导为每个连接到 Cloud App Security 的应用程序。

1. 在设置部分激活 Azure 信息保护集成：

配置 AIP 集成

1. 导航到信息保护 | Azure 信息保护并激活以下两个设置：

Cloud App Security 中的 AIP 设置

1. 授予 Cloud App Security 检查受保护文件的权限：

授权 OAuth 以分配权限

1. 点击接受。

现在，我们已经将应用连接到 Cloud App Security 并配置了 Azure 信息保护，我们可以开始处理下一个任务。通过以下步骤，我们开始配置：

1. 使用ye.xu@yourdomain1.com登录到其中一台测试客户端。Ye Xu 在 Sales 部门工作。

2. 登录到您的访问面板 UI：myapps.microsoft.com.

3. 点击 Salesforce。

4. 发布代码包中的以下文件：

   • Q3 销售和市场费用报告审计

   • 员工详情

   • de-drv

   • 超市销售

   • 客户账户：

Salesforce 用户视图和数据使用行为

1. 作为全局管理员，跳回到 Cloud App Security 门户（portal.cloudappsecurity.com）。

2. 导航到 Investigate | 文件：

Cloud App Security 文件使用概览

1. 将 APP 更改为 Salesforce——您的已发布文件现在可以查看：

Salesforce 的数据使用报告

一些敏感数据未加密传输到 Salesforce，从这一点起，我们可以定义规则，阻止将此信息上传到此类应用程序。如果我们将过滤器更改为 Microsoft OneDrive for Business，并将文档上传到这些位置，Cloud App Security已经能够手动或自动为信息设置正确的分类标签：

使用 Cloud App Security 应用分类标签

现在我们已经看到了 Cloud App Security 的一些强大功能，接下来让我们查看最后一个场景：使用 Office 365 进行数据泄露防护。

场景 4 - Office 365 中的数据泄露防护

在本节中，我们将使用 Exchange Online 邮件流规则来检测敏感信息。我们将自动加密邮件以保护内容。这是一个典型的用例。

我们创建 Exchange Online 邮件流规则：

• 规则 1：加密包含信用卡号码的任何电子邮件，如果该邮件离开组织：

# Open an evaluated PowerShell
# Provide your global administrator credentials
$Creds = Get-Credential
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $Creds -Authentication Basic -AllowRedirection
Import-PSSession $Session
New-TransportRule -Name "Protect external mails (Contains Credit Card)" -SentToScope NotInOrganization -ApplyRightsProtectionTemplate "Encrypt" -MessageContainsDataClassifications @(@{Name="Credit Card Number"; minCount="1"})

• 规则 2：防止已分类为Confidential / All Employees的邮件外发：

# Label ID of Confidential / All Employees gathered on the Azure Information Protection blade
$labelid = "6eae6a7b-f321-4fc4-8049-1ef7cc9575b2"
$label = "MSIP_Label_"+$labelid+"_enabled=true"
New-TransportRule -name "Protect External User Access" -SentToScope notinorganization -HeaderContainsMessageHeader "msip_labels" -HeaderContainsWord $label -RejectMessageReasonText "Internal Protected Message"

1. 使用ye.xu@yourdomain1.com登录到其中一台测试客户端。Ye Xu 在 Sales 部门工作。

2. 将以下内容的邮件发送至 Karim.Manar@yourdomain1.com 和您的私人邮箱地址。Karim 是一名控制员。

你好，Karim

我的 AMEX 卡号是 344047014854133。有效期是 09/28，CVV 是 4368

最好的祝愿

叶

1. 以 Karim.Manar@yourdomain1.com 的身份登录第二个客户端并查看该电子邮件。

2. 登录到您的私人账户。

3. 点击“阅读消息”，您可以阅读该消息：

OMEv2 用户体验

1. 使用 Dan.Jump@yourdomain1.com 登录到其中一台测试客户端。Dan 是首席执行官。

2. 将以下内容的电子邮件分类为“机密 | 所有员工”，然后发送到您的私人电子邮件账户以及 Ye Xu：

1. 您应该收到类似以下的消息：

Office 365 DLP 消息

在这个场景中，我们看到了一些 Office 365 服务的功能，帮助我们发现并识别敏感内容。在接下来的部分，我们将探讨 Azure 信息保护功能在静态数据上的应用。

理解并使用 AIP 功能来保护静态数据

对于未被主动移动的敏感信息的识别和检测，是信息保护解决方案中非常重要的组成部分。为此，Microsoft 提供了 Azure 信息保护扫描器，它允许您扫描两个典型的文件位置：文件共享和 SharePoint 文档库，您可以在以下图表中看到：

Azure 信息保护扫描器架构和组件

为了探索 AIP 扫描器 的功能，我们需要将一些示例文档分发到以下文件位置：

1. 将代码包中的示例内容移动到我们在 YD1INF01 服务器上创建的以下测试共享位置：

示例文件结构

1. 将一些测试文件上传到您的 SharePoint 文档库：

SharePoint 上的示例数据

我们需要在 YD1APP01 服务器上安装并配置 AIP 扫描器，该服务器在第七章中已安装 SQL 服务器，章节名为 在 Azure AD 和 ADFS 上部署解决方案：

1. 使用以下命令创建运行和扫描 AIP 扫描器服务的服务账户：

New-ADUser -Name "svcaipscanner" -SamAccountName svcaipscanner -UserPrincipalName svcaipscanner@inovitdemos.ch -path "OU=Users,OU=AIP,OU=Managed Service Objects,DC=inovitdemos,DC=ch" -AccountPassword (ConvertTo-SecureString "YourPassword" -AsPlainText -Force) -Enabled $True

如果您想使用仅限云的账户，可以使用以下命令：

Connect-AzureAD
$PasswordProfile = New-Object -TypeName Microsoft.Open.AzureAD.Model.PasswordProfile $PasswordProfile.ForceChangePasswordNextLogin = $false $Password = Read-Host -assecurestring "Please enter password for cloud service account" $Password = [System.Runtime.InteropServices.Marshal]::PtrToStringAuto([System.Runtime.InteropServices.Marshal]::SecureStringToBSTR($Password)) $PasswordProfile.Password = $Password
$Tenant = Read-Host "Please enter tenant name for UserPrincipalName (e.g. inovitdemos.ch)" New-AzureADUser -AccountEnabled $True -DisplayName "AIP Scanner Cloud Service" -PasswordProfile $PasswordProfile -MailNickName "AIPScannerCloud" -UserPrincipalName "AIPScannerCloud@$Tenant"

1. 将服务账户同步到您的 Azure AD：

在 Azure AD 中同步的 AIP 扫描器服务账户

1. 服务账户需要在不同的服务上拥有以下权限：

   • 本地登录（需要分配）和作为服务登录权限（通过安装完成）：

本地登录权限分配

• • 对文档库具有读取（发现）或贡献权限，以便进行分类/保护：

AIP 扫描器服务帐户的 SharePoint 访问权限

以下列表显示所需的权限：

• • 对每个文件共享库的读取权限用于发现，并且对分类/保护具有读/写权限

  • 服务器的本地管理员权限和对 SQL Server 主数据库的写权限，SQL 特定权限，如果你无法授予安装的 Sysadmin 权限

  • AzInfoProtectionScanner 数据库需要手动创建

以下帐户需要具有db_owner权限：

• • 扫描器的服务帐户

  • 扫描器安装的用户帐户

  • 扫描器配置的用户帐户

  • 对于重新保护或移除保护的标签，帐户需要成为超级用户组的一部分

1. 使用以下命令安装Azure RMS PowerShell模块：

Install-Module AADRM

1. 使用以下 cmdlet 和全局管理员凭据连接到 Azure RMS：

Connect-AadrmService

1. 启用Azure RMS 超级用户功能，默认情况下该功能是禁用的：

Enable-AadrmSuperUserFeature

1. 在你的 Azure AD 中创建一个邮件启用的组并将该组分配为SuperUserGroup：

Set-AadrmSuperUserGroup -GroupEmailAddress "AzureRMSSuperUsers@yourdomain1.com"

我们将在第十五章中更深入地讨论超级用户组，配置 Azure 信息保护解决方案。

1. 从bit.ly/2ccqSu0下载AzInfoProtection.exe二进制文件.

2. 在YD1APP01服务器上运行二进制文件安装。

3. 在服务器上安装 AIP 扫描器：

$cred = Get-Credential
Install-AIPScanner -SqlServerInstance YD1APP01 -ServiceUserCredentials $cred

1. 要运行配置任务，请安装AzureADPreview PowerShell 模块：

Install-Module AzureADPreview

1. 运行以下命令连接到你的 Azure AD并提供全局管理员凭据：

Connect-AzureAD

1. 创建WebApp及相关的Service Principle：

New-AzureADApplication -DisplayName AIPOnBehalfOf -ReplyUrls 'http://localhost'
$WebApp = Get-AzureADApplication -Filter "DisplayName eq 'AIPOnBehalfOf'"
New-AzureADServicePrincipal -AppId $WebApp.AppId
$WebAppKey = New-Guid
$Date = Get-Date
New-AzureADApplicationPasswordCredential -ObjectId $WebApp.ObjectID -startDate $Date -endDate $Date.AddYears(1) -Value $WebAppKey.Guid -CustomKeyIdentifier "AIPClient"

1. 构建需要的RequiredResourceAccess对象，以自动化权限委派给本地应用程序：

$AIPServicePrincipal = Get-AzureADServicePrincipal -All $true | ? {$_.DisplayName -eq 'AIPOnBehalfOf'}
 $AIPPermissions = $AIPServicePrincipal | select -expand Oauth2Permissions
 $Scope = New-Object -TypeName "Microsoft.Open.AzureAD.Model.ResourceAccess" -ArgumentList $AIPPermissions.Id,"Scope"
 $Access = New-Object -TypeName "Microsoft.Open.AzureAD.Model.RequiredResourceAccess"
 $Access.ResourceAppId = $WebApp.AppId
 $Access.ResourceAccess = $Scope

1. 运行以下命令创建Native App及相关的 Service Principle：

New-AzureADApplication -DisplayName AIPClient -ReplyURLs http://localhost -RequiredResourceAccess $Access -PublicClient $true
 $NativeApp = Get-AzureADApplication -Filter "DisplayName eq 'AIPClient'"
 New-AzureADServicePrincipal -AppId $NativeApp.AppId

1. 构建Set-AIPAuthentication命令，以便在 AIP 扫描器服务帐户下运行：

"Set-AIPAuthentication -WebAppID " + $WebApp.AppId + " -WebAppKey " + $WebAppKey.Guid + " -NativeAppID " + $NativeApp.AppId | Out-File ~\Desktop\Set-AIPAuthentication.txt
 Start ~\Desktop\Set-AIPAuthentication.txt

1. 打开 PowerShell（以不同用户身份运行），并提供本地 AIP 扫描器服务帐户的凭据。

2. 从Set-AIPAuthentication.txt文件中运行命令，如下所示：

Set-AIPAuthentication -WebAppID 10fea33d-a6c0-44cb-88ea-eca3cf673d4d -WebAppKey f84ec310-cb36-44f9-ab7f-4edeecf099d0 -NativeAppID 4f478966-0930-4fc3-b1e4-a3acb92d4932

1. 接受获取身份验证令牌。

2. 重启 AIP 扫描器。

在接下来的步骤中，我们将提供升级AIP 扫描器的方法，从 GA 版本升级到最新的预览版本AzInfoProtection_PREVIEW_1.45.32.0.exe：

1. 从bit.ly/2ccqSu0下载最新的预览版本并安装二进制文件。

2. 使用Profile参数更新扫描器：

Update-AIPScanner -Profile WestEurope

1. 要检查扫描器是否成功重启，在 Azure 信息保护面板中创建配置文件：

AIP 配置文件，用于位置处理

1. 数据库也将重命名为配置文件名：

在 SQL 管理工作室查看的 AIP 扫描器数据库

1. 打开新创建的个人资料并配置 AIP 扫描器设置

2. 配置以下仓库（替换服务器名称）：

配置好的 AIP 扫描器仓库

1. 对所有文件共享仓库和 SharePoint 文档库使用以下配置：

仓库策略设置选项

1. 对于个人资料，请使用以下设置：

AIP 扫描器的个人资料设置部分

1. 导航至“分类”部分下的策略设置。

2. 点击“全局策略”，并将默认标签更改为“常规”：

AIP 全局策略中的默认标签配置

1. 导航至扫描器 | 节点部分，标记扫描器服务器并点击立即扫描：

启用仓库扫描

1. 导航至 Dashboards | 数据发现（预览）以查看第一次结果：

扫描器的发现结果

阅读以下文章以获取有关根据需要自定义配置的信息：bit.ly/2T9CPn6 和 bit.ly/2Dk2YdK。

你也可以使用所有已讨论的技术收集静态数据的信息。但非常重要的一点是，所有的工作都依赖于你从运动数据和相关流程中获得的检测规则的质量。我们将在第十五章，配置 Azure 信息保护解决方案中继续探讨此规则。

摘要

本章节中，我们讨论并配置了用于发现运动中、传输中和静态数据的关键技术。你了解到这些任务的重要性，以及它们为你的环境提供的数据控制和优势。它们赋予你构建高效检测和数据泄露防护规则的能力。我们将在第十五章，配置 Azure 信息保护解决方案中利用这些知识，构建 Azure 信息保护解决方案。但首先，我们将学习更多关于 Azure RMS 密钥的信息，这是你理解保护过程并找到适当工具排查错误所必需的。

在下一章节中，你将学习 Azure RMS 密钥的使用方式以及针对不同合规性要求可用的部署模型。

第十四章：理解加密密钥管理策略

在本章中，您将学习使用三种不同的密钥部署模型来满足不同的合规性要求，并了解 Azure 密钥保管库服务在其中扮演的角色。我们将讨论三种 Azure 权利管理服务流程，以便更好地理解密钥在完整的 Azure 信息保护 (AIP) 解决方案中如何使用，从而确保正确实施，并帮助您排查解决方案中的问题。本章将分为以下几个部分：

• Azure 信息保护密钥基础知识：

  • 密钥部署模型

  • 什么是 硬件安全模块 (HSM)？

  • 什么是 Azure 密钥保管库？

• Azure RMS 的工作原理：

  • 算法和密钥长度

  • 用户环境初始化流程

  • 内容保护流程

  • 内容消费流程

让我们从 AIP 密钥基础知识开始！

Azure 信息保护 密钥基础知识

Azure 权利管理服务 (RMS) 是微软 AIP 解决方案的一部分。权利管理网页服务提供保护功能，包括管理、账户认证和许可。认证是指由 Azure RMS 执行的账户认证和激活活动。每个用户必须获取一组证书和相关密钥才能参与。许可是指 Azure RMS 通过一系列操作，授予授权用户访问受保护内容的权限。Azure RMS 服务为每个文档授予使用许可证（使用权限）给授权用户。

Azure RMS 服务公开了 简单对象访问协议 (SOAP) 接口，供客户端与 Azure RMS 交互。

Azure 权利管理网页服务还使用权利管理模板，这些模板指定了一组预定义的权限和条件，可以应用于保护内容。在 AIP 中，权利管理模板与标签相关联。为了支持其他分类解决方案，权利管理模板也可以在没有标签关联的情况下进行配置。我们已经在第十三章，识别和检测敏感数据中深入探讨了这些主题。

该网页服务默认提供所需的高可用性，并具有 服务水平协议 (SLA) 99.9% 的正常运行时间。

Azure RMS 是一个 Azure 服务，通过加密提供信息保护，帮助保护文档、文件、电子邮件和其他内容。

默认情况下，AIP 和权利管理部分会生成租户密钥并管理租户密钥生命周期的大部分方面。这是最简单的选项，具有最低的管理开销。在大多数情况下，没有额外或特殊安全需求的组织会使用此部署模型。他们只需注册 AIP，密钥管理过程由微软处理。

另外，出于安全性或合规要求，组织可能希望完全控制其租户密钥。为此，微软提供了一个名为自带密钥（BYOK）的单独部署模型。典型客户通常来自保险或医疗行业。在此部署模型中，客户可以创建硬件或软件密钥。基于硬件的密钥将创建在 HSM（硬件安全模块）上，这是推荐的选项，并将安全地传输并存储在 Azure 密钥库中。AIP 将配置为使用客户密钥。许多大型组织已经有了管理密钥材料的硬件、软件和流程——这通常发生在 HSM 上。大多数组织更倾向于将 HSM 基础设施扩展到云端。

第三种部署模型被称为自持密钥（HYOK）。此模型需要在 Windows Server 上安装一个孤立的本地活动目录权限管理服务（AD RMS）实例。AD RMS 实例将使用不同的私钥来保护敏感数据。基于此 AD RMS 实例的保护是基于标签的。默认情况下，AD RMS 不提供任何标签功能。

在不同模型之间的选择取决于贵组织的合规要求，具体如下：

• 与您的客户签订的具有特定加密和审计要求的合同

• 行业、企业和监管要求

• 数据主权法律，涉及规定和密钥位置

• 数据分类，定义了哪些敏感数据不能存储在云中

以下图表展示了三种部署模型：

Azure RMS 部署模型

在以下许可证中，您可以使用三种部署模型：

场景	Office 365 E3 或更高版本	AIP P1 或 EMS E3/M365 E3	AIP P2 或 EMS E5/M365 E3
微软管理	X	X	X
BYOK	X	X	X
HYOK			X

也可以选择在 Office 365 中使用服务加密与客户密钥，提供并控制应用层上存储在 Office 365 中的加密密钥。

以下租户密钥操作可用：

操作	微软管理	客户管理
撤销		X
Rekey	X	X
备份与恢复		X
导出	X
违约响应	X	X

若要了解有关使用客户密钥进行 Office 365 服务加密的更多信息，请访问bit.ly/2SxCJW5。

上述图表中还显示了在主要保护流程中重要的三个密钥：

• 红色：租户私钥（非对称），用于解密发布许可证

• 橙色：租户公钥（非对称），用于发布许可证的加密

• 绿色：文档特定密钥（对称），用于加密/解密内容

要更好地理解这一点，请查看以下图示中的权限管理服务的主要功能：

Azure RMS 基本功能。

该过程从保护信息开始，最终通过数据所有者或分类级别应用的权限进行使用：

1. 文档将被创建、标记并使用 RMS 保护—为此，我们需要通过身份验证与权限管理服务进行认证。

2. 与标签相关的权限和关键材料将透明地从用户那里请求。

3. 关键材料将由用户透明地接收。

4. 文档将使用所选权限进行保护。

5. 文档将分发给需要的接收者。

6. 文档将由接收者接收，因此接收者需要通过单一登录（SSO）或单一登录方式认证身份，以访问权限管理服务。

7. 关键材料和使用权将对接收者透明地请求。

8. 关键材料将被接收，接收者可以在适当的权限下访问信息，否则用户将收到访问拒绝消息。

确保仔细规划你的密钥部署。

接下来，我们将讨论微软托管密钥部署模型。

微软托管的密钥。

如果激活 AIP，将生成一个新的租户密钥，并由 Azure 信息保护服务存储和管理。在这种默认情况下，密钥类型被称为微软托管密钥。以下图示展示了该部署模型：

微软服务密钥模型。

如果微软的安全性和控制措施足够满足你的组织需求，你应该使用这种部署模型。该模型默认可用，不需要额外的订阅或配置。对于容量、性能或规模，也无需特别的计划。对大多数组织来说，这是最佳选择。该部署模型具有以下特点：

• 完全托管的租户私钥。

• 租户私钥在静态状态下加密并作为客户数据处理。

• 默认的密钥长度是 2,048 位 RSA。

现在，我们将使用以下命令验证我们租户使用的Microsoft-managed密钥：

# Installing the AADRM module to administer Azure RMS
Install-Module -Name AADRM
# Connecting to Azure RMS with global administrator rights
Connect-AadrmService
# Listing the Azure RMS keys
Get-AadrmKeys

以下截图显示了一个新激活租户的预期结果：

实际的 RMS 密钥信息。

另一个重要因素是你部署的 Azure RMS 服务所在的位置，这有助于选择在 BYOK 部署中的 Azure 密钥库位置，以减少延迟。我们可以通过以下命令收集此信息：

Get-AadrmConfiguration

在我们的案例中，Azure RMS 租户部署在欧洲，我们可以从以下截图中看到：

Azure RMS 实际配置概述。

接下来，我们将深入了解 BYOK 部署模型。

自带密钥（BYOK）。

如果你使用 Azure 密钥保管库存储密钥，表示你使用的是 BYOK 部署，你可以从本地 HSM 导入密钥或在Azure 密钥保管库内生成密钥，并将其存储在 HSM 中。密钥永远不会离开 HSM 的边界。

在撰写时，Microsoft 提供了使用专用 HSM 的公共预览版。你可以在 bit.ly/2KFnJT7 找到更多信息。

如果你需要满足额外的合规性要求，如数据驻留或特定的加密法规，应使用 BYOK 部署模型。下图展示了该部署的架构：

自带密钥模型

以下是与 BYOK 相关的关键事实：

• Azure 信息保护无法查看私钥；通过使用Azure 密钥保管库，职责得到了明确分离。

• 加密操作完全在 Azure 密钥保管库内完成

• 租户私钥存储在 Azure 密钥保管库中

在配置部分，我们将更深入地了解 HSM 和 Azure 密钥保管库。我们将配置基于 Azure 密钥保管库的密钥，并切换到 BYOK 部署。

什么是 HSM？

HSM 是提供加固、抗篡改环境的物理设备，用于管理和安全存储在 Azure RMS 及其他应用程序中使用的数字密钥。HSM 使组织能够在本地安全地管理其私钥。以下由 Thales 提供的图示展示了 BYOK 集成场景：

Thales HSM 集成

以下表格总结了在 Azure RMS 部署中实现Thales HSM 的好处：

安全密钥存储	HSM 提供了一个抗篡改的环境，用于存储私钥。所有 Thales HSM 都已获得认证，符合最高的安全标准。
合规性	HSM 符合 FIPS 140-2 Level 3 标准，这是企业和政府环境中广泛接受的硬件安全基准。
可扩展性	使用 Thales HSM 存储密钥可以使 Azure RMS 环境具有可扩展性，支持未来向本地迁移。

你还可以使用 Gemalto HSM 进行此场景。你可以在 bit.ly/2GW3t1d 找到一个示例。

什么是 Azure 密钥保管库？

Azure 密钥保管库可以最好地描述为基于 FIPS 140-2 验证的 HSM 的密钥管理服务，它还提供秘密和证书管理服务。Azure 密钥保管库用于 Azure RMS 的 BYOK 部署。该服务本身提供以下功能：

• 集中化的秘密管理

• 通过软件/硬件 HSM 保护实现合规性

• 通过 REST API/SDK/PowerShell 和 CLI 进行读/写管理

• 访问和使用监控

• 自动化分发、日志检查和部署

• 节流与版本控制

• SLA 99.9%和 6 个持久副本（3 个副本在同一区域/3 个副本在其他区域）

对于 Azure RMS 和 BYOK，您需要使用 P1 Premium 选项从本地导入密钥或直接在 Azure Key Vault 中创建密钥。此术语 BYOK 在两种情况下都使用。对于生产环境，我们建议使用本地 HSM，您可以通过以下资源配置您的环境：bit.ly/2wma4Yl。

出于演示目的，我们使用在 Azure Key Vault 中生成的密钥，因为我们认为您不想为您的个人 HSM 投入成千上万的美元。

执行以下步骤以测试您的演示环境中的 BYOK 部署：

1. 作为全局管理员打开portal.azure.com，选择 Key Vaults，点击“创建密钥保险库”：

创建 Key Vault

1. 填写以下信息：

   • 使用高级定价层

   • 使用靠近您服务的区域，以避免网络延迟问题

   • 目前暂时保留访问策略和虚拟网络访问的默认设置：

Key Vault 属性

1. 使用“生成/导入”选项生成密钥：

密钥创建过程

1. 使用以下选项：

   • 密钥类型：RSA-HSM，密钥大小为 2048 位

   • 将密钥标识符复制到记事本中以备后用：

密钥属性

1. 将 Microsoft Rights Management Services 主体添加到您的访问策略中：

服务主体分配

1. 分配以下最小权限：

   • 密钥管理操作：获取和列出

   • 加密操作：解密和签名：

权限分配

1. 可选地，您可以通过使用一个新功能集（即前置的防火墙）来限制对您的保险库的访问：

Key Vault 防火墙选项

1. 配置Azure RMS服务以使用我们新创建的密钥：

# Connecting to Azure RMS with global administrator rights
Connect-AadrmService

# Configure Azure RMS to use the key from our key vault
Use-AadrmKeyVaultKey -KeyVaultKeyUrl "<Your Key Identifier from the notepad>" -FriendlyName FirstBYOKKey -Verbose

前面的命令输出将如下所示：

将密钥使用更改为新创建的密钥

将密钥设置为Active状态：

# View the new key with the "Archived state"
Get-AadrmKeys

# Next we set the key to the "Active" state
Set-AAdrmKeyProperties -KeyIdentifier "<Your Key Identifier>" -Active $true

前面的命令输出将如下所示：

激活密钥

1. 您的 Azure Key Vault 存储密钥正在使用中：

实际使用的密钥概览

1. 您可以使用以下命令切换回Microsoft-managed key：

# Next we set the Microsoft-managed key to the "Active" state
Set-AAdrmKeyProperties -KeyIdentifier "<Your Microsoft-managed Key Identifier>" -Active $true

现在我们了解了 HSM、Azure Key Vault 以及如何配置 BYOK 部署，接下来我们将进入 HYOK 部署模型部分。

持有自己的密钥

HYOK 使用一个隔离的本地 AD RMS 实例，基于由 AIP 标签驱动的第二个不同私钥提供 RMS 模板。此部署模型应选择用于高安全性和合规性要求。

大多数时候，这用于不能存储在公共云上的数据。这些敏感数据需要存储并保护在本地。请记住，HYOK 保护的数据通常占组织受保护数据的 3% 到 5%。以下图表显示了部署模型：

持有您自己的密钥模型

以下限制/优势是按设计提供的：

• 通过 Azure 信息保护服务无法进行外部共享配置

• 外部共享仅在受控方式下与已知且命名的合作伙伴进行

• Office 365 服务无法提供索引或搜索功能；Exchange Online 传输规则和 Office 365 DLP 无法解密内容并检查它

• 共享和访问日志不会透露给任何人

• 数据始终保持加密，甚至 Microsoft 服务也无法访问

要在 AIP 标签中使用本地 AD RMS 基础设施，您需要在保护选项中选择 HYOK（AD RMS）选项。您可以选择两个选项：

• 设置 AD RMS 模板详情（模板 GUID 和授权 URL）

• 设置用户定义的权限（预览）

以下截图显示了基于模板的方法：

在标签中配置 HYOK 模板

为了在您的演示环境中配置 HYOK 部署，我们需要向现有域添加一个额外的虚拟机以安装和配置 AD RMS。

请记住，以下配置仅用于概念验证或演示目的：

• 对于生产环境，我们建议使用 SQL Server 作为 AD RMS

• 如果需要，使用身份联合选项来支持外部共享

• 使用专用的管理员帐户

• 通过防火墙或反向代理发布服务端点

按照以下步骤，我们开始配置本地 AD RMS 基础设施：

1. 创建一个 Windows Server 2016/2019 服务器虚拟机，如下所示：

创建虚拟机以承载 AD RMS 服务

1. 在您的公共 DNS 配置中创建一个 CNAME 条目——在我们的示例中，rms.inovitdemos.ch CNAME inodemosrms01.westeurope.cloudapp.azure.com。

2. 直接打开虚拟机以进行 HTTPS（概念验证/演示）：

防火墙配置以接受虚拟机上的 HTTPS 流量

1. 您需要一个至少包含 RMS 集群 URL 的公共 SSL 证书：

   • 我们使用通配符证书—*.inovitdemos.ch

确保将您的虚拟机加入域并将证书安装到本地计算机存储！为了演示目的，您也可以使用 HTTP 配置运行。

1. 作为域管理员，在域控制器上准备活动目录对象进行配置。

2. 创建 RMS 集群服务帐户：

New-ADUser -Name "svcrmscluster" -SamAccountName svcrmscluster -UserPrincipalName svcrmscluster@inovitdemos.ch -path "OU=Users,OU=AIP,OU=Managed Service Objects,DC=inovitdemos,DC=ch" -AccountPassword (ConvertTo-SecureString "MIA@me1976ch" -AsPlainText -Force) -EmailAddress "svcrmscluster@inovitdemos.ch" -Enabled $True

1. 创建 RMS 超级用户组并应用电子邮件地址以恢复受保护的数据：

New-ADGroup -Name "AIP RMS Super Users" -SamAccountName "AIP RMS Super Users" -GroupCategory Security -GroupScope Global -DisplayName "AIP RMS Super Users" -Path "OU=Groups,OU=AIP,OU=Managed Service Objects,DC=inovitdemos,DC=ch" -Description "AIP RMS Super Users"

1. 创建一个测试组，例如 Executives，用于 RMS 模板，并配置一个电子邮件地址——将需要测试的用户添加到该组：

New-ADGroup -Name "Executives" -SamAccountName "Executives" -GroupCategory Security -GroupScope Global -DisplayName "Executives" -Path "OU=Groups,OU=Managed Business Objects,DC=inovitdemos,DC=ch" -Description "Executives"

1. 为 RMS 端点创建一个内部 DNS 条目：

Add-DnsServerResourceRecord -ZoneName "inovitdemos.ch" -A -Name "rms" -IPv4Address "10.0.0.11"

1. 以域管理员身份登录到托管 AD RMS 服务器的新服务器。

2. 打开服务器管理器，添加活动目录 Rights Management 服务：

   • 点击“添加功能”：

AD RMS 角色安装

1. 保持所有默认设置不变，点击“下一步”：

角色服务安装

1. 通过在欢迎屏幕上点击“下一步”配置 AD RMS。

2. 创建 RMS 集群（“集群”是 AD RMS 中的特定术语，表示你可以有多个 RMS 服务器——这并不意味着 Windows 服务器集群）：

RMS 集群创建过程

1. 选择数据库部署——对于生产环境，使用专用 SQL 服务器：

AD RMS 集群的数据库配置

1. 配置我们之前创建的服务帐户，即 svcrmscluster@inovitdemos.ch：

AD RMS 的服务帐户使用

1. 配置以下选项，如下所示：

   • 加密模式：模式 2

   • 集群密钥存储：使用 AD RMS

   • 集群密钥密码：选择你的集群密钥词，例如 455A#aasdd+!

   • 集群网站：使用默认网站

2. 配置集群地址：

AD RMS 集群地址配置

如果你不想使用 HTTPS，可以改为 HTTP 用于 PoC/Demo 目的。

1. 如果你在上一步配置了 HTTPS，选择你的证书。

2. 给你的许可证书命名。我们建议使用组织名称，例如 INOVITDEMOS。

3. 不注册 SCP。如果你已经在现有的基础架构上，必须更改选项以不使用 SCP。

4. 我们已经完成了 AD RMS 实例的配置。我们需要注销并重新登录以完成配置：

AD RMS 安装结果概览

1. 打开 AD RMS 管理控制台配置最后的选项。

2. 打开“属性”并像配置内部网络 URL 一样配置外部网络 URL：

配置 AD RMS 外部网络 URL

1. 配置 AD RMS 超级用户组：

提供 AD RMS 超级用户组

1. 打开注册表编辑器，设置 GICURL REG_SZ 项——http 或 https rms 集群名称 /_wmcs/certification/certification.asmx：

设置 HYOK 注册表项

1. 配置 HYOK 的 RMS 模板：

HYOK RMS 模板设置

1. 定义一些示例权限和你之前创建的组来测试其功能：

执行人员组的分配

1. 完成配置后，打开 PowerShell 以收集相关信息，这样你就可以配置 Azure 信息保护标签。

2. 运行以下命令以获取 RMS 模板 GUID：

Import-Module AdRmsAdmin
New-PSDrive -Name AdrmsCluster -PSProvider AdRmsAdmin -Root https://localhost
Get-ChildItem -Path AdRmsCluster:\RightsPolicyTemplate

1. 登录到 portal.azure.com 配置新的子标签以测试 HYOK 配置——在“高度机密”下添加一个新的子标签：

AIP 全局策略概览

1. 配置标签如下：

配置 HYOK 标签

1. 为全局策略启用新的子标签，测试用户将能够选择该标签：

将标签添加到全局策略

1. 从 第十三章 识别和检测敏感数据 中打开一台启用了 Azure 信息保护的内部域加入测试客户端。

2. 创建一个新文档并选择 HYOK 标签。保存文档后，首次使用新标签时，你应该会看到以下消息：

本地 RMS 模板的首次使用消息

1. 文档应使用 HYOK RMS 模板权限进行保护：

HYOK 受保护文档

你已成功在测试环境中实施 HYOK 部署。现在，我们已经全面走完了所有三种部署方法的流程，接下来我们将更详细地查看 Azure RMS 的功能。

Azure RMS 背后的工作原理

了解 RMS 的工作原理非常重要，它提供了完整的 Azure 信息保护解决方案的数据保护服务。首先，受保护的数据永远不会被传输到 Azure 信息保护或权限管理服务本身。基本上，数据在应用程序级别被加密，并包括一个定义谁有权限以及为这些用户应用哪些使用权限的策略。请记住，组成员资格会缓存三小时。因此，如果你更改了权限，请记得这一点，以免产生误解的结果。为了更好地理解三种典型的流程，让我们在本节中深入探讨这些流程。但首先，我们将看看 Azure RMS 使用的算法和密钥长度。

算法和密钥长度

Azure RMS 在不同的使用场景中使用以下加密控制。以下表格为你提供了在项目或研讨会上可能被问到的必要信息：

加密控制	Azure RMS 使用情况

| 算法：AES 密钥长度：128/256 位 | 文档保护使用者：

• Azure 信息保护客户端

• 权限管理共享应用程序

|

| 算法: RSA 密钥长度: 2,048 位 / 1,024 位 | 密钥保护

• 从 AD RMS 加密模式 1 迁移

• 使用 AD RMS 和 Exchange Online 的迁移

• 迁移前的归档密钥（本地）

• BYOK 支持 1024/2048 位 - 推荐: 2,048 位

|

SHA-256	证书签名

现在我们已经对加密控制有了清晰的了解，可以进一步探讨第一次使用流程，或用户环境初始化。

用户环境初始化流程

用户环境初始化也称为引导过程。该过程从安装 Azure 信息保护客户端并且用户打开 Office 应用程序（例如）时开始。如果用户访问受保护内容或保护新创建的文档时，它将会运行。

请记住，如果用户换到另一台机器，或者另一位用户使用同一台机器，过程总是会在首次使用时运行。

在此过程中，后台发生了许多事情，如果用户在联合环境中通过单点登录提供认证，他们并不会识别出整体步骤。成功认证到 RMS 服务后，三张主要证书将会被接收：

• 安全处理器证书（SPC）

• 客户端许可证书（CLC）

• 权限账户证书 (RAC)，前身为组身份证书（GIC）

这些证书有效期为 31 天，并验证用户到 Azure Active Directory。

同时，组织的权限管理模板也将被接收。

以下图表展示了此过程中的主要组件：

启动过程中的主要组件和参与者

在此过程中还会发生许多其他事情。如果你需要更多关于引导过程的详细信息，可以参考 bit.ly/2FbcxNt 和 bit.ly/2RxtcRR。

以下是一些其他有用的资源：

• AIP 客户端管理员指南: bit.ly/2Txpoxr

• *AD RMS 到 Azure 信息保护的演变 第六部分，作者：Matt Felton: bit.ly/2AwGR1Q

• 记录和分析使用情况：bit.ly/2RdJ3Wf

接下来，我们将探讨内容保护流程。

内容保护流程

接下来是内容保护流程，即当用户保护文档或电子邮件时发生的情况。RMS 客户端创建一个随机内容密钥，并使用 AES 对称加密算法对文档进行加密。流程在以下图中完整展示。我们仅强调几点：

• 识别用户或组的主要属性是 ProxyAddresses 属性；始终保留旧的电子邮件地址，以便能够使用较旧的受保护内容

• 如果 ProxyAddresses 为空，则会使用 UserPrincipalName。

• RMS 客户端使用组织的密钥来加密策略和内容密钥

• RMS 客户端使用用户证书签署策略

• 保护级别始终与内容一起存在

在下图中，你可以看到内容保护流程：

内容保护流程

接下来，我们将深入探讨内容消费流程。

内容消费流程

当用户尝试打开一个 RMS 保护的文档或电子邮件时，就会发生内容消费。这个过程始终从请求访问 Azure 权限管理服务开始。让我们重点突出几个关键点：

• 认证用户将文档策略和用户的证书发送到 Azure 权限管理服务

• 策略将由服务解密并评估

• 服务通过 ProxyAddresses 或 UserPrincipalName 属性为每个用户身份构建权限

• 内容密钥从解密后的策略中提取；密钥将使用用户的公钥进行加密

• 加密的使用许可证包含重新加密的内容密钥

• RMS 客户端使用自己的私钥解密加密的使用许可证

• RMS 客户端解密文档正文，应用程序将执行权限列表

以下视图展示了内容消费流程：

内容消费流程

通过这个流程，我们已经完成了 Azure RMS 流程的讲解。做得好！

总结

在本章中，你已获得了所有必要的信息，将你的需求映射到正确的密钥部署模型。我们探讨了使用 HYOK 的优缺点。通过提供的配置示例，我们积累了实践经验，现可以在你的下一个项目或研讨会中分享或使用这些经验。我们了解了主要的 Azure RMS 流程，这有助于理解 Azure RMS 如何在后台工作。你可以利用这些知识支持部署或排查常见问题，因为许多错误发生在环境初始化（引导）过程或部署过程中。

在下一章，我们将完成示例 Azure 信息保护解决方案的配置，之后你就可以为这项技术的应用之旅做好充分准备。

第十五章：配置 Azure 信息保护解决方案

在学习了理论知识、敏感信息的检测与识别后，我们将通过一些项目中的实用技巧帮助您更好地理解技术及相关流程。始终尝试在没有保护措施的情况下开始项目，并进行分类，以避免数据丢失和不良的项目营销，因为当用户无法访问他们常用的信息时，业务流程将无法顺利运作。此外，始终将培训对准最终用户。本章将扩展您的实验环境，并为您提供重要的 PowerShell cmdlet，以便管理您的解决方案。最后，我们将通过一些实际示例配置Azure 信息保护（AIP）。

本章分为以下几个部分：

• 准备配置和管理 AIP

• 使用 PowerShell 管理 Azure RMS

• 配置 AIP

好的！让我们从准备任务开始。

准备配置和管理 AIP

要配置和管理我们的 AIP 解决方案，我们需要准备好具有必要工具的 Windows 10 管理工作站。我们需要在工作站上安装以下 PowerShell 模块：

• Azure AD 预览版: Install-Module -Name AzureADPreview

• Azure RMS: Install-Module -Name AADRM

此外，我们从以下来源安装 AIP 客户端到机器上：bit.ly/2ccqSu0。

对于我们的用例和实验室挑战，我们需要创建所需的邮件启用组。我们选择使用 Office 365 动态组。您可以使用以下 PowerShell cmdlet 创建所需的组。

第一组组是必需的，第二组是可选的：

# Connect to Azure AD and provide global administrator credentials
Connect-AzureAD New-AzureADMSGroup -Description "Finance and Accounting Department Users" -DisplayName "Finance and Accounting" -MailEnabled $true -SecurityEnabled $true -MailNickname "financeandaccounting" -GroupTypes "DynamicMembership","Unified" -MembershipRule "(user.department -contains ""Accounting"")" -MembershipRuleProcessingState "On" New-AzureADMSGroup -Description "Sales Department Users" -DisplayName "Sales" -MailEnabled $true -SecurityEnabled $true -MailNickname "sales" -GroupTypes "DynamicMembership","Unified" -MembershipRule "(user.department -eq ""Sales"") -or (user.department -eq ""Sales Engagement Management"")" -MembershipRuleProcessingState "On" 
New-AzureADMSGroup -Description "Project Management Department Users" -DisplayName "Project Management" -MailEnabled $true -SecurityEnabled $true -MailNickname "projectmanagement" -GroupTypes "DynamicMembership","Unified" -MembershipRule "(user.department -contains ""Project Management"")" -MembershipRuleProcessingState "On" New-AzureADMSGroup -Description "Senior Management Department Users" -DisplayName "Senior Management" -MailEnabled $true -SecurityEnabled $true -MailNickname "seniormanagement" -GroupTypes "DynamicMembership","Unified" -MembershipRule "(user.department -contains ""Senior Management"")" -MembershipRuleProcessingState "On"

New-AzureADMSGroup -Description "Sales Department Users" -DisplayName "Sales" -MailEnabled $true -SecurityEnabled $true -MailNickname "sales" -GroupTypes "DynamicMembership","Unified" -MembershipRule "(user.department -eq ""Sales"") -or (user.department -eq ""Sales Engagement Management"")" -MembershipRuleProcessingState "On" New-AzureADMSGroup -Description "Strategy Consulting Department Users" -DisplayName "Strategy Consulting" -MailEnabled $true -SecurityEnabled $true -MailNickname "strategyconsulting" -GroupTypes "DynamicMembership","Unified" -MembershipRule "(user.department -contains ""Strategy Consulting"")" -MembershipRuleProcessingState "On" New-AzureADMSGroup -Description "Human Resources Department Users" -DisplayName "Human Resources" -MailEnabled $true -SecurityEnabled $true -MailNickname "humanresources" -GroupTypes "DynamicMembership","Unified" -MembershipRule "(user.department -contains ""Human Resources"")" -MembershipRuleProcessingState "On"

New-AzureADMSGroup -Description "Executives Department Users" -DisplayName "Executives" -MailEnabled $true -SecurityEnabled $true -MailNickname "executives" -GroupTypes "DynamicMembership","Unified" -MembershipRule "(user.department -contains ""Executive"")" -MembershipRuleProcessingState "On"

以下一组组是可选的：

New-AzureADMSGroup -Description "Project Management Department Users" -DisplayName "Project Management" -MailEnabled $true -SecurityEnabled $true -MailNickname "projectmanagement" -GroupTypes "DynamicMembership","Unified" -MembershipRule "(user.department -contains ""Project Management"")" -MembershipRuleProcessingState "On" 
New-AzureADMSGroup -Description "Operations Department Users" -DisplayName "Operations" -MailEnabled $true -SecurityEnabled $true -MailNickname "operations" -GroupTypes "DynamicMembership","Unified" -MembershipRule "(user.department -eq ""Operations"") -or (user.department -eq ""Engineering Operations"")" -MembershipRuleProcessingState "On"

New-AzureADMSGroup -Description "Marketing Department Users" -DisplayName "Marketing" -MailEnabled $true -SecurityEnabled $true -MailNickname "marketing" -GroupTypes "DynamicMembership","Unified" -MembershipRule "(user.department -contains ""Marketing"")" -MembershipRuleProcessingState "On"

New-AzureADMSGroup -Description "Engineering Department Users" -DisplayName "Engineering" -MailEnabled $true -SecurityEnabled $true -MailNickname "engineering" -GroupTypes "DynamicMembership","Unified" -MembershipRule "(user.department -contains ""Engineering"")" -MembershipRuleProcessingState "On" 
New-AzureADMSGroup -Description "Contractors" -DisplayName "Contractor" -MailEnabled $true -SecurityEnabled $true -MailNickname "contractor" -GroupTypes "DynamicMembership","Unified" -MembershipRule "(user.department -contains ""1099 Contractor"")" -MembershipRuleProcessingState "On" 
New-AzureADMSGroup -Description "Content Management Consulting Department Users" -DisplayName "Content Management Consulting" -MailEnabled $true -SecurityEnabled $true -MailNickname "contentmanagementconsulting" -GroupTypes "DynamicMembership","Unified" -MembershipRule "(user.department -eq "" Content Management Consulting"")" -MembershipRuleProcessingState "On" 
New-AzureADMSGroup -Description "Customer Relationship Management Department Users" -DisplayName "Customer Relationship Management" -MailEnabled $true -SecurityEnabled $true -MailNickname "customerrelationshipmanagement" -GroupTypes "DynamicMembership","Unified" -MembershipRule "(user.department -contains ""Customer Relationship Management"")" -MembershipRuleProcessingState "On"

此外，我们需要设置 Office 365 组的正确邮件后缀。您可以使用以下命令来设置地址：

# Set your preferred PowerShell execution policy
Set-ExecutionPolicy Unrestricted
# Provide global administrator rights
$UserCredential = Get-Credential
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $UserCredential -Authentication Basic -AllowRedirection
Import-PSSession $Session
# Set the correct suffix
set-UnifiedGroup -Identity Sales -PrimarySmtpAddress "sales@inovitdemos.ch"
set-UnifiedGroup -Identity Marketing -PrimarySmtpAddress "marketing@inovitdemos.ch"
set-UnifiedGroup -Identity "Strategy Consulting" -PrimarySmtpAddress "strategyconsulting@inovitdemos.ch"
set-UnifiedGroup -Identity "Project Management" -PrimarySmtpAddress "projectmanagement@inovitdemos.ch"
set-UnifiedGroup -Identity Operations -PrimarySmtpAddress "operations@inovitdemos.ch"
set-UnifiedGroup -Identity "Human Resources" -PrimarySmtpAddress "humanresources@inovitdemos.ch"
set-UnifiedGroup -Identity Executives -PrimarySmtpAddress "executives@inovitdemos.ch"
set-UnifiedGroup -Identity Engineering -PrimarySmtpAddress "engineering@inovitdemos.ch"
set-UnifiedGroup -Identity Contractor -PrimarySmtpAddress "contractor@inovitdemos.ch"
set-UnifiedGroup -Identity "Finance and Accounting" -PrimarySmtpAddress "financeandaccounting@inovitdemos.ch"
set-UnifiedGroup -Identity "Customer Relationship Management" -PrimarySmtpAddress "customerrelationshipmanagement@inovitdemos.ch"
set-UnifiedGroup -Identity "Content Management Consulting" -PrimarySmtpAddress "contentmanagementconsulting@inovitdemos.ch"
set-UnifiedGroup -Identity "Senior Management" -PrimarySmtpAddress "seniormanagement@inovitdemos.ch"

请注意，这是一个完全配备 Microsoft 365 E5 许可证的用户列表：

我们已准备好工作站并创建了相关的用例资源。接下来，我们将讨论用于配置和管理 Azure RMS 服务的最重要的 PowerShell cmdlet。

使用 PowerShell 管理 Azure RMS

在接下来的部分中，我们将讨论并使用最重要的 PowerShell 命令来配置和管理 Azure RMS。您将获得对功能的全面了解，并学习如何开始配置。

Azure RMS 超级用户

我们将从连接 Azure RMS 服务和管理超级用户功能开始。此功能默认是禁用的。要使用此功能，我们需要启用该功能并为其分配一个邮件启用的组。我们强烈建议将 AIP 扫描器帐户永久添加到该组，并根据需要添加其他所需用户。无论何时将用户添加到组中，都不影响解密过去的信息。

Azure RMS 超级用户功能在 Azure RMS 中提供以下功能：

• 对所有由权限管理管理的受保护内容拥有完全控制权

• 对所有由订阅者组织发放的用户许可证，超级用户拥有完全的所有者权限

• 解密任何受权限保护的内容文件，并将其从之前在该组织内保护的内容中移除保护

超级用户功能的典型用例包括：

• 阅读离职员工的受保护信息

• 替换当前分配的保护策略

• 在 Exchange Online 中使用搜索操作（eDiscovery）

• 支持需要检查受保护信息的安全解决方案

按照以下步骤，你可以配置超级用户功能：

1. 使用全局管理员权限连接到 Azure RMS 服务，如下所示：

Connect-AadrmService

1. 获取所有超级用户命令，如下所示：

Get-Command "*SuperUser*"

1. 检查超级用户功能，如下所示：

Get-AadrmSuperUserFeature

1. 启用超级用户功能，如下所示：

Enable-AadrmSuperUserFeature

1. 获取所有超级用户，如下所示：

Get-AadrmSuperUser
Get-AadrmSuperUserGroup

1. 接下来，我们将在 Exchange Online 管理中心创建一个启用邮件功能的安全组。

2. 导航到“收件人”|“组”，并创建一个新的启用邮件功能的安全组，如下所示：

创建启用邮件功能的安全组

1. 在我们创建该组后，我们还将使用访问审查每季度审查该组的成员资格，因为该组权限非常强大，不应充满旧用户。

2. 打开 Azure 门户 portal.azure.com 并导航到 Azure AD 切片。

3. 选择“组织关系”|“访问审查”。

4. 点击“入驻”并为实际的 Azure AD 创建。

5. 使用默认程序并在“管理”|“控制”下进行设置。

6. 点击“新建访问审查”，如下所示：

创建访问审查

1. 选择以下设置进行审查，并将你的个人测试帐户指定为审查员：

访问审查属性

1. 接下来，我们将分配该组作为超级用户组。设置一个超级用户组，如下所示：

Set-AadrmSuperUserGroup -GroupEmailAddress "azurermssuperusers@inovitdemos.ch"

现在，如果组织开始加密信息，我们是安全的。所有受保护的内容都可以被超级用户组中的用户解保护并恢复。

为了管理 Azure RMS 服务，我们可以通过以下 cmdlet 委派管理员权限：

Get-AadrmRoleBasedAdministrator
Add-AadrmRoleBasedAdministrator

如果你使用一个组进行此委派，该组不需要启用邮件功能。

另一方面，你应该在 Azure AD 特权身份管理 (PIM) 切片中分配 AIP 管理权限，如下所示：

信息保护管理员 - Azure AD 中的描述

在下一部分，我们将讨论入驻控制。

入驻控制

推荐在组织中计划性地推出 AIP，包括 RMS 保护功能。为此，微软实现了入职控制功能。你可以使用以下命令检查默认配置：

Get-AadrmOnboardingControlPolicy 

在你通过以下命令建立与 Azure RMS 服务的连接后，打开一个提升权限的 PowerShell：

Connect-AadrmService

该功能默认情况下是禁用的。

要启用入职控制，你可以使用以下命令：

Set-AadrmOnboardingControlPolicy

通过入职控制，你可以启用基于组的推出。确保用户和关联的计算机已经准备好使用 AIP。你可以使用以下资源来准备你的用户：bit.ly/2CvBfF7。

Azure RMS 模板

Azure RMS 模板主要用于 AIP 中的标签。如果一个组织没有使用 AIP 进行分类和标记信息，他们仍然可以使用基本的 Azure RMS 服务来保护内容。Azure RMS 模板可以通过 AIP 刀片下的标签或通过 PowerShell 创建。实际的 Azure RMS 使用权限文档可以在bit.ly/2HkDK2F查看。要管理 Azure RMS 模板，我们可以使用以下程序：

1. 获取所有模板命令，如下所示：

Get-Command -Module AADRM Template

1. 获取所有模板，如下所示：

Get-AadrmTemplate

上述命令的输出如下所示：

获取所有实际的 RMS 模板

1. 删除模板，如下所示：

Remove-AadrmTemplate -TemplateId "template ID"

1. 创建一个新模板，如下所示：

$names = @{}
 $names[1033] = "Template Name"
 $descriptions = @{}
 $descriptions[1033] = "Template description"
 $r1 = New-AadrmRightsDefinition -DomainName "yourdomain1.com" -Rights "VIEW","EXPORT"
 $r2 = New-AadrmRightsDefinition -EmailAddress "Email address of group or user" -Rights "OWNER"
 Add-AadrmTemplate -Names $names -Descriptions $Descriptions -LicenseValidityDuration 7 -RightsDefinitions $r1, $r2 -Status Published

在下一部分，我们将提供一些关于 Azure RMS 日志功能的重要信息。

Azure RMS 日志

在本节中，我们将验证默认启用的 Azure RMS 日志功能。请执行以下步骤来分析 Azure RMS 服务的使用情况：

1. 获取实际的 Azure RMS 配置，如下所示：

Get-AadrmConfiguration

1. 获取所有日志命令，如下所示：

Get-Command "*Log*" -Module AADRM

创建 AIP 日志目录并设置变量，如下所示：

New-Item -ItemType directory -Path C:\AIPLogs\User
New-Item -ItemType directory -Path C:\AIPLogs\Admin
$UserLogs = "C:\AIPLogs\User"
$AdminLogs = "C:\AIPLogs\Admin"

1. 获取用户日志，如下所示：

Get-AadrmUserLog -Path $UserLogs -FromDate (Get-Date).AddDays(-45)

1. 获取管理员日志，如下所示：

Get-AadrmAdminLog -Path $AdminLogs\admin.log

1. 获取文档追踪功能的状态，如下所示：

Get-AadrmDocumentTrackingFeature

下一部分将向你介绍 AIP PowerShell 功能。

AIP 客户端 PowerShell

安装了 AIP 客户端后，你可以收集关于配置的信息，并执行分类和保护活动。你可以使用 AIP cmdlets 的以下命令：

Get-Command -Module AzureInformationProtection

使用以下 cmdlet，你可以获取客户端上实际可用的 RMS 模板：

Get-RMSTemplate

你可以使用以下 cmdlet 获取文件的实际状态：

Get-AIPFileStatus .\Q3_Product_Strategy.docx 

AIP 文件状态信息

你可以使用以下 cmdlet 设置标签：

Set-AIPFileLabel -LabelId de82bccd-c50f-4162-b113-8aa9e98ed45f -Path .\Testfile.docx

在这个管理介绍部分之后，我们将继续介绍不同的用例，以配置和使用 AIP。

配置 AIP

配置和管理 AIP 应该始终从全球用户的整体方法开始。在开始接触技术之前，最重要的任务是制定清晰的分类架构和相关政策。在分类和信息项目中，配置只是最小的一部分。你应该根据分类架构考虑默认标签，并且一开始不要使用加密和大量自动分类规则。从理解并使用新技术的全球用户开始。请记住使用逐步推进的方法，并从最敏感的部门（如人力资源、法律或财务）开始，逐步解决具体要求。不要让用户感到不堪重负，也不要让他们违背你的概念和分类系统。

以下是一些数据分类的额外提示：

• 获得管理层和将使用该系统的员工的支持

• 对所有内容进行标签化和分类几乎是不可能的

• 使用有效的元数据策略

• 使用数据清理技术来去除冗余或过时的数据

• 提供可用性

• 考虑要分类的数据的机密性和安全性

微软已对应用于数据的分类标签进行了深入的研究和可用性测试。尽量从 AIP 的默认标签开始，例如：

AIP 默认标签集

你还可以自定义 AIP 中的每个标签，以满足你的需求。

创建分类架构

配置 AIP 解决方案的第一步是从创建分类架构开始。让我们按照以下步骤为我们的演示组织创建分类架构：

1. 打开 AIP 控制面板，网址为 portal.azure.com。

来自 第十四章， 理解加密密钥管理策略，我们启用了 HYOK 标签。现在我们将移除此标签，因为我们不想将本地部分包括在我们的解决方案中。

1. 默认架构应如下所示：

AIP 的默认分类/标签架构

一个好的起点是，你可以开始为你的信息添加默认标签，并禁用“机密”和“高度机密”标签的加密功能。

1. 你可以在“策略 | 全局”下找到该配置。

2. 使用“General”作为默认标签，并确保所有信息对于全球用户都需要分类，例如：

默认标签激活和其他全局设置

我们强烈建议你为用户提供更多有关数据分类的信息来源。在我们的项目中，我们使用一个用户经常访问的网站作为额外的信息来源。

1. 将启用保护的标签设置为“未配置”，如下所示：

禁用保护选项

1. 在其中一台测试客户端上测试结果，用户名为 Don Hall。

2. 新文档或电子邮件会自动分类为一般，具体如下：

默认标签结果

通常标签下的业务数据不打算供公众使用，但可以根据需要与外部合作伙伴共享。例如，包括公司内部电话目录、组织结构图、内部标准以及大多数内部通信。

创建子标签和作用域策略

现在我们已经为用户提供了第一组配置，我们可以开始为我们的敏感部门提供基本配置。我们可以通过作用域策略来仅向特定部门用户提供更改。作用域策略需要 AIP P2 许可证。

通过以下步骤，我们将创建所需的子标签：

1. 在分类 | 标签下。在机密标签下创建一个新的子标签，具体如下：

添加子标签

• • 名称：财务和会计

  • 描述：财务和会计 敏感数据，不打算在部门外部使用。

  • 添加以下条件：信用卡号码和 国际银行账户名称（IBAN）。

  • 保持推荐应用标签。

1. 接下来，我们将为财务和会计部门配置自定义策略。

2. 在分类 | 策略下，为 财务和会计 创建一个策略。

3. 将 财务和会计 组分配给策略。

4. 点击添加或删除标签。

5. 添加财务和会计标签。

AIP 目前仅限于提供一个子级标签。

1. 保留其他设置为默认设置，具体如下：

为财务和会计用户设置作用域

1. 以 Karim Manar 身份登录第二个测试客户端上的财务和会计组，并打开 Word。

2. 您应该会看到如下的新标签：

财务和会计标签结果

所有其他用户将收到默认标签设置。

1. 我们已启用的下一个功能是，如果特定条件匹配，将自动推荐标签。

2. 以 Karim Manar 身份登录。

3. 打开 Word 并创建包含内容 我的 AMEX 卡号是 344047014854133 的文档。

4. 保存文档后，标签推荐将显示如下：

AIP 标签推荐功能示例

记住，我们从不加密信息开始，以便教会用户并避免影响最终用户体验和加密信息的使用。我们还希望收集更多关于规则的信息，以便在开始自动加密之前拥有明确的标识符。

使用此选项，你还可以为每个策略定义特定的默认标签。这是一个非常有用的功能，能够支持特定部门用户的可用性，因为财务和会计部门大多处理机密内容。定义默认标签，如下所示：

在自定义策略中限定默认标签

为以下部门创建更多子标签，以便了解如何设计你的标签。在实际项目中，测试并监控标签的使用，并保持最低限度，例如：

• 战略咨询

• 高级管理

• 人力资源

• 高层管理人员

如果你使用多个策略，最后一个策略在冲突设置中胜出。

下一张截图显示了分类架构：

修改后的分类架构

你可以为其他部门的敏感项目使用相同的策略。始终思考、讨论新的标签的实际需求，并将其分配给相关用户组。明确使用目的并正确处理，对于用户提供成功的解决方案至关重要。

使用视觉标记

接下来的选项是标记选项，使得分类在邮件或文档的内容中也能作为页眉、页脚或水印可见。默认情况下，标记选项应用于机密和高度机密标签下。

在本节的下一步中，我们将达到并查看以下结果：

• 查看机密标签的默认行为

• 以 Don Hall 的身份打开 Word，并应用“机密 | 所有员工”标签

• 你会注意到页脚包含“分类为机密”

如果你使用已经包含页眉/页脚部分的模板，你需要测试这些模板，以确保分类不会导致模板设计崩溃。默认情况下，不会应用水印。

使用以下来源自定义视觉标记：bit.ly/2Cu8BnU。

一个典型的例子可以是Classified as ${Item.Label} from ${User.Name} at ${Event.DateTime}。

如果你使用新的自动保存选项，我们建议在高级设置中启用连续分类功能，使用以下字符串：NAME: RunPolicyInBackground，VALUE: True，例如：

AIP 策略高级设置

你将在此区域找到其他功能，如下所示：

在策略中配置的高级设置

接下来，我们将探索自动分类功能。

配置自动分类和保护

AIP 还提供自动分类功能。此功能需要Azure 信息保护 P2许可。此功能包含在EMS E5和Microsoft 365 E5计划中。

从清晰的规则和标识符开始自动分类。例如，如果公司在文档中使用某个标识符，如“公开消费批准”，你可以像我们在以下步骤中所做的那样构建一个简单的条件：

1. 编辑“高度机密 | 所有员工”标签并添加以下条件：

自动分类的关键词定义

1. 将“选择此标签的应用方式：自动或推荐给用户”更改为“自动”，如下所示：

激活自动分类

1. 与 Don Hall 一起测试配置。

2. 创建一个新的 Word 文档，并在文档中输入 My password is Pass@word1。

3. 该文档将自动分类为“高度机密 | 所有员工”。

我们还可以通过以下步骤使用云应用安全自动分类并保护内容：

1. 以全局管理员身份打开portal.cloudappsecurity.com。

2. 在“开始”部分点击“创建策略”。

3. 使用以下模板进行我们的示例（确保将一些个人身份信息（PII）文件从代码包上传到你的测试用户 OneDrive）：

云应用安全个人身份信息（PII）扫描结果

1. 在新策略中使用以下设置：

在 Cloud App Security 中创建策略以捕获 PII 信息

1. 选择 Microsoft OneDrive for Business，并选择“机密-所有员工”标签，如下所示：

云应用安全自动分类选项

1. 你会注意到，如果点击其他应用，如 Dropbox 或 Salesforce，选项不可用。

2. 接下来，返回到仪表板，你将收到与我们刚创建的文件策略匹配的警报，如下所示：

扫描后的规则结果

1. 点击 OneDrive 警报并查看结果；该文件包含 PII 信息并已分类：

自动分类的文档

在 Office 365 中找到另一种自动分类和保护敏感信息的选项，按以下步骤操作：

1. 访问 Office 365 门户 portal.office.com 并以全局管理员身份登录。

2. 你将看到以下“保护敏感信息的推荐”。这是因为系统已经检测到你从代码包上传到 OneDrive 的一些文件：

Office 365 中的 DLP 选项

1. 点击“查看推荐”，系统将为你提供以下选项，以创建一个保护信息的策略：

扫描敏感信息，例如信用卡详细信息

1. 点击消息底部的“创建政策”。

2. 你将在 bit.ly/2FMYBJS中找到新创建的政策，它将被称为 默认数据丢失保护策略：

使用规则的政策创建向导

1. 编辑政策并查看设置，如下所示：

政策总结

1. 编辑位置下的规则；移除 SharePoint 网站和 OneDrive 账户：

政策的位置定义

1. 编辑操作下的规则；选择加密邮件：

如果检测到敏感内容，则启用加密

1. 让我们与 Don Hall 一起在我们的一个测试客户端上测试此政策。

2. 打开 Outlook，并向 Ye Xu 和你的私人邮件账户发送以下内容的邮件。

3. 你可以在以下源创建信用卡号码（bit.ly/2KeZHR1）：

   • 卡片类型: MasterCard

   • 卡号: 5131493203693245

   • 到期日期: 06/2027

   • CVV: 225

以下截图显示了带有敏感内容的邮件：

测试带有敏感内容的邮件

1. 打开你的私人邮件账户：

预期结果为私人邮件账户

1. 点击阅读邮件：

阅读加密邮件的对话框

1. 你将获得两种访问受保护内容的选项：

登录或一次性密码认证选项

1. 选择一次性密码选项查看密码行为。

2. 你将收到一封带有密码的邮件：

收到验证代码

1. 输入密码并点击继续：

代码验证

1. 然后你可以阅读邮件：

纯文本消息

在处理完一些自动选项后，我们将开始使用说明选项。

使用说明

说明功能是一个很好的选择，可以更改推荐标签或修改现有标签，以应对修改文档的敏感性。你可以在政策设置中启用此功能：

启用说明

为了测试功能，打开一个文档并将其降级为个人标签：

提供说明

稍等片刻，你将能在活动日志中看到以下修改：

说明的日志信息

我们建议使用活动日志来提供你的分类生命周期信息。你尤其需要这些信息来改进你的自动规则。可能是你的条件已经不再有效或不够清晰，导致数据被推荐到错误的分类标签。

配置保护选项

一旦你的分类标签适当，并且用户已接受新方法的培训，我们可以增强保护选项，达到更高的保护状态。

对于电子邮件消息，我们可以使用该选项基于最高的附件分类来提高邮件的分类级别。我们强烈建议将其作为推荐选项，只有在你有明确的自动选项使用案例时才使用。通过以下步骤，你可以配置这个使用案例：

1. 你可以在策略配置中找到此选项：

推荐的分类选项

1. 以 Don Hall 身份登录到测试客户端，并创建两个 Word 文档，一个分类为公开，另一个分类为机密。

2. 接下来，创建一封带有两个附件的测试电子邮件，并将其发送给叶旭，如下所示：

实施中的推荐

以下两种选项适用于使用自定义保护：

Office 用户的附加保护功能

我们将在以下步骤中与 Don Hall 一起测试这些选项：

1. 以 Don Hall 身份登录并创建一个新的 Word 文档。

2. 点击保护图标并使用自定义权限：

自定义权限对话框

1. 将协作者权限分配给叶旭和一名外部用户，如下所示：

使用自定义权限选项，包括外部账户

1. 将邮件和文档附件发送给两个收件人。

2. 在外部用户的计算机上打开邮件和附件：

外部用户，受保护信息的查看

请注意，Azure RMS 保护内容的行为稍有不同，取决于收件人的配置和 RMS 启用情况。如果另一方也使用 Office 365，收件人应能无缝使用，无需登录提示。当用户没有使用任何 Microsoft 云服务且没有 Azure AD 时，收件人将自动处理，创建一个临时的 Azure AD 账户以使用 Azure RMS 功能。准备好你的外部收件人，并将其纳入你为内部用户进行的培训中：

如果你想管理所有 Azure RMS 保护内容，你应为此流程创建一个标签并隐藏按钮。

1. 使用 Outlook 中的“不要转发”按钮对邮件进行加密：

Outlook 中的“不要转发”按钮（其他 Office 产品中没有）

提供详细解释的 B2B 和 B2C 保护场景。

1. 您可以在标签内提供此功能。

2. 我们可以创建一个名为Partners的自定义标签，放在“机密”类别下，并将其分配到全局策略中，如下所示：

在标签中使用自定义保护选项

1. 使用自定义页脚，内容为“分类为合作伙伴机密”。

2. 以 Don Hall 身份登录测试客户端。

3. 创建一个 Word 文档并测试新功能，如下所示：

测试 Word 中的自定义权限选项

1. 在 Outlook 中创建一封新邮件并测试新功能，如下所示：

测试 Outlook 中的“禁止转发”按钮

请记住，在线 Office 组件无法使用受保护的信息。

实际上，微软支持许多不同的应用程序和文件格式进行分类和保护；您可以在以下截图中查看这些应用程序：

Azure RMS 支持的文档类型

微软还提供了一个通用解决方案，我们可以通过它来分类和保护敏感数据。以下步骤展示了该过程：

1. 以 Don Hall 身份登录并打开您的OneDrive文件夹，如下所示：

使用桌面分类选项

1. 右键点击Finance文件夹并选择“分类与保护”。

2. 使用“机密 | 所有员工”标签来基本分类文档，如下所示：

选择“所有员工”标签来对信息进行分类

1. 稍后，如果您已完成整个流程，您可以提供一个特定标签并保护信息。

2. 您将能够看到所有操作的报告：

特定标签报告

通过此选项，您可以基于自动规则或手动选择的标签对多个不同的文件进行分类和保护。

启用统一标签

随着微软构建完整信息保护解决方案的战略，Office 365 和 AIP 标签将合并在一起。通过此选项，您将能够与最重要的服务进行完全集成。

在接下来的步骤中，我们将激活统一标签功能：

1. 您可以通过使用全局管理员凭据打开bit.ly/2RHzZZZ来激活统一标签。

2. 点击“激活”按钮并发布您的标签，如下所示：

启用统一标签

1. 访问protection.office.com/，点击分类和标签，查看已迁移的标签。

接下来，我们将让您进行一个实验室挑战，以发现更多 AIP 功能。

实验室挑战

构建一个完整的分类架构，利用实际创建的组并测试所有不同的功能。尝试实施以下流程：

• 合作伙伴和客户流程

• 敏感项目内容管理

• 部门之间的内部协作流程

• 外部用户的电子邮件保护

• 保护你的 SharePoint/OneDrive 信息/数据共享

• 防止在其他平台（如 Dropbox 和 Salesforce）中的数据泄露

祝你好运！

总结

完成本章后，你将能够开始优化你在组织内部或客户中的信息保护解决方案。我们提供了一个起始实验环境，用于测试 AIP 所需的所有功能和流程。使用关键的 PowerShell 命令，你应该可以顺利启动并准备好开始配置任务。此外，我们还提供了典型配置任务的概述，并分享了我们在多个项目中获得的经验。

在本书的最后一章，我们将通过一个启用了 AIP 的示例应用程序，带给你更多关于 AIP 技术的深入了解。

第十六章：Azure 信息保护开发

本章是任何想深入了解 Azure 信息保护技术的人的良好起点，能够帮助您获取更多的故障排除信息或支持解决方案的信息。本章还将帮助您编写应用程序，帮助您的客户满足您组织的需求。使用 Azure 信息保护的开发资源将让您对这项技术有更深入的了解。

在本章中，我们将为您提供不同开发资源的概述，帮助您开始探索不同的 Azure 信息保护开发选项。我们将为您提供启动工具，准备开发环境，并提供一些示例，以便您开始分析这一出色的服务。您将获得有关 Microsoft 信息保护 SDK、PowerShell 使用以及其他可用 SDK 的信息，以帮助您开启您的开发之旅。

本章分为以下几个部分：

• Microsoft 信息保护解决方案

• 了解 Microsoft 信息保护 SDK

• 为测试准备您的 Azure AD 环境

• 使用 MIP 二进制文件探索功能

• 使用 PowerShell 与 Azure 信息保护

• RMS 2.1 和 4.2 SDK 概述

让我们来看看在我们的实验环境中开始开发所需的技术要求。

技术要求

在本章中，您可以使用已经安装 Visual Studio 2017 的 YD1APP01 服务器，详情请见 第七章，在 Azure AD 和 ADFS 上部署解决方案。此外，您需要从 bit.ly/298QzMn 安装 Information Protection SDK 2.1 以进行开发。同时，您还需要从 bit.ly/2CBVvoE、bit.ly/2RHCjjO 和 bit.ly/2HtYKEj 下载示例，放到您的 Visual Studio 项目目录中的服务器上，例如 C:\Users\cloudadmin.INOVITDEMOS\Documents\Visual Studio 2017\Projects>，以便您在框架中进行实验。

在下一节中，我们将深入探讨 Microsoft 信息保护解决方案，了解所有相关技术。

Microsoft 信息保护解决方案

Azure 信息保护本身旨在对 Office 365 和许多其他应用中的文件进行分类、标记和保护。以下列表展示了不同的解决方案组件及其与 Azure 信息保护的关系：

• Microsoft 云应用安全：通过直接集成 Azure 信息保护来保护云应用。

• 条件访问：控制对敏感信息的访问，无需直接集成到 Azure 信息保护中。

• SharePoint：提供 RMS 保护的库和组，以实现访问控制。

• Office 365 邮件加密：在组织内部或外部发送加密电子邮件，并与 Azure 信息保护直接集成。

• Office 365 数据丢失防护：旨在防止通过 Exchange 和 SharePoint Online 丢失数据，包括 OneDrive for Business，并与 Azure 信息保护直接集成。

• Office 365 高级数据治理：为敏感信息提供保留和删除策略，并与 Azure 信息保护直接集成。

• Azure 安全中心信息保护：为结构化数据分配分类，例如 Azure SQL 或 SQL 服务器，以及其他与 Azure 信息保护无直接集成的 Azure 仓库。

• Windows 信息保护：旨在将手机或 PC 上的私人和业务环境分开。

• Office 应用程序：用于通过间接集成到 Azure 信息保护中保护 Excel、PowerPoint、Word 和 Outlook 中的敏感信息。

• Adobe PDF：Azure 信息保护提供本机支持，以便为 Adobe PDF 添加标签并进行保护。

总体而言，Microsoft 提供了 Microsoft SDK，帮助开发人员为传统的本地基础设施、云平台和移动设备上的现代应用程序开发解决方案。让我们更深入地了解它。

了解 Microsoft 信息保护 SDK

Microsoft 信息保护 SDK 扩展了标签和保护功能，因此您可以在跨平台场景中提供一致的体验，并且它提供了全面的功能集。使用该 SDK，您可以将分类、标签和保护扩展到任何其他应用程序和服务。一般来说，Microsoft 信息保护解决方案与传统的 Active Directory RMS 基础设施兼容。您在使用持有自有密钥（HYOK）功能时已经体验过这一点。

Microsoft 信息保护 SDK 可在以下平台上使用：

• macOS、Linux 和 Windows

• Android、iOS 和其他平台的预览版

SDK 支持用户和服务应用程序，包括支持多租户。用户应用程序包括常见的创作工具，如 Office 和 Adobe。也支持为结构化数据加标签。服务应用程序大多在后台运行，如 DLP、云访问安全代理（CASBs）和电子发现功能。这些应用程序使用 OAuth 进行身份验证。

详细来说，API 提供以下功能：

API	功能	使用案例
保护

• 接受明文内容并返回发布许可

• 允许密文和发布许可

• 返回明文

• 如有需要，执行权限强制

|

• 对任何数据进行加密

• 不需要密钥交换管理

• 例如，需要检查数据传输中的安全软件

|

策略

• 计算策略应采取的操作

• 审计流程中事件的提交启用

• 如有需要，应用标签元数据

|

• 用于分类零件或组件的 CAD 和 CAM 应用程序

• 用于读取标签和监控服务或网络的 DLP 平台

|

文件

• 支持常见文件类型

• 允许读取、写入或删除标签

• 启用保护移除

• 应用程序提供的元数据

|

• Word、Excel、PowerPoint 或其他

• 需要标记文件的扫描仪

|

在下一节中，我们将提供一个来自 Microsoft 的示例应用程序MipSdk-FileApi-Cpp-Sample-Basic，并帮助您开始使用 SDK 并探索不同的功能。

准备您的 Azure AD 环境进行测试

在本节中，我们将调整 Azure AD 环境，以便运行来自 Microsoft 信息保护 SDK 的代码，针对我们的 Azure 信息保护基础设施。像往常一样，这从创建 Azure AD 应用程序开始：

1. 使用全局管理员凭据登录到 Azure 门户：portal.azure.com。

2. 导航到 Azure AD 页面。

3. 点击“应用程序注册”以创建一个新应用程序。

4. 点击“新建应用程序注册”。

5. 使用以下设置：

示例应用程序属性

1. 点击注册应用程序上的设置按钮：

应用程序设置选项

1. 点击 API 访问的“所需权限”部分。

2. 点击“添加”：

所需权限配置

1. 点击“选择一个 API”。如有需要，可以使用搜索字段查找 Microsoft 版权管理服务。

2. 选择 Microsoft 版权管理服务 API：

选择 Microsoft RMS API

1. 在“选择权限”部分，使用“为用户创建和访问受保护内容”的权限，属于“委托权限”选项。

2. 点击“选择”并完成：

权限范围

1. 点击“添加”按钮。

2. 点击“选择一个 API”选项以选择正确的 API。

3. 搜索 Microsoft 信息保护同步服务并选择该服务：

选择 Microsoft 信息保护同步服务 API

1. 在“选择权限”选项下，选择“读取用户可以访问的所有统一策略”。在“委托权限”下。

2. 点击“选择”然后按“完成”：

委托权限配置

1. 在所需权限页面，点击“授予权限”按钮并确认对话框：

权限授予程序

1. 复制main.cpp文件第57行中的应用程序 ID，并将您的测试用户信息添加到第64行，以配置应用程序：

示例应用程序的修改

现在我们已经准备好了 Azure AD 环境，您可以开始探索代码示例。

使用 Visual Studio 打开MipSdk-FileApi-Cpp-Sample-Basic.vcxproj文件，并按照以下步骤操作：

1. 将标签 ID 复制到剪贴板或记事本。

2. 将标签粘贴到输入提示中。

3. 应用程序会询问文件路径。输入您特定 Office 文档的路径。

4. 应用程序将显示当前应用标签的名称。

5. 在支持标签或保护功能的查看器中打开文件。

接下来，我们将探索 Microsoft 信息保护（MIP）二进制文件的功能，看看您可以在开发解决方案时纳入的广泛功能。

使用 MIP 二进制文件探索功能

使用来自 SDK 的 Microsoft 信息保护二进制文件，我们可以探索 Microsoft 统一信息保护解决方案的新功能。二进制文件提供了所有必要的示例，用于开始使用不同的功能，如获取文件的实际状态、对文件进行分类和保护以及批量解密文件。在接下来的部分中，我们将重点介绍提供所有基本功能的 file_example.exe 二进制文件。这个示例将为您开发自己的应用程序提供灵感，应用程序将使用 SDK 和信息保护功能。

我们下载了 MIP 二进制文件以探索功能。您可以使用以下步骤更深入地了解功能：

1. 打开 PowerShell 并导航到示例文件。

2. 执行.\file_sample.exe二进制文件以查看您可以测试的功能：

应用程序命令行选项

使用此二进制文件，您可以使用以下命令：

• 获取标签列表：

./file_sample --username jenny.green@leano.ch --password "YOURPASSWORD " --file "PATH" --listlabels

• 设置标签：

./file_sample --username jenny.green@leano.ch --password "YOURPASSWORD" --file "PATH" --setlabel <GUID>

• 读取标签：

./file_sample --username jenny.green@leano.ch --password "YOURPASSWORD" --file "PATH" --getfilestatus

在使用 MIP file_sample.exe 示例后，我们将向您介绍 PowerShell 的多种功能，帮助您管理和开发自己的解决方案。功能类似于二进制文件，但对于管理员或具有 PowerShell 经验的人来说，可能更容易理解。

使用 PowerShell 配合 Azure 信息保护

PowerShell 提供了管理 Azure 信息保护的功能。特别是，为了处理自定义分类和保护解决方案，您需要能够使用 PowerShell 来解决您的挑战，例如，在文件共享或单个计算机上标记和保护文件。通过以下 cmdlet，您可以获得执行大多数管理任务的基本工具集。我们通过示例使用这些 cmdlet 提供了单个文件夹的监控解决方案，并根据关键词标记和加密文件。通过以下命令，您可以开始探索更多有关 Azure 信息保护的功能和技术：

• Import-Module AzureInformationProtection

• Get-AIPFileStatus：用于识别所有具有特定标签的文件

• Set-AIPFileClassification: 用于检查文件内容并自动标记未标记的文件

• Set-AIPFileLabel：用于应用指定标签

• Set-AIPAuthentication：用于非交互方式标记文件（脚本/调度器）

接下来，我们将展示一些有用的 PowerShell cmdlet 来管理 Azure RMS。

有用的 Azure RMS cmdlet

在接下来的部分中，我们将提供用于管理 Azure RMS 的服务主体。以下命令用于创建一个新的服务主体：

$ServicePrincipalName="RMSPowerShell"
Connect-AadrmService
$bposTenantID=(Get-AadrmConfiguration).BPOSId
Disconnect-AadrmService
Connect-MsolService
New-MsolServicePrincipal -DisplayName $ServicePrincipalName

预期的输出如下：

新服务主体的创建结果

复制生成的对称密钥值：

$symmetricKey="<value from the display of the New-MsolServicePrincipal command>"
 $appPrincipalID=(Get-MsolServicePrincipal | Where { $_.DisplayName -eq $ServicePrincipalName }).AppPrincipalId
 Set-RMSServerAuthentication -Key $symmetricKey -AppPrincipalId $appPrincipalID -BposTenantId $bposTenantID

预期的输出如下：

关键信息

现在，你可以开始使用服务主体账户执行以下命令：

• 枚举所有 RMSTemplate：

Get-RMSTemplate

• 保护一个文件：

Protect-RMSFile -File C:\Test.docx -InPlace -TemplateId <yourtemplateid>

• 获取文件的状态：

Get-RMSFileStatus -File C:\Test1.docx

• 解除保护文件：

Unprotect-RMSFile C:\test.docx -InPlace

现在我们已经开始使用 PowerShell 来与 Azure 信息保护和 Azure 权限管理服务合作，我们将向你提供一些有用的信息，关于其他可用的 SDK，用于开发与这些服务的对接，提升你的知识。

RMS 2.1 和 4.2 SDK 概述

有两个活跃的 RMS SDK 版本可供开发者使用，用于以下开发：

• Microsoft Rights Management SDK 4.2 for Android, iOS/macOS, Windows 设备和 Linux

• Microsoft Rights Management SDK 2.1 for Windows Desktop Client

• AD RMS SDK 已被取代

4.2 版本中包括了以下改进：

• 混合支持 AD RMS 和 Azure RMS（需要 AD RMS 的移动设备扩展才能在移动设备上使用 AD RMS，并提供所需的认证方法）

• 离线访问受保护的内容

• 带上你的认证库

• 带上你的用户界面

• 重新设计的 API

你可以使用以下示例设计来开发你的应用程序：

带有功能规格的应用程序设计示例

上面的示例演示了用户如何加密文档。为此任务，他需要选择一个 Azure RMS 模板，或者使用 Azure RMS AdHoc-Protection。为了从 Azure 信息保护获取模板信息，用户需要进行身份验证。在成功认证后，用户可以请求模板和服务并返回它们。如果之前的所有步骤成功，所需的模板可以应用，并且文档将被加密。此外，设计和开发中必须包括解密文档的功能，以存储未加密的敏感信息。加密和解密功能对于完整解决方案非常重要。

如果我们查看你在本章开头下载的 Azure IP 测试应用程序，在技术要求部分，你可以借助这个示例开始构建这样的应用程序，因为它提供了 SDK 的许多主要功能。

否则，微软提供了其他示例，帮助你开始收集更多知识。一个完美的起步方式是通过与文本文件的简单交互，你可以使用 IpcNoteapp 应用程序来实现。这个应用程序展示了如何保护一个简单的文本文件。我的首选方式是直接从一个具体的用例入手，例如保护 Azure Blob 存储中的数据。如果你和我一样，开始使用 IpcAzureApp，因为它会自动引导你使用 IpcManagedAPI，为你提供许多帮助类。否则，如果你想深入了解 DLP 功能，可以使用 IpcDlpApp，它通过文件 API 与数据交互，进行保护或解保护。你可以监控文件系统中的目录，并使用 RMSFileWatcher 应用保护策略。如果你还想在简单的 PowerShell 脚本中看到此类功能，你可以使用以下示例：

1. 设置你要监控的文件夹，包括子文件夹：

$watcher = New-Object System.IO.FileSystemWatcher
 $w.Path = "C:\Users\jochen.nickel\Desktop\Monitored"
 $w.Filter = "*.*"
 $w.IncludeSubdirectories = $true
 $w.EnableRaisingEvents = $true

1. 定义在检测到事件时的操作：

$action = { 
 $fname = $Event.SourceEventArgs.Name
 if ($fname -like "*.tmp" -or $fname -like "*~$*"){}
 else {
 $path = $Event.SourceEventArgs.FullPath

 $changeType = $Event.SourceEventArgs.ChangeType
 $logline = "$(Get-Date), $changeType, $path"
 #write-host $logline
 Add-content "C:\Users\jochen.nickel\Desktop\log.txt" -value $logline
 }
 }
$action1 = { 
 $fname = $Event.SourceEventArgs.Name
 if ($fname -like "*.tmp" -or $fname -like "*~$*" -or $fname -like "*.TMP" ){}
 else {
 $path = $Event.SourceEventArgs.FullPath

 $changeType = $Event.SourceEventArgs.ChangeType
 $logline = "$(Get-Date), $changeType, $path"
 write-host $logline
 Add-content "C:\Users\jochen.nickel\Desktop\log.txt" -value $logline
 Set-AIPFileLabel $path -LabelId '6523069d-6f4a-4486-8dc3-71de23457c71'
 $logline = "$(Get-Date), APPLIED: Set-AIPFileLabel $path -LabelId '6523069d-6f4a-4486-8dc3-71de23457c71'"
 write-host $logline
 Add-content "C:\Users\jochen.nickel\Desktop\log.txt" -value $logline
 }
 } 

1. 决定应监控哪些事件：

$created = Register-ObjectEvent $w "Created" -Action $action
 $changed = Register-ObjectEvent $w "Changed" -Action $action
 $deleted = Register-ObjectEvent $w "Deleted" -Action $action
 $renamed = Register-ObjectEvent $w "Renamed" -Action $action
 while ($true) {sleep 2}

为了扩展你的知识，借助 Azure Active Directory Authentication Library (ADAL)，你可以使用 FormFileEncrypt 应用程序加密文件。如果你需要支持 HYOK 场景，我推荐你使用 DualSererTestApp。有了你的实验室基础设施，你就能运行所有的场景。

更多信息，请参阅微软开发者参考资料（Azure 信息保护开发者指南）：bit.ly/2HIDjQ2。

总结

在本章的最后，我们首先向你介绍了几种 PowerShell 脚本以及 SDK 相关代码，帮助你了解整个微软信息保护解决方案框架，或者开始开发你的扩展或应用程序。我们的目标从来不是在一章中让你成为一名开发者，但利用这些资源对于故障排除或管理此类解决方案是一个很好的知识来源。你现在应该能够描述有哪些 SDK 可用以及它们的用途。此外，你有足够的代码示例可以开始工作。我们希望为你提供一个功能完善且现成的工作环境，帮助你轻松入门。

希望本书中的信息能帮助你当前的组织或项目。非常感谢你坚持看到本书的最后。如果你有任何问题，欢迎通过我的博客 jochennickel.ch 或电子邮件 info@inovit.ch 向我咨询。