无密码身份验证通过将密码替换为更强大的登录方法（如 Windows Hello、FIDO2 安全密钥、通行密钥、证书、Microsoft Authenticator 手机登录和临时访问通行证）来减少网络钓鱼和凭据盗窃。
Microsoft Intune 不颁发无密码凭据。 相反，它准备设备、应用和用户体验，以便这些无密码方法能够可靠地大规模工作。 Microsoft Entra ID 是验证凭据并强制实施身份验证和条件访问策略的标识颁发机构，而 Microsoft Intune 则配置设备设置、强制实施合规性并启用这些方法所依赖的平台功能。 Microsoft Entra ID 和 Microsoft Intune 共同提供跨不同平台和外形规格采用无密码身份验证所需的标识基础和设备就绪性。
无密码体验因平台而异。 在 Windows 上，它通常跨越设备登录和通过 SSO 访问应用。 在 macOS 上，它侧重于平台身份验证和对应用的 SSO，而不是与设备绑定的深度标识。 在iOS/iPadOS 和 Android 上，它更侧重于应用登录、代理身份验证和密钥行为，而不是设备登录。 在评估平台需求和规划部署时，请牢记这些区别。
本文从管理员的角度介绍 Microsoft Intune 如何支持无密码策略。 有关部署详细信息，请遵循每个无密码方法的实现链接。
Microsoft 的无密码解决方案如何工作
Microsoft 的无密码解决方案将Microsoft Entra ID用于标识和单一登录 (SSO) 与用于设备配置和策略强制执行的Microsoft Intune配对。 通过这种组合，用户无需输入密码即可使用强凭据（如生物识别、FIDO2 安全密钥或密钥）进行身份验证。
Microsoft Entra ID 是核心标识提供者。 它验证无密码凭据，如 Windows Hello PIN、FIDO2 密钥和密钥。 身份验证成功后，Microsoft Entra ID 将颁发主刷新令牌 (PRT) 或等效令牌，从而实现无缝 SSO 以Microsoft 365、Azure和其他受保护的资源。 条件访问策略在授予访问权限之前评估设备状态、身份验证强度和风险信号。
Microsoft Intune 通过配置设置、强制执行合规性、部署所需的应用以及支持大规模使无密码实用的平台体验来为无密码登录准备设备。 Microsoft Intune 为管理员提供了适用于 Windows、macOS、iOS/iPadOS 和 Android 的一个管理平面。
Windows、macOS、iOS 和 Android 上的平台功能提供设备绑定体验，包括生物识别、Windows 上的安全硬件 (TPM、macOS) 上的安全 Enclave、密钥支持和代理单一登录。
这种分离很重要。 Microsoft Entra ID 是标识颁发机构。 Microsoft Intune 是帮助用户成功采用和使用这些方法的管理层。
无密码、MFA 和防网络钓鱼
无密码身份验证并不能消除安全因素。 大多数无密码方法实际上都满足多重身份验证 (MFA) 要求。 例如，Windows Hello使用设备绑定凭据 (所有) 与生物识别手势 (固有) 或 PIN (知识) 配对，从设计上满足 MFA。 因此，条件访问身份验证强度策略将许多无密码方法分类为 符合 MFA 甚至 防 钓鱼 MFA。
并非所有无密码选项都提供相同级别的保护。 了解 防网络钓 鱼方法和 非防网络钓 鱼方法之间的区别有助于您选择正确的身份验证强度并设计安全的身份策略。
- 防网络钓鱼 方法使用无法拦截或重播的硬件绑定非对称加密密钥 - 即使用户与恶意或欺骗性提示交互也是如此。
- 非防网络钓 鱼的方法使用无密码流，但仍可能通过社交工程、提示操作或 MFA 疲劳受到损害。
本文稍后介绍的每种方法都包括其网络钓鱼防护等级。
了解更多
使用 Microsoft Intune 进行无密码身份验证的好处
将 Microsoft Intune、Microsoft Entra ID 和平台功能结合使用时，组织将获得：
- 无缝单点登录：用户登录设备一次，即可自动访问应用、云服务，在某些情况下还会自动访问本地资源。 消除了密码重置调用和重复的身份验证提示。
- 跨设备的用户便利性：用户可以跨设备获得原生、一致的体验。 Windows Hello 使用操作系统登录，macOS 将触控 ID 与 Microsoft Entra ID 集成，移动平台使用 Microsoft Authenticator 和平台密钥。 用户无需为每个设备处理单独的密码。
- 更强大的安全态势：防网络钓鱼方法可防止凭据盗窃和重放攻击。 设备合规性门控可确保即使是有效的凭据也只能在正常的托管设备上工作 - 符合零信任原则。
- 减少 IT 支持负载：更少的密码重置、通过 Temporary Access Pass 更顺畅的载入以及自助恢复选项可减少支持人员工作量。
- 面向未来的体系结构：随着标准的发展，新的无密码方法（包括同步的密钥和硬件支持的凭据）可以插入到同一 Microsoft Entra ID + Microsoft Intune 体系结构中，而无需重新设计。
Microsoft Intune 如何推动无密码采用
Microsoft Intune 通过确保正确配置设备和应用程序为使用强大的新式凭据来启用和实施无密码身份验证。 Microsoft Entra ID 管理标识和身份验证策略，而 Microsoft Intune 准备无密码方法依赖的设备环境。
主要贡献包括：
- 设备就绪情况：注册、注册和配置设备，以便它们可以参与无密码登录流。
- 配置部署：提供 Windows Hello 企业版、基于证书的身份验证、Apple 平台 SSO 和类似平台功能所需的策略。
- 合规性和访问信号：提供条件访问在授予访问权限之前评估的设备运行状况和合规性数据。
- 应用和代理预配：部署支持标识代理和无密码 SSO 方案的核心应用程序，例如 Microsoft Authenticator 和 Microsoft Intune 公司门户。
- 统一跨平台管理：跨 Windows、macOS、iOS/iPadOS 和 Android 提供一致的策略和管理框架，以简化企业部署。
用户可用的无密码方法取决于设备平台和 Microsoft Entra ID 中启用的身份验证选项。 Microsoft Intune 确保每台设备都准备就绪、配置完毕，并能够提供安全可靠的无密码体验。
Windows Hello
防网络钓鱼
Windows Hello 将密码替换为设备绑定的非对称密钥，该密钥已生成并密封到 TPM。 对密钥的访问通过 PIN 或生物识别手势 (指纹或面部识别) 控制，在单个登录步骤中结合所有权和固有性。 此方法有硬件支持，适用于 Windows 设备，可防止网络钓鱼攻击。
Intune 的角色
Microsoft Intune 通过传递和强制实施 Windows Hello 企业版策略设置来为 Windows Hello 准备 Windows 设备。在需要执行以下操作时，此方法最相关：
- 为无密码登录准备云优先的 Windows 设备。
- 在注册和持续管理期间提供 Windows Hello 企业版策略设置。
- 使 Windows 登录与设备合规性和现代管理保持一致。
FIDO2 安全密钥
FIDO2 安全密钥是 (USB、NFC 或蓝牙) 的物理设备，它们存储 FIDO 凭据并提供防钓鱼身份验证，而不依赖于设备平台。 由于凭据绑定到硬件密钥并通过加密质询进行验证，因此无法拦截或重播。 FIDO2 密钥非常适合共享设备、高保证环境或与基于平台的凭据一起作为恢复路径。
Microsoft Intune 可以通过管理支持的平台和相关的登录体验来帮助设备为此方法做好准备。当组织需要以下情况时，此方法通常非常适合：
- 适用于共享或专用设备的便携式无密码选项。
- 强大的防网络钓鱼选项，不绑定到单个平台或 Microsoft Authenticator。
- 恢复或备用路径以及基于平台的凭据。
通行密钥
密钥是基于标准的 FIDO 凭证保护伞，可以绑定设备或跨设备同步。 在 Microsoft Entra ID 中，可以使用：
- 存储在单个设备上 (TPM 或安全 Enclave) 中的设备绑定密钥，例如通过 iOS 17+ 和 Android 14+ 上的 Windows Hello 或 Microsoft Authenticator。
- 由平台密码管理器管理的同步密钥， (如 iCloud 钥匙串或 Google 密码管理器) 或支持的第三方提供商管理，从而支持跨设备使用。
- Windows 上的 Microsoft Entra 密钥是一种 FIDO2 密钥，使用 Windows Hello 进行生物识别验证，但不需要设备加入或注册。 用户可以在同一设备上为多个 Microsoft Entra 帐户注册多个密钥，使其非常适合共享设备、非托管终结点以及未预配 Windows Hello 企业版的方案。
从 Microsoft Intune 的角度来看，密钥主要与平台和应用就绪情况有关，即管理设备和应用先决条件，使密钥在各个平台上可行。这种依赖关系对于以下方面尤为重要：
- 其中，平台登录和 Windows Hello 可以与更广泛的无密码规划相交。 Windows 上的 Microsoft Entra 密钥将密钥覆盖范围扩展到未注册或加入的设备，对托管设备上的 Windows Hello 企业版起到补充作用。
- iOS/iPadOS 和 Android，其中密钥可能取决于移动设备状态和应用代理行为。
- macOS，其中平台标识集成和用户登录体验塑造了采用率。
Microsoft Authenticator 手机登录
不防网络钓鱼
Microsoft Authenticator 手机登录在用户的受信任移动设备上通过基于推送的批准和号码匹配替换密码。 它很方便并且受到广泛支持，但依赖于推送通知而不是硬件绑定凭据，这意味着它不能完全防止网络钓鱼攻击，例如 MFA 提示操纵。
注意
Microsoft Authenticator 还可以 存储 iOS 17+、Android 14+) (设备绑定密钥 ，这些密钥 具有防网络钓鱼功能。 本节专门介绍基于推送的手机登录流程。
Microsoft Intune 通过部署和管理移动应用和设备先决条件来支持此流程。在许多环境中，此支持包括：
- 将 Microsoft Authenticator 部署到托管移动设备。
- 支持跨 Microsoft 应用的代理登录体验。
- 考虑移动平台上的应用保护策略注意事项，如果这些是更广泛的移动访问设计的一部分。
临时访问通行证
临时访问通行证 (TAP) 是管理员颁发的限时凭据，用于帮助用户在完成长期无密码设置之前引导或恢复访问权限。 TAP 不是一种永久性的无密码方法，也不防网络钓鱼，但它通常是成功推出的关键部分，因为它无需颁发密码即可解决首次登录问题。
从 Microsoft Intune 的角度来看，临时访问通行证在你想要执行以下操作时非常重要：
- 简化无密码方法的载入。
- 减少部署期间对临时密码的依赖。
- 将载入方案连接到托管 Windows 设备安装程序。
使用 TAP 进行零天载入
无密码部署中的一个常见挑战是先 有鸡还是先有蛋的问题 ：新用户需要登录以注册其无密码凭据，但你不希望为首次登录颁发密码。 TAP 通过为初始设备设置和凭据注册提供短期凭据解决了这一问题。
典型的载入流如下所示：
- 管理员发出 TAP - IT 管理员或自动化工作流在 Microsoft Entra 管理中心中或通过 Microsoft 图形 API 为新用户生成限时 TAP。
- 用户设置其设备 - 用户在 Windows Autopilot OOBE、macOS 设置助手或移动设备注册期间输入 TAP。 在 Windows 11 上，Web 登录可以直接在锁屏界面上输入 TAP。
- 用户注册无密码方法 - 使用 TAP 登录后，系统会提示用户注册 Windows Hello、FIDO2 安全密钥、Microsoft Authenticator 中的密钥或其他无密码方法。 这是替换 TAP 的永久凭据。
- TAP 过期 — TAP 是一次性或限时 (可配置) ，因此在用户注册其无密码方法后无法重复使用。
此流无需颁发然后吊销临时密码，并为 Microsoft Intune 提供从首次登录开始的托管载入路径。
基于证书的身份验证 (CBA)
基于证书的身份验证 (CBA) 使用数字证书和非对称加密来验证身份，从而防止网络钓鱼并防止凭据重播。 它在受监管的行业和政府环境中得到广泛采用，通常通过 PIV 和 CAC 等智能卡。 与 Microsoft Intune 主要准备设备环境的其他无密码方法不同，CBA 是 Microsoft Intune 在分发凭据本身方面直接发挥作用的一个领域。
Microsoft Intune 支持两种基础结构模型以提供证书：
- 本地 PKI：现有证书颁发机构 (CA) 的组织可以使用适用于 Microsoft Intune 的证书连接器桥接其本地 PKI 和 Microsoft Intune。 该连接器使 Microsoft Intune 能够使用现有 CA 基础结构将 SCEP 和 PKCS 证书配置文件部署到托管设备。 此模型适合已在运营企业 CA 或需要与已建立的 PKI 投资集成的组织。
- Microsoft 云 PKI：对于希望简化或消除本地证书基础结构的组织，Microsoft 云 PKI 提供基于云的 CA 作为 Microsoft Intune Suite 的一部分。 云 PKI 发行和管理证书，而无需本地服务器、连接器或硬件安全模块。
无论基础结构模型如何，Microsoft Intune 都使用证书配置文件将证书传递到设备：
- 受信任的根证书配置文件 分发 CA 的根证书，以便设备可以建立信任链。
- SCEP 证书配置文件 从启用 SCEP 的 CA 请求和部署证书。
- PKCS 证书配置文件 使用 PKCS #12 标准请求和部署证书。
- 导入的 PFX 证书配置文件将部署导入到 Microsoft Intune 的预生成证书。
这些配置文件可跨 Windows、macOS、iOS/iPadOS 和 Android 工作，使 Microsoft Intune 成为将 PKI 基础结构（无论是本地还是基于云）连接到 Microsoft Entra ID 中定义的标识方法的交付机制。
先决条件
在计划无密码部署之前，请验证您的环境是否满足预期使用的方法的许可和平台要求。 某些无密码功能需要特定的 Microsoft Entra ID 或 Microsoft Intune 许可证层，并且每种方法都有最低操作系统版本要求。
许可要求
根据所选的无密码方法，你的组织可能需要为用户提供 Microsoft Entra ID P1 或 Microsoft Entra ID P2 许可证，以及用于设备管理和证书传递的特定 Microsoft Intune 许可证。 下表总结了常见无密码功能的许可要求：
| 功能 | 许可证要求 |
|---|---|
| Windows Hello | Microsoft Entra ID P1 (条件访问强制) |
| FIDO2 安全密钥 | Microsoft Entra ID P1 |
| (设备绑定和同步) 的密钥 | Microsoft Entra ID P1 |
| Microsoft Authenticator 手机登录 | Microsoft Entra ID P1 |
| 临时访问通行证 | Microsoft Entra ID P1 |
| 基于证书的身份验证 (CBA) | Microsoft Entra ID P1 (P2 适用于基于风险的条件访问) |
| 身份验证强度策略 | Microsoft Entra ID P1 |
| 基于风险的条件访问 | Microsoft Entra ID P2 |
| Microsoft 云 PKI | Microsoft Intune Suite 或独立云 PKI 许可证 |
| 设备合规性和配置文件 | Microsoft Intune 计划 1 |
了解更多
平台要求
本文所述的无密码方法依赖于仅在某些操作系统版本中可用的特定平台功能。 下表总结了每种方法的平台要求：
| 方法 | Windows | macOS | iOS/iPadOS | Android |
|---|---|---|---|---|
| Windows Hello | 所有 受支持 的 Windows 客户端 | — | — | — |
| FIDO2 安全密钥 | 所有 受支持 的 Windows 客户端 | — | — | — |
| 通行密钥 | Windows 11 | 支持的所有版本 | 支持的所有版本 | Android 14+ |
| Microsoft Authenticator 中的设备绑定密钥 | — | — | 支持的所有版本 | Android 14+ |
| 平台 SSO (Secure Enclave) | — | 支持的所有版本 | — | — |
| Web 登录 (点击锁屏界面) | Windows 11 | — | — | — |
| Microsoft Authenticator 手机登录 | — | — | 支持的所有版本 | Android 11+ |
注意
支持是指 Microsoft Intune 当前支持用于完整功能、策略部署和管理的操作系统版本。
平台版本要求可能随每个发布周期而变化。 始终验证产品文档中针对正在部署的特定方法的当前要求。
了解更多
平台注意事项
无密码不是一个功能。 它是一组特定于平台的体验，依赖于 Microsoft Entra ID 进行标识，依靠 Microsoft Intune 进行设备管理。
Windows
Windows 是设备注册、云登录、安全态势和无密码用户体验如何协同工作的最完整示例。
Microsoft Intune 通常通过以下方式支持 Windows 无密码方案：
- 准备已加入云优先的 Microsoft Entra 设备。
- 提供 Windows Hello 企业版配置。
- 支持 FIDO2 安全密钥体验。
- 使设备就绪性与合规性和现代管理保持一致。
- 支持可连接到 Windows Autopilot 的载入体验。
当用户使用 Windows Hello 或 FIDO2 密钥登录时，Windows 将从 Microsoft Entra ID 获取主刷新令牌。 该 PRT 可实现到 Microsoft 365 应用、SaaS 应用程序以及本地资源（如文件共享）的无缝 SSO，所有这些都无需额外的登录提示。
混合和旧版注意事项
本文中所述的无密码体验假定云优先方向与 Microsoft Entra 联接的设备。 具有已加入混合 Microsoft Entra 的设备的组织应注意以下差异：
- Web 登录 (用于在 Windows 锁屏界面上进行 TAP) 仅在加入Microsoft Entra的设备上受支持，不支持已加入Microsoft Entra混合的设备。
- Windows Hello 企业版适用于加入 Microsoft Entra 的设备和加入混合 Microsoft Entra 的设备，但混合部署可能需要额外的基础结构，具体取决于信任模型。
- 从已加入 Microsoft Entra 的设备访问本地资源需要云 Kerberos 信任或基于证书的信任。 建议使用云 Kerberos 信任模型，因为它不需要为 Kerberos 身份验证部署证书。 有关详细信息，请参阅 [云 Kerberos 信任部署] (/windows/security/identity-protection/> hello-for-business/deploy/hybrid-cloud-kerberos-trust) 。
- 需要 Active Directory Kerberos 身份验证的旧版应用程序仍可以使用无密码方法，但需要 NTLM 或直接 LDAP 绑定的应用程序可能需要额外的规划。
如果你的环境是混合环境，请从加入 Microsoft Entra 的设备开始规划无密码推出，然后扩展到基础结构支持的混合 Microsoft Entra 设备。
macOS
在 macOS 上，无密码规划取决于 Microsoft Entra ID 如何与平台登录和单一登录体验集成。 Microsoft Intune 提供以 Apple 为中心的标识集成所需的设备配置。
借助 Microsoft 企业 SSO 插件和 Apple 平台 SSO 框架，Microsoft Intune 可以部署允许用户使用其 Microsoft Entra ID 凭据登录到 Mac 的配置。 如果使用安全 Enclave 密钥方法进行配置，这将提供类似于 Windows Hello 的防网络钓鱼、有硬件支持的登录体验。
在进行计划时，此信息非常重要：
- 平台 SSO 和相关登录体验。
- 设备与 Microsoft 应用之间的单一登录。
- 与 Windows 和移动设备一致的管理模型。
iOS 和 iPadOS
在 iOS 和 iPadOS 上，无密码计划更侧重于应用登录、代理身份验证和密钥行为，而不是设备登录。 Microsoft Intune 部署和管理应用和设置，使用户体验一致。
iOS 上的 Microsoft SSO 扩展可以跨 Microsoft 和第三方应用拦截身份验证请求，从而在初始设备设置后实现无缝登录。 Microsoft Authenticator 充当身份验证代理，还可以在 iOS 17+ 上存储设备绑定密钥以进行防网络钓鱼身份验证。
Android
在 Android 上，Microsoft Intune 建立了无密码和代理身份验证流所依赖的托管上下文。 当 Microsoft Authenticator 或相关应用体验成为移动访问设计的一部分时，此上下文尤其相关。
公司门户和 Microsoft Authenticator 都可以充当 Android 上的身份验证代理。 用户通过代理登录后，Microsoft Entra ID 将颁发一个主刷新令牌，该令牌可在工作配置文件中的所有代理感知应用之间启用 SSO。 在 Android 14+ 上，Microsoft Authenticator 还可以存储设备绑定的密钥，以进行防网络钓鱼身份验证。
无密码身份验证的依赖项
零信任架构
无密码身份验证是更广泛的标识和设备访问策略的一部分。 对于 Microsoft Intune 管理员，规划通常涉及以下层：
- 标识：Microsoft Entra ID 中的防网络钓鱼身份验证方法。
- 设备信任： Microsoft Intune 注册、合规性和配置。
- 访问策略：条件访问和相关的排除计划。
- 数据保护：Microsoft Purview 功能可帮助在授予访问权限后保护内容。
- 调查和响应：当风险或入侵需要跟进时，Microsoft Defender 信号和工作流。
了解更多
条件访问
条件访问在授予访问权限之前评估设备状态和身份验证强度等信号。 与无密码方法结合使用时，条件访问可以强制实施身份验证强度策略，这些策略需要防网络钓鱼 MFA - 通过阻止密码或短信代码等较弱的方法来有效地强制使用无密码。
在实现条件访问的同时实现无密码访问时，还应考虑紧急访问规划，以防止意外锁定情况。
了解更多
紧急访问和恢复
删除密码时的一个常见问题是，当用户丢失其唯一的无密码设备 - 手机、FIDO2 密钥或装有 Windows Hello 的笔记本电脑时会发生什么。 如果没有恢复计划，管理员可能会面临支持升级，并且用户可能会被锁定在关键资源之外。
在无密码部署过程中规划这些方案：
- 紧急访问帐户：维护至少两个从条件访问策略和无密码强制实施中排除的紧急帐户。 如果配置错误或中断阻止所有其他访问，这些帐户将提供回退路径。 安全地存储凭据并监视这些帐户上的登录活动。
- 使用临时访问通行证恢复：当用户丢失无密码设备时，管理员可以发出新的 TAP，以便用户可以登录并注册替换凭据。 此方法避免将用户重置为密码，并将恢复流保持在无密码模型中。
- 多种注册方法：鼓励用户尽可能注册多个无密码方法。 例如，在笔记本电脑上使用 Hello 企业版的用户也可能在其手机上的 Microsoft Authenticator 中注册密钥。 如果一台设备丢失，其他方法仍然有效。
- 自助凭据管理：用户可以在 “我的安全信息”中管理其身份验证方法。 当与基于 TAP 的恢复结合使用时，此方法可减少支持人员对凭据重置的依赖。
- 使用验证 ID 进行全损恢复：对于用户丢失所有注册凭据和设备的情况，使用验证 ID 的 Microsoft Entra 帐户恢复提供了一个经过身份验证的恢复路径，该路径不依赖于密码或支持人员颁发的凭据。
在强制实施无密码之前规划恢复至关重要。 在没有恢复路径的情况下阻止密码的推出会造成锁定情况，从而削弱管理员和用户对过渡的信心。
了解更多
合规性和设备就绪情况
无密码通常取决于设备处于正确状态，然后用户才能依赖体验。 就绪情况通常包括：
验证和持续运营
若要验证无密码部署，常见检查点包括：
- Microsoft Entra 登录日志
- Microsoft Intune 设备和策略报告
- 针对部署的无密码方法的特定于平台的验证体验。
用户采用和沟通
技术就绪只是无密码部署的一部分。 当登录流发生更改时，习惯密码的用户可能会感到困惑或阻力。 规划用户沟通和支持可以在平稳过渡和广泛的帮助台升级之间发挥作用。
请考虑以下做法：
- 及早传达更改：让用户知道其登录体验正在更改、更改的原因以及预期更改。 重点关注优势 - 需要记住的密码更少、登录速度更快、安全性更强。
- 提供特定于平台的指导：无密码体验在 Windows (Hello 生物识别或 PIN) 、macOS (Touch ID 和平台 SSO) 、iOS (Authenticator 或密钥) 以及 Android (Authenticator 代理) 上有所不同。 根据用户拥有的平台定制通信。
- 确定试点组：先从一组可以测试体验并提供反馈的用户开始，然后再在整个组织中强制实施无密码。 IT 人员、早期采用者和具有安全意识的团队通常是不错的候选人。
- 让支持人员做好准备：确保支持团队知道如何颁发用于恢复的临时访问通行证、如何指导用户完成凭据注册，以及出现问题时在何处检查登录日志。
了解更多