无密码身份验证通过将密码替换为更强大的登录方法（例如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使用 OS 登录，macOS 将 Touch ID 与Microsoft Entra ID集成，移动平台使用Microsoft Authenticator 和平台密钥。 用户无需为每个设备处理单独的密码。
- 更强的安全态势：防钓鱼方法可防止凭据被盗和重播攻击。 设备符合性门控可确保即使有效的凭据也只能从正常的托管设备工作 - 符合零信任原则。
- 降低 IT 支持负载：减少密码重置、使用临时访问密码更流畅的载入，以及自助服务恢复选项可减少支持人员数量。
- 面向未来的体系结构：随着标准的发展，新的无密码方法（包括同步的密钥和硬件支持的凭据）可以插入同一Microsoft Entra ID + Microsoft Intune体系结构，而无需进行重大重新设计。
Microsoft Intune如何推动采用无密码
Microsoft Intune通过确保设备和应用程序正确配置为使用强新式凭据来启用和操作无密码身份验证。 虽然Microsoft Entra ID控制标识和身份验证策略，但Microsoft Intune准备无密码方法所依赖的设备环境。
主要贡献包括：
- 设备就绪性：注册、注册和配置设备，以便它们能够参与无密码登录流。
- 配置部署：提供Windows Hello 企业版、基于证书的身份验证、Apple 平台 SSO 和类似平台功能所需的策略。
- 符合性和访问信号：提供设备运行状况和符合性数据，条件访问在授予访问权限之前评估这些数据。
- 应用和代理预配：部署核心应用程序（如 Microsoft Authenticator 和 Microsoft Intune 公司门户），以启用标识代理和无密码 SSO 方案。
- 统一的跨平台管理：跨 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。
- 恢复或备用路径以及基于平台的凭据。
Passkeys
密钥是基于标准的 FIDO 凭据保护，可以绑定设备或跨设备同步。 在 Microsoft Entra ID 中，可以使用：
- 存储在单个设备上的安全硬件 (TPM 或安全 Enclave 中的设备绑定密钥) ，例如通过 iOS 17+ 和 Android 14+ 上的 Windows Hello 或 Microsoft Authenticator。
- 由平台密码管理器管理的同步密钥 (（例如 iCloud Keychain 或 Google Password Manager) 或支持的第三方提供商），这些提供程序支持跨设备使用。
- Windows 上的Microsoft Entra密钥是一种 FIDO2 密钥，它使用Windows Hello进行生物识别验证，但不需要设备加入或注册。 用户可以在同一设备上为多个Microsoft Entra帐户注册多个密钥，使其非常适合共享设备、非托管终结点和未预配Windows Hello 企业版的方案。
从Microsoft Intune的角度来看，密钥主要与平台和应用就绪性有关，即管理设备和应用先决条件，使密钥采用跨平台可行。此依赖项在以下方面尤其重要：
- Windows，其中平台登录和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许可证层，并且每种方法都有最低 OS 版本要求。
许可要求
根据你选择的无密码方法，你的组织可能需要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 |
了解更多信息
平台要求
本文中所述的无密码方法依赖于特定平台功能，这些功能仅在某些 OS 版本中可用。 下表汇总了每个方法的平台要求：
| 方法 | Windows | macOS | iOS/iPadOS | Android |
|---|---|---|---|---|
| Windows Hello | 所有 受支持的 Windows 客户端 | — | — | — |
| FIDO2 安全密钥 | 所有 受支持的 Windows 客户端 | — | — | — |
| Passkeys | Windows 11 | 所有 受支持的 版本 | 所有 受支持的 版本 | Android 14+ |
| Microsoft Authenticator 中的设备绑定密钥 | — | — | 所有 受支持的 版本 | Android 14+ |
| 平台 SSO (Secure Enclave) | — | 所有 受支持的 版本 | — | — |
| Web 登录 (锁屏界面上 TAP) | 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，可以无缝 SSO Microsoft 365 个应用、SaaS 应用程序，并在配置云 Kerberos 信任时使用本地资源（如文件共享），所有这些都无需额外的登录提示。
混合和旧版注意事项
本文中所述的无密码体验假定已加入Microsoft Entra设备的云优先方向。 具有已加入混合Microsoft Entra设备的组织应注意以下差异：
- 在 Windows 锁屏界面上用于 TAP 的 Web 登录 () 仅在已加入Microsoft Entra设备上受支持，而不支持加入混合Microsoft Entra的设备。
- Windows Hello 企业版同时适用于已加入Microsoft Entra和已加入混合Microsoft Entra的设备，但混合部署可能需要其他基础结构，具体取决于信任模型。
- 从已加入Microsoft Entra设备的本地资源访问需要云 Kerberos 信任或基于证书的信任。 建议使用云 Kerberos 信任模型，因为它不需要为 Kerberos 身份验证部署证书。 有关详细信息，请参阅 [cloud 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 Enterprise 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 for Business 的用户也可能在其手机上的 Microsoft Authenticator 中注册密钥。 如果一台设备丢失，另一种方法仍有效。
- 自助服务凭据管理：用户可以在 “我的安全信息”中管理其身份验证方法。 与基于 TAP 的恢复结合使用时，此方法可减少凭据重置的支持人员依赖关系。
- 使用验证 ID完全丢失恢复：对于用户丢失所有已注册凭据和设备的情况，Microsoft Entra帐户恢复使用 验证 ID 提供不依赖于密码或支持人员颁发的凭据的经过标识验证的恢复路径。
在强制实施无密码之前规划恢复至关重要。 在没有恢复路径的情况下阻止密码的推出会创建那种会削弱管理员和用户对转换的信心的锁定方案。
了解更多信息
合规性和设备就绪情况
无密码通常取决于设备处于正确状态，然后用户才能依赖体验。 就绪情况通常包括：
验证和正在进行的操作
若要验证无密码部署，常见检查点包括：
- Microsoft Entra登录日志
- Microsoft Intune设备和策略报告
- 部署的无密码方法的特定于平台的验证体验。
用户采用和通信
技术就绪只是无密码部署的一部分。 习惯使用密码的用户可能会在登录流更改时遇到混淆或阻力。 规划用户通信和支持可以区分平稳过渡和广泛的支持人员升级。
请考虑以下做法：
- 尽早传达更改：让用户知道其登录体验正在更改、更改原因以及预期内容。 专注于优势 - 减少要记住的密码、更快的登录和更强的安全性。
- 提供特定于平台的指导：Windows (Hello 生物识别或 PIN) 、macOS (触控 ID 与平台 SSO) 、iOS (Authenticator 或密钥) 以及 Android (Authenticator 代理) 时，无密码体验有所不同。 根据用户拥有的平台定制通信。
- 确定试点组：从一组用户可以测试体验并提供反馈的用户开始，然后在整个组织中强制实施无密码。 IT 人员、早期采用者和具有安全意识的团队通常是很好的候选人。
- 准备支持人员：确保支持团队知道如何颁发用于恢复的临时访问通行证、如何指导用户完成凭据注册，以及出现问题时在何处检查登录日志。
了解更多信息