欢迎来到公海710 Azure AD - 基本概念

如果您在这里，那么您至少对 Azure Active Directory（又称 Azure Active Directory）有一些疑问。 AAD/Azure AD。作为“最差微软服务”奖的可能获奖者，如果您不完全清楚 AAD 是什么、应该如何使用以及不是什么，也没有什么可耻的。我们将尝试从高度层面上澄清这些问题。

如果您在这里，那么您至少对 Azure Active Directory（又称 Azure Active Directory）有一些疑问。 AAD/Azure AD。作为“最差微软服务”奖的可能获奖者，如果您不完全清楚 AAD 是什么、应该如何使用以及不是什么，也没有什么可耻的。我们将尝试带来一些非常对这些问题进行高度澄清。

当然，有无数的 TechNet 文章阐述了 AAD 的各种奇迹，并且他们在辩护中做了令人钦佩的工作；然而我们总是发现他们往往过于关注树木（双关语），而对森林关注不够。

活动目录

在描述这个隐喻森林的最后，我们实际上应该退后一步，简要回顾一下到底是什么传统Active Directory 是。这可能看起来很基本，但它是接下来对话的重要基础。

阅读本文的任何人都在或曾经在传统的 Active Directory 环境中工作。 20 多年来，Active Directory 一直是地球上几乎所有企业的支柱（也许那些小说商店除外……但我们在这里不谈论此类事情）。但是什么是活动目录？

首先，它的功能是身份验证机制和身份来源。它保留用户身份（用户名）和密码哈希，并在这些配对匹配或不匹配时向请求服务提供确认。

第二，这是一个层级管理和组织结构。组织单位 (OU)、容器、嵌套组 — x500 目录结构的所有组件，使管理员能够以极大的粒度组织和分类端点和用户帐户。这种层次结构至关重要，因为当您开始利用 LDAP 查询时，您可以询问有关对象的位置和成员资格的复杂问题，以便了解它是谁/什么/在哪里。

最后，它捆绑在一个政策申请引擎以组策略处理引擎的形式。

GPO 作为自定义用户和机器体验及配置的基本方式在组织中无处不在。 GPO 在 OU 级别应用，甚至支持一些基本的条件应用机制（例如，if用户正在X组，然后申请政策 Y).

如果您对 Active Directory 的更多功能感兴趣，请查看这个维基百科文章，出乎所有人的意料，它实际上非常准确地列出了 Active Directory 的功能和历史。

Active Directory 的不足之处

Active Directory 已经满足了我们 20 多年来所要求的一切，但与任何传统技术一样，它不支持一些更现代的身份验证机制。具体来说，它无法处理任何基于云的身份协议，例如 SAML、OAuth、OAuth2 或 OpenID Connect。

缺乏对现代云身份验证的支持，这一单一缺点正是 Azure AD 的用武之地。

什么是 Azure Active Directory（又名 Azure AD、AAD）？

从本质上讲，Azure AD 只不过是一个基于云的身份提供商，可以使用更现代的、以云/SaaS 为中心的身份验证协议。它是一个包含帐户对象和密码哈希的平底桶。就是这样。如果您来这里是为了寻找“什么是 AAD”的答案，那么您现在已经找到了。

就具体功能和许可级别而言，Microsoft 提供了一个非常好的矩阵，详细说明了哪些许可级别包含哪些内容，可以在此处找到：https://docs.microsoft.com/en-us/azure/active-directory/authentication/concept-mfa-licensing.

Azure AD 不是什么

您可能已经了解到，AAD 对于该产品来说是一个非常糟糕的名称，因为它实际上是不是 Azure 中的 Active Directory，无论其名称有何含义。

Azure AD 根本不支持 Kerberos、NTLM 或 LDAP。除其他外，这意味着任何“非云”或遗留应用程序可能无法对其进行身份验证，也无法从中查询信息。

此外，Azure AD 是完全扁平的 - 没有传统 Active Directory 中那样的 OU 层次结构。所有的账户都放在一个很大的桶里。接下来，AAD 中也没有直接的组策略概念。如果您考虑一下，如果没有 OU 结构，GPO 结构中通常依赖的许多粒度和组织就不存在，因此尝试以这种方式管理这些对象没有什么意义。

你呢需要AAD？

对于几乎所有拥有本地 Active Directory 的现有组织来说，上述问题的答案都是响亮的“可能”。

虽然纯粹的本地环境在技术上并不需要，但即使是对云最犹豫的组织也很可能需要在至少一项正在使用的服务或应用中进行某种现代身份验证。

例如，任意组织正在运行任意Microsoft 在线服务（O365、OneDrive、SharePoint Online、Exchange Online 等）必须有 AAD设置（最好与本地 Active Directory 同步 - 稍后详细介绍）。

从安全角度来看，Azure AD 的最佳论据之一是它能够控制对应用程序的访问并保护用户的身份。为此，Azure AD 具有几个关键的内置功能：

• 有条件访问
  • 在访问应用程序或设备时提供进入障碍
• 多重身份验证
  • 软令牌、短信等
• 自助密码重置
• Azure AD 密码保护
  • 根据全球已知的禁止密码数据库扫描泄露的密码
