本文是通过利用生成式 AI 的自动化生成流程创建的。
什么是 Microsoft Entra ID P1 / P2？理清 M365 E3 与 E5 在身份验证和身份管理上的差异
关于本文
截至2026年9月18日，已核对微软官方许可证信息，并从身份验证、条件访问（Conditional Access）、身份保护（Identity Protection）以及 PIM 的角度，梳理了 Microsoft Entra ID P1/P2 与 Microsoft 365 E3/E5/E7 之间的关系。验证状态：📘 已核对微软官方信息・实机未验证
Microsoft Entra ID 是支撑 Microsoft 365 用户、组、登录及应用访问的身份（Identity：代表“我是谁”的数字身份）基础设施。
P1 与 P2 的区别并非在于“能否登录 Microsoft 365”。其核心区别在于，在基础身份管理之上，条件访问、风险检测以及特权管理能够提升到何种高级程度。
首先需要掌握的术语
| 术语 | 面向初学者的含义 |
|---|---|
| MFA | 多因素认证，除了密码之外还使用其他要素 |
| 条件访问 (Conditional Access) | 根据用户、设备、位置和风险等条件来判断访问权限的机制 |
| 登录风险 (sign-in risk) | 本次登录可能是由攻击者发起的风险 |
| 用户风险 (user risk) | 用户账户本身遭到入侵的可能性 |
| 身份保护 (Identity Protection) | 用于检测和响应有风险的用户/登录的 Entra 功能 |
| PIM | Privileged Identity Management（特权身份管理）。仅在需要的时间内启用管理员权限的机制 |
| 紧急账号 (break-glass account) | 在条件访问故障等紧急情况下使用的应急管理账号 |
与 E3/E5/E7 的关系
微软官方 2026 年 6 月 18 日更新的许可证文档对此进行了如下梳理：
| Microsoft 365 | Entra ID |
|---|---|
| E3 | Entra ID P1 |
| E5 | 包含相当于 Entra ID P1 + P2 的权限（包含 P2） |
| E7 | 除 Entra ID P2 功能外，还包含 Microsoft Entra Suite |
P1 包含在 E3/E5/E7 中，P2 包含在 E5/E7 中。E7 还进一步包含了 Microsoft Entra Suite，其适用范围扩展至私有访问（Private Access）、互联网访问（Internet Access）、身份治理（ID Governance）、身份保护（ID Protection）、Verified ID 高级功能等。
在实务中区分 P1 与 P2
| 功能示例 | P1 | P2 |
|---|---|---|
| 条件访问 | ○ | ○ |
| SSPR 写回 | ○ | ○ |
| 基于风险的条件访问 | – | ○ |
| 来自 Identity Protection 的完整风险信息 | 受限制 | ○ |
| Privileged Identity Management | – | ○ |
虽然 P1 也可以使用条件访问，但以登录风险/用户风险作为条件进行自动控制的基于风险的策略属于 P2 范畴。
登录控制流程
flowchart LR
U[利用者] --> S[Microsoft Entra sign-in]
S --> CA[Conditional Access P1+]
CA --> D{端末・場所・アプリ等}
D --> MFA[MFA要求]
D --> B[Block / Allow]
S --> R[Identity Protection P2]
R --> RR{Sign-in/User Risk}
RR --> CA
在 P1 中，可以创建诸如“来自外部网络时要求多因素身份验证 (MFA)”或“仅允许受管设备”等明确条件。在 P2 中，可以将 Microsoft 检测到的风险作为条件，从而设计出“如果登录风险高则阻止”等控制措施。
首先尝试：读取你自己的租户
在 Microsoft Entra 管理中心打开“概述”，以检查租户名称、租户 ID 和许可证。接下来，浏览用户和组以了解其配置。
最安全的方法是一开始不要修改条件访问策略。
使用 Microsoft Graph PowerShell 仅读取你自己的数据
如果是在可以使用 Graph PowerShell 的验证环境中，请使用最小的User.Read来获取你自己的信息。
Connect-MgGraph -Scopes "User.Read" $ctx = Get-MgContext $ctx | Select-Object TenantId, Account, Scopes Get-MgUser \ -UserId $ctx.Account \ -Property Id,DisplayName,UserPrincipalName | Select-Object Id,DisplayName,UserPrincipalName
查看此处
TenantId是否为预期的租户。Scopes是否User.Read是以中心为主的最小权限？是否只能获取你自己的用户？
成功标准
以读取权限连接到预期的租户，并获取你自己的 ID 信息。
修改一处
与其添加写入范围（scope），不如在Select-Object中只更改显示属性（property）。在使用 API 时，也要养成从最小权限开始的习惯。
使用 PIM 减少“常驻管理员”
sequenceDiagram
participant A as 管理者
participant P as PIM
participant C as 条件/承認/MFA
participant R as 管理者Role
A->>P: Role activationを要求
P->>C: 条件を評価
C-->>P: 承認
P-->>A: 一定時間だけRole有効
A->>R: 管理作業
P-->>A: 時間終了でRole無効
PIM 不会让管理员一直担任 Global Administrator 等角色，而是在需要时才激活（activate）权限即时（Just-In-Time，仅在需要时）用于运营。
微软官方规定，使用 PIM 需要 Entra ID P2 或 Entra ID Governance 等有效许可证。不仅拥有 eligible assignment 的用户，对于审批者和 access review 负责人员等也存在许可证条件。
实务示例：来自海外的可疑登录
在 E3/P1 环境中，可以根据位置、设备、MFA 等条件配置 Conditional Access。如果是 E5/P2，则可以利用 Identity Protection 的 risk detection，将异常登录连接到 risk-based Conditional Access。
但是，如果在全公司范围内一下子应用自动阻止，可能会将正常用户拒之门外。应使用 Report-only、验证组和 break-glass account 分阶段引入。
普通用户、文职人员及 IT 部门的确认事项
| 立场 | 确认内容 |
|---|---|
| 普通用户 | MFA 注册、登录警告、密码重置方法 |
| 文职/账户负责人 | 入职离职、调动、组、许可证分配 |
| IT 部门/安全部门 | Conditional Access、risk、PIM、审计、应急账户 |
管理员需确认的项目
检查 E3/E5/E7 或附加的 Entra SKU。
条件访问目标用户是否具备所需的 P1 及以上权限？
使用基于风险的策略的对象是否具备 P2 权限？
是否设计为不使用与普通用户相同的策略来锁定紧急访问账户（break-glass account）？
条件访问是否已从“仅报告”模式开始进行验证？
是否盘点了 Pim 目标角色和常态分配角色？
是否确认了包含 PIM 审批者和审核者在内的许可证条件？
是否梳理了 MFA/身份验证方法策略？
是否确认了登录/审计日志的保留和集成要求？
是否确认了诸如 Agent 365 等代理 ID 专属功能与面向用户的 P1/P2 存在不同的条件？
常见误解
“E3 无法使用条件访问”
E3 包含 Entra ID P1，且条件访问是 P1 的功能。
“即使在 P1 中也可以通过用户风险自动阻止”
基于风险的条件访问需要使用 Identity Protection 的 P2 功能。
“只要给所有管理员每人买一个P2就能使用PIM”
PIM对不同角色的用户有各自的许可条件，例如拥有合格角色的用户、审批者、审阅者等。
Microsoft官方信息
Entra ID P1/P2并不是“管理控制台的高级版”。通过P1基于条件进行访问控制，通过P2提升风险检测和特权管理的级别这样理解有助于更好地把握E3/E5的区别。
