gss_import_name() called with GSS_C_NT_USER_NAME

[Roland C. Dowdeswell]

On Mon, Nov 02, 2015 at 07:23:04AM +1300, Andrew Bartlett wrote:
>

> > On Tue, 2015-10-27 at 15:54 -0400, Roland C. Dowdeswell wrote:
> > instead of GSS_C_NT_HOSTBASED_SERVICE.
> > 
> > So, I'm debugging a problem where smbclient doesn't correctly
> > traverse my multiple realm environment but can only connect to
> > hosts in the same realm as the initiator.  I noticed the following
> > approximate pseudo-code snippet:
> >  
> >         sprintf(princ, "%s/%s@%s", service, host, realm);
> >         name_type = GSS_C_NT_USER_NAME;
> >  
> >         gss_import_name(..., princ, name_type, &name);
> >  
> > in source4/auth/gensec/gensec_gssapi.c lines 334-357 and
> > source3/librpc/crypto/gse.c lines 219-242.
> >  
> > In the source3 file, it has a comment indicating that it is
> > intentionally
> > avoiding using the GSSAPI libraries because they may do DNS.
> > 
> > I would like to ask that this decision be reconsidered because I
> > do not think that it makes sense in the modern world.  I have a
> > few Kerberos realms and applications which use GSSAPI normally have
> > no difficulty traversing them either via DNS or KDC referrals.
> 
> The issue is that while this works flawlessly in some Unix Kerberos
> realms, in AD, the behaviour expected of clients is quite different -
> you are expected to connect to your own KDC, and it will give the
> referral.

This is what GSS_C_NT_HOSTBASED_SERVICE is supposed to address.
When you say gss_import_name(..., GSS_C_NT_HOSTBASED_SERVICE,
"cifs at host.example.com", ...), what you are really telling the
Kerberos libraries is "Get me a ticket in whatever realm host.example.com
is in using your logic to determine which realm that is."  Older
Kerberos libraries use the [domain_realm] and [capaths] sections
of /etc/krb5.conf.  Newer Kerberos libraries will issue a request
to their closest KDC without specifying the realm asking for a
referal.

When a client issues a request to the KDC with GSS_C_NT_USER_NAME, it
is actually telling the KDC that it is not supposed to canonicalise or
change the name.  It may very well be the case that AD ignores this flag
but I don't think that MIT krb5 or Heimdal do.

What Samba is doing at the moment is specifying the realm which
causes the system libraries to ignore the administrator's settings.

It probably does make sense to leave some logic in for the user to
specify the remote principal on the command line and/or via a Samba
configuration file for certain cases, but I don't think that it
makes sense to do this by default.

> That is why it is done that way, and a change would break a number of
> working AD networks, I fear.

I don't actually think that this breaks anything.  It would
just mean that people using older Kerberos implementations that
do not have referals would need to specify their x-realm setup
in /etc/krb5.conf.

Granted, a change of the default behaviour could cause some level
of user confusion, but this would fix a number of issues.

--
    Roland Dowdeswell                      http://Imrryr.ORG/~elric/