GSSAPI Mechanism

[Douglas E. Engert]

Shirish Rai wrote:
> Thanks Douglas. This is how I call gss_import_name. Is there something
> obviously wrong?
> 
> #define PN "HTTP/service.domain.com"

Yes, try this:
#define PN "HTTP at 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