-
Bug
-
Resolution: Fixed
-
P4
-
6
-
b78
-
sparc
-
solaris_10
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-2134681 | 5.0u8 | Weijun Wang | P4 | Resolved | Fixed | b01 |
JDK-2136028 | 1.4.2_14 | Kevin Walls | P4 | Resolved | Fixed | b02 |
The salt field in the KRB-ERROR 25 (precisely, the salt in PA-ETYPE-INFO/2 as the edata field inside KRB-ERROR) is used by the server to suggest the correct salt. However, when connecting to a Windows Server with an encryption type the server does not support (like AES-128) it can be an empty string(""). When trying to renegotiate with the server, current Java code will use the empty string as the new salt and throws an Exception.
When the user does not explicitly specify encryption type in krb5.conf and try to connect to a Windows Server, this bug always shows.
When the user does not explicitly specify encryption type in krb5.conf and try to connect to a Windows Server, this bug always shows.
- backported by
-
JDK-2134681 krb5 shouldn't use an empty salt field in KRB_ERROR
- Resolved
-
JDK-2136028 krb5 shouldn't use an empty salt field in KRB_ERROR
- Resolved
- relates to
-
JDK-6572805 regression: krb5 log in failed
- Resolved
-
JDK-2135127 JDK on Windows does not wait for preauthorizaion record from Kerberos and causes an error
- Resolved