On Sun, 18 Aug 2013 09:08:39 -0700 Richard Sharpe <realrichardsharpe@xxxxxxxxx> wrote: > On Sun, Aug 18, 2013 at 8:57 AM, Richard Sharpe > <realrichardsharpe@xxxxxxxxx> wrote: > > On Sun, Aug 18, 2013 at 8:26 AM, Marcus Moeller <marcus.moeller@xxxxxx> wrote: > >> Am 18.08.2013 17:14, schrieb Richard Sharpe: > >>>>>>> > >>>>>>> No, it is not possible to set the same SPN on more than one computer > >>>>>>> object in AD. > >>>>>>> > >>>>>>> What happens here is a combination of DNS magic (there are multiple > >>>>>>> SRV records) and replication of the DFS info between DCs in the AD > >>>>>>> domain. > >>>>>>> > >>>>>>> A client can query any DC for the translation of a DNS namespace. > >>>>>>> > >>>>>>> My use case lives below that level and it is all pretty much working > >>>>>>> (except for XP, which will not do multiple levels of DFS referrals, it > >>>>>>> seems.) > >>>>>>> > >>>>>>> In any event, I might eventually have to use a shared secrets file, > >>>>>>> which overcomes the issue of SPNs. > >>>>>>> > >>>>>> > >>>>>> What SRV records are used? Should we fix mount.cifs to try and query > >>>>>> for an SRV record first and then try to resolve that hostname before > >>>>>> attempting to mount? > >>>>> > >>>>> > >>>>> Those are just for finding the namespace, and I am not sure exactly > >>>>> how it is handled, but if you have a namespace of > >>>>> \\domain.realm\namespace1, I think any DC in that domain can be used > >>>>> to get to the first level. > >>>>> > >>>> > >>>> Bear with me, as I'm pretty clueless as to how AD stuff works. > >>>> > >>>> If all I have is \\domain.realm\namespace1 what should I be doing to > >>>> connect to it at that point? Currently we just treat "domain.realm" as > >>>> a hostname, but evidently that's not quite the right thing to do. Is it? > >>> > >>> > >>> Let me check. > >>> > >>> It might be that Windows returns the IP addresses of all the DCs in > >>> that domain in that case (and, if Sites and Services has been set up > >>> properly, returns them with the closest ones to you first in the > >>> list.) That is, my mentioning of SRV records might be a red herring. > >>> > >>> In that case, if the first one fails, you should simply try the next > >>> one until you find one that responds. > >> > >> > >> Yes, that's how it works. It then tries to reverse lookup the ip address in > >> order to mount the share. As our reverse DNS Setup is somewhat broken, that > >> part fails. I thought that removing the -t option could be a workaround for > >> that, but as the cifs/domain SPN can only be set on one DC, that's no option > >> to. > > > > Well, more precisely, it needs the name in order to generate a service > > ticket. I don't think Windows cares these days what the called-name > > is. > > Do you have a capture? > > In my experience, the client has to distinguish between a multi-homed > host and a name that refers to a domain. > > In the case of a multi-homed host, Windows (at least Win7/Srv 2008) > does not seem to bother to back-translate the IP address used to > connect to a name. > > It simply uses the name presented to look for the SPN and thus > generate the ticket. > > That is, if you try to connect to > \\somemhomedname.realm.com\share-name and it turns out that there are > multiple IP addresses for somemhomedname.realm.com windows connects on > one of them but uses somemhomedname.realm.com to find the SPN to > generate the ticket. > > I have probably deleted my capture so I don't know if it tries to look > for the SRV records to see if that thing is a domain name. > Yes, that's what cifs.ko does currently too. We just try to use the name as presented. If there is no such SPN, then you can optionally try to reverse-resolve the address and use that with the -t flag, but that's subject to DNS spoofing of course. How does the windows client determine whether it's a domain or multi-homed host? Perhaps we could try to emulate what it does for this? -- Jeff Layton <jlayton@xxxxxxxxxx> -- 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
