GSSAPI Mechanism

[Shirish Rai]

Thanks Douglas. This is how I call gss_import_name. Is there something
obviously wrong?

#define PN "HTTP/service.domain.com"
gss_buffer_desc name_tok;
gss_name_t target_name;
OM_uint32 maj_stat, min_stat;
name_tok.value = PN;
name_tok.length = strlen(PN);
maj_stat = gss_import_name(&min_stat, &name_tok,
(gss_OID)gss_nt_service_name, 	&target_name);
if (maj_stat != GSS_S_COMPLETE) {
	...
}

Thanks. 

Shirish.

-----Original Message-----
From: Douglas E. Engert [mailto:deengert at anl.gov] 
Sent: Wednesday, December 09, 2009 1:49 PM
To: Shirish Rai
Cc: krbdev at mit.edu
Subject: Re: GSSAPI Mechanism



Shirish Rai wrote:
> 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

http is usually upper case, HTTP.

> 
>  
> 
> 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.
> 
>  

Sounds like you call to gss_import_name may be wrong.

Even though Kerberos principals used "service/fqdn at realm"
when calling gss_import_name, the string passed in would be
"service at fqdn" which gets mapped internally to service/fqdn at realm
where realm is determined by the krb5 libs.

> 
> 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.
> 
>  
> 
>  
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> 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
-------------- 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/e6513a70/attachment.bin