On Tue, 13 Aug 2013 11:00:08 +0200 Marcus Moeller <marcus.moeller@xxxxxx> wrote: > Hi again, > > >>>>>>>>> On Mon, 29 Jul 2013 14:50:03 +0200 > >>>>>>>>> Marcus Moeller <marcus.moeller@xxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxx > >>> > >>> ...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 > I would imagine so, but I'm afraid I don't know much about AD. -- Jeff Layton <jlayton@xxxxxxxxxx> -- 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
