Windows xp ticket cache read causes crash
UPDATE Old title: Error calling function Protocol status: 1312 FormatMessage failed with 1815
I have written an application that authenticates to kerberos using the KerberosLoginModule. It used to work fine on all OS磗. (Windows 98, 2k, xp and Linux tested.)
Now I have upgraded my application to java 1.5 code. And it still works fine on all tested OS磗, except Windows xp. Wich in first case does not even throw磗 a error. It just exits in javaws. If I run it manually with java -jar I get the following output:
Error calling function Protocol status: 1312
FormatMessage failed with 1815
UPDATE:
After some more messing around I found out it craches because it want to read the ticket cache.
Now I can understand there are some differences in ticket cache versions, but then java could choose not to read the ticket, like under linux. But why does it crash under Windows XP if it only try's to read a ticket?
Now I can only choose between no ticket cache at all on all os's, or to build in a Windows XP filter for the ticket cache option.
Both not very good solutions. Why is this and how can it be solved?
Message was edited by:
mivz@spugium.net
This is not an issue with the ticket cache version. Java Kerberos can read the native ticket cache. The problem here is with the Windows API FormatMessage usage in a different locale.
If you switch to an English US locale, you'll not get this error.
Note: Kerberos is not internationlized. In order to use Kerberos, it would be best
to use English locale.
Seema
Thank you for the information. Much appreciation.
Wouldn't this mean that that internationalized application's can't use Kerberos authentication?
Why, if kerberos isn't Internationalized, it uses the Locale anyway?
If kerberos does not support it, and even craches the jvm, should the kerberos libarary not ensure that the English Locale is always used?
Kerberos V is not internationalized. Applications are expected to provide ASCII characters with Kerberos, which is in compliance with the specification. Non-ASCII username/passwords are not supported under the present definition.Seema
Hi Seema,I also get this error and I am using only ASCII characters as username/password. I this then a defect in the Kerberos Login Module or depends the Kerberos Login Module on Locale.getDefault() to be Locale.US ?Regards Oliver
The problem here is with the Windows API (FormatMessage) that reports error.
We are in the process of fixing this error reporting, so you get the error message in
your locale.
However, the underlying problem is that the Windows API failed to return the native ticket.
The Kerberos Login Module calls the Windows API to read the native ticket cache.
When the Windows API fails, and it reports an error.
If you want to use the native Kerberos ticket, you'll need to switch your locale.
Seema
Hey,
is there any news regarding this topic? I am getting the same error on WinXP Prof. while trying to authenticate against Active Directory using JAAS (both 1.4.2 and 1.5.0).
However, both tools klist and kerbtray report that there are no tickets stored on my machine. Is there any connection?
Could anyone provide a solution or workaround?
Many thanks,
Seb
It's fixed in 5.0 Update 10, not backported to 1.4.2.
Thank you! Using 1.5.0_11 fixed my issue but led me to the next problem:
I am able to read the ticket cache now, but somehow it's emtpy. The code returns
Acquire TGT from Cache
Principal is null
null credentials from Ticket Cache
followed by
Acquire TGT using AS Exchange
[Krb5LoginModule] authentication failed
null (68)
javax.security.auth.login.LoginException: null (68)
Caused by: KrbException: null (68)
Caused by: KrbException: Identifier doesn't match expected value (906)
Error calling function Protocol status: 1312
Eine angegebene Anmeldesitzung ist nicht vorhanden. Sie wurde gegebenenfalls bereits beendet.
However, I think this is a different case, thanks anyway!
Seb
Haha, of course you won't see the ticket.
In fact, this bug happens when Java tries to use the Windows API FormatMessage to inform the user that a valid logon session is not found. Unfortunately, a bug before 5.0_u11 prevents the message from being printed out and thus crash (the "eine..." you see now is the same message in your own locale). If the ticket exists, you would never have the chance to come to this bug!
You've mentioned that you cannot find a key in kerbtray. There must be some problem in your login process. If you are using WIndows XP as the client, are you sure you login to a Windows 2000 or 2003 realm (instead of a local XP account)?
Gesundheit.
I am certain to log on to one of the server versions you mentioned, but made an appointment with our admins next week to figure out what's wrong with my login process/their configurations.Actually quite funny to see German error messages while working solely in English...
The meeting was quite successful as I can obtain a a ticket from the Win2k KDC now by Acquire TGT using AS Exchange
(I have to enter my logon username/password because we have a Novell Logon and not WinLogon...) which results in Commit Succeeded
.
But the ticket is not stored in the Windows XP credential/ticket cache, klist tgt says "Error calling function LsaCallAuthenticationPackage: 0
Format message failed with 1815", klist tickets says "Cached tickets: (0)" and kerbtray is empty!
And I stll receive the same error messages as mentioned earlier: "Error calling function Protocol status: 1312
Eine angegebene Anmeldesitzung ist nicht vorhanden. Sie wurde gegebenenfalls bereits beendet."
Do you have any suggestions/ideas what could be wrong with my system/configuration?
Message was edited by:
Santacruzshores
Message was edited by:
Santacruzshores
Well, as I know:
1. Krb5LoginModule can use cached tickets, either native LSA cache from WinLogon, or MIT-style file-based cache.
2. Krb5LoginModule can also get a fresh new ticket through AS_REQ/AS_REP
3. Krb5LoginModule will NOT automatically store the ticket to any cache. Therefore, you won't be able to klist it
4. If you do want to store the ticket to a cache (without WinLogon). Call kinit (which comes with the Windows version of JRE). This command stores a ticket in a MIT-style file named $HOME/krb_ccachexx (or something else, I cannot remember exactly). Then, K5b5LoginModule can use this cache.
getting closer! Thanks for that reply!
I didn't get that the Windows native cache is only filled when using WinLogon (which I will use at a later stage) and that Krb5LoginModule actually does not store anything to any cache!
When I call kinit, a ticket is stored in a file-based cache which I can read with Krb5. Somehow, I have a quite strange workaround: I call kinit programmatically,
String[] args = new String[2];
args[0] = "principal@realm.com";
args[1] = "password";
Kinit.main(args);
which I found here: http://forum.java.sun.com/thread.jspa?threadID=509736&start=15&tstart=0.
However, I think I can live with it for the first! Thanks again for these valuable answers!
Congrats!However, I don't quite encourage using the Kinit.main() method in any real (commercial) program. It's a Sun-internal method supported by nobody. It may even go away at any time (it already goes away in Linux).
Hey,
I have some kind of workaround for the
Error calling function Protocol status: 1312
FormatMessage failed with 1815
problem. Just write an empty file to the $user.home directory which is called just like the file Kinit would create, i.e. krb5cc_$user.name.
String krb5FileLoc = System.getProperty("user.home") + "\\krb5cc_"+ System.getProperty("user.name");
File krb5File = new File(krb5FileLoc);
if(!krb5File.exists())
new FileWriter(krb5FileLoc);
Then you gotta call the LoginModule without using the ticket cache (JAAS-config: useTicketCache=false) and run Kinit to obtain a new ticket.
Works for me,
cheers!
