On Sun, Aug 18, 2013 at 6:10 AM, Jeff Layton <[email protected]> wrote: > On Sat, 17 Aug 2013 15:11:37 -0700 > Richard Sharpe <[email protected]> wrote: > >> On Tue, Aug 13, 2013 at 8:32 AM, Jeff Layton <[email protected]> wrote: >> > On Tue, 13 Aug 2013 08:00:14 -0700 >> > Richard Sharpe <[email protected]> wrote: >> > >> >> On Tue, Aug 13, 2013 at 2:00 AM, Marcus Moeller <[email protected]> >> >> wrote: >> >> > Hi again, >> >> > >> >> >>>>>>>>>> On Mon, 29 Jul 2013 14:50:03 +0200 >> >> >>>>>>>>>> Marcus Moeller <[email protected]> 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/[email protected] >> >> >>>> >> >> >>>> ...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? >> >> >> >> 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. -- Regards, Richard Sharpe (何以解憂？唯有杜康。--曹操) -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
