Re: Permission denied mounting a DFS share with multiuser options

[abrosich@inogs.it]

Hello Steve,
after a while I'am trying again to find a solution.

I've changed the environment.
The linux client now is a Debian machine with testing flavour to have the latest
versions of the involved softwares. These are the versions of some of them:

Kernel: #1 SMP Debian 5.4.19-1 (2020-02-13)
cifs.upcall: version: 6.9
keyutils: keyctl from keyutils-1.6.1 (Built 2020-02-10)
sssd: 2.2.3
cifs module: 2.23

The linux machine is joined in the AD domain. I can log on using ssh as domain
user and I can use smbclient with "-k" option after obtaining a ticket using
"kinit".

When I try to do a mount

mount --type cifs --verbose //server.domain/ShareName /mountpoint --options
sec=krb5i,username=domainuser,domain=ad.domain

I receive the following error:
mount error(2): No such file or directory

and dmesg gives:

CIFS VFS: \\server.domain Send error in SessSetup = -126
fs/cifs/connect.c: CIFS VFS: leaving cifs_get_smb_ses (xid = 54) rc = -126
...
CIFS VFS: cifs_mount failed w/return code = -2

Raising log level as in 
https://wiki.samba.org/index.php/LinuxCIFS_troubleshooting gives (to me) no
useful information about the cause.

What does it mean "Send error in SessSetup"? And error -126?

In the event viewer of the windows server I cannot find any event related to it.

I sniffed the ethernet conversation using wireshark. The conversation is quite
short (9 packets). The client closes it with a FIN,ACK after receiving a good
SMB Negotiate Protocol Response that seems good to me. The version of the
protocol is correctly set (3.1.1 when it is not specified).

Any suggest?

Best regards

Alberto


