Active Directory 与 Azure Active Directory 解释 - Microsoft 平台管理 - 博客 - Quest Community

“Active Directory 与 Azure Active Directory”？好吧，我承认这场对决永远不会像“可口可乐 vs. 百事可乐”、“漫威 vs. DC”或“柯克 vs. 皮卡德”那样激发激情。尽管如此，这两项 Microsoft 核心技术对您数字生活的影响比您想象的还要大，因此了解它们非常重要。

为了提供帮助，这篇博客文章列出了您需要了解的所有关键事项：它们有何相似之处、有何不同以及（最重要的是）它们如何协同工作。

Active Directory 与 Azure Active Directory：主要相似之处

“Active Directory”这一名称揭示了 Active Directory (AD) 和 Azure Active Directory (Azure AD) 的很多共同点。让我们从“目录”开始。一般来说，目录是一个有组织的列表，就像以前放在您（或您父母）家门口的厚厚的黄页或手机上的联系人列表。 AD 和 Azure AD 都维护数据库或对象目录；最重要的对象类型之一是用户帐户，其中包括一个人的用户名和密码等详细信息，以及他们的真实姓名、职位、部门等。

但与黄页不同的是，Active Directory 和 Azure AD 目录是活动的。打印的目录是相当静态的：它不做任何事情；它它就在那里供您查阅。相比之下，AD 和 Azure AD 的功能就相当多了。事实上，它们执行相同的两项基本服务：为尝试访问 IT 生态系统中的设备、数据、应用程序和其他数字资源的用户提供身份验证和授权：

• 身份验证是验证某人或某物是否确实如其所声称的那样的过程。传统上，个人通过提供用户名和密码进行身份验证 - 理想情况下，只有您知道您的密码，因此通过输入密码，您可以证明实际上是您登录的，而不是其他人。您无疑知道，如今其他人很容易猜测或窃取您的密码，因此现在您经常必须提供第二个证据来证明您的身份，例如发送到您的密码移动设备或指纹，这个过程称为（您猜对了！）多重身份验证 (MFA)。
• 授权是确定某人或某事在经过身份验证后可以执行哪些操作的过程。例如，公司可能希望允许注册会计师 Alex 创建和编辑某些财务文档，但不允许系统管理员 Chris 阅读它们。同样，Chris 将被允许构建和运行 PowerShell 脚本并访问 Alex 禁止的数据。

换句话说，Active Directory 和 Azure Active Directory 都是两件事：一个包含有关 IT 环境中对象的关键信息的目录，以及一组控制的服务正在进行的大部分活动，其中身份验证和授权是两项最重要的服务。

Active Directory 与 Azure Active Directory：主要区别

这两种技术之间最根本的区别在于，Active Directory 最初位于本地数据中心，而 Azure Active Directory 是为 Microsoft 云设计的。让我们来解释一下这意味着什么。

Active Directory 通常驻留在称为域控制器 (DC) 的特殊本地计算机上。您购买这些机器，在每台机器上安装 Windows Server 操作系统，配置它们，并负责它们的维护和喂养。 DC 托管 AD 目录并运行 AD 服务。通常，组织有多个协同工作的 DC。特别是，对一个域控制器上的目录所做的任何更改（例如用户更新密码或用户帐户因登录尝试失败次数过多而被锁定）都会复制到其他域控制器，以便它们都保持最新状态。近年来，一些组织已将其 Active Directory 迁移到云端；然而，他们仍然对基础设施的位置负责。

Azure AD 驻留在 Microsoft 数据中心的 Microsoft 服务器上。您无需购买、配置它们、确保它们具有适当的温度和湿度，或保护它们免受入侵者和自然灾害的侵害。如果您的组织订阅了任何 Microsoft Online 业务服务，例如 Office 365（现在称为 Microsoft 365），您就拥有 Azure AD。 （但是，仅部分 Azure AD 功能免费提供；其他功能则需要 Azure AD Basic、Premium P1 或 Premium P2 许可证。）

但需要理解的关键一点是：Azure AD 与您所知的旧 Active Directory 不同，它只是在 Microsoft 服务器而不是您自己的 DC 上运行。 Azure AD 是一种不同的技术，专门为满足云环境而不是本地环境的需求而设计。让我们深入探讨其中最关键的差异。

结构

在 Active Directory 中，主要单位是域：一组存储在单个数据库（目录）中且可以一起管理的相关用户、计算机和其他 AD 对象。小公司可能只有一个域，但较大的组织通常有多个域，例如不同位置或业务部门的单独域。多个域可以组合成一个树，多个树可以组合成一个森林。

