JDK-2182089 : ESC: AD Authentication with user with umlauts fails
  • Type: Backport
  • Backport of: JDK-6862679
  • Component: security-libs
  • Sub-Component: org.ietf.jgss:krb5
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2009-08-20
  • Updated: 2010-11-04
  • Resolved: 2009-10-09
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 6 JDK 7
6u17-revFixed 7 b74Fixed
Comments
EVALUATION Part I: Introduces the sun.security.krb5.msinterop.kstring system property. When set to true, UTF-8 is used in encoding. Otherwise, ASCII is used. Part II: Another interop issue is string-to-key encoding for DES keys. RFC 3961 claims UTF-8 should be used, but Microsoft AD uses machine-specific charset, precisely, the code page specified in the registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\CodePage\OEMCP To interop, introduces the sun.security.krb5.msinterop.des.s2kcharset system property to specify the charset used when performing string-to-key. For example, on an English version of AD server, the OEMCP value is 437. In order to interop with it from a Linux system with UTF-8 default codepage, set up these system properties: -Dsun.security.krb5.msinterop.kstring=true -Dsun.security.krb5.msinterop.des.s2kcharset=iso-8859-1
02-10-2009
EVALUATION http://hg.openjdk.java.net/jdk7/tl/jdk/rev/56bad48e2810
02-10-2009