五个橘核在 VCF 环境里，vCenter 和 SSO 的关系有点像小区门禁卡和闸机：SDDC Manager 要拿着 SSO 管理员的凭据，才能去调每一台 vCenter 的 API；反过来，vCenter 也要在 SSO 域里注册自己的服务主体，才被允许向用户和系统发令牌。两头的注册关系只要有一方对不上，管理面就会出现各种冲突：vCenter 在 SDDC Manager 里长期显示不可管理、新建 Workload Domain 时提示 SSO 实体已存在、或者 vSphere Client 登录到一半直接 401。这篇文章就是讲怎么把 VCF 里 vCenter 和 SSO 的关联安全地重置一遍，并给出我实际用的排查和验收方法。适合正在维护 VCF 平台、遇到这类告警但不想直接叫二线的运维和架构师看。
1. 先搞明白：VCF 里的 vCenter 和 SSO 是怎么绑在一起的
很多人一看到“重置 SSO 关联”就急着去重启服务，结果越搞越乱。其实大多数冲突不是服务挂了，而是注册关系不一致。所以第一步不是动手，而是把这个信任链看清楚。
1.1 VCF 里的三个信任层次
VCF 里的 SSO 关联并不是单层关系，拆开看至少有三个层次：
第一层是 vCenter 自身内嵌的 SSO。VCF 4.x 及之后的版本，vCenter 都是部署成 VCSA，SSO 就内嵌在同一个 appliance 里，不再支持外置 PSC。以前做 VMware vCenter Server Appliance 6.7 部署的时候还能选外部 Platform Services Controller，但在 VCF 统一纳管之后，这种外置 PSC 模式就不再符合规范了，本文的操作也都以内嵌 SSO 为前提。
第二层是 vCenter 的服务主体在 SSO 域里的注册。VCSA 安装或部署时，会把自己注册进指定的 SSO 域，生成类似 host/<vcenter-fqdn>@vsphere.local 的服务主体，并写入 vmdird 目录库。这个目录库是整个 SSO 域的身份核心，所有域内 vCenter 的服务主体和用户列表都保存在里面。
第三层是 SDDC Manager 对 vCenter 的管理信任。SDDC Manager 并不是直接拿 vCenter 的本地账号去登录，而是使用 SSO 域的管理员账号（通常是 administrator@vsphere.local）调用 vCenter 的 REST API，由 SSO 颁发 security token 后再执行建域、加主机、纳管集群等操作。SDDC Manager 会把这组 SSO 管理员的用户名和密码存在自己的 vcf 数据库里，后续所有和 vCenter 的交互都依赖这组凭证。
理解这三层之后，你就明白所谓的“管理冲突”可能出在哪一层：可能是 SDDC Manager 存的 SSO 管理员密码变了，可能是 vCenter 在 vmdird 里的服务主体被删了或重复了，也可能是 STS 证书和时钟一致性出问题导致 token 校验失败。
1.2 管理冲突到底长什么样
我在现场见过最典型的冲突大概有五种，整理成一张对照表：
| 现场现象 | 报错或状态变化 | 初步判断 |
|---|---|---|
| SDDC Manager 打开 vCenter 详情一直转圈 | vCenter Server not reachable | 网络/DNS 或凭证失联 |
| 新建 Workload Domain 走到一半失败 | An SSO entity with name 'xxx' already exists | SSO 目录库里有旧实体残留 |
| 加入自带 vCenter 时提示冲突 | unable to register vCenter with SSO | SSO 域名或站点不匹配 |
| vSphere Client 登录到一半报 401 | Cannot authenticate user | STS 证书或时间漂移导致 token 校验失败 |
| SDDC Manager 告警列表出现 SSO 信任告警 | SSO credential validation failed | SDDC Manager 保存的 SSO 管理员密码失效 |
注意最后一个场景最容易被误判。SDDC Manager 报“credential validation failed”，很多人的第一反应是网络有问题，但它本质上是个身份问题：你改过 SSO 管理员密码、AD 组权限有调整、或者账号被锁定，都可能导致告警。这类问题不需要动 vCenter，甚至不需要动 VCSA，只要把 SDDC Manager 保存的凭证更新掉就行。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 重置前先想清楚：什么时候该重置，重置前要留什么后路
我不建议任何人在没有准备的情况下直接对 SSO 动手。SSO 关联一旦断错，vCenter 上所有 API 客户端都会跟着断，影响面可能远超预期。
2.1 先判断是“凭证问题”还是“注册实体问题”
拿到一个 SSO 关联冲突的工单，先别急着重置，先用报错关键词分类定位：
- 如果 SDDC Manager 能 ping 通 vCenter，但告警里写的是
SSO credential validation failed，优先怀疑凭证问题。先试试能否用administrator@vsphere.local正常登录 vSphere Client，能登进去就说明 SSO 域本身是健康的，剩下的就是把 SDDC Manager 里的密码同步成新密码。 - 如果加域或纳管时提示
SSO entity already exists，这是典型的旧实体残留问题。以前有一台同名 vCenter 注册进过同一个 SSO 域，被下线后服务主体没有清理干净。这时候你重新注册多少次都会撞车，必须先把旧实体从 vmdird 里清掉。 - 如果提示证书无效、签名校验失败这类字眼，先查时间再查证书。SSO 的 token 签发强依赖 UTC 时间，时间差超过几分钟就会直接拒绝认证。
- 如果多个 vCenter 都出现关联异常，别在单台上耗时间，先排查 NTP 和 DNS，这往往是共因。
简单说：凭证问题刷新凭证，实体问题清理残留，证书时间问题恢复信任，最后才谈得上重置关联。
2.2 准备工作清单和风险提示
在真正执行重置之前，把下面这张清单走一遍，能帮你省掉很多回滚时间：
| 类型 | 操作 | 说明 |
|---|---|---|
| 账号 | 确认 SSO 管理员账号可登录 vSphere Client | 例如 administrator@vsphere.local |
| 账号 | 确认 SDDC Manager API 账号可用 | 用于后续调用 API 和查询任务 |
| 账号 | 准备 VCSA root 或可 ssh 的管理账号 | 登录 /bin/appliancesh 用 |
| 备份 | 对 VCSA 做一次快照或完整备份 | 重置过程会动 SSO 注册，必须有回退点 |
| 备份 | 导出 VCSA 上的 SSO 配置文件 | 例如 /etc/vmware-sso、/etc/vmware-vmafd 目录打成 tar 包 |
| 资源 | 确认维护窗口 | 整个过程中 vCenter 的认证会中断，所有依赖 API 的任务都可能失败 |
| 信息收集 | 记录 vCenter FQDN、IP、SSO 域名 | 排查时反复要用 |
还有一个容易忽略的风险：如果这台 vCenter 还承担了企业身份联合的职责，比如接入了 ADFS、Okta，或者有的客户用 SAP NetWeaver AS for Java 的 SSO 做了服务商身份源注册，那么 vCenter 重新注册进 SSO 之后，需要留意对方 IdP 里缓存的证书指纹是否一致，否则会出现“SSO 通了但联合登录又断了”的连锁问题。我遇到过不止一次这种“重置完了反而更糟”的情况，原因就是没提前核对下游的信任配置。
3. 实操：三种重置路径的选择和完整步骤
下面按从轻到重的顺序给出三种路径。我的经验是：先从最轻量的开始，能不动 VCSA 就别动。
3.1 路径一：在 SDDC Manager 里刷新凭证并重试关联
这是最安全的路径，适合凭证过期、密码被外部轮换、或者用户手动改过 SSO 密码的场景。整体思路是让 SDDC Manager 重新保存新的 SSO 管理员密码，然后重新验证一次关联。
操作步骤：
- 用 sddc-admin 账号登录 SDDC Manager Web UI。
- 进入 Inventory > Workload Domains，找到目标 vCenter 所在的那个域。
- 选中对应的 vCenter，在操作菜单里找到 Manage 或 Update 类似的入口（不同小版本叫法略有差异）。
- 在弹出的表单中填入 SSO 管理员用户名和新的密码，保存。
- 回到 Workload Domains 页面，点击 Refresh 或 Re-sync，让 SDDC Manager 重新对 vCenter 做一次验证。
- 观察状态，如果 vCenter 从不可管理变成了 Active，说明只是凭证问题，到此收工。
这步看起来简单，但很实用。很多 VCF 管理冲突的本质就是“SDDC Manager 里存的密码和 SSO 域里实际密码不一致”，这个入口正是为这种情况准备的。执行完以后，可以从 SDDC Manager 后台日志确认一次：
bash复制tail -f /var/log/vmware/vcf/domainmanager/domainmanager.log
看到类似 vCenter validation succeeded 的记录，基本就稳了。
3.2 路径二：用 SDDC Manager API 做解绑和重新绑定
如果 UI 刷新凭证之后，vCenter 仍然处于不可管理、或者状态卡在某个异常值，就需要走 API 把关联关系拆掉再重建。这种方式适合 UI 没有提供重置入口、或者你想批量处理几台 vCenter 的场景。
先用 GET 接口拿到 vCenter 列表和 ID：
bash复制curl -sk -u 'sddc-admin@vsphere.local:密码' \
-H 'Accept: application/json' \
'https://<sddc-manager-fqdn>/v1/vcenters' | jq '.elements[] | {id, name, version}'
拿到对应的 vCenter ID 之后，执行解绑：
bash复制curl -sk -u 'sddc-admin@vsphere.local:密码' \
-H 'Content-Type: application/json' \
-X POST \
'https://<sddc-manager-fqdn>/v1/vcenters/<vc-id>/disassociate' | jq .
返回值里会有 taskId。把 taskId 拿来轮询任务状态，确认任务成功后再重新关联：
bash复制curl -sk -u 'sddc-admin@vsphere.local:密码' \
-H 'Accept: application/json' \
'https://<sddc-manager-fqdn>/v1/tasks/<task-id>' | jq .
任务成功之后，再发起关联，把最新的 SSO 管理员密码作为参数传进去：
bash复制curl -sk -u 'sddc-admin@vsphere.local:密码' \
-H 'Content-Type: application/json' \
-X POST \
-d '{"ssoAdminUser":"administrator@vsphere.local","ssoAdminPassword":"新密码"}' \
'https://<sddc-manager-fqdn>/v1/vcenters/<vc-id>/associate' | jq .
这里必须提醒一句：不同 VCF 版本对端点的命名不一样。我上面给的路径是 VCF 4.x 常见的写法，5.x 或 3.x 环境可能要求走 /v1/domains/{domainId}/vcenters/{vcenterId}/associate 之类的别名。执行前先调一次 GET 看该资源支持哪些操作，或者干脆去官方 API 文档里查你当前小版本的路径，避免收到 404 或 405。
这种“先解绑再重新绑定”的方式，本质上是在 SDDC Manager 侧重建与 vCenter 的信任关系，不会删除 vCenter 上的任何业务数据。但会短暂中断 SDDC Manager 对这台 vCenter 的管理连接，所以要在维护窗口内做。
3.3 路径三：在 VCSA 本地清理 SSO 残留并重新注册
如果前面两条路径都解决不了，比如 vCenter 在 vmdird 里的服务主体被误删、恢复备份后注册记录对不上、或者目录库里确实出现了重复实体，就需要登到 VCSA 上处理。这是风险和操作复杂度最高的一条路径，动手前一定确保有可回退的快照。
登进 VCSA 后，先看当前 SSO 注册状态：
bash复制/usr/lib/vmware-vmafd/bin/vmafd-cli show-identity --server localhost
再确认机器账户注册信息：
bash复制/usr/lib/vmware-vmafd/bin/vmafd-cli get-machine-account-info \
--server localhost --domain vsphere.local
如果发现机器账户信息缺失、GUID 对不上，或者注册的域和预期不一致，可以用 sso-config.sh 强制重新注册服务主体：
bash复制cd /usr/lib/vmware-sso/bin
./sso-config.sh -register \
-domain_name vsphere.local \
-user_name "administrator@vsphere.local" \
-password 'SSO管理员密码' \
-server '<vCenter自身FQDN>' \
-server_port 7444
注意如果环境是内嵌 SSO，-server 一般填 vCenter 自己的 FQDN；如果 SSO 域里有其他 vCenter 节点，也可以换成该域内的另一台 PSC 或 vCenter 的 FQDN。执行完这条命令后，vCenter 的服务主体会被重新写进 vmdird 目录库，完成 SSO 注册。
操作完以后，需要重启 SSO 相关服务让它完全生效：
bash复制service-control --stop --all
service-control --start --all
全停全起会让 vCenter 上所有 API 客户端断连，所以这条命令只在确认维护窗口时才执行。我个人不太建议一上来就全停全起，很多情况下重启 vmafdd、vmdird、vmonapi 这三个服务就够了。
如果现场报的是“SSO entity already exists”，说明 vmdird 目录库里残留了旧的同名服务主体。最直接的处理是使用 vmdir 管理工具登录目录库，把旧实体删掉。这个工具是交互式菜单，删除不可逆，操作前务必先备份整本目录数据，或者至少记录好要删除对象的 DN 和证书指纹。这类操作非常容易把 vCenter 的 SSO 弄到彻底起不来，我在现场的原则是：如果没有官方支持在场，不要随便动删除功能。 更稳妥的做法是先联系支持，把残留实体的 DN 核对清楚再动手。
4. 重置后的验收：不要只看“状态变绿”
很多人做完重置，看到 SDDC Manager 上 vCenter 状态变成绿色就以为结束了。SSO 关联这条链路上游下游都涉及，必须从服务层、日志层、真实业务路径三个维度验收。
4.1 服务层和日志层的验证
先确认关键服务都处于 Running：
bash复制service-control --status --all
重点看 vmafdd、vmdird、vmonapi，这几个是 SSO 相关服务。如果有一个处于异常，先解决它，再去测别的。服务都正常后，在 VCSA 的后台确认一下身份信息是否已经写回：
bash复制/usr/lib/vmware-vmafd/bin/vmafd-cli show-identity --server localhost
同时，SSO 的健康检查还可以通过 VCSA 管理界面做，在浏览器打开 https://<vcenter-fqdn>:5480，进入“服务”页面查看各服务的运行状态，SSO 相关服务显示正常运行即可。
SDDC Manager 侧要看任务和日志。如果刚才走的是 API，轮询 task 状态直到 SUCCESS；然后用 GET 重新拉一次 vCenter 信息，确认状态从 DISASSOCIATING 或 ERROR 恢复成 ACTIVE：
bash复制curl -sk -u 'sddc-admin@vsphere.local:密码' \
-H 'Accept: application/json' \
'https://<sddc-manager-fqdn>/v1/vcenters/<vc-id>' | jq '{name, status}'
日志方面，VCF 的管理日志集中在 /var/log/vmware/vcf/ 下，最常看的是 domainmanager/domainmanager.log，SSO 相关报错在这里会有明确记录。看到 vCenter validation succeeded、SSO connection healthy 这类日志才算真正通过。
4.2 用真实业务路径再测一次
服务状态正常不等于业务链路恢复，我还会做一次能触发完整信任链的验证。推荐两个动作：
一是到 SDDC Manager 的 Workload Domains 页面，手动触发一次 Refresh，看会不会再冒出 SSO 告警。二是对一个已有 Workload Domain 执行一次“加主机”的前置校验，或者直接尝试扩展集群。扩展操作会触发 SDDC Manager 拿 SSO 凭证去调 vCenter 建任务、检查主机规格、写入配置，只要这个流程能走过 Validation 阶段，就说明整个信任链已经打通。
如果这台 vCenter 上有 NSX Manager 纳管关系，最好也在 NSX 侧做一次同步检查。重置 SSO 关联后，vCenter 在 SSO 域里的证书指纹可能已经变化，NSX Manager 如果缓存了旧指纹，会出现“能看到 vCenter 但回调失败”的现象，这时需要把 NSX 里的 vCenter 注册信息重新更新一遍。
5. 现场排障速查：我踩过的坑和一句话解决法
最后把我真实踩过、也看别人踩过的坑整理成速查表，遇到对应现象直接对着查。
5.1 高频故障对照表
| 问题现象 | 根因 | 解决方案 |
|---|---|---|
| SDDC Manager 刷新 vCenter 状态报 401 | SSO 管理员密码过期或账号锁定 | 在 Workload Domains 界面更新 SSO 管理员凭证，并确认该账号可登录 vSphere Client |
| 新建 Workload Domain 失败：SSO entity already exists | vmdird 目录库里有同名旧服务主体 | 用 vdcadmintool 删除旧实体，或联系官方协助确认 DN 后再删 |
| vCenter 状态卡在 DISASSOCIATING | 上一次解绑任务未正常结束 | 查 domainmanager.log 定位断点，用 API 重跑任务，避免重复提交 |
| vSphere Client 登录 401 / Cannot authenticate user | 时间漂移或 STS 证书异常 | 先同步全部组件时间，再检查 STS 证书有效期并替换 |
| NSX Manager 回调 vCenter 失败 | SSO 重置后证书指纹变化 | 到 NSX Manager 重新注册 vCenter 并更新指纹 |
5.2 容易忽略的连锁问题
有三件容易忽略但影响很大的事情，单独拎出来提醒一下。
第一是时间同步。SSO 的 token 签发和校验强依赖时间一致性，UTC 时间相差超过默认容忍范围，认证就会被拒。很多 SSO 冲突其实是 NTP 服务没配好导致的“假 SSO 故障”。我在重置前一定会先做一次全组件的时间检查，哪怕只是顺手跑一条 chronyc tracking 看下偏差，都能少走很多弯路。
第二是证书指纹。SSO 关联重置后，vCenter 在 SSO 域里的证书指纹可能更新，凡是信任旧证书的客户端，比如备份软件、vRealize Automation、部分第三方监控工具，都要去拿新指纹。这些下游系统不会自动更新，你重置的时候不处理，等两三天后它们开始报错，你又要重新排查一遍。
第三是密码管理习惯。SDDC Manager 保存的是 SSO 管理员密码，不是 vCenter root 密码，也不是 ESXi root 密码。很多客户内部流程里会定期轮换密码，但只改了 AD 域密码或 root 密码，把 SSO 管理员密码漏掉了，结果就是 SDDC Manager 在某个固定周期后开始报 SSO 告警。这不是技术问题，而是运维流程问题，建议在密码轮换清单里明确列出“VCF SDDC Manager 里保存的 vCenter SSO 管理员密码”这一项。
最后分享一点个人习惯
落到现场，我最常用的顺序其实是：先看告警关键词。如果是 credential validation failed，就先在 Workload Domains 里把 SSO 管理员密码刷一遍；再不行才考虑 API 解绑和重新绑定；最后才登 VCSA 做本地注册修复，而且登之前一定先把 /etc/vmware-sso、/etc/vmware-vmafd 目录备份出来。最后再分享一个小技巧：重置完别急着关浏览器，先调一次 GET /v1/vcenters/<vc-id>，把返回的 version 和 status 记录下来，和重置前对比。只要这个状态稳定，说明 SSO 关联真的稳住了，后续就算再出问题，你也有明确的基准点可以回溯。