mcpField
E
entra-id

entra-id

github.com/vinayaklatthe安全17887 次安装19 周前更新
代码仓库

关于 entra-id

面向 Microsoft Entra ID 管理员的身份与访问管理技能，涵盖租户基础、混合身份、身份验证和应用治理。提供建立安全基线及规划常见身份控制的指导。

主要功能

  1. 01规划租户与身份模型
  2. 02配置混合身份同步
  3. 03规划抗钓鱼身份验证
  4. 04管理应用与授权同意
  5. 05配置自助服务和紧急账户

适用场景

  1. 01设计 Entra Cloud Sync 混合身份方案
  2. 02规划用户从密码迁移到通行密钥
  3. 03配置紧急访问账户与监控
  4. 04降低应用授权同意风险

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/vinayaklatthe/microsoft-security-skills --skill entra-id

安装后在 Claude Code 中输入/entra-id确认已加载。

详细介绍

Microsoft Entra ID

Microsoft Entra ID（前身为 Azure Active Directory）是云身份和访问管理服务，用于对用户、设备和工作负载进行身份验证。它是零信任的控制平面，也是其他所有 Microsoft 安全控制正常运行的基础。

适用场景

建立身份基础：租户、用户/组、身份验证方法、应用单点登录，以及与本地 Active Directory 的混合身份。请在配置条件访问、身份保护或 PIM 之前使用此技能——这些功能都以干净的 Entra ID 基线为前提。

此技能不适用于基于风险的登录检测（entra-id-protection）、策略强制（conditional-access-mfa）、实时管理员角色（azure-pim）或生命周期工作流（entra-id-governance）。

将身份目标映射到合适的 Entra 控制

如果目标是……使用说明
将本地 AD 用户同步到云端Entra Cloud Sync（新部署优先）或 Entra Connect SyncCloud Sync 更轻量，无需服务器场
将登录联合到本地环境AD FS（旧版）或 Pass-Through Authentication避免新部署 AD FS；优先选择 PHS + WHfB
替代密码Passkeys (FIDO2) > Windows Hello for Business > Microsoft Authenticator 无密码身份验证仅限抗钓鱼方式
单点登录 SaaSEnterprise Applications（库应用或非库应用）在支持的情况下优先使用 OIDC，而非 SAML
自助式密码重置SSPR，并启用云写回（混合环境）需要 Entra ID P1
将管理员权限委派并限定到某个区域/业务部门Administrative Units结合自定义角色，实现最小权限
应用调用 Microsoft Graph 或其他 APIApp Registration + 委派权限/应用程序权限对高风险范围要求使用管理员许可工作流
如果 MFA 出现故障，仍可访问租户Break-glass accounts（2 个仅限云端的账户，从 CA 中排除）仅使用硬件 FIDO2；每次登录都发出警报

**经验法则：**如果你打算在 2026 年将用户名和密码输入 Microsoft 服务，请停下来。改用 Passkeys 或 WHfB。密码重复使用加上网络钓鱼，仍然是身份安全事件响应中最主要的根本原因。

