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
This is a digitally signed message part