Am 18.08.2013 18:08, schrieb Richard Sharpe: > 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. Yes, connecting directly to a host works without a problem, but I wanted to connect using the domain name. Right now I am using a dirty workaround to figure out the fastest server to connect to, and then using it directy. But in the end our DNS setup needs to be fixed. Greets Marcus -- 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
