mount.cifs cannot mount a DFS share when using Kerberos authentication

[Etienne Goyer]

Binary package hint: smbfs

In Karmic, it is possible to mount a CIFS filesystem from a DFS referral, but it would fail when using Kerberos authentication. Witness:

WARTHOGS\carol@karmic-desktop:~$ mount.cifs //warthogs.biz/namespace1/firstshare share --verbose -o sec=krb5

mount.cifs kernel mount options: unc=//warthogs.biz\namespace1,user=carol,,,,,,,,,,domain=WARTHOGS,ver=1,sec=krb5,uid=288883801,gid=288883201,prefixpath=firstshare,ip=192.168.122.200
mount error(126): Required key not available
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)

In the above example, //warthogs.biz/namespace1/firstshare is a DFS referral that points to //warthogs-adc/share1.

When not specifying "-o sec=krb5" (or when using "-o sec=ntlm"), the mount complete just fine. It also work is I use the direct UNC path, //warthogs-adc/share1, with "-o sec=krb5", so it does really appear that the problem manifest itself only when both conditions are true (the UNC path is a DFS referral *and* we are authenticating using Kerberos).

uname -r: 2.6.31-20-generic

keyutils 1.2-10 (no change to /etc/request-key.conf)

likewise-open5 5.0.3991.1+krb5-0ubuntu2, AD functional level Win2k3 domain joined.

I assigned the bug to smbfs, but I think it might actually be in the cifs kernel module and not in smbfs at all. I attached the relevant part of dmesg, after enabling the cifs module debug mode (echo 1 > /proc/fs/cifs/cifsFYI).

[Etienne Goyer (etienne-goyer-outlands)]

For comparison purpose, here is the output of "smbclient -d3 -k -c showconnect //warthogs.biz/namespace1/firstshare". We can see that it work as expected.

[Etienne Goyer (etienne-goyer-outlands)]

For comparison purpose, here is the output of "smbclient -d3 -k -c showconnect //warthogs.biz/namespace1/firstshare". We can see that it work as expected.

[Etienne Goyer (etienne-goyer-outlands)]

The output of klist after running the mount.cifs command.

[Etienne Goyer (etienne-goyer-outlands)]

We still have the same problem in lucid, using kernel 2.6.32-16-generic. Attached the relevant dmesg snippet. keyutils is 1.2-12, and likewise-open is 5.4.0.39949-3.

[Etienne Goyer (etienne-goyer-outlands)]

In lucid, there was the following in /var/log/debug that seems to relate to the problem at hand.

[Etienne Goyer (etienne-goyer-outlands)]

Investigating the problem further, I thought the problem might have been that resolving the DFS referral returned a NetBIOS machine name, not a FQDN, for the server hosting the service (ie, WARTHOGS-ADC instead of warthogs-adc.warthogs.biz). After looking around, I followed the advice in Microsoft KB #244380 to make it so that Windows would return FQDN when resolving DFS referral, but it still would not work.

Discussing the problem further with colleagues, it seems like cifs.upcall does do any DFS referral resolution, hence why mount.cifs fails to mount a DFS referral *just* when using Kerberos for authentication. I was pointed at the following linux-cifs-client mailing list thread explaining the situation:

    http://old.nabble.com/Handling-Kerberos-principals-that-don%27t-match-hostnames-td27055470.html

In lucid, I tried adding -t to the cifs.spnego entry in /etc/request-key.conf, and it work indeed! \o/ Unfortunately, this option to cifs.upcall is not available in the version we ship in karmic, so this is a lucid-only workaround.

However, i understand this is just working around the problem, which is that cifs.upcall do not support resolving DFS referral.

Is this correct, or am I wrong somewhere?

[Thierry Carrez (ttx)]

From https://bugzilla.samba.org/show_bug.cgi?id=7257#c12 :

Ok, I think I see what's happening. The server in this case is sending a
principal name back to the client in the Negotiate Protocol response. smbclient
is using that to get a ticket name.

Note that this is really bad behavior by both the server and client. The
client, in particular since you're essentially trusting the server to tell you
what service principal to use. This allows an attacker to potentially spoof DNS
and redirect the connection to a server that he/she controls.

Not trusting that info was a conscious decision. You can read the thread from a
couple of years ago here:

http://lists.samba.org/archive/linux-cifs-client/2008-August/003348.html

The correct solution is to fix it so that your KDC holds service principals for
all possible hostnames.

...now, that said, I'm not 100% opposed to patches that turn on this behavior
as an option. I'm not interested in doing that work, but if you or someone else
wants to take it on, I'd be willing to help review them.