• 监控有风险的用户登录和有风险的用户行为

传统 Active Directory 的未来

即使存在巨大差异，人们仍然会问这样的问题：“AAD 会取代 Active Directory 吗？”简短的回答是：不。我们今天所知道的 Active Directory 是不会消失.

坦率地说，较长的答案以“当然不是！”开头

Azure AD 不是“下一代”Active Directory，也不是后继者、附加组件，也不是与传统 Active Directory 真正相关的任何方式，只是由同一软件供应商提供的一种身份提供商。它们的功能集几乎完全是互斥的。

打个比方，尽管这两种东西都能让你从一个地方移动到另一个地方，但你不能再用汽车代替船作为从纽约到伦敦的出行方式。

这两种解决方案都有特定的目的，尽管它们可以结合在一起，但它们实际上是针对两个不同问题的两个完全独立的解决方案。一个不是另一个的迭代。

由于它们是如此不同，因此不要指望当前的每个软件供应商都会将“AAD 支持”添加到其其他非云产品中。如前所述，Active Directory 不会消失，对于非云工作负载，Active Directory 将继续成为当今使用的所有领域的黄金标准。

如果 Active Directory 没有任何进展，那为什么还要存在 AAD？

我们非常简短地提到 Azure AD 是一个云身份提供商，这一切都很好，但它为什么存在呢？为什么不直接向现有的 Active Directory 添加 SAML 或 OAuth 支持？从本质上讲，从大多数企业的基础设施角度来看，尝试将所需的现代身份验证功能转移到本地 Active Directory 中需要这样的方法，以使其成为有效的失败者。

构建第二个独立的身份验证平台（基于并支持所有现代身份验证概念），然后提供一种将其连接到旧版 Active Directory 的方法，而不是将此功能硬塞到现有平台中，更有意义。

携手共进 - Azure AD Connect

知道 Active Directory 无法“与云对话”并且 AAD 无法与 LDAP 对话，几乎每个组织最终都需要运行某种混合Active Directory/AAD 环境。

Azure AD Connect 是一个工具集，旨在将本地 Active Directory 基础架构链接到 Microsoft 托管的 AAD 实例。本质上，这个工具所做的就是将您的本地用户帐户名称复制到 AAD，以及密码的哈希值，从而允许针对 AAD 的现代身份验证反映存储在本地 Active Directory 中的凭据。 （如果您熟悉 Microsoft Forefront Identity Manager，那么您也非常熟悉 Azure AD Connect。）本地 Active Directory 与 AAD 同步后，用户就可以无缝登录 Microsoft 365 等 SaaS 应用程序。

在这种混合环境中，本地 Active Directory永远是真理的源泉。这意味着 Azure Active Directory 永远不会拥有用户的密码。如果用户从 Azure 发起密码重置，则 Azure AD Connect 会处理该重置请求并将请求转发到本地域控制器。

Azure Active Directory 域服务怎么样？

Active Directory/AAD 组合还有另一种风格，即 Azure Active Directory 域服务器 (AAD-DS)。简单来说，想想AAD-DS 作为精简的“Active Directory 即服务”解决方案，由 Microsoft 提供。

它可以用作独立的 Active Directory 实例，以支持您不希望向生产 Active Directory 基础架构进行身份验证的不受信任环境。

AAD-DS 也有很多问题。仅举几例：

• 它不能与您的本地目录或旧目录相同。
• 它完全由 Azure 管理，因此管理访问权限受到限制。
• 已加入 AAD-DS 的端点必须位于 Azure 中。
• 不存在双向信任。
• 无法将其移动到 Azure、VNet 或子网中的其他区域。
• 它无法同步到多个 Azure 区域。

简而言之，_AAD-DS 不是运行“_Active Directory”的方法在云端。”对于大多数希望构建基于云的目录存在的传统组织来说，构建一个由在 Azure 中运行的传统 Active Directory 控制器组成的混合基础架构，并通过 AD Connect 将这些控制器同步到 Azure AD 实例，将是推荐的解决方案。

建议

抽象地需要消化大量信息，所以让我们从解决方案的角度对其进行一些分解。

没有传统 Active Directory 的 Azure AD

此解决方案仅适用于纯云组织，没有遗留或本地应用程序，其中 AAD 将成为您的身份真实来源。请记住，如果没有传统的 Active Directory，就没有 LDAP 支持，也没有 Kerberos 身份验证，因此您将仅限于现代 SAML/OAuth SaaS 平台。

具有传统 Active Directory 的 Azure AD（标准“混合”模型）

对于大多数希望在其环境中建立现代身份验证支持的现有组织来说，这将是最佳途径。

此解决方案提供了两全其美的优点：既保留对本地和当前应用程序和端点的完整旧版 ldap/kerberos/ntlm 支持，同时也弥补了与需要使用 SAML、OAuth 等现代身份验证的现代 SaaS 应用程序和平台之间的差距。

其他一切

一如既往，如果您对 Azure、Azure AD 甚至传统 Active Directory 有任何疑问，Alchemy Services 可以为您提供帮助。请联系[[电子邮件受保护]]，或您的客户经理，安排时间与我们的解决方案架构师之一一起审查您的业务需求。