Azure AD 没有这些东西。相反，基本构建块是租户：特定公司的 Azure AD 专用实例。当您的组织注册 Office 365 等 Microsoft 云服务时，您将创建租户。您的 Azure 租户有一个专用目录，其中包含您的所有用户并为您执行身份验证和授权等服务。

验证

Active Directory 和 Azure Active Directory 都执行身份验证，但它们使用完全不同的协议来完成工作。 （协议基本上是一组用于在不同机器之间交换数据的规则，包括如何构建信息以及各方如何发送和接收信息。）

Active Directory 已经存在了很长时间，因此身份验证协议已经发生了很大的变化，从 LM 到 NTLM，再到当前支持的 NTLMv2 和 Kerberos。每一项进步都让冒名顶替者更难欺骗系统并使用其他人的凭据成功进行身份验证。

Azure AD 不支持任何这些协议。相反，它使用 OAuth、SAML 和 OpenID Connect 等现代身份验证协议。此外，Azure Active Directory 身份验证是一个多方面的过程，包括自助密码重置、Azure AD 多重身份验证、条件访问策略甚至无密码身份验证等组件。

授权

Active Directory 和 Azure Active Directory 也以完全不同的方式执行授权。在这两种情况下，授权都是一个复杂的过程，涉及很多组件；我将只关注最重要的元素，所以不要将这篇简短的博客文章误认为是全面的讨论。

在 Active Directory 中，主要通过三种方式来控制允许用户执行的操作：

• AD 安全组成员资格 - AD 安全组基本上是用户帐户的列表以及授予组中每个用户的一组权限。有各种内置安全组，例如域管理员和访客，您也可以创建自己的自定义安全组。例如，您可能有一个名为“财务团队”的安全组，该安全组允许组中的每个人运行某些应用程序并修改与其集体职责相关的某些文件。
• 直接分配权限 - 您还可以直接向 Active Directory 对象（例如用户帐户）分配权限。这可以对访问进行非常细粒度的控制，但这通常不是最佳实践，因为单独管理每个用户的权限非常容易出错，并且几乎无法立即有效管理。
• 组策略 - 组策略是 Active Directory 的一项非常强大的功能，它会影响许多进程，其中之一就是授权。它支持对用户和计算机的集中管理，因此，例如，您可以使用它来防止任何人从其计算机上的命令提示符执行命令或将数据复制到可移动设备。它还可以更精细地使用，例如，阻止远程计算机上的身份不明的用户连接到网络共享。

因此，当经过身份验证的用户尝试执行某些操作（例如读取一段数据或运行应用程序）时，Active Directory 会通过（除其他外）检查直接授予的权限并通过安全性来决定是否允许该操作组成员资格和组策略中规定的规则。

Azure AD 处理授权的方式非常不同。同样，这是一个复杂的过程，我没有完全详细说明，但以下是主要组成部分：

• Azure AD 安全组 - Azure AD 中的安全组在结构和功能上与本地 Active Directory 中的安全组类似：该组的所有成员都被授予分配给该组的所有权限。但是，Active Directory 组由本地用户帐户组成，并控制对本地应用程序和资源的访问，而 Azure AD 安全组由 Azure AD 用户帐户组成，用于授予对 Microsoft 365 资源（例如 SharePoint）的访问权限在线的。
• Microsoft 365 组（以前称为 Office 365 组）- Microsoft 365 组有点像增强型 Azure AD 安全组。它有一个成员列表，但它也与该组的资源和工作负载相关联，例如 SharePoint 团队网站和共享 Exchange 邮箱。 Microsoft 365 群组可以包含来自公司内部和外部的用户，并且可以将他们配置为动态成员身份，这意味着群组成员会根据部门、位置或职位等属性自动添加或删除。
• Azure AD 角色 - Azure AD 角色向不同类型的管理员授予特定的权限集。例如，全局管理员角色授予对 Azure AD 中所有管理功能以及使用 Azure AD 标识的服务（例如 Microsoft 365 安全中心、Exchange Online 和 SharePoint Online）的访问权限。顾名思义，Exchange 管理员角色向用户授予 Exchange Online 中的全局权限。有数十个内置 Azure AD 角色，您还可以创建自己的自定义角色。

计算机和设备管理

在 Active Directory 中，组策略是最强大的计算机管理工具之一。例如，您可以使用组策略阻止用户在特定计算机上添加新的 Microsoft 帐户、防止安装未经授权的计算机、在一段时间不活动后锁定计算机、在所有计算机上自动安装软件更新以及防止使用可移动存储设备。

