Turning off hostname canonicalisation

[Andrew Bartlett]

On Fri, 2005-09-09 at 20:34 -0400, Jeffrey Altman wrote:
> Ken Raeburn wrote:
> > On Sep 9, 2005, at 20:10, Jeffrey Altman wrote:
> > 
> >> MIT has already implemented this functionality.
> >> We added
> >>
> >> [libdefaults]
> >>   rdns = {no, yes}
> >>
> >> It currently defaults to "on" but can be turned off in the profile.
> > 
> > 
> > No, this is different functionality.
> > 
> > MIT's current code does basically this:
> > 
> >   1) get hostname from user/app
> >   2) call getaddrinfo on hostname
> >   3) pull out ai_canonname, the canonical name, if non-null
> >   4) if rdns=yes:
> >     a) call getnameinfo(NI_NAMEREQD) on first address
> >     b) if successful, use returned name
> > 
> > What Andrew's proposing basically cuts this off after step 1.  The  user
> > provides a name, we drop it into a principal and send it off to  the KDC.
> > 
> > It sounds like a good thing, except ... if a host is being a Samba 
> > client, does that mean it's talking to the AD for all its Kerberos 
> > communication?  It won't be talking to, say, an MIT KDC that expects 
> > fully qualified canonical name to be used in the principal name?  
> > Changing /etc/krb5.conf will affect all Kerberos applications on the 
> > machine; if that's not the right result, then Samba would need its  own
> > config file, or we should use a different way to switch it off.
> > 
> > BTW, Andrew's original message seems to conflate "canonical" and  "fully
> > qualified" names.  A name can be fully qualified without being 
> > canonical.  I assumed from his description that he wants any sort of 
> > name lookup and transformation shut off....
> > 
> > Ken
> 
> 
> You are correct.  The "rdns" addition we made allows the configuration
> to disable the worst of the hacks.
> 
> I agree that we should have the ability to disable this after step 1
> as well.   There is a need for an application to be able to state
> explicitly what the hostname should be.  Especially in the Windows world
> which often relies on the first component of the hostname as obtained
> via a Netbios lookup not a DNS lookup.

Exactly.

In the past, Samba did this by calling the mk_req_extended (and then
using the name from the SPNEGO negtokeninit), but this was disgusting,
and at the wrong layer.  I'm trying in Samba4 to use real GSSAPI, and so
I need a way to specify this via that interface.  

I'm not sure if a krb5.conf option is the 'right way' to do this:  but I
can see it being useful beyond Samba, and for general GSSAPI apps in AD
realms.  Samba would set this to disable DNS in our wrapper for
krb5_init_context, perhaps only if there wasn't an explicit entry in the
krb5.conf.  (Setting options on the krb5_context under GSSAPI is another
matter, but I have to deal with that anyway).

How are MIT/Heimdal realms coping with windows clients, which I presume
don't do such fqdn resolution.  Is the concept of servicePrincipalName
spreading to cope, or are there just multiple principals and keytab
entries being created?

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Samba Developer, SuSE Labs, Novell Inc.        http://suse.de
Authentication Developer, Samba Team           http://samba.org
Student Network Administrator, Hawker College  http://hawkerc.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20050910/39224b47/attachment.bin