ORA-12638根本原因是Kerberos预认证失败，非密码错误；常见于sqlnet.authentication_services=(kerberos5)时客户端无有效TGT、时间不同步、AD预认证禁用、KDC不可达或加密类型不匹配。
根本原因不是密码错，而是Kerberos预认证阶段被KDC拒绝——这一步不涉及密码校验，只检查凭据合法性、时间同步、加密类型和账户策略。
ORA-12638：客户端连不上KDC或身份凭据不可用
这个错误出现在Oracle客户端启用Kerberos（比如sqlnet.authentication_services = (kerberos5)）但无法完成初始TGT获取时。本质是SQL*Net在底层调用GSSAPI失败，常见于Navicat、SQL*Plus或JDBC Thin连接场景。
-
sqlnet.ora里sqlnet.authentication_services设成(kerberos5)，但客户端没运行过kinit，/tmp/krb5cc_uid缓存为空 → 报ORA-12638 - Windows域环境下，客户端用NTLM账户登录，但
sqlnet.ora却配了(kerberos5)，而域控未启用Kerberos或禁用了预认证 → KDC直接拒收请求 - Oracle服务端
krb5.conf中default_realm或kdc地址写错，或DNS无法解析KDC主机名 → 客户端根本连不到KDC
预认证失败（KDC_ERR_PREAUTH_REQUIRED等）的四大硬性条件
Kerberos预认证不是可选项，是强制安全门禁。只要其中一条不满足，KDC就在TGT发放前返回失败，Oracle客户端就拿不到票据，后续一切免谈。
- AD用户属性里“使用Kerberos预身份验证”被手动取消勾选 → 必须进
Active Directory 用户和计算机→用户属性→帐户页重新启用 - 客户端与域控时间偏差＞5分钟 → 运行
w32tm /query /status确认，用w32tm /resync /force强制同步 - 账户已禁用、密码过期、或密码不符合域策略（比如刚批量建号但没重置密码）→ 用
dsquery user -samid username | dsget user -disabled -pwdlastset快速核对 - 客户端尝试用DES-CBC-CRC等弱加密类型请求TGT，但域策略已禁用 → 检查Windows注册表
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters\SupportedEncryptionTypes，确保含0x10（AES128）或0x20（AES256）
JDBC Thin + Kerberos连接时GSSException: No valid credentials provided
这是Java侧典型报错，和Oracle客户端报ORA-12638逻辑一致，但堆栈更深一层。重点不在Oracle配置，而在JVM环境是否真正持有了有效TGT。
- 没执行
kinit -k -t keytabfile principal，或kinit后没导出KRB5CCNAME环境变量 → Java进程启动时读不到票据缓存 - 使用Oracle JDK 8u260以下版本 → 无法解析MIT Kerberos 1.8.1+生成的凭证缓存格式，换成OpenJDK 11+或Oracle JDK 8u291+可绕过
- 连接URL里
oracle.jdbc.java.security.krb5.conf指向的krb5.conf缺失[libdefaults]节里的default_realm或ticket_lifetime→ JVM GSS库初始化失败 - 应用以服务账号运行（如Linux上
systemd服务），但该账号没权限读/tmp/krb5cc_*→ 改用keytab方式，避免依赖用户级缓存文件
最容易被忽略的是时间同步和预认证开关——它们不报具体错误码，只让整个流程静默失败；而krb5.conf配置错误或加密类型不匹配，则会让KDC日志里出现KDC_ERR_ETYPE_NOTSUPP或KDC_ERR_CANT_VERIFY_CERTIFICATE这类线索，但默认不透传给Oracle客户端。
