I am currently running into an issue with Kerberos ticket expiration from a keytab on WAS 8.5.5.5. The same process works correctly on Tomcat 8, and I believe the primary difference is the JDK / JAAS client configurations. I am running both as vanilla configurations (no server configurations except memory / heap sizings).
Here is a sample from the log file when ran on Websphere -
2015-12-01 19:49:42,393 WARN [UserGroupInformation] PriviledgedActionException as:principal/fqdn@place (auth:KERBEROS) cause:javax.security.sasl.SaslException: Failure to initialize security context [Caused by org.ietf.jgss.GSSException, major code: 8, minor code: 0
major string: Credential expired
minor string: Kerberos credential has expired]
Are there any custom JAAS configurations I use within WAS itself without having to write code to circumvent the IBM JDK behaving differently? I see an attempted re-login, but does not appear to handle the expiration (as it does on Oracle JDK).
2015-12-01 20:06:30,718 INFO [UserGroupInformation] Initiating logout for principal/fqdn@place
2015-12-01 20:06:30,718 DEBUG [UserGroupInformation] hadoop logout
2015-12-01 20:06:30,718 INFO [UserGroupInformation] Initiating re-login for artimapp/qa01-ost-tesla-h-ds02.td.local
2015-12-01 20:06:30,731 DEBUG [UserGroupInformation] hadoop login
2015-12-01 20:06:30,731 DEBUG [UserGroupInformation] hadoop login commit
2015-12-01 20:06:30,731 DEBUG [UserGroupInformation] using existing subject:[principal/fqdn@place, principal/fqdn@place]
Any help on this would be greatly appreciated.
I have come across this link - https://issues.apache.org/jira/browse/HADOOP-9969 .
I have also come across a similar ticket in Spring Security, in which the a custom Kerberos Client has been written for IBM to mirror the SunJaasKerberosTicketValidator - https://jira.spring.io/browse/SES-15 .
My preference is to avoid waiting on the Hadoop JIRA to be resolved and having to write custom clients just to get Websphere to work properly.