正如我们已经看到的，Azure AD 没有组策略。相反，设备管理是通过 Microsoft Intune 完成的。您可以为 Intune 中注册的组织拥有的设备和个人 (BYOD) 设备设置不同的规则。选项包括阻止越狱设备、将证书推送到设备以便用户可以通过 VPN 连接到您的网络，以及擦除丢失或被盗设备上的公司数据。

Active Directory 与 Azure Active Directory：两者之一或两者！

两种技术之间的这些显着差异意味着它们适用于不同的场景。但它不一定是“Active Directory与 Azure Active Directory”——事实上，大多数时候，它实际上是“Active Directory和 Azure Active Directory” 。 ” 让我们看看组织为何以及如何在所谓的混合 IT 环境中同时使用这两者。

保留本地 Active Directory 的原因

虽然有些组织诞生于云中，因此从未有任何本地 IT 环境需要管理，但大多数组织的情况却截然不同。在云出现之前，他们拥有完善、复杂的 IT 生态系统，现在他们希望利用 Microsoft 云提供的所有功能。

他们为什么要保留本地 Active Directory，而不是完全迁移到云端？实际上有多个令人信服的原因，包括以下几点：

• 较旧的应用 - 组织通常拥有各种对其运营至关重要的第三方和定制应用程序，但这些应用程序不易移植到云端。例如，医疗保健组织可能拥有昂贵的 MRI 机器，依赖 Active Directory 进行访问控制，更换它们的成本太高。另一个组织可能已经构建了自己的业务流程自动化或客户关系管理软件，对其进行修改既昂贵又存在风险。话虽如此，许多应用程序可以进行现代化改造或替换为基于云的替代方案；只是需要时间和关心。
• 安全性和合规性 - 某些数据和流程非常关键或敏感，不应该存在于云端。例如，工业控制系统和敏感基础设施不应暴露在互联网上。组织可能已经制定了稳健的程序来保护敏感且高度监管的数据（例如本地健康记录或财务信息），但如果将其迁移到云端，则担心是否符合 HIPAA、SOX、GDPR 和其他法规。
• 业务连续性 - 组织还担心确保即使失去互联网访问或 Azure AD 出现故障也能继续运行。 （对于管理关键基础设施（例如水厂）的组织来说尤其如此。）这种担忧是完全有道理的：3 月份的 Azure AD 身份验证中断导致世界各地的 Microsoft 365 用户无法登录 Teams 和其他 Office 365 应用程序，并被召回2020 年 9 月发生的类似 Azure AD 中断的痛苦回忆。保留本地 Active Directory 可以减轻这种风险。此外，对于某些组织来说，数据的物理位置本身就是一个运营问题；例如，贸易公司需要将其计算机放置在靠近证券交易所计算机的位置，因为微秒可以在高频交易中产生至关重要的差异。
• 自给自足 - 更一般而言，组织对于将所有鸡蛋放在一个篮子中并将该篮子交给具有自身利益和优先事项的第三方持谨慎态度。如果您的本地 Exchange Server 出现故障，您可以决定 IT 团队的首要任务是否是将其恢复，但如果您的 Microsoft 365 电子邮件无法正常工作，您将受到 Microsoft 的摆布，此刻谁可能有更大的鱼要煎。

连接 Active Directory 和 Azure Active Directory

出于这些原因和其他原因，组织选择拥有混合 IT 环境并将数据从本地 Active Directory 同步到 Azure Active Directory。

Microsoft 提供了两种工具来提供帮助：Azure AD Connect 和 Azure AD Connect 云同步。这些工具会自动同步本地 Active Directory 环境和 Azure AD 之间的身份数据，使用户能够使用相同的凭据来访问本地应用程序和 Microsoft 365 等云服务。有关基本详细信息，请查看我的博客文章，“Azure AD Connect：它的工作原理和最佳实践。 ”

最后的想法

我希望我已经让您相信“Active Directory 与 Azure Active Directory”是一种错误的二分法。这两种技术只是服务于不同的目的。诞生于云中的组织可能永远不需要 Active Directory，少数公司可能会坚持使用他们已有的 AD，从不采用 Azure AD。但大多数组织都有充分的理由同时使用这两种技术——就像他们的自助餐厅可能同时提供可口可乐和百事可乐，并且他们的员工可以合理地喜欢《星际迷航》TOS 和 TNG 一样。