配置Java应用支持Oracle数据库AD/Kerberos身份验证

JVM启动参数，一个都不能少

Java自己不会去读系统里的Kerberos配置文件，你得明确告诉它去哪里找。有三项参数是必须设置的，缺一不可： * `-Djava.security.krb5.conf=/etc/krb5.conf`：指向你实际的Kerberos配置文件。千万别指望它能自动找对路径，手动指定最稳妥。 * `-Djava.security.auth.login.config=/path/to/jaas.conf`：这是JAAS配置文件的路径，它定义了具体的登录行为。 * `-Dsun.security.krb5.debug=true`：这个参数平时可以不开，但出问题追查时，它就是你的救命稻草。它能输出详细的票据获取过程，否则你连错误日志都看不到。 这里有个特别容易踩的坑：`jaas.conf`里的登录模块名，比如`KrbLogin`，必须和你代码里`new LoginContext("KrbLogin", ...)`的第一个参数一字不差，大小写敏感。如果这里对不上，一切配置都是白搭。

JDBC URL与SPN，必须严丝合缝

Oracle JDBC驱动启用Kerberos，靠的是SPN。URL里必须包含`oracle.net.authentication_services=(KERBEROS5)`这个标记。而且，数据库的服务名必须和AD里注册的SPN完全一致。 举个例子，如果你的Oracle实例DNS是`oradb.example.com`，端口1521，服务名是`ORCL`，那么SPN应该是`oracle/oradb.example.com@EXAMPLE.COM`。注意大小写和域名后缀。对应的JDBC URL应该写成： ``` jdbc:oracle:thin:@oradb.example.com:1521/ORCL?oracle.net.authentication_services=(KERBEROS5) ``` 如果SPN写错了，比如漏了域名或大小写不对，驱动就会默默地回退到密码认证，然后反馈给你一个让人摸不着头脑的ORA-01017。

AD用户与Oracle企业用户，必须建立映射

就算你的Kerberos票据拿到了，JDBC参数也都对了，这仅仅说明“你是AD里的那个人”。But，Oracle数据库层面可不一定认你。你需要把这个AD用户映射成一个Oracle的企业用户（Enterprise User），并授予它`CREATE SESSION`权限。 最容易掉坑的有三处： * 没有在Oracle中执行`CREATE USER "EXAMPLE\username" IDENTIFIED EXTERNALLY;`。注意这里要用双引号和反斜杠转义，格式非常关键。 * 没有执行`GRANT CREATE SESSION TO "EXAMPLE\username";`。 * 没有启用Enterprise User Security（EUS），也就是没配置Oracle Internet Directory或Oracle Unified Directory作为用户仓库来承载这些映射关系。 如果你想快速验证Kerberos能不能通，可以用RDS for Oracle自动创建的托管用户来测试。但生产环境，必须老老实实走EUS映射。 说到底，很多人反复排查发现，Kerberos票据能用，JDBC参数也对，但Oracle就是不认。问题往往就出在SPN注册和EUS映射这两步上。最有效的调试方法是，先在命令行用`kinit`拿到票据，再用`kvno oracle/oradb.example.com@EXAMPLE.COM`验证票据的有效性。确认没问题后，再去Oracle数据库里查`dba_users`表，看看有没有对应的外部用户。这样一步步来，大部分问题都能定位到。