GSSAPI Mechanism

[Shirish Rai]

I have a fairly basic question. I have written a client (on Solaris) that
gets a service ticket from Microsoft Kerberos Server (Windows 2003). It then
tries to establish a context with the service using GSSAPI. 

 

The program fails because it cannot find the service ticket in the
credential cache. The reason it cannot find the ticket is because the
target_name that I pass to gss_init_sec_context is parsed differently than
the principal named that is retrieved from the cached. Specifically, the
target name after it is parsed is set to type KRB5_NT_SRV_HST (1)  and the
service principal from the credential cache is parsed to type
KRB5_NT_SRV_INST (3). This leads to the components in the principal to be
different. For example if my principal name is:

 

http/service.domain.com at DOMAIN.COM

 

The target_name has three components:

http/service.DOMAIN.COM

host.DOMAIN.COM

<some binary value>

 

Whereas the principal from the cache has two components

http

service.DOMAIN.COM

 

Therefore the call to krb5_principal_compare fails from
krb5int_cc_creds_match_request.

 

It seems that the parsing of the target_name is dependent on the mechanism
that I pass to gss_init_sec_context. I pass NULL which means the default
krb5 mechanism is picked up. 

 

Can someone point out what I am missing here. 

 

Thank you. 

 

Shirish.

 

 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5093 bytes
Desc: not available
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20091209/e3aba1f1/attachment.bin