方法

  1. 租户与身份模型 — 决定采用纯云端还是混合模式。为用户、组（分配型或动态型）和管理单元定义命名约定。默认在租户级别阻止来宾邀请；按协作场景单独允许。 验证：Get-MgPolicyAuthorizationPolicy 显示默认用户的 allowedToCreateApps = false；已启用管理员同意工作流。

  2. 混合身份 — 新部署请选择 Entra Cloud Sync（基于代理、轻量，支持断开连接的林）。仅当你需要 Cloud Sync 尚不支持的 PHS + 回写功能时，才使用 Entra Connect Sync。避免新建 AD FS 部署——它会增加本地依赖和攻击面（需要 MDI 传感器）。 验证：Get-MgDirectoryOnPremisesSynchronization 显示同步运行正常；已启用密码哈希同步。

  3. 身份验证方法 — 转向抗网络钓鱼方法 — 通过身份验证方法策略管理（取代旧版 MFA + SSPR 注册策略）。按以下顺序推出：Authenticator（推送通知 + 数字匹配）→ 受管理设备上的 WHfB → 管理员使用 FIDO2 密钥 → 全面推广密钥。禁用 SMS 作为主要方法。 验证：User Registration Details 报告显示，超过 90% 的用户至少有一种抗网络钓鱼方法。

  4. 应用与同意治理 — 在可用时使用应用库进行 SSO。启用管理员同意工作流，让用户申请高风险权限，而不是自行授予。每月运行风险应用报告。应用最小权限原则管理 Graph 权限，并审核应用凭据（机密、证书或联合身份）。 验证：已同意的应用中，没有任何应用在批准列表之外拥有 Application.ReadWrite.All 或 Directory.ReadWrite.All。

  5. 自助服务与生命周期 — 为混合用户启用带回写功能的 SSPR。配置 My Account / My Apps。使用动态组，根据属性（部门、国家/地区、employeeType）确定成员资格。

  6. 紧急访问帐户 — 创建两个仅限云端的紧急访问帐户。从所有条件访问策略中排除这些帐户。仅使用 FIDO2 硬件密钥进行身份验证，并将密钥分别存放在不同的实体位置。通过 Sentinel 对每次登录发出警报。 验证：每月使用每个紧急访问帐户进行登录测试；警报会在 5 分钟内触发。

  7. 阻止旧式身份验证和弱方法 — 使用条件访问（单独的技能）阻止旧式身份验证协议（POP、IMAP、SMTP AUTH、基本身份验证）。禁用 SMS / 语音作为主要 MFA 方法。

防护措施

  • 紧急访问帐户至关重要。 必须有两个，仅限云端，使用 FIDO2 硬件密钥，从每项 CA 策略中排除，并监控每次登录。每月测试。如果跳过此步骤，CA 配置错误可能导致你失去租户访问权限。
  • 避免新建 AD FS 部署。 它依赖本地身份基础设施，会增加攻击面和维护负担。PHS + WHfB 几乎可以满足所有需求。
  • 阻止旧式身份验证。 POP、IMAP、SMTP AUTH 和基本身份验证都能绕过 MFA。通过条件访问进行阻止，然后监控登录日志 30 天，排查仍在使用这些方式的情况。
  • 管理应用同意。 攻击者会利用非法同意授权在密码重置后继续潜伏。启用管理员同意工作流并审核风险应用报告。
  • 不要将基于组的许可作为管理员帐户的唯一分配方式。 如果组同步中断，管理员将失去许可证和访问权限。对紧急访问帐户和第 0 层管理员直接分配许可证。
  • 新建环境优先选择 Cloud Sync，而非 Connect Sync。 它更轻量，无需服务器场，故障模式也更少。

常见反模式

  • “我们用 SMS 进行 MFA——这已经够用了”——SMS 容易遭受网络钓鱼攻击，也容易被通过 SIM 卡调换攻击。只能将其视为恢复验证因素，绝不能作为主要验证因素。
  • “在 Keepass 中放一个紧急访问账户”——这会造成单点故障，且无法审计。应设置两个由不同人员保管硬件密钥的账户。
  • “通过 AD FS 联合登录，因为我们一直都是这么做的”——在 2026 年，这会增加成本和风险。除非有特定的联合身份验证需求，否则应改用 PHS + Conditional Access。
  • “允许用户为所有权限授予应用同意”——租户中会堆积已获同意但存在风险的应用。请启用管理员同意工作流。
  • “不用管 Administrative Units，直接使用全局管理员即可”——这会破坏职责分离并绕过 RBAC。请将帮助台和区域管理员的权限范围限定到 AU。
  • “先禁用安全默认值，Conditional Access 过一周再配置”——在这段间隔期间，租户将完全暴露。请先启用 CA 策略，再禁用安全默认值。

示例提示词

  • 设计一个采用 Entra Cloud Sync 和密码哈希同步的混合身份模型。
  • 规划将 5,000 名用户从密码迁移到通行密钥的推广方案。
  • 为我们的 Entra 租户配置紧急访问账户和监控警报。
  • 让用户不再使用 SMS MFA——迁移路径是什么？
  • 防止在我们的 Entra ID 租户中非法授予同意。
  • 为混合环境配置带回写功能的 SSPR。
  • 委派管理时，什么时候应该使用 Administrative Units，什么时候应该使用自定义角色？

Microsoft Learn

评论

支持 Markdown