Re: DFS referrals

[Richard Sharpe <realrichardsharpe-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

On Sun, Aug 18, 2013 at 8:57 AM, Richard Sharpe
<realrichardsharpe-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Sun, Aug 18, 2013 at 8:26 AM, Marcus Moeller <marcus.moeller@gmx.ch> 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
(何以解憂？唯有杜康。--曹操)