On 2009-02-13 19:41:41 +0100, Ken Raeburn <[email protected]> said: > > On Feb 13, 2009, at 06:23, Lorenzo Costanzia wrote: > >> Hi everybody, >> >> I'm trying to set up a AFP server with (MIT) Kerberos authentication >> and DNS service discovery (aka Bonjour, see http://www.dns-sd.org/) in >> my home network (which uses a private .lan top level domain). The AFP >> server works beautifully when connecting "directly" to it. >> >> But when I try to connect to the AFP after discovery via dns-sd, the >> client tries to fetch a >> "afpserver/[email protected]" ticket (note the trailing dot in the >> SPN), which doesn't exist, so authentication fails. (This is btw the >> correct behavior of dns-sd, which always gives back the more verbose >> "form" of the hostname with trailing dot.) > > I'm not familiar with dns-sd, but my first thought would be that the > correct behavior for the resolver APIs for producing fully-qualified > DNS names is to omit the dot. (There is the argument that the > trailing dot indicates it's anchored at the root instead of possibly a > relative name, but in some cases where a name is unambiguously known > to be fully-qualified, including some standard APIs, the trailing dot > is omitted.) I've looked at a few pages on the dns-sd.org web pages, > and it just sounds to me like they're just being aggressive about > making the names explicitly fully-qualified when the option is > available. But they're talking about GUIs like web browsers, and I'm > interested in programming APIs.
You're right. I stated above that the "dotted form" is the correct behavior, but in the RFC doesn't explicitly say so. But as far as I understood, Apples implementation (which is the main proponent of Bonjour) _does_ return the dotted form, so their applications like Safari, iChat and especially the AFP client built into the Finder use also this form. There is not much I can do about it. > The standard DNS-host-based principal representation in Kerberos is > for the second component to be the fully-qualified domain name, > without the trailing dot. > > At some point, the hostname gets translated into a principal name. It > might be the right answer for the trailing dot to be omitted at that > point -- but then, without knowing why or how dns-sd is special in one > case, I have no idea whether it should be treated specially in the > other case. I personally think this would be the right way, as the dot explicitly states: this is a FQDN, there's no need to canonicalize the hostname further, simply remove the trailing dot and use it. And I guess there are not many way this root label (the dot) would get appended if it _were not_ a FQDN, so it should work out in most situations. But your mileage may vary, and of course when introducing a new arbitrary (albeit somewhat understandable) rule one should always balance benefits and drawbacks (in this case potential confusion)... > Actually, it looks like we *have* code in one of the code paths (in > the library function krb5_sname_to_principal) for removing a trailing > dot, because the Windows APIs (in at least one beta version) behaved > differently from everyone else. So I don't think they're using that > function to generate principal names. Which leads to the question of > how the AFP client *is* generating principal names; perhaps it's a bug > in that code? Do you have access to the AFP client code, to see what > it's doing? No, it's proprietary software, and I'm using Mac OS X. As said above, I guess that this behavior is intentional, see http://developer.apple.com/documentation/Cocoa/Conceptual/NetServices/Articles/domainnames.html#//apple_ref/doc/uid/TP40002460 where they explain specifically the meaning of the trailing dot. >> Now I can't simply add "afpserver/afp.lan." principal, as the AFP >> server accepts only one principal, > > That's arguably a bug, as even with ordinary DNS a host could have > multiple names mapping to its IP address(es). I agree. >> and I want to be able to connect >> both "directly" and via dns-sd. > > >> However, when the client connects to the KDC asking for that >> nonexistent service principal, the "canonicalization" flag is set, but >> the KDC doesn't care and reports KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN. >> >> Now is there a way to activate kdc-side canonicalization and/or setup a >> static alias between "afpserver/afp.lan." and "afpserver/afp.lan"? > > Not currently, no. In the 1.7 alpha release we recently put out, > there are hooks for the database back end (which may be turning into > "the interface to the rest of all your infrastructure including > Kerberos principal data and other things") to do alias processing, but > we don't have any alias processing currently defined in the database > back ends we ship, nor any general heuristics applied in the main KDC > code. > > If you feel like writing KDC code, I could probably tell you where to > look to drop it in... Thanks for the offer, however, I'm not a programmer... > > Ken Thank you for your long and informative answer. Take care, Lorenzo Costanzia ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
