Skip to Content.
Sympa Menu

freetds - Re: [freetds] tds9 and gssapi

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "ZIGLIO, Frediano, VF-IT" <Frediano.Ziglio AT vodafone.com>
  • To: <achim AT grolmsnet.de>, "FreeTDS Development Group" <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] tds9 and gssapi
  • Date: Tue, 6 Nov 2007 17:25:26 +0100

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




Archive powered by MHonArc 2.6.24.

Top of Page