Microsoft 365 用户、许可证与 B2B 来宾协同：从创建到治理的全链路实战

〇、2025 推荐身份治理架构

整篇博文的实操都围绕这张图展开：

HR 系统（Workday / SAP / 自研）
│
▼
Lifecycle Workflow（Entra ID Governance）
│ ─── 入职 / 调岗 / 离职 触发 Joiner-Mover-Leaver 流程
▼
Cloud Sync / Entra Connect Sync
│ ─── 新建混合场景优先 Cloud Sync；Exchange Hybrid / 设备写回 / 复杂过滤仍需 Connect Sync
▼
Microsoft Entra ID User
│
├── Group-based License（需要 Entra ID P1 或包含该能力的许可证）
│
├── Conditional Access（Zero-Trust Baseline）
│
├── Authentication Method Policy
│ ├── Phishing-resistant MFA
│ ├── Passkey（FIDO2 / 平台密钥，结合 TAP 完成首次注册）
│ └── Temporary Access Pass（TAP）
│
└── 资源访问
├── Microsoft 365 Groups → Teams / SharePoint / Planner / Loop
├── Security Group → Conditional Access / Intune / Power BI
├── Application → Entra Enterprise Applications
└── Distribution Group / Mail Contact → Exchange Online

一、身份模型：先选对再创建用户

Microsoft 365 的用户身份本质上是 Microsoft Entra ID 中的一个对象。Module 2 反复强调"先选模型再创建用户"，原因很简单：身份模型决定后续的认证、SSO、Conditional Access、合规边界。

三种身份模型：

2025 年的工程性变化

• Microsoft Entra Cloud Sync 对大多数新建混合场景已成为优先推荐方案；
• 但 Cloud Sync 并不完全替代 Entra Connect Sync——以下场景仍需 Connect Sync：
  • Exchange Hybrid（混合部署）；
  • 设备写回（Device Writeback）；
  • 复杂 OU / 属性过滤；
  • 部分高级同步能力（如 Group Writeback）。
• Passkey（FIDO2 / 平台密钥） 已完全 GA，Microsoft 鼓励把所有管理员账户升级到 Phishing-resistant MFA；
• Cross-Tenant Sync 让多子公司场景不再需要 ADFS 信任链，直接跨租户同步用户/组；
• Temporary Access Pass（TAP） 让新员工入职当天即可"无密码登录 → 设置 Passkey"——管理员应通过 Authentication Methods Policy 控制允许的认证方式。
• Authentication Strength（认证强度）：Conditional Access 2023 GA、2024–2025 大规模采用，可针对不同资源强制不同强度（"Passwordless + MFA" / "Phishing-resistant MFA" / "Multifactor" 等）；
• Authentication Method Reports & Insights：管理员可通过 Entra → Protection → Authentication Methods 看每个方法的注册率 / 使用率，是评估 Passkey 推广进度的重要工具。

二、创建用户：4 种主流方式对比

1. CSV 批量导入的关键字段

CSV 模板必须包含的列（简化版）：

User Name,First Name,Last Name,Display Name,Job Title,Department,Office Number,Office Phone,Mobile Phone,Fax,Address,City,State,ZIP/Postal Code,Country or Region,Usage Location,User Type,Domain Name,Password

• Usage Location 一定不能省略——这是触发某些区域受限服务许可证（如 Teams 电话、Copilot 区域可用性）开关的关键字段；
• User Type 默认为 Member；
• 关于 Password 字段：是否自动生成初始密码由导入向导决定，不是单纯"CSV 留空 = 自动生成"。导入完成后，可下载包含初始密码的结果文件，请妥善保存。

2. PowerShell 批量创建（Graph SDK 推荐）

Import-Module Microsoft.Graph.Users

$params = @{
accountEnabled = $true
displayName = "Ada Liu"
mailNickname = "adaliu"
userPrincipalName = "adaliu@contoso.com"
passwordProfile = @{
forceChangePasswordNextSignIn = $true
password = (New-Guid).Guid + "Aa1!"
}
usageLocation = "CN"
jobTitle = "Senior PM"
department = "Engineering"
}

