用 Entra ID SSO 部署密码管理器：2026 指南

为什么“先有 SSO”胜过“后补 SSO”

多数保管库把 SSO 当作企业档位的附加项，外挂在一套基于密码的账户体系之上。这个次序会显形：用户到头来还是有一个保管库密码，管理员侧的生命周期管理成了事后补丁，而 SSO 档位还要额外收费。以 SSO 为起点的设计从你的目录出发：不用创建新账户，不用分发密码，新人被自动识别，离职者则随着你已经在 Entra ID 里执行的那次停用一并被切断。你的条件访问和多因素策略会自动生效，因为登录就是你的目录。

那个硬问题：加密密钥在哪里？

SSO 回答的是你是谁。它绝不能回答你能解密什么。如果只要用 Entra ID 登录就足以读到保管库内容，那么掌控或攻破身份层的人同样能读到，厂商的零知识说法也就悄悄死掉了。诚实的架构会把两套系统分开：身份来自你的目录，解密密钥则由主密码在成员自己的设备上派生，从不外传。Keyvaci 就是这样运作的，这个分离在安全架构页面上有完整说明。无论你评估的是哪个产品，请先问这个问题，并且要一份书面答复。

部署过程应该是什么样

1. 由一位管理员用 Microsoft 登录。创建组织这一步，应当限定为你租户里真正的全局管理员，并且从 Microsoft 签发的令牌中验证这一角色，这样就没有人能仅凭一个工作邮箱把你公司的名字注册走。
2. 恢复密钥包在客户端生成。由你的浏览器创建组织的签名密钥和恢复密钥，并且只展示一次。厂商从不看到它们；正是这一点让恢复留在你手里，而不落到他们手里。
3. 成员用已有的账户登录。每个人设置一个主密码，由管理员为其密钥副署，然后开始接收保管库。不用安装代理程序，不用改动目录架构，用的是标准的 OIDC 加 PKCE。

完整流程，包括管理员验证的细节，以及租户之外的来宾会怎么处理，都在Entra ID 集成页面上。

来自真实部署的推广建议

• 一次性授予租户级的管理员同意，这样成员永远不会看到同意提示。
• 在邀请任何人之前，先把头三个保管库填好：银行、云账户、共享的 SaaS。人们愿意用的，是一个已经装着他们所需内容的保管库。
• 把恢复密钥包打印出来，按它本来的分量当作总钥匙保管。厂商没有能力重置任何东西，这是功能，不是小字条款。
• 用的是 Google Workspace？邮箱账户今天就能用，原生 Google 单点登录已在路线图上。