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. -- Regards, Richard Sharpe (何以解憂？唯有杜康。--曹操) -- 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
