United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-8028351 : JWS doesn't get authenticated when using kerberos auth proxy

Details
Type:
Bug
Submit Date:
2013-11-14
Status:
Closed
Updated Date:
2014-08-22
Project Name:
JDK
Resolved Date:
2013-12-04
Component:
security-libs
OS:
windows
Sub-Component:
org.ietf.jgss:krb5
CPU:
generic
Priority:
P2
Resolution:
Fixed
Affected Versions:
7u45,8
Fixed Versions:

Related Reports
Backport:
Backport:
Backport:
Backport:
Blocks:

Sub Tasks

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
                                     
2014-01-21
URL:   http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/e1bc55ddf1ad
User:  lana
Date:  2013-12-10 18:28:32 +0000

                                     
2013-12-10
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e1bc55ddf1ad
User:  weijun
Date:  2013-12-04 01:21:24 +0000

                                     
2013-12-04
Release team: Approved for fixing
                                     
2013-12-03
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.
                                     
2013-11-28
SQE: approves this critical request.
                                     
2013-11-28
Shouldn't the critical request be made for the JDK 8 bug JDK-8028360 ?
                                     
2013-11-27
SQE is OK with the webrev. Changed to 8-critical-request now.
                                     
2013-11-26
webrev with reg test: http://cr.openjdk.java.net/~weijun/8028351/webrev.00/
                                     
2013-11-22
Max, can you please add a link here to the webrev and associated regression test
                                     
2013-11-21
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.
                                     
2013-11-16
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
                                     
2013-11-15
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.
                                     
2013-11-14
Do you know if this also affects JDK 8?
                                     
2013-11-14
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.
                                     
2013-11-14



Hardware and Software, Engineered to Work Together