On Wed, 2011-11-16 at 11:08 -0500, simo wrote: > On Wed, 2011-11-16 at 08:37 +1100, Andrew Bartlett wrote: > > On Tue, 2011-11-15 at 09:15 -0500, Jeff Layton wrote: > > > > > Ok, based on the comments so far, how does this sound for a potential > > > scheme: > > > > > > INPUT: foo > > > TRY: > > > FOO$ > > > cifs/foo.[guessed domain] > > > > > > INPUT: foo.example.com > > > TRY: > > > cifs/foo.example.com > > > > > > To summarize, for shortnames, we'd try SHORTNAME$ first. If that fails, > > > then guess a domain name, append the value to the hostname, and prepend > > > it with "cifs/". > > > > No, we should never use FOO$ (this is AD only, and equivalent to > > cifs/foo), so we should instead simply do: > > > > INPUT: foo > > TRY: > > cifs/foo > > This ^^^^ is also AD-only, so what's the point of objecting to one or > another ? > At least when you see FOO$@REALM, admins know it is an AD only thing. The reason that we should not translate between foo and foo$ on the client side is that a server may have multiple service principal names. A host with multiple names will have only one machine account in AD, and we have no way to know that this particular name is that of the machine account. Also, while requests for cifs/foo will cause a lookup of host/foo and foo$ on the server side, this is a server-side fallback, not an absolute rule. If an account has the more specific form as a servicePrincipalName, then implicit mappings are not needed. We cannot on a client make assumptions about how the administrator has configured their domain. Finally, cifs/foo is a perfectly valid and reasonable kerberos service principal name, and the name that other cifs clients such as Samba 3.6, and Windows will use, and so we should ensure constancy with those clients to reduce the administrator burden in the non-AD case. Indeed, it is this final reason why this process is futile. The correct fix is to ensure that the non-AD KDC has principal entries for each aliases (cifs/foo and cifs/foo.domain) by which the server can be resolved. Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
