JDK-8028351 : JWS doesn't get authenticated when using kerberos auth proxy
  • Type: Bug
  • Component: security-libs
  • Sub-Component: org.ietf.jgss:krb5
  • Affected Version: 7u45,8
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: windows
  • CPU: generic
  • Submitted: 2013-11-14
  • Updated: 2014-08-22
  • Resolved: 2013-12-04
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7 JDK 8 Other
7u60Fixed 8 b120Fixed naResolved
Related Reports
Blocks :  
JDK-8033120 - JWS doesn't get authenticated when using kerberos
Description
Cu has proved that kerberos set up correctly by using IE. IE can browse
internet via Kerberos authentication. But JWS cannot.

From network capture, they saw AS-REP "KRB5KDC_ERR_PREAUTH_REQUIRED" and
"KRBKDC_ERR_PREAUTH_FAILED" when allowtgtsessionkey = 0 for request
krbtgt/DOMAIN to AD server. When allowtgtsessionkey = 1, they got TGS-REP
"KRB5KRB_AP_ERR_MODIFIED" for HTTP/squidproxy.domain.

If they disable kerberos pre- authentication for that user and user was KINIT
in JRE/bin before launch JNLP, JWS can download properly.

system configuration
====================
Environment - Squid proxy with Kerberos authentication enabled. Squid OS is
Ubuntu. AD is Windows 2008. Client is Windows 7 x86 with 7u45

javaws -J-Dsun.security.krb5.debug=true <http://your jnlp>

And the log can be found in https://mos-cores.us.oracle.com/web/cores/3-8062194441/tds-2013-11-13/javaws5447623760750531854.log

They use krb5.ini that is available in https://mos-cores.us.oracle.com/web/cores/3-8062194441/tds-2013-11-08/krb5.ini
Comments
sun/security/krb5/auto/LoginNoPass.java passed since B120
21-01-2014
Release team: Approved for fixing
03-12-2013
SQE: approves this critical request.
28-11-2013
I thought it should always go to the main bug. Anyway, I've updated the target of this bug to 8 and JDK-8028360 to 7-pool. That an 8 bug is a backport of a 7u bug makes me feel itchy.
28-11-2013
Shouldn't the critical request be made for the JDK 8 bug JDK-8028360 ?
27-11-2013
SQE is OK with the webrev. Changed to 8-critical-request now.
26-11-2013
webrev with reg test: http://cr.openjdk.java.net/~weijun/8028351/webrev.00/
22-11-2013
Max, can you please add a link here to the webrev and associated regression test
21-11-2013
8-critical-request justification: Java's Krb5LoginModule attempts to use an empty password at login time if the user has not provided one (i.e. JAAS PasswordCallback::getPassword returns null). This would lead to a useless login attempt that always fails. The worst thing is: a lot of KDC servers are configured to block a user after a certain number of incorrect password logins. JWS never shows a login dialog for Kerberos because it believes Kerberos is designed as a single sign-on method and should never ask for a password. If it cannot find an existing Kerberos credential It should fallback to NTLM at once. Currently it performs a (failed) login using an empty password and then fallback to NTLM, which is a waste of time. After several such useless login and the client is blocked from the KDC, even NTLM authentication won't work. Krb5LoginModule should throw a LoginException instead, then JWS can fallback to NTLM without trying any Kerberos at all.
16-11-2013
Reason found. In Krb5LoginModule.java [1], we have 917 if (tmpPassword == null) { 918 // treat a NULL password as an empty password 919 tmpPassword = new char[0]; 920 } This "treatment" was there from the beginning. It could be useful to prevent an NPE but I cannot imagine the empty password will be any useful later. Should be changed to throw new LoginException("No password provided") As for the KRB5KRB_AP_ERR_MODIFIED error for allowtgtsessionkey = 1, I cannot reproduce it on my own system. But this is not an out-of-box setting and can be addressed later. [1] http://hg.openjdk.java.net/jdk8/tl/jdk/file/3470101fae58/src/share/classes/com/sun/security/auth/module/Krb5LoginModule.java
15-11-2013
If you are pretty sure this affects 8, I think it makes sense to open a backport issue, and have you look into it and fix it (will need a critical request), and then have Mala do the backport. I'll go ahead and open a backport issue and assign it to you.
14-11-2013
The "KRBKDC_ERR_PREAUTH_FAILED" message means a password error. My understanding is that HTTP prefers Kerberos authentication scheme but it cannot get the correct password for the user (no CallbackHandler specified). In this case, HTTP should not try AS-REQ at all and fallback to NTLM as soon as possible. But for some reason it continues with AS-REQ (maybe using "" or "null" as the password) and then fails. This should affects JDK 8 also.
14-11-2013
Do you know if this also affects JDK 8?
14-11-2013