JDK-6793475 : krb5.ini not found on some Windows
  • Type: Bug
  • Component: security-libs
  • Sub-Component: org.ietf.jgss:krb5
  • Affected Version: 7
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_2008
  • CPU: generic
  • Submitted: 2009-01-14
  • Updated: 2017-05-19
  • Resolved: 2009-01-31
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 Availabitlity Release.

To download the current JDK release, click here.
7 b46Fixed
We're now looking for the location of krb5.ini on Windows like this:

   len = GetWindowsDirectory(NULL, 0);
   TCHAR* path = new TCHAR(len);
   GetWindowsDirectory(path, len);
   // krb5.ini should be in path now

However, in some Windows Server 2008 SP1 installations, a strange behavior is observed:

   GetWindowsDirectory(NULL, 0) return 11, looks like length of "C:\Windows" + 1
   GetWindowsDirectory(path, 11) returns 12, and fills path with ""
   GetWindowsDirectory(longpath, 999) returns 20, and fills path with "C:\Users\Me\Windows"

The reason is unknown yet, but the result is Java looks for krb5.ini in "", and -- unfound.
This only happens in Windows 2008 (and Vista) when Terminal Services are installed.

EVALUATION http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9260d9bd0843

WORK AROUND Place krb5.conf in $jre/lib/security, Java looks for this file at this location first.

EVALUATION Evaluating this bug brings out a question: what exactly is the Windows directory? The common sense would be C:\Windows. However, MSDN says "The Windows directory is the directory where an application should store initialization and help files. If the user is running a shared version of the system, the Windows directory is guaranteed to be private for each user". Furthermore, "If the application is running in a Terminal Services environment, each user has a private Windows directory. There is also a shared Windows directory for the system. If the application is Terminal-Services-aware (has the IMAGE_DLLCHARACTERISTICS_TERMINAL_SERVER_AWARE flag set in the image header), this function returns the path of the system Windows directory, just as the GetSystemWindowsDirectory function does. Otherwise, it retrieves the path of the private Windows directory for the user". In the case of this bug, the Windows directory turns into "C:\Users\UserName\Windows". The Kerberos 5 config file -- krb5.ini -- is a system-wide configuration that should have gone into the "real" Windows directory, which is the result of GetSystemWindowsDirectory. For compatibility reasons, we would first search krb5.ini in GetWindowsDirectory(), and then, if not found, look for it in GetSystemWindowsDirectory(). After this fix, we can make sure the system-wide krb5.ini can always be reached. It would be picked up as the Kerberos 5 config file unless overrided by 1) java.security.krb5.conf, 2) $JRE/lib/security/krb5.conf, or 3) krb5.ini in the user-private Windows directory. BTW, the MIT Kerberos implementation still uses GetWindowsDirectory but they have a registry item for leash32.exe.

EVALUATION No regression test. Need a Windows 2008 with Terminal Services turn on, and a Kerberos config file in the Windows directory.

EVALUATION According to MSDN on GetWindowsDirectory(), the preferred way to call it is -- TCHAR path[MAX_PATH+1]; GetWindowsDirectory(path, MAX_PATH) This code snippet works fine on the questionable Windows Server 2008.