Kerberos 停用与回退

停用 Kerberos 会改变整个集群的认证模式，并触发服务配置调整和重启。不要通过手工修改 security_type、删除 Keytab 或移除 KDC 服务来代替向导；这些做法很容易让页面状态、服务配置和真实运行状态彼此不一致。

警告

平台托管 KDC 和外部 KDC 的停用边界不同。平台托管模式会结束旧 Realm 生命周期；外部模式只解除本集群接入，不修改企业侧 KDC 数据。执行前一定要先确认当前认证中心来源。

进入安全停用向导

从 权限与审计 → Kerberos 管理 进入 安全停用 Kerberos。向导按顺序分为四个阶段：安全检查、影响确认、停用确认、执行与恢复。

页面刚打开时不会直接提交停用任务，必须先运行预检。

安全检查

点击 开始预检 后，平台会核对：

• 是否有正在执行的安装、启停、升级或安全变更任务。
• 是否具备可用的配置与服务状态快照。
• 当前服务状态能否在停用后恢复。
• LDAP、Ranger 和身份同步是否存在依赖关系。
• 当前认证中心来源与拓扑是否已经确认。

检查结果分为“已通过”“需留意”“需处理”和“待确认”。存在阻断项时，向导不会开放下一步。

注意

“需留意”不等于可以忽略。尤其是缺少完整快照时，页面可能只提供尽力恢复。生产环境应先补齐恢复条件，再进入停用。

看清影响范围

预检通过后，第二阶段会展示当前环境的实际影响。通常包括：

影响	说明
服务短时调整	受影响服务按依赖顺序停止、切换配置并恢复。
认证模式调整	集群切回非 Kerberos 运行模式。
目录服务联动	LDAP 保持独立运行，停用期间暂停新的身份同步。
Ranger 授权	Ranger 服务不会因为停用 Kerberos 自动卸载，但插件与访问方式需要按新认证模式验证。

LDAP 与 Kerberos 是两条独立生命周期。Kerberos 停用完成后，如果还要停用 LDAP，应从 LDAP 专题单独操作，不要在这里顺带删除目录服务。

进入第三步后必须输入当前集群名，按钮才会放行。本文仅展示确认页，不执行停用。

确认所有权边界

进入停用确认前，先根据当前来源理解系统会处理什么：

平台托管 KDC

平台会删除旧 Realm、Principal、Keytab、运行状态和托管服务拓扑。以后再次启用时按全新流程建立认证中心。

外部 MIT KDC

平台只解除当前集群与外部 KDC 的接入，外部 KDC、Active Directory 或 FreeIPA 的进程与数据不在停用范围内。

第三阶段需要输入当前集群名进行确认。这个确认只用于防止误操作，不应填写 Realm、KDC 主机名或平台登录用户名。

执行与恢复

提交后，平台会重新运行预检并锁定本次操作，然后分步切回非 Kerberos 模式、调整服务配置并恢复原运行状态。

执行过程中如果失败，不要手工跳过步骤。页面会保留精确失败阶段，并根据现场提供继续停用或恢复服务状态的入口。优先沿原操作恢复，避免同时创建第二个停用任务。

验证停用结果

完成后我会逐项确认：

检查项	通过状态
集群认证模式	已切回非 Kerberos 模式。
Kerberos 生命周期	停用操作已完成，没有待恢复或失败中的操作。
服务状态	受影响服务恢复到停用前的运行状态。
平台托管 KDC	旧 Realm 与托管服务拓扑已按向导结束。
外部 MIT KDC	企业侧 KDC 数据和进程未被修改。
LDAP 与 Ranger	仍按各自生命周期运行，并完成新的认证路径验证。

最后再用实际业务链路做一次非 Kerberos 验证，例如 HDFS 文件访问、Hive 查询或 Kafka 生产消费。页面显示“停用完成”只是控制面结果，业务链路验证通过后才算真正收尾。