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/afp.l...@myrealm.lan" 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. 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. 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? > 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). > 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... Ken ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos