Azure Active Directory（Microsoft Entra ID）
📋 本章概览
| 信息 | 详情 |
|---|---|
| 考试领域 | Manage Azure identities and governance |
| 考试权重 | 20% |
| 建议时长 | 180 分钟 |
| 难度 | ⭐⭐ 中等 |
| 前置知识 | 了解基本的身份认证概念（用户名/密码） |
📢 命名说明: 微软已将 Azure Active Directory 更名为 Microsoft Entra ID。考试中两个名字都会出现，本章统一用 Entra ID (Azure AD) 表示。看到 Azure AD = Entra ID，别被名字吓到。
🎯 学习目标
完成本章后，你将能够：
- ✅ 创建和管理 Entra ID 用户（单个 + 批量）
- ✅ 配置安全组和 Microsoft 365 组，包括动态成员资格
- ✅ 理解并配置多因素认证（MFA）和条件访问策略
- ✅ 区分 Entra ID 角色 vs Azure RBAC 角色——考试最爱考的混淆点
- ✅ 管理设备注册和加入方式
本章知识地图
Entra ID (Azure AD) — 身份与访问管理
│
├── 租户 Tenant ─────── 你的组织在云端的"身份空间"
│
├── 用户管理 ─────────── 云用户 / 同步用户 / 来宾用户(B2B)
│ ├── 单个创建（Portal / CLI / PowerShell）
│ └── 批量创建（CSV 导入）
│
├── 组管理 ───────────── 安全组 / M365 组
│ ├── 静态成员（手动加人）
│ └── 动态成员（规则自动匹配）
│
├── 认证安全 ─────────── MFA（多因素）
│ └── 条件访问（Conditional Access）
│ └── IF 用户+应用+条件 THEN 控制
│
├── 角色体系 ─────────── Entra ID 角色（管目录）
│ │ vs Azure RBAC 角色（管资源）← 必考
│ ├── 内置角色（Global Admin, User Admin...）
│ └── 自定义角色（最小权限原则）
│
└── 设备管理 ─────────── 注册 / 加入 / 混合加入
🖼️ 身份与访问全景图
📌 图解说明：
- 这张图在讲什么：从用户登录（身份认证）到访问资源（授权）的完整链路——Entra ID 处理"你是谁"，RBAC/应用权限处理"你能做什么"。
- 你应该先看哪里：从左侧"用户/组/服务主体"开始 → 经过 Conditional Access + MFA 关卡 → 最终落到右侧资源授权。
- 考试常见问法："用户能登录但看不到资源"——说明认证通过了但授权没配。"需要同时配 CA + RBAC"——CA 管登录条件，RBAC 管资源权限，两层各管各的。
🏢 Entra ID 是什么？为什么 AZ-104 第一章就学它？
术语：Entra ID (Azure Active Directory / Azure AD)
- 一句话解释：微软的云端身份和访问管理服务——管"谁能登录"以及"登录后能做什么"。
- 形象比喻：公司的人事部 + 门禁系统。人事部管员工花名册（用户目录），门禁系统决定谁能刷卡进哪个房间（访问控制）。
- 考试怎么考：几乎每道 AZ-104 身份题都会涉及 Entra ID，因为所有 Azure 资源的访问都从这里开始。
- 最易混淆：Entra ID ≠ 传统 Active Directory。Entra ID 是云原生的，用 REST API + OAuth；传统 AD 是本地的，用 LDAP + Kerberos。
为什么第一章就学这个？因为没有身份，什么都做不了。你不能创建 VM、不能配网络、不能管存储——除非你先有一个 Entra ID 账户并被赋予了权限。身份是 Azure 一切操作的入口。
Entra ID vs 传统 Active Directory
很多考生有 Windows Server 背景，容易把两者搞混。关键区别：
| 维度 | Entra ID (Azure AD) | 传统 Active Directory (AD DS) | 一句话区分 |
|---|---|---|---|
| 部署位置 | 云端（微软托管） | 本地服务器 | 云 vs 本地 |
| 认证协议 | OAuth 2.0 / OIDC / SAML | Kerberos / NTLM | 现代 Web 协议 vs 传统企业协议 |
| 查询方式 | REST API (Microsoft Graph) | LDAP | RESTful vs 目录协议 |
| 组织结构 | 扁平（无 OU） | 层次化（OU 树形结构） | 扁平 vs 层级 |
| 管理对象 | 用户、组、应用、设备 | 用户、组、计算机、GPO | Entra ID 多了"应用"管理 |
| 多租户 | 天然支持 | 需要额外配置信任 | 云天生多租户 |
⚠️ 考试陷阱：Entra ID 没有 OU（组织单元）。如果题目问"如何在 Entra ID 中创建 OU 来组织用户"——答案是不能，Entra ID 用组和管理单元(Administrative Units)代替 OU。
术语：Tenant（租户）
- 一句话解释：你的组织在 Entra ID 中的独立身份空间，每个租户有自己的用户目录、应用注册和安全策略。
- 形象比喻：一栋写字楼里的一个独立办公区——你有自己的门禁系统和员工名单，和隔壁公司完全隔离。
- 考试怎么考："多个订阅可以关联同一个租户吗？"——可以。租户管身份，订阅管计费和资源，两者是多对一关系。
- 最易混淆：Tenant vs Subscription。Tenant = 身份容器；Subscription = 资源和计费容器。一个 Tenant 可以挂多个 Subscription。
👤 用户管理
三种用户类型
Entra ID 里的用户不只是"在 Portal 上手动创建的账号"，实际上有三种来源：
| 用户类型 | 来源 | 适用场景 | 一句话记忆 |
|---|---|---|---|
| 云用户 (Cloud Identity) | 直接在 Entra ID 中创建 | 纯云环境的员工 | 原生云账号 |
| 同步用户 (Synced Identity) | 从本地 AD 通过 Azure AD Connect 同步 | 混合环境、已有本地 AD 的企业 | 本地账号的"云影子" |
| 来宾用户 (Guest / B2B) | 从外部组织邀请 | 合作伙伴、外包团队、跨公司协作 | 外人临时工牌 |
💡 实际工作中：大多数企业是"同步用户"为主——员工账号在本地 AD 创建，通过 AD Connect 同步到 Entra ID，实现"一套密码、两边都能用"。
术语：Azure AD Connect
- 一句话解释：把本地 Active Directory 的用户和组同步到 Entra ID 的桥梁工具。
- 形象比喻：两栋大楼之间的穿梭巴士——员工信息从本地那栋楼同步到云端那栋楼，保持两边名单一致。
- 考试怎么考：问"混合身份方案"或"本地用户如何访问云资源"时，答案几乎都涉及 AD Connect。
- 最易混淆：AD Connect 只同步身份信息，不同步 Azure 资源。同步方向默认是本地 → 云（可配回写）。
创建用户
Azure CLI
az ad user create \
--display-name "John Doe" \
--user-principal-name john@contoso.com \
--password "SecureP@ss123"
PowerShell
New-AzADUser -DisplayName "John Doe" `
-UserPrincipalName john@contoso.com `
-Password (ConvertTo-SecureString "SecureP@ss123" -AsPlainText -Force)
术语：User Principal Name (UPN)
- 一句话解释：用户的登录名，格式像邮箱地址（
user@domain.com），但它不是邮箱。 - 考试怎么考：题目可能给一个 UPN 问"这个用户能登录吗"——关键看
@后面的域名是否已在租户中验证。 - 最易混淆：UPN ≠ Email。UPN 是登录标识，Email 是通讯地址。大多数情况下两者相同，但可以不同。
批量操作
实际管理中，不可能一个一个创建用户。CSV 批量导入是 AZ-104 的考点：
Name,UserPrincipalName,Password,Department
John Doe,john@contoso.com,TempP@ss1,Engineering
Jane Smith,jane@contoso.com,TempP@ss2,Marketing
Bob Wilson,bob@contoso.com,TempP@ss3,Sales
操作路径：Entra ID → Users → Bulk operations → Bulk create → 上传 CSV
⚠️ 考试重点：批量创建用户时必须包含
UserPrincipalName和初始密码。考试会问"以下哪些字段是 CSV 必填项"。
用户属性管理
AZ-104 还会考用户属性的修改权限：
| 操作 | 最低需要的角色 | 常见陷阱 |
|---|---|---|
| 创建用户 | User Administrator | 不需要 Global Admin |
| 重置密码（普通用户） | Password Administrator | Helpdesk Admin 也行 |
| 重置密码（管理员用户） | Privileged Authentication Admin | 普通 Password Admin 不够 |
| 删除用户 | User Administrator | 删除后 30 天内可恢复 |
| 恢复已删除用户 | User Administrator | 超过 30 天永久删除 |
👥 组管理
为什么需要组？因为权限不应该一个用户一个用户地配。组就是"批量管理权限的容器"。
两种组类型
| 类型 | 核心用途 | 成员类型 | 一句话记忆 |
|---|---|---|---|
| 安全组 (Security Group) | 分配权限（RBAC、条件访问） | 用户、设备、服务主体 | 管权限用安全组 |
| Microsoft 365 组 (M365 Group) | 协作（共享邮箱、Teams、SharePoint） | 仅用户 | 管协作用 M365 组 |
⚠️ 考试陷阱：M365 组不能包含设备和服务主体，只能包含用户。如果题目需要给一组设备分配策略，只能用安全组。
两种成员资格
| 成员资格类型 | 机制 | 适用场景 | 一句话记忆 |
|---|---|---|---|
| 已分配 (Assigned) | 手动添加/移除成员 | 人数少、变动不频繁 | 手动管理 |
| 动态 (Dynamic) | 基于属性规则自动匹配 | 人数多、按部门/地区自动归组 | 规则自动匹配 |
动态组是 AZ-104 的高频考点。你写一条规则，系统自动把符合条件的用户加进来，不符合的自动移出去。
动态组规则示例
(user.department -eq "Sales") and (user.country -eq "Australia")
这条规则的含义：部门是 Sales 且国家是 Australia 的用户自动成为组成员。如果有人调部门了，系统会自动把他移出这个组。
更多规则语法：
| 运算符 | 含义 | 示例 |
|---|---|---|
-eq | 等于 | user.department -eq "IT" |
-ne | 不等于 | user.jobTitle -ne "Intern" |
-startsWith | 以...开头 | user.displayName -startsWith "Admin" |
-contains | 包含 | user.proxyAddresses -contains "smtp:*@contoso.com" |
-match | 正则匹配 | user.department -match "Eng.*" |
💡 动态组需要 Entra ID P1 或 P2 许可证。考试会问"配置动态组需要什么前提条件"——答案是 Premium 许可证。
🔐 多因素认证（MFA）
术语：MFA (Multi-Factor Authentication)
- 一句话解释：在密码之外再加一道验证——"我知道密码"+"我有手机"才能登录。
- 形象比喻：银行大额转账——输完密码（你知道的）还要短信验证码（你拥有的）才能操作。
- 考试怎么考：题目给一个安全需求，问如何实现。只要涉及"增强登录安全"，MFA 是第一反应。
- 最易混淆：MFA 管"登录安全"，RBAC 管"登录后的权限"。MFA 不能控制"用户能访问哪些资源"。
三种认证因素
| 因素类型 | 含义 | 示例 | 一句话记忆 |
|---|---|---|---|
| 你知道的 (Something you know) | 知识 | 密码、PIN、安全问题 | 脑子里的信息 |
| 你拥有的 (Something you have) | 持有物 | 手机、硬件令牌、智能卡 | 手上的设备 |
| 你本身的 (Something you are) | 生物特征 | 指纹、面部识别、虹膜 | 身体本身 |
MFA 要求至少使用两种不同类型的因素。"密码 + PIN" 不是 MFA（都是"你知道的"）；"密码 + 手机验证码" 是 MFA（知道 + 拥有）。
MFA 验证方法
| 方法 | 类型 | 安全等级 | 一句话记忆 |
|---|---|---|---|
| Microsoft Authenticator 推送 | 拥有 | ⭐⭐⭐ | 微软推荐首选 |
| OATH 硬件令牌 | 拥有 | ⭐⭐⭐ | 最安全但最贵 |
| OATH 软件令牌 | 拥有 | ⭐⭐ | Authenticator 内生成 |
| 短信验证码 | 拥有 | ⭐ | 方便但可被 SIM 劫持 |
| 语音呼叫 | 拥有 | ⭐ | 回退方案 |
⚠️ 考试重点：微软推荐的首选 MFA 方法是 Microsoft Authenticator 应用推送通知，不是短信。题目如果问"most secure MFA method"，选 Authenticator 或硬件令牌。
🚦 条件访问（Conditional Access）
术语：Conditional Access（条件访问）
- 一句话解释：根据"谁、从哪、用什么设备、访问什么应用"这些条件，动态决定放行、要求 MFA 还是直接阻止。
- 形象比喻：机场安检的智能分流通道——VIP 旅客快速通行，普通旅客需要额外检查，可疑人员直接拦截。不是所有人都经历同样的安检流程，而是根据"风险等级"动态调整。
- 考试怎么考：这是 AZ-104 身份部分的最高频考点。题目描述一个安全需求，问你如何配置条件访问策略。
- 最易混淆：条件访问 vs MFA。MFA 是条件访问的一个执行动作——条件访问可以"要求 MFA"，也可以"要求合规设备"或"直接阻止"。
条件访问策略的逻辑结构
一条策略由三部分组成：谁 + 什么条件 + 执行什么控制
IF [Assignments - 谁在什么条件下]
├── Users/Groups → 哪些用户或组
├── Cloud apps → 访问哪些应用
└── Conditions → 什么条件下触发
├── 位置（公司内/外）
├── 设备平台（iOS/Android/Windows）
├── 设备状态（合规/不合规）
└── 登录风险（低/中/高）
THEN [Access Controls - 执行什么]
├── Grant（放行但要求...）
│ ├── Require MFA
│ ├── Require compliant device
│ ├── Require Hybrid Azure AD joined device
│ └── Require approved client app
└── Block（直接阻止）
策略示例
示例 1：外部网络访问财务系统必须 MFA
IF 用户属于 "Finance-Users" 组
AND 访问 "Finance App"
AND 位置 ≠ 公司网络（Trusted Location）
THEN 要求 MFA
示例 2：高风险登录直接阻止
IF 任何用户
AND 登录风险 = High
THEN Block access
示例 3：移动设备只能用受管应用
IF 所有用户
AND 设备平台 = iOS 或 Android
THEN 要求使用 Approved client app
条件访问的评估顺序
多条策略同时命中时怎么办？
| 优先级 | 规则 | 一句话记忆 |
|---|---|---|
| 1 | Block 永远优先 | 只要有一条策略 Block，就被阻止 |
| 2 | 所有 Grant 条件必须全部满足 | 要求 MFA + 合规设备 = 两个都要满足 |
| 3 | 没有匹配任何策略 = 默认放行 | 无策略 = 不限制 |
⚠️ 考试陷阱：如果用户同时命中"要求 MFA"和"Block"两条策略，最终结果是 Block。Block 永远赢。
条件访问需要的许可证
| 功能 | 最低许可证 |
|---|---|
| 基础条件访问策略 | Entra ID P1 |
| 基于风险的条件访问 | Entra ID P2 |
| 动态组 | Entra ID P1 |
🎭 角色体系——最容易混淆的考点
AZ-104 考试最爱考的混淆点就是 Entra ID 角色 vs Azure RBAC 角色。很多考生在这里反复丢分，因为两套角色体系名字都带"角色"，但管的东西完全不同。
术语：Entra ID 角色 vs Azure RBAC 角色
- 一句话解释：Entra ID 角色管目录对象（用户、组、应用）；Azure RBAC 角色管 Azure 资源（VM、VNet、Storage）。
- 形象比喻：Entra ID 角色 = 人事部的组织架构权限（谁能招人、改花名册）；Azure RBAC = 公司的办公资源权限（谁能用会议室、谁能开服务器）。人事权限和办公资源权限是两套独立体系。
- 考试怎么考：题干说"管理用户和组" → Entra ID 角色。题干说"管理 VM 和 Storage" → Azure RBAC。
- 最易混淆：Global Administrator（Entra ID 角色）和 Owner（RBAC 角色）。Global Admin 默认不拥有 Azure 资源权限，需要单独提升。
两套角色对比
| 维度 | Entra ID 角色 | Azure RBAC 角色 |
|---|---|---|
| 管什么 | 目录对象（用户、组、应用、设备） | Azure 资源（VM、VNet、RG） |
| 在哪分配 | Entra ID 门户 | 资源/RG/订阅级别 |
| 作用范围 | 租户级 | 管理组/订阅/RG/资源 |
| 典型角色 | Global Admin, User Admin | Owner, Contributor, Reader |
| 自定义 | 支持（需要 P1/P2） | 支持 |
Entra ID 内置角色
| 角色 | 权限范围 | 什么时候分配 | 一句话记忆 |
|---|---|---|---|
| Global Administrator | 所有 Entra ID 功能 | 极少数人（2-3 人） | 最高权限，谨慎使用 |
| User Administrator | 创建/管理用户和组 | IT 运维人员 | 管人，不管资源 |
| Billing Administrator | 管理账单和订阅购买 | 财务人员 | 只管花钱 |
| Application Administrator | 管理应用注册和企业应用 | 开发团队负责人 | 管应用，不管用户 |
| Conditional Access Administrator | 管理条件访问策略 | 安全团队 | 管策略，不管人 |
| Helpdesk Administrator | 重置非管理员密码 | IT 服务台 | 只能改普通用户密码 |
| Privileged Role Administrator | 管理角色分配 | 安全管理员 | 管"谁有什么角色" |
💡 最小权限原则 (Least Privilege)：别给 Global Admin，给够用的最低角色。考试问"least privilege"时，从表里找权限最小但够用的那个。
自定义角色
当内置角色权限太大或不够精准时，创建自定义角色：
{
"Name": "App Reader",
"Description": "Can read application registrations",
"Actions": [
"microsoft.directory/applications/standard/read"
],
"NotActions": [],
"AssignableScopes": ["/"]
}
自定义角色的关键字段：
- Actions：允许做什么
- NotActions：从 Actions 中排除什么
- AssignableScopes：这个角色能分配到哪些范围
⚠️ 考试重点：自定义 Entra ID 角色需要 Entra ID P1 或 P2 许可证。免费版只能用内置角色。
💻 设备管理
Entra ID 不只管人，也管设备。设备管理决定了"哪些设备可以访问公司资源"。
三种设备注册方式
| 注册方式 | 适用场景 | 设备归属 | 一句话记忆 |
|---|---|---|---|
| Azure AD 注册 (Registered) | BYOD（员工自带设备） | 个人 | 松散关联，设备仍归个人 |
| Azure AD 加入 (Joined) | 纯云管理的公司设备 | 公司 | 设备完全归 Entra ID 管理 |
| 混合 Azure AD 加入 (Hybrid Joined) | 同时加入本地 AD + Entra ID | 公司 | 混合环境两边都要管 |
自带设备（BYOD）
→ Azure AD Registered（最松散，不强制管控）
纯云公司设备
→ Azure AD Joined（设备直接归 Entra ID 管）
有本地 AD 的企业 + 需要云管理
→ Hybrid Azure AD Joined（两边都加入）
⚠️ 考试陷阱：条件访问可以要求"Compliant device"或"Hybrid Azure AD joined device"。BYOD Registered 设备通常不满足"Compliant"条件，除非经过 Intune 合规检查。
🔄 B2B 来宾用户（外部协作）
术语：B2B (Business-to-Business) 协作
- 一句话解释：邀请外部组织的用户以"来宾"身份访问你的租户资源。
- 形象比喻：给合作伙伴发一张临时访客工牌——能进指定会议室，但不能进其他办公区。
- 考试怎么考：题干出现"external collaboration"、"partner access"、"外部用户"——答案通常是 B2B Guest。
- 最易混淆：B2B（邀请外部用户到你的租户）vs B2C（面向消费者的身份管理）。AZ-104 主要考 B2B。
B2B 协作流程
1. 管理员发送邀请 → 合作伙伴收到邮件
2. 合作伙伴用自己的身份登录 → Entra ID 创建 Guest 对象
3. 管理员将 Guest 加入安全组 → 通过组分配权限
4. (可选) 配置 Access Review → 定期审查是否还需要访问
5. (可选) 配置生命周期策略 → 30/60/90 天后自动失效
💡 最佳实践：不要为合作伙伴在你的租户里创建新用户——用 B2B Guest。这样对方用自己的凭据登录，你不用管他们的密码和 MFA。
🧠 核心概念辨析（考试必考）
Entra ID 角色 vs Azure RBAC 角色
这个区别太重要了，用一个完整场景说清楚：
场景：张三是 IT 管理员，需要能创建新用户，同时能管理 Production 资源组里的 VM。
解法：
- 给张三分配 User Administrator（Entra ID 角色）→ 管用户
- 给张三分配 Contributor（Azure RBAC 角色）在 Production RG 上 → 管 VM
两个角色在不同体系、不同界面、不同范围分配。
| 问自己 | 如果答案是... | 用哪套角色 |
|---|---|---|
| 要管的是用户/组/应用？ | 是 | Entra ID 角色 |
| 要管的是 VM/VNet/Storage？ | 是 | Azure RBAC 角色 |
| 题干说"manage directory objects"？ | 是 | Entra ID 角色 |
| 题干说"manage Azure resources"？ | 是 | Azure RBAC |
Authentication vs Authorization
| 维度 | Authentication（认证） | Authorization（授权） |
|---|---|---|
| 问什么 | 你是谁？ | 你能做什么？ |
| 由谁负责 | Entra ID（身份验证） | RBAC / 应用权限 |
| 方式 | 密码 + MFA | 角色分配 |
| 比喻 | 门口刷工牌 | 刷卡后能进哪个房间 |
Global Admin 的特殊性
Global Administrator 是 Entra ID 的最高角色，但它有一个经常被考到的特殊行为：
- Global Admin 默认没有 Azure 资源权限（即没有 RBAC 角色）
- 需要在 Entra ID → Properties → "Access management for Azure resources" 手动提升
- 提升后会获得所有订阅的 User Access Administrator 角色
- 这个操作叫 Elevate access，考试会考
⚡ 30 秒答题框架
拿到一道身份与访问题，按这个顺序判断：
Step 1: 分清是"目录权限问题"还是"资源权限问题"
└── 目录权限 → Entra ID 角色
└── 资源权限 → Azure RBAC
Step 2: 涉及"额外安全要求"？
└── 是 → Conditional Access + MFA
Step 3: 涉及"外部用户"？
└── 是 → B2B Guest（不是创建新本地用户）
Step 4: 涉及"批量操作"？
└── 是 → CSV 批量导入 + 动态组
Step 5: 涉及"最小权限"？
└── 是 → 选权限最小但够用的角色，不选 Global Admin
🔍 高频关键词速配
| 题干关键词 | 秒选方向 | 常见干扰项 |
|---|---|---|
least privilege | 最小权限角色（常常不是 Global Admin） | 给 Global Admin 图方便 |
external collaboration | B2B Guest 邀请 | 新建本地用户 |
enforce MFA outside corporate network | 条件访问策略 | 全局 MFA（粒度太粗） |
bulk user onboarding | CSV 批量导入 + 动态组 | 一个一个手动创建 |
manage users and groups | User Administrator 角色 | Global Admin |
risk-based sign-in | 条件访问 + Identity Protection (P2) | 普通 MFA |
compliant device required | 条件访问 + Intune 合规策略 | 只靠 MFA |
automatic group membership | 动态组规则 | 手动 Assigned 组 |
partner 30-day access | B2B Guest + 生命周期策略 | 永久账户 |
🧪 场景加练（秒选版）
场景 1：财务系统安全访问
公司要求"财务系统只能在公司设备上访问，且必须 MFA"。
秒选思路： 条件访问策略——Assignments 绑定财务用户组 + 财务应用，Grant 选择 Require MFA + Require compliant device。
为什么不只配 MFA？因为还有"公司设备"要求，需要设备合规条件。
场景 2：合作伙伴临时访问
合作伙伴需访问你方租户内一个应用，且 30 天后自动失效。
秒选思路： B2B Guest 邀请 + Access Review / Entitlement Management 生命周期策略。
为什么不是新建用户？因为合作伙伴用自己的凭据登录更安全，你不用管他的密码。
场景 3：自动化部门分组
公司有 500 人，希望销售部的人自动归入 "Sales-Team" 组，离开销售部自动移出。
秒选思路： 动态安全组 + 规则 (user.department -eq "Sales")。
前提：需要 Entra ID P1 许可证。
场景 4：管理员密码重置权限
IT 服务台需要能帮忙重置普通员工密码，但不应该能重置其他管理员的密码。
秒选思路： 分配 Helpdesk Administrator 角色。
为什么不是 Password Administrator？Helpdesk Admin 更受限，只能重置非管理员密码，符合最小权限原则。
场景 5：混合身份环境
公司有本地 Active Directory，希望员工用同一套凭据访问本地系统和 Azure 资源。
秒选思路： 部署 Azure AD Connect 实现身份同步 + Hybrid Azure AD Join 管理设备。
为什么不是纯云方案？因为已有本地 AD，不可能一夜之间全部迁到云端。
🚨 常见陷阱
| 陷阱 | 正确理解 |
|---|---|
| "Entra ID 有 OU" | ❌ 没有 OU，用组和管理单元代替 |
| "Global Admin 自动有 Azure 资源权限" | ❌ 需要手动 Elevate access |
| "动态组免费" | ❌ 需要 Entra ID P1/P2 许可证 |
| "MFA = 安全问题 + 密码" | ❌ 两个都是"你知道的"，不算多因素 |
| "密码 + PIN = MFA" | ❌ 同一因素类型，不是多因素 |
| "B2B Guest 不能配 MFA" | ❌ 可以通过条件访问要求 Guest 也做 MFA |
| "条件访问 MFA 和 Block 同时命中 = MFA" | ❌ Block 永远赢 |
📚 官方资源
| 资源 | 链接 |
|---|---|
| Microsoft Entra ID 文档 | learn.microsoft.com/entra/identity |
| 条件访问文档 | learn.microsoft.com/entra/identity/conditional-access |
| AZ-104 考试大纲 | learn.microsoft.com/certifications/exams/az-104 |
开始本章测验
完成学习后，建议先做章节练习题，重点关注 Entra ID 角色 vs RBAC 角色的区分题。