New-MgUser -BodyParameter $params

三、用户生命周期：删了之后 30 天还能救——但要分清"恢复对象"和"恢复数据"

1. 删除用户的"软删除"机制

• 用户被删除后，分配的 M365 许可证立即释放（License Slot 不需要等 30 天）；
• 账号进入 soft-deleted 状态 30 天，期间任何登录被拒绝，但管理员可以恢复；
• 30 天后变为 hard-deleted，Entra ID 中的用户对象永久删除，无法直接恢复。

2. "恢复"到底恢复什么？

⚠️ 必须区分两个完全不同的概念：

实际工程中超过 30 天的场景：

• Entra ID 用户对象：重新创建；
• 业务数据：从 Microsoft 365 Backup 或第三方备份还原；
• License、组成员关系：重建。

3. 恢复操作（30 天内）

# 查看已删除用户
Get-MgDirectoryDeletedItem -DirectoryObjectId <objectId>

# 恢复 Entra ID 用户对象
Restore-MgDirectoryDeletedItem -DirectoryObjectId <objectId>

⚠️ 恢复后的会话与 Token 处理：恢复后的用户必须重新登录才能使用 M365，旧的 Refresh Token / 浏览器会话 / 移动设备缓存全部失效。如果该用户在被删除前存在已登录的设备会话，需要：

• 调用 Revoke-MgUserSignInSession 强制使旧 Token 失效；
• 通知用户在新设备或重新登录后建立新会话；
• 复核 Conditional Access 是否对恢复用户仍正确应用。

4. 离职流程 Checklist

四、许可证分配：2025 年最常见的几类问题

1. "我买了 E5，为什么有些功能还是用不了？"

最常见原因：

• 该用户没被分配 E5，而是只被分配了下层 E1/E3；
• 该 Service Plan 被单独禁用（例如某些公司为节省成本关闭了"电话会议"）；
• 用户 Usage Location 未设置，某些国家/区域的服务计划不会启用；
• 该用户走的是 Direct assignment，需要重新基于组（Group-based licensing） 分配。

2. 基于组的许可证分配（推荐）

📌 前置条件：Group-based licensing 需要 Microsoft Entra ID P1 或包含该能力的许可证（如 M365 E3 / E5、EM + E5 等）。

# 需要 Microsoft Graph PowerShell SDK
# 权限：LicenseAssignment.ReadWrite.All
$sku = Get-MgSubscribedSku | Where-Object SkuPartNumber -eq "ENTERPRISE_E5"
Set-MgGroupLicense -GroupId <groupId> `
-AddLicenses @(@{SkuId = $sku.SkuId}) `
-RemoveLicenses @()

好处：

• 用户入职/调岗自动生效；
• 与 Microsoft Entra ID Governance 的 Access Package + Lifecycle Workflow 联动可实现全自动；
• 报表、计费、回滚简单。

🔄 重要机制细节：Group-based Licensing 并不会"绕开"用户 License 的本质——组作为授权聚合层，最终每个用户仍会写入 assignedLicenses 字段（User 对象上的实际授权）。也就是说：

• 计费仍按"实际分配 License 的用户数"计；
• Get-MgUser -PropertyId assignedLicenses 仍能看到用户实际持有的 Service Plan；
• 组的角色是"驱动授权的容器"，不是 License 的存放位置。

五、B2B 来宾协同：把外部人员"装进"你的 Entra ID

1. B2B 的本质

Microsoft Entra B2B 让外部用户以"guest"身份存在于你的租户里：

• 不复制用户凭据——外部用户用自己的 IdP（Google、Facebook、企业 AD、组织账号…）；
• 来宾账户是 Entra ID 中的一个 User 对象，userType=Guest；
• 可以加入安全组（Security Group）、Microsoft 365 Group，并因此访问 Teams、SharePoint、Planner、Loop、Power BI 等资源（前提是相应服务支持 Guest）；
• 资源支持的边界：部分旧应用、第三方 SaaS、特定自定义角色可能不直接支持 Guest，需要评估。

