Re: DFS referrals

[Marcus Moeller <marcus.moeller-OI3hZJvNYWs@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 6348 bytes --]

Hi again,

>>>>>>>>> On Mon, 29 Jul 2013 14:50:03 +0200
>>>>>>>>> Marcus Moeller <marcus.moeller-OI3hZJvNYWs@public.gmane.org> wrote:
>>>>>>>>>
>>>>>>>>>> [  124.607810] fs/cifs/cifssmb.c: negprot rc 0
>>>>>>>>>> [  124.607814] fs/cifs/connect.c: Security Mode: 0xf Capabilities:
>>>>>>>>>> 0x8001f3fc TimeAdjust: -7200
>>>>>>>>>> [  124.607817] fs/cifs/sess.c: sess setup type 4
>>>>>>>>>> [  124.607826] fs/cifs/cifs_spnego.c: key description =
>>>>>>>>>> ver=0x2;host=d.ethz.ch;ip4=82.130.70.6;sec=krb5;uid=0xaf05;creduid=0xaf05;user=mam4tst;pid=0x61a
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> [  124.803185] fs/cifs/sess.c: ssetup freeing small buf
>>>>>>>>>> ffff88022c31a000
>>>>>>>>>> [  124.803195] CIFS VFS: Send error in SessSetup = -126
>>>>>>>>>> [  124.803203] fs/cifs/connect.c: CIFS VFS: leaving
>>>>>>>>>> cifs_get_smb_ses (xid = 5) rc = -126
>>>>>>>>>> [  124.803212] fs/cifs/fscache.c:
>>>>>>>>>> cifs_fscache_release_client_cookie:
>>>>>>>>>> (0xffff88022a1b6000/0xffff88022a6430f0)
>>>>>>>>>> [  124.803368] fs/cifs/connect.c: CIFS VFS: leaving cifs_mount (xid
>>>>>>>>>> = 4) rc = -126
>>>>>>>>>> [  124.803374] CIFS VFS: cifs_mount failed w/return code = -126
>>>>>>>>>
>>>>>>>>> The only failure I see is the one above, and that's because it failed
>>>>>>>>> to upcall for the correct key. Are you sure you have krb5 creds as
>>>>>>>>> that
>>>>>>>>> user?
>>>>>>>>
>>>>>>>> Yes, creds are there and it also works when mounting from one of the
>>>>>>>> servers directly.
>>>>>>>>
>>>>>>>> Only mounting using the domainname does not work.
>>>>>>>>
>>>>>>>>
>>>>>>>>>> [  131.324798] fs/cifs/cifssmb.c: negprot rc 0
>>>>>>>>>> [  131.324804] fs/cifs/connect.c: Security Mode: 0xf Capabilities:
>>>>>>>>>> 0x8001f3fc TimeAdjust: -7200
>>>>>>>>>> [  131.324808] fs/cifs/sess.c: sess setup type 4
>>>>>>>>>> [  131.324821] fs/cifs/cifs_spnego.c: key description =
>>>>>>>>>> ver=0x2;host=d.ethz.ch;ip4=172.31.65.62;sec=krb5;uid=0xaf05;creduid=0xaf05;user=mam4tst;pid=0x62c
>>>>
>>>>>>>>>> [  131.384335] fs/cifs/transport.c: For smb_command 115
>>>>>>>>>> [  131.384344] fs/cifs/transport.c: Sending smb: smb_len=1666
>>>>>>>>>> [  131.387043] fs/cifs/connect.c: RFC1002 header 0xf9
>>>>>>>>>> [  131.387055] fs/cifs/misc.c: checkSMB Length: 0xfd,
>>>>>>>>>> smb_buf_length: 0xf9
>>>>>>>>>> [  131.387095] fs/cifs/transport.c: cifs_sync_mid_result: cmd=115
>>>>>>>>>> mid=2 state=4
>>>>>>>>>> [  131.387100] fs/cifs/misc.c: Null buffer passed to
>>>>>>>>>> cifs_small_buf_release
>>>>>>>>>
>>>>>>>>> Here' the upcall for a similar set of creds worked fine. The only
>>>>>>>>> thing
>>>>>>>>> that seems to have changed in the key description is the IP address.
>>>>>>>>>
>>>>>>>>> Do you have cifs.upcall set up to use the --trust-dns flag? If so,
>>>>>>>>> why?
>>>>>>>>
>>>>>>>> A relict from the past. I have removed it from the config. Thanks for
>>>>>>>> pointing out.
>>>>
>>>> Sorry, I was wrong. Without the -t option I am not even able to mount it
>>>> at all. The man page states a few words on that parameter, but I am
>>>> still not sure how it works when -t is not set.
>>>>
>>>> With -t set, the initial problem with the domain lookup works, when
>>>> reverse DNS is configured propably.
>>>>
>>>
>>> Ok, that makes sense then. The problem here is that the kernel needs to
>>> know what service principal name to use when contacting the server, and
>>> I suspect your krb5 configuration is not quite right.
>>>
>>> It looks like you're doing something like:
>>>
>>>       mount //d.ethz.ch/dfs /mnt/dfs -o sec=krb5...
>>>
>>> ...at this point, what happens is that the kernel needs to get a krb5
>>> service ticket to talk to the CIFS service on the host.
>>>
>>> What it typically does is take the hostname in the UNC that you're
>>> trying to mount, prepend it with "cifs/" and then try to get a service
>>> ticket for that. In your case, it'll look something like this:
>>>
>>>       cifs/d.ethz.ch-ofn1FrHcITAsyahpCud6bTnlAmrJQu31@public.gmane.org
>>>
>>> ...now, typically if that fails, we'll give up. Trying to do anything
>>> else is not considered safe since it's vulernable to DNS spoofing.
>>>
>>> If however, you add the '-t' flag to cifs.upcall, that tells it to try
>>> and guess the hostname part of that principal by reverse resolving it in
>>> DNS. It takes the IP address to which you are connecting, does a
>>> reverse DNS lookup and then uses that in the SPN.
>>>
>>> This is less safe, since if your DNS server is compromised someone
>>> could redirect you to a malicious server, and your client wouldn't be
>>> able to trivially detect that. So it in effect waters down krb5
>>> security.
>>>
>>> The correct fix is to ensure that the server(s) to which you are
>>> connecting have the ability to accept SPNs for the "hostnames" to which
>>> you want to connect. That means that you need to add SPNs for
>>> cifs/d.ethz.ch and ensure that the server will accept them to talk to
>>> its cifs service.
>>>
>>> Alternately, you can continue to use the '-t' flag and ensure that each
>>> possible server accepts principals for the hostnames to which their IP
>>> addresses reverse-resolve, with the caveat that its less safe than
>>> doing that the "right way".
>>>
>>> As to how to add these principals and make the server accept them...it
>>> depends on the server.
>>>
>>> Clear as mud?
>>
>> Hehe, thanks for pointing that out. One thing I am not yet aware of is
>> where the SPN cifs/d.ethz.ch has to be set? On the DFS Servers and/or on
>> the servers which hold the shares? The latter ones are EMC and the DFS
>> Servers are 2008R2.
>>
>> Greets
>> Marcus
>>
>
> Definitely on the first DFS server. On the others, they'll need to
> accept SPNs holding the hostnames that are in the DFS referrals. So if
> your DFS server gives you a referral that's something like this:
>
>      bar -> //foo.d.ethz.ch/bar
>
> ...then you'll need to ensure that foo.d.ethz.ch accepts SPNs that have
> that hostname in them.

I have found some time to talk to our Active Directory Admins. They 
mentioned that every DC in our setup is a DFS server and there is 
nothing like a 'first DFS'. So is it possible to set the same SPN on all 
of these servers?

Greets
Marcus




[-- Attachment #2: S/MIME Kryptografische Unterschrift --]
[-- Type: application/pkcs7-signature, Size: 2460 bytes --]