On Tue, 2019-12-03 at 16:16 -0600, Steve French wrote:
> Have you experimented with a newer kernel (e.g. Ubuntu 19 or the
> download from the Ubuntu mainline kernel download site) to see if some
> of Paulo's DFS fixes (e.g. a large set went in last year) help.
> 
> On Wed, Nov 27, 2019 at 6:20 AM <abrosich@inogs.it> wrote:
> > 
> > Hello,
> > 
> > I'm trying to configure a linux client (Unubtu 18.04.3) to mount a DFS
> > share from a windows server 2019. Both machines are joined in the same
> > Active Directory domain. I joined the linux client using the "realm"
> > command and it works fine: for example I can login with ssh using AD
> > credentials.
> > 
> > The package cifs-utils is version 6.8.
> > 
> > I start by saying that I have a little konwledge of the windows world
> > and in particular of SMB, hence my question could by silly but I
> > searched for days without find any solution.
> > 
> > I found the following entries in the krb5.conf file (I suppose added by
> > "realm" coomand):
> > 3 11/11/19 08:54:09 host/LINUXCLIENT@AD.DOMAIN (des-cbc-crc)
> >    3 11/11/19 08:54:09 host/LINUXCLIENT@AD.DOMAIN (des-cbc-md5)
> >    3 11/11/19 08:54:09 host/LINUXCLIENT@AD.DOMAIN (arcfour-hmac)
> >    3 11/11/19 08:54:09 host/LINUXCLIENT@AD.DOMAIN (aes128-cts-hmac-
> > sha1-96)
> >    3 11/11/19 08:54:09 host/LINUXCLIENT@AD.DOMAIN (aes256-cts-hmac-
> > sha1-96)
> >    3 11/11/19 08:54:09 host/linuxclient@AD.DOMAIN (des-cbc-crc)
> >    3 11/11/19 08:54:09 host/linuxclient@AD.DOMAIN (des-cbc-md5)
> >    3 11/11/19 08:54:09 host/linuxclient@AD.DOMAIN (arcfour-hmac)
> >    3 11/11/19 08:54:09 host/linuxclient@AD.DOMAIN (aes128-cts-hmac-
> > sha1-96)
> >    3 11/11/19 08:54:09 host/linuxclient@AD.DOMAIN (aes256-cts-hmac-
> > sha1-96)
> > 
> > I created on the Domain Controller a user principal "linuxclientuser-
> > cifs" and associated to it an SPN "cifs/linuxclient.fqdn@AD.DOMAIN". I
> > exported the keytab file and added it in krb5.keytab where I have now
> > the followind entries:
> > 
> >   3 11/12/19 12:50:59 cifs/linuxclient.fqdn@AD.DOMAIN (des-cbc-crc)
> >    3 11/12/19 12:50:59 cifs/linuxclient.fqdn@AD.DOMAIN (des-cbc-md5)
> >    3 11/12/19 12:50:59 cifs/linuxclient.fqdn@AD.DOMAIN (arcfour-hmac)
> >    3 11/12/19 12:50:59 cifs/linuxclient.fqdn@AD.DOMAIN (aes256-cts-
> > hmac-sha1-96)
> >    3 11/12/19 12:50:59 cifs/linuxclient.fqdn@AD.DOMAIN (aes128-cts-
> > hmac-sha1-96)
> > 
> > 
> > I use the following command to mount the share:
> > sudo mount --verbose --types cifs //winsrv/CifsShare /mnt/cifs --
> > options
> > sec=krb5,multiuser,vers=3,user=cifs/linuxclient.fqdn,domain=AD.DOMAIN
> > 
> > and the response is: "mount error(13): Permission denied"
> > 
> > Looking at logs I find:
> > Nov 27 13:07:18 linuxclient cifs.upcall: key description:
> > cifs.spnego;0;0;39010000;ver=0x2;host=winsrv;ip4=XXX.XXX.XXX.XXX;sec=kr
> > b5;uid=0x0;creduid=0x0;user=cifs/linuxclient.fqdn;pid=0x6ac
> > Nov 27 13:07:18 linuxclient cifs.upcall: ver=2
> > Nov 27 13:07:18 linuxclient cifs.upcall: host=winsrv
> > Nov 27 13:07:18 linuxclient cifs.upcall: ip=XXX.XXX.XXX.XXX
> > Nov 27 13:07:18 linuxclient cifs.upcall: sec=1
> > Nov 27 13:07:18 linuxclient cifs.upcall: uid=0
> > Nov 27 13:07:18 linuxclient cifs.upcall: creduid=0
> > Nov 27 13:07:18 linuxclient cifs.upcall: user=cifs/linuxclient.fqdn
> > Nov 27 13:07:18 linuxclient cifs.upcall: pid=1708
> > Nov 27 13:07:18 linuxclient cifs.upcall:
> > get_cachename_from_process_env: pid == 0
> > Nov 27 13:07:18 linuxclient cifs.upcall: get_existing_cc: default
> > ccache is FILE:/tmp/krb5cc_0
> > Nov 27 13:07:18 linuxclient cifs.upcall: get_tgt_time: unable to get
> > principal
> > Nov 27 13:07:18 linuxclient cifs.upcall: handle_krb5_mech: getting
> > service ticket for winsrv
> > Nov 27 13:07:18 linuxclient cifs.upcall: handle_krb5_mech: obtained
> > service ticket
> > Nov 27 13:07:18 linuxclient cifs.upcall: Exit status 0
> > 
> > 
> > where it says that it get the service ticket (I can see it sniffing
> > packets with wireshark) but it is "unable to get principal". Which
> > principal?
> > 
> > On the server side I have the following error:
> > 
> > A process has requested access to an object, but has not been granted
> > those access rights. (0xC0000022)
> > SPN: session setup failed before the SPN could be queried
> > SPN Validation Policy: SPN optional / no validation
> > 
> > 
> > What I'm doing wrong?
> > 
> > Any suggest is welcome.
> > 
> > Best regards
> > 
> > Alberto
> > 
> > 
> 
>