2. 来宾权限默认级别

B2B 来宾在目录里的默认权限为 Limited access（远低于 Member）。管理员可在 Entra 管理中心 → External Identities → External collaboration settings 中调整为：

• Same as member users（极少使用，等于完全信任）；
• Restricted access（默认之上进一步限制——例如来宾不能枚举其他用户）。

2025 年新引入的 External Collaboration Settings 还多了"信任 MFA 状态跨租户传递"等新能力，可以避免外部合作伙伴在每次邀请时再 MFA 一次。

3. 邀请来宾的方式与对象生命周期

正确的邀请与授权逻辑：

邀请阶段
│
▼
Guest 对象在租户中创建（userType=Guest）
│
▼
管理员/Owner 授予对特定组、应用、Teams、SharePoint 站点等资源的访问权限

也就是说：先有 Guest 对象，再授予资源访问。"邀请到某个组/应用"实际上是"邀请 → 创建 Guest → 加入到组/应用"两阶段动作。

邀请入口：

• Entra 管理中心：手动填邮箱发邀请；
• Graph API：自动化；
• Self-service sign-up via user flow：为应用/资源开启注册流，外部用户自助注册（适用于社区、合作伙伴门户）；
• SharePoint / Teams 站点：在站点成员页面直接邀请（实际仍是先创建 Guest，再加入站点）。

# 通过 Microsoft Graph 邀请来宾
$invitation = @{
invitedUserEmailAddress = "partner@example.com"
inviteRedirectUrl = "https://myapp.contoso.com/welcome"
invitedUserDisplayName = "Partner User"
sendInvitationMessage = $true
}
New-MgInvitation -BodyParameter $invitation

4. 来宾的"退出"机制

来宾账户不会自动过期。Access Review 是主要的清理机制：

• 可以按组织策略设置为每月、每季度、每半年等周期自动复核（90 天是常见实践，但不是默认值）；
• Access Review 结束后具体行为取决于 Access Review 的完成设置（Completion Settings）：可配置为"自动批准"、"自动拒绝"、"自动移除访问权限"等不同策略；
• 也可以手动清理长期不活跃来宾。

5. Cross-Tenant Access Settings

未显式配置 Cross-Tenant Access Settings 时，双方租户将采用默认跨租户访问策略（Allow + Default Settings），而不是自动阻止。

企业应根据业务伙伴关系显式配置：

• Inbound Trust：外部用户登录时是否信任其 IdP 的 MFA 状态；
• Outbound Access：本租户用户访问外部租户资源的策略；
• MFA Trust：跨租户 MFA 是否互认。

这样才能实现精细化的跨组织访问控制。

6. 区分：Cross-Tenant Synchronization vs HR Provisioning

2024–2025 年 Entra ID 引入的两个容易混淆的能力：

• CTS 主要解决"租户间身份打通"，不是 HR 源；
• HR Provisioning 才是把 Workday 等作为权威源，自动驱动 Entra ID 用户创建 / 更新 / 停用；
• Salesforce Provisioning 则属于 SaaS 应用层的 Outbound Provisioning，把 Entra 用户同步到 Salesforce；
• 实施时不要把 CTS 当成 HR 集成来用，两者是不同的能力。

六、与外部协作的安全默认值（2024–2025）

微软已经把以下能力演进为 GA / 默认推荐：

• 来宾邀请的 MFA 满足 跨租户信任 时不再重复验证；
• External Identities Cross-Tenant Access Settings 应根据业务伙伴关系显式配置；
• B2B 同步（B2B Sync） 让 SaaS 应用的来宾账号可以从外部系统（如 Workday、Salesforce）同步；
• Teams Shared Channels（跨组织共享通道）已 GA，是真正的"外部协同"主力。

来宾激增 ≠ Consent Phishing

来宾数量异常增加应结合 Audit Log、Entra Sign-in Logs、Enterprise Applications、Consent Activity 等进一步分析，而不是直接判定为 Consent Phishing。可能原因包括：

• 大规模项目上线（B2B Sync 自动邀请）；
• Teams 站点成员扩容；
• 合作伙伴门户 Self-service Sign-up 触发；
• 真正的 Consent Phishing 攻击。

GAL 中 Guest 的可见性

根据组织策略决定是否将 Guest 隐藏在地址列表（GAL）中，并定期检查该配置：

• 默认情况下 Guest 通常不作为 GAL 的重要成员出现，但并非"自动隐藏"；
• 安全起见，建议显式设置 Guest 隐藏 GAL。

📌 属性归属澄清：HiddenFromAddressListsEnabled 是 Exchange Online Recipient 属性（通过 Exchange Online 管理，而非 Entra ID User 对象属性）。也就是说：

• 该属性的设置位置在 Exchange 管理中心 / Exchange Online PowerShell（如 Set-MailUser -HiddenFromAddressListsEnabled $true）；
• Entra ID → Users 界面看不到，但 Exchange GAL 渲染时会读取；
• B2B Guest 在 Entra 中是 User 对象，在 Exchange 中是 MailUser 对象，因此走的是 Set-MailUser 或 Set-Recipient 而不是 Set-MgUser。

七、Mail Contacts：Exchange Online 里的"地址簿名片"

邮件联系人（Mail Contact）与 B2B 来宾的区别：

关键澄清：Mail Contact 不创建可登录的 Entra ID 用户对象，仅用于邮件通讯录和邮件路由；这与 B2B Guest（创建可登录对象）是本质区别，而不是"占不占用户额度"的问题。

联系人可在 新 Exchange 管理中心 / 经典 EAC / Exchange Online PowerShell 中管理，所需权限：Recipient Management / Organization Management / Mail Recipients 之一。

# 新建联系人
New-MailContact -Name "John Doe (Vendor)" `
-ExternalEmailAddress "john.doe@vendor.com" `
-DisplayName "John Doe"

💡 何时用 Contact，何时用 B2B Guest：

• 只需对方收 / 发邮件且不需要任何 M365 协作 → Mail Contact（更轻量、不创建可登录对象）；
• 需要对方加入 Teams / SharePoint / Loop 工作区 / Power BI → B2B Guest；
• 混合场景：一家供应商的主要联系人作为 Mail Contact（频繁邮件往来），同时为该公司 IT 接口人开 B2B Guest（协同项目）。两者不互斥，可以共存。

八、运营 Checklist

•  身份模型（Cloud-only / Hybrid / Federated）已明确，混合场景已评估 Cloud Sync vs Entra Connect Sync；
•  Cloud Sync / Entra Connect 已稳定同步超过 7 天（这是企业建议的稳定性观察窗口，并非产品硬性要求，但有助于识别早期同步异常）；
•  所有用户 Usage Location 已设置；
•  许可证按组（Group-based licensing）分配，Entra ID P1 或以上许可证已具备；
•  Passkey + TAP 已为所有管理员开启，Authentication Methods Policy 已收紧；
•  B2B 来宾策略：默认 Limited + 周期性 Access Review；
•  来宾 GAL 可见性已显式配置（HiddenFromAddressListsEnabled）；
•  离职流程已脚本化：30 天内可恢复 Entra ID 对象；超过 30 天重新创建 + 从备份恢复数据；
•  Mail Contacts 与 B2B Guest 按业务场景分类使用，联系人定期清理过期项；
•  Cross-Tenant Access Settings 已按业务伙伴关系显式配置。

九、与 Operational Excellence 的连接

用户与来宾的管理最终要落到 Operational Excellence 上：

• Daily 巡检：Sign-in Risk / Service Health；
• Weekly 巡检：
  • Get-MgUser -Filter "userType eq 'Guest'" 统计来宾数量变化；
  • 未激活 License 用户清单 → License 浪费报告；
• Monthly 巡检：来宾激增、Consent Grant 异常、应用风险评分；
• Quarterly 巡检：Access Review、Conditional Access 策略审计、PIM 角色复核；
• Yearly：完整 User / Group / Guest 配置审计 + Backup Restore 演练。