gss_import_name() called with GSS_C_NT_USER_NAME

[Alexander Bokovoy]

On Tue, 03 Nov 2015, Roland C. Dowdeswell wrote:
> 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.
MIT has support for client referrals but it was actually broken
until recently. I did implement support for trusted forests referrals in
FreeIPA 4.2.2 and that required a fix in MIT Kerberos KDC code.
Standard KDC drivers in MIT Kerberos don't have support for client
referral in their databases so nobody noticed it before.

See 4e036ef4127a9b09d1a567472da1df24c55cdb89 in MIT Kerberos git.

In Samba the support for client referrals was added by Metze for
cross-forest trusts this year. Standalone Heimdal has support for client
referral propagation but no support in the default database driver.

> 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.
I think your finding wiht GSS_C_NT_HOSTBASED_SERVICE is actually a
correct one.

-- 
/ Alexander Bokovoy