FreeTDS Development Group

["ZIGLIO, Frediano, VF-IT" <Frediano.Ziglio AT vodafone.com>]

> 
> On Wednesday 31 October 2007, Frediano Ziglio wrote:
> 
> > - I didn't understand how to generate a service/instance 
> name instead of
> > a principal one...
> 
> The remarks below reference to the GSSAPI as defined in RFC2744.
> 
> In GSSAPI the servicename is constructed by a call to
> 
> gss_import_name()
> 
> In GSSAPI the name that goes into this call is
> of format   servicename@hostnamefqdn.
> For example using GSSAPI for authenticating to a POP3 server of name
> "bla.example.com" means the string going into gss_import_name()
> becomes 
> 
> "pop AT bla.example.com".
> 
> (registered servicenames are available at 
> <http://www.iana.org/assignments/gssapi-service-names>)
> 
> If your GSSAPI lib maps the request to the Kerberos5 layer
> this results internally in a request to a Kerberosticket
> of servicepricipal pop/bla.example.com@REALM,
> But using the GSSAPI-Interface you don't become in touch
> with dealing with Kerberos5 directly.
> 

I finally found that using GSS_KRB5_NT_PRINCIPAL_NAME in gss_import_name
works correctly.
Having all gss_* functions means that I only need one library to load so
I can load it dynamically :)

> In other words here are the corresponding elements of names:
> 
> GSSAPI:
> =======
> 
> servicename@hostnamefqdn
> 
> Kerberos5:
> ==========
> 
> servicename/hostnamefqd@REALM
> 
> 
> The output of gss_import_name() is "output_name", a opaque
> struture that can be used to pass into
> 

I just realized that I can use getdomainname in order to translate from
hostname to full qualified hostname...

> gss_init_sec_context.
> 
> gss_init_sec_context returns the GSSAPI token ("output_token")
> that has to be passed into the tls message stream at the right place.
> 
> How many times (of roundtrip) gss_init_sec_context has to be called
> depends on the return value of gss_init_sec_contex.
> (For example if the uses of "SPNEGO" Athentication triggers a 
> Negotiation
> of authentication type that means to the programmer looping over
> gss_init_sec_context until the return values becomes "GSS_S_COMPLETE")
> (The signal for "do the loop again" is "GSS_S_CONTINUE_NEEDED")
> 

Currently I support only a single round-trip, server seems to agree but
it's not that fine...
There is also a problem selecting algorithm... currently if code is
enabled kerberos is preferred but is enable only giving any domain
user/password (even invalid) while IMO should be selected in some other
way...

> 
> In pseudcode the structure ist this:
> 
> #include <gssapi.h>
> 
> gss_import_name(...);
> major = gss_init_sec_context( &context_hdl,
>                               emptyinputtoken,
>                               outputtoken );
> errorchecking( major );
> put_token_into_tls_datastream( outputtoken );
> send_tls_datastream();
> read_tls_datastream();
> 
> while ( major == GSS_S_CONTINUE_NEEDED ) {
>     extract_servers_answertoken ( &serversidetoken );
>     major = gss_init_sec_context( &context_hdl, 
>                                   serversidetoken,
>                                   outputtoken );
>     errorchecking( major );
>     put_token_into_tls_datastream( outputtoken );
>     send_tls_datastream();
>     read_tls_datastream();
> }
> /* authentication finished, go on using the authenticated 
> connection  */
> 
> Achim

Mmmm... a bit more complicated cause these tokens are nested to sql
packets... currently NTLMSSP (without SPNEGO) is the only handled
authentication after login...

freddy77