> -----Original Message----- > From: linux-cifs-owner@xxxxxxxxxxxxxxx [mailto:linux-cifs- > owner@xxxxxxxxxxxxxxx] On Behalf Of Jeff Layton > Sent: Monday, August 19, 2013 7:12 AM > To: Richard Sharpe > Cc: Marcus Moeller; linux-cifs@xxxxxxxxxxxxxxx > Subject: Re: DFS referrals > > 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? Domain referrals are different, their responses aren't intermingled with file referrals. And server types in the response are also distinct (Referral servers vs Storage servers). Note also there is a difference between the requests issued by a domain-joined Windows client vs. non-domain-joined. If the Windows client is issuing SRV record lookups, it may be related to domain behavior. It's not DFS. See MS-DFSC: The DFS: Referral Protocol is a command/acknowledge protocol that sends out a sequence of referral requests to eventually resolve the DFS path to an actual path. There are five types of referral requests, as specified in section 2.2.2: Domain referrals, which identify the domains in the forest to which the DFS client is joined and the domains in other forests, which are part of a trust relationship with the DFS client's forest. DC referrals, which identify the DCs of a specific domain. Root referrals, which identify the DFS root targets of a specific DFS namespace. Link referrals, which identity the DFS link targets of a specific link in a DFS namespace. Sysvol referrals, which identify the DCs that host a domain's SYSVOL or NETLOGON shares. Domain-joined clients issue all five types of referral requests, while non-domain-joined clients issue only DFS root and DFS link referral requests. Optionally, clients can also be used to administer DFS namespaces (see [MS-DFSNM]). Tom. ��.n��������+%������w��{.n�����{�����ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
