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.