Error calling function protocol status: 1312
Douglas E. Engert
deengert at anl.gov
Wed Oct 21 16:22:32 EDT 2009
Santiago Rivas wrote:
> After enabling debug mode, this is what I've got:
>
> Case 1: No principal is specified in jaas.conf
>
> *Debug is true storeKey false useTicketCache true useKeyTab false
> doNotPrompt fa
> lse ticketCache is null isInitiator true KeyTab is null refreshKrb5Config is
> fal
> se principal is null tryFirstPass is false useFirstPass is false storePass
> is fa
> lse clearPass is false
> Acquire TGT from Cache
> Error calling function Protocol status: 1312
> A specified logon session does not exist. It may already have been
> terminated
> Principal is null
> null credentials from Ticket Cache
> Username for Kerberos [santi]:*
>
> Case 2: Principal "santi" is specified in jaas.conf
>
> *Debug is true storeKey false useTicketCache true useKeyTab false
> doNotPrompt fa
> lse ticketCache is null isInitiator true KeyTab is null refreshKrb5Config is
> fal
> se principal is **santi at zigia.org* <santi at zigia.org>* tryFirstPass is false
> useFirstPass is false stor
> ePass is false clearPass is false
> Acquire TGT from Cache
> Error calling function Protocol status: 1312
> A specified logon session does not exist. It may already have been
> terminated
> Principal is **santi at zigia.org* <santi at zigia.org>
> *null credentials from Ticket Cache
> Kerberos password for **santi at zigia.org* <santi at zigia.org>*:*
> IMHO, it seems like JVM is not able to parse the credentials file generated
> by NIM. Referring to the credentials cache, is there any "known
> incompatibility" between NIM and JVM which I should be aware of?
>
> Thanks again!
>
This could be an issue of the cache version. NIM looks like it is writing
a type 4 cache. (First two bytes in the file are 0x05 0x04. The 0x04 is the
version.) It could be Java only knows how to handle versions up to 3.
In the MIT krb5.conf used by NIM, try adding to [libdefaults] sectiom:
ccache_type = 3
NIM will then write a type 3 cache.
(This is not the only Kerberos feature that Java is way behind on either.
Using dns_lookup_kdc = 1 to use the DNS SRV records is a major one
especially on Windows...)
> Regards,
> Santi
>
>
> 2009/10/19 Max (Weijun) Wang <Weijun.Wang at sun.com>
>
>> Java first looks for cache from the file and then from LSA. If you see the
>> 1312 error it means there's no cache in the file. Maybe the principal name
>> is not the same with your JAAS conf setting? Or, NIM generates a file Java
>> cannot parse.
>>
>> Can you show the content of the cache with klist.exe in JDK (not the one
>> from Microsoft)? Also, add -Dsun.security.krb5.debug=true to your Java
>> program and see what debug output is saying.
>>
>> -- Max
>>
>>
>> On Oct 19, 2009, at 6:21 PM, Santiago Rivas wrote:
>>
>> It did help, Max!
>>> I started using kinit.exe from JDK and verified that credentials cache is
>>> stored, by default, in:
>>>
>>> "C:\Documents and Settings\santi\krb5cc_santi" <=>
>>> %HOMEPATH%\krb5cc_<user>
>>>
>>> Nothing new until here. But good news are that now JVM is able to read
>>> credentials and obtain TGT from that cache (which was my purpose). As you
>>> pointed out, my jaas.conf only specifies "useTicketCache=true", without any
>>> path to file, since I'm using the default settings.
>>> However, it's weird because if I set NIM to store credentials in the same
>>> location, the file is actually created, but then JVM throws the "1312
>>> status" when it tries to read the cache. And this time the reason cannot be
>>> that "it's not finding the credentials cache" ... ¿?
>>>
>>> Regards,
>>> Santi
>>>
>>>
>>> 2009/10/17 Max (Weijun) Wang <Weijun.Wang at sun.com>
>>> Sorry I'm not an expert on NIM.
>>>
>>>
>>> On Oct 17, 2009, at 1:56 AM, Santiago Rivas wrote:
>>>
>>> By the moment, my purpose is to *generate a TGT (anyhow, using kinit or
>>> NIM)
>>> and configure the cache so those credentials are stored in a file*,
>>>
>>> Then you can use any kinit.exe, the one from JDK or MIT. To use a file
>>> cache, you don't need to care about the registry key mentioned by Douglas at
>>> all.
>>>
>>> In fact, I had thought you were trying to use the LSA cache (non-file
>>> in-memory Windows-specific cache). BTW, if you do want to use the LSA cache,
>>> please make sure that the file cache is not there, since Java always try to
>>> use the file cache first. You can check this out by calling the klist.exe
>>> command in JDK.
>>>
>>>
>>> where Java will read them from later.
>>>
>>> *Step 1: Configure credentials cache*
>>>
>>> Since you told me to "*update the Identity object to use a FILE: ccache*",
>>> I
>>> went to
>>>
>>> NIM: Options->Identities->santi at ZIGIA.ORG (which is my test principal)
>>>
>>> On "Kerberos v5" folder, I set the "Credential cache" option to
>>> *FILE:ccache
>>> *. And now I can see that a file named ccache is created or deleted
>>> everytime I generate or destroy the TGT. So I think now I have credentials
>>> cache configured properly. Am I right?
>>>
>>> *Step 2: Configure JAAS so that TGT is read from file (in order to obtain
>>> a
>>> TGS)*
>>>
>>> Here is my *jaas.conf* file for the client:
>>>
>>> *Client {*
>>> * com.sun.security.auth.module.Krb5LoginModule required*
>>> * useTicketCache=true*
>>> * ticketCache="c:\docume~1\santi\ccache";*
>>> *}*
>>>
>>> But when I run the client I get the following exception:
>>>
>>> *java.lang.SecurityException: Configuration Error :*
>>> * Line 4: expected [option key], found [null]*
>>> * at com.sun.security.auth.login.ConfigFile.<init>(Unknown Source)*
>>> * ...*
>>>
>>> I think Java is complaining about the ticketCache value. It does not like
>>> Windows style "\" in path. You can try "\\" or "/".
>>>
>>> In fact, if you have not provided special argument to kinit, the cache
>>> file should be generated at the default location, and you don't need to
>>> specify ticketCache in the JAAS conf file at all.
>>>
>>> To debug, add "debug=true" into the JAAS conf file, *and* add
>>> -Dsun.security.krb5.debug=true into you Java command line, you will see a
>>> lot of things.
>>>
>>> Hope this helps
>>>
>>> Weijun (aka Max)
>>>
>>>
>>> I guess there some information missing about the credentials, but I don't
>>> know what. Any idea?
>>>
>>> I never tire for saying thank you!
>>>
>>> Regards,
>>> Santi
>>>
>>> 2009/10/16 Douglas E. Engert <deengert at anl.gov>
>>>
>>>
>>>
>>> Santiago Rivas wrote:
>>>
>>> Ok, here is what I've done:
>>> I changed the JAAS config file, setting "useTicketCache=<somePath>". That
>>> was enough to make de 1312 status error dissappear. But I'm still not able
>>> to configure the ticket caching properly.
>>> I forgot to mention that I have had already tried to set some file path
>>> under
>>> NIM: Options->Kerberos v5->Credential Cache ... with no results.
>>> I typed the path "C:\Documents and Settings\user\krb5cc_1000" into the
>>> text box and clicked the "Add" button, but it said something like "the
>>> credentials cache file was not found". If I only set the path to some
>>> folder
>>> (with no file name) there is no error message, but when I generate new
>>> tickets no file is created. I've reset the machine and verified that the
>>> user has privileges to access the path I'm typing son I don't known where
>>> I'm mistaking... ¿?
>>>
>>>
>>> Did you make the registry setting change as suggested bu both NIM and
>>> Java?
>>>
>>> I don't think Java actually writes tickets to the cache. It just reads a
>>> TGT
>>> from the cache, then keeps tickets in memory. (I could be wrong)
>>> The Java kinit.exe will write the TGT but I have never needed to use it.
>>> Windows and NIM/KfW also have kinit.exe files so be careful which one you
>>> are using.
>>>
>>> Thanks, Douglas, for introducing Jeff Altman and Weijun Wang to me.
>>> Regards,
>>> Santi
>>> 2009/10/14 Douglas E. Engert <deengert at anl.gov <mailto:deengert at anl.gov
>>>
>>>
>>> P.S. The other responder to your note, Weijun Wang, is the
>>> author of the Sun web page I listed below. Small world!
>>>
>>>
>>> Douglas E. Engert wrote:
>>>
>>>
>>> Santiago Rivas wrote:
>>>
>>> So, if I didn't misunderstood your words, I basically have
>>> at least 2
>>> alternatives to achieve ticket collection from cache under
>>> Windows XP
>>> environment:
>>>
>>> 1) Configure Network Identity Manager to store credentials
>>> into a file, in
>>> order to read them from Java.
>>>
>>>
>>> One of the other responder to your first e-mail, Jeff Altman, is
>>> the
>>> developer of Network Identity Manager, and said:
>>> " Network Identity Manager can be configured to store the user's
>>> credentials in a FILE:<drive>:<path> cache which can then be
>>> accessed via Java."
>>>
>>> Start by looking under Options->Kerberos v5->Credential Cache
>>>
>>> 2) Set up the configuration so that logon session is
>>> authenticated with
>>> Kerberos, and then retrieve the TGT ticket from LSA querying
>>> via JAAS.
>>>
>>>
>>> Also see this:
>>>
>>>
>>> http://java.sun.com/javase/6/docs/technotes/guides/security/kerberos/jgss-windows.html
>>>
>>> It talks about using the LSA, or the ticketCache=file options and
>>> the use of the "TGT accessibility" registry setting for
>>> allowtgtsessionkey.
>>> Network Identity Manager also uses this registry setting.
>>>
>>> (This registry setting may be you main issue!)
>>>
>>> Personally, I'm more interested on the second option, since
>>> the main target
>>> is to achieve single sign-on with kerberos. Anyway, I would
>>> appreciate to
>>> read some documentation on both tasks. Could you please tell
>>> me where I can
>>> find it?
>>>
>>>
>>> A third option is to use the Microsoft runas /netonly
>>> /user:user at realm program
>>> This will run the program with a new LSA. Program could be
>>> cmd.exe or even
>>> explorer.exe
>>>
>>>
>>> Thanks a lot, guys!
>>>
>>> Regards,
>>> Santi
>>>
>>>
>>> 2009/10/14 Douglas E. Engert <deengert at anl.gov
>>> <mailto:deengert at anl.gov>>
>>>
>>>
>>> Santiago Rivas wrote:
>>>
>>> Well, I do specify "useTicketCache=true" in the JAAS
>>> config file, but
>>> there
>>> is something I must be missing, cause I cannot get
>>> it working with cached
>>> tickets. In fact, I must provide username and
>>> password in the config file
>>> (or via command line).
>>>
>>> I can obtain TGT tickets with both Leash32 and
>>> Network Identity Manager
>>> tools, but I cannot see where they are stored, if
>>> cached (just the same as
>>> /tmp/krb5cc_1000 file in Linux...) ¿?
>>>
>>> On Unix, with JXplorer, I can add
>>> -Duser.krb5ccname=$KRB5CCNAME
>>> to the command line, and the JXplorer gssapi.conf has:
>>>
>>> com.ca.commons.jndi.JNDIOps {
>>> com.sun.security.auth.module.Krb5LoginModule required
>>> client=TRUE
>>> ticketCache="${user.krb5ccname}"
>>> doNotPrompt=TRUE
>>> useTicketCache=TRUE;
>>> };
>>>
>>> On Windows it does not have the ticketCache= line,
>>> but I think it could try it.
>>>
>>> If Leash32 or Network Identity Manager is storing them
>>> in a file,
>>> say \tmp\krb5cc_username
>>> you could try ticketCache=\tmp\krb5cc_username
>>>
>>>
>>>
>>>
>>> So may be the question should be: How do I configure
>>> the ticket cache in
>>> Windows? Is it mandatory to be configured through LSA?
>>>
>>> Thank you very much, Max!
>>>
>>> Regards,
>>> Santi
>>>
>>> 2009/10/14 Max (Weijun) Wang <Weijun.Wang at sun.com
>>> <mailto:Weijun.Wang at sun.com>>
>>>
>>>
>>> Java tries to get the credentials cache (ccache)
>>> from Windows LSA if you
>>>
>>> specify useTicketCache=true in the JAAS config
>>> file. In some cases, Java
>>> believes there's a ccache at the beginning, but
>>> finally it cannot get
>>> one.
>>> For example, you login as a AD account but then
>>> purge the TGT using klist
>>> or
>>> kerbtray. Then, you will see this error.
>>>
>>> Without the ccache, Java will try the Kerberos
>>> login itself, you'll need
>>> to
>>> provide username and password in your program.
>>>
>>> -- Max
>>>
>>> On Oct 14, 2009, at 6:55 PM, Santiago Rivas wrote:
>>>
>>> Hi again,
>>>
>>> After some tough work, it seems I've got my
>>> test environment configured
>>> and
>>> working with DHCP server, DNS server, ldap
>>> and Domain Controller,
>>> running
>>> on
>>> a GNU Linux Debian platform. I've also
>>> configured KDC + AS services on
>>> that
>>> machine, and I'm glad to see that I'm able
>>> to create a secure context
>>> between the server and other GNU Linux
>>> machine. I'm using GSS-API in
>>> Java
>>> 1.6, and everything works fine.
>>>
>>> The problem comes when I run the same Java
>>> code on a Windows XP SP3
>>> platform
>>> with jdk 1.5.0_21 version installed. Just
>>> before the context is created,
>>> I
>>> get the message:
>>>
>>> *Error calling function protocol status:
>>> 1312. A specified logon session
>>> does not exist. It may already have been
>>> terminated.*
>>>
>>> But the most curious thing is that execution
>>> continues and secure
>>> context
>>> is
>>> created indeed. I've also checked
>>> *krb5kdc.log* and verified that both
>>> TGT
>>> ans TGS tickets are generated and delivered
>>> correctly.
>>>
>>> I've searched the web and I've found many
>>> posible explanations, like:
>>>
>>> *"There is a problem with Windows API
>>> FormatMessage usage in a non
>>> English
>>> locale"* - forums.sun
>>> *"The identity associated with a
>>> **KerberosToken2*<
>>>
>>>
>>>
>>> http://msdn.microsoft.com/en-us/library/microsoft.web.services2.security.tokens.kerberostoken2.aspx
>>> * security token is being used for
>>> constrained delegation, but
>>> constrained
>>> delegation is not configured correctly."* -
>>> msdn
>>> *"There is a bug in Java 1.5"* - other source
>>>
>>> ... but none of them convinces me.
>>> So the cuestion is: Why is that message
>>> appearing? Should I worry about
>>> it?
>>> How can I solve it?
>>>
>>> Thanks in advance!
>>>
>>> Regards,
>>> Santi
>>> _______________________________________________
>>> krbdev mailing list
>>> krbdev at mit.edu <mailto:krbdev at mit.edu>
>>>
>>> https://mailman.mit.edu/mailman/listinfo/krbdev
>>>
>>>
>>> _______________________________________________
>>>
>>> krbdev mailing list krbdev at mit.edu
>>> <mailto:krbdev at mit.edu>
>>> https://mailman.mit.edu/mailman/listinfo/krbdev
>>>
>>>
>>>
>>> --
>>>
>>> Douglas E. Engert <DEEngert at anl.gov
>>> <mailto:DEEngert at anl.gov>>
>>> Argonne National Laboratory
>>> 9700 South Cass Avenue
>>> Argonne, Illinois 60439
>>> (630) 252-5444
>>>
>>> _______________________________________________
>>> krbdev mailing list krbdev at mit.edu
>>> <mailto:krbdev at mit.edu>
>>> https://mailman.mit.edu/mailman/listinfo/krbdev
>>>
>>>
>>>
>>>
>>> --
>>> Douglas E. Engert <DEEngert at anl.gov <mailto:DEEngert at anl.gov>>
>>> Argonne National Laboratory
>>> 9700 South Cass Avenue
>>> Argonne, Illinois 60439
>>> (630) 252-5444
>>>
>>>
>>>
>>> --
>>>
>>> Douglas E. Engert <DEEngert at anl.gov>
>>> Argonne National Laboratory
>>> 9700 South Cass Avenue
>>> Argonne, Illinois 60439
>>> (630) 252-5444
>>>
>>> _______________________________________________
>>> krbdev mailing list krbdev at mit.edu
>>> https://mailman.mit.edu/mailman/listinfo/krbdev
>>>
>>>
>>>
> _______________________________________________
> krbdev mailing list krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev
>
>
--
Douglas E. Engert <DEEngert at anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
More information about the krbdev
mailing list