GSSAPI Mechanism

[Shirish Rai]

Its working better now. The trick was to change this: 

> maj_stat = gss_import_name(&min_stat, &name_tok,
> (gss_OID)gss_nt_service_name, 	&target_name);

To 

maj_stat = gss_import_name(&min_stat, &name_tok,
(gss_OID)gss_nt_user_name, 	&target_name);

What I found was that the MIT Kerberos library requests the service ticket
as type 1 and the ticket is returned as type 1. A side note, the JAVA
Kerberos library does the same request with type 0 (UNKNOWN) and is returned
a ticket with type set to 0. So on the client side I have to parse the name
as gss_nt_user_name as opposed to gss_nt_service_name. 

Thanks you for your help. 

Shirish.


-----Original Message-----
From: Douglas E. Engert [mailto:deengert at anl.gov] 
Sent: Thursday, December 10, 2009 6:47 AM
To: Shirish Rai
Cc: krbdev at mit.edu
Subject: Re: GSSAPI Mechanism



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
-------------- 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/20091210/1a6f6cc9/attachment.bin