linux-cifs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: abrosich@inogs.it
To: CIFS <linux-cifs@vger.kernel.org>
Subject: Re: Permission denied mounting a DFS share with multiuser options
Date: Thu, 05 Mar 2020 16:07:56 +0100	[thread overview]
Message-ID: <5d4bb5621aa6d204c9d1ab668224b55edfe01009.camel@inogs.it> (raw)
In-Reply-To: <CAH2r5mvYeX5y-=ajH7h9i1TqrRgS8SCO6hXCjFVZx--QqTzD_A@mail.gmail.com>


Hello,
I always tried as root, using sudo.
I'm trying using a domain administrator accout. In production I will use (if it
will work) using an SPN.
I obtain a ticket using kinit and I can see it with klist.

The problem is surely with kerberos and cifs.upcall used together, because:

- using "smbclient -k -U domainuser -W AD.DOMAIN" I can connect and browse the
share without password

- using "mount -t cifs" without "sec=krb5" works, after asking for the password


These are the errors in /var/log/debug

Mar  5 15:33:19 linws003 cifs.upcall: get_existing_cc: default ccache is
FILE:/tmp/krb5cc_0
Mar  5 15:33:19 linws003 cifs.upcall: handle_krb5_mech: getting service ticket
for server.domain
Mar  5 15:33:19 linws003 cifs.upcall: cifs_krb5_get_req: unable to get
credentials for server.domain
Mar  5 15:33:19 linws003 cifs.upcall: handle_krb5_mech: failed to obtain service
ticket (-1765328377)
Mar  5 15:33:19 linws003 cifs.upcall: Unable to obtain service ticket
Mar  5 15:33:19 linws003 cifs.upcall: Exit status -1765328377

The cache file /tmp/krb5cc_0 exists. I can see the content with klist and it is
correct.

Tracing the call of cifs.upcall the only errors I can find are:

7295  15:33:19 openat(AT_FDCWD, "/var/lib/sss/pubconf/kpasswdinfo.AD.DOMAIN",
O_RDONLY) = -1 ENOENT (No such file or directory)
7295  15:33:19 sendto(3, "<31>Mar  5 15:33:19 cifs.upcall: cifs_krb5_get_req:
unable to get credentials for server.domain", 100, MSG_NOSIGNAL, NULL, 0) = 100
7295  15:33:19 sendto(3, "<31>Mar  5 15:33:19 cifs.upcall: handle_krb5_mech:
failed to obtain service ticket (-1765328377)", 96, MSG_NOSIGNAL, NULL, 0) = 96
7295  15:33:19 sendto(3, "<31>Mar  5 15:33:19 cifs.upcall: Unable to obtain
service ticket", 64, MSG_NOSIGNAL, NULL, 0) = 64
7295  15:33:19 sendto(3, "<31>Mar  5 15:33:19 cifs.upcall: Exit status
-1765328377", 56, MSG_NOSIGNAL, NULL, 0) = 56

I don't know if the absence of the file
/var/lib/sss/pubconf/kpasswdinfo.AD.DOMAIN is the cause of the following errors.

What I'm doing wrong?

Best regards

Alberto

On Wed, 2020-03-04 at 15:11 -0600, Steve French wrote:
> The first thing I would look at for a problem like this is what
> kerberos ticket you are using.
> 
> The username and domain on the mount command shouldn't matter much
> since you are using kerberos tickets not ntlmv2/ntmssp.  The request
> key upcall will typically look in the key cache for the kerberos
> ticket for the user running the current process (usually root).  One
> common problem is that user's ssh into the system but it doesn't get
> them a krb5 ticket in the expected location due to the kerberos client
> library they are using (you can use the klist command e.g. "klist -a"
> to display additional information) or another common problem is that
> the user sshs into the system but then mounts while running as a
> different user (usually root) so it can't find the kerberos ticket
> that root got (you can do a "kinit" as root to get one to workaround
> this.
> 
> Sachin has a blog entry that can be useful:
> http://sprabhu.blogspot.com/2014/12/debugging-calls-to-cifsupcall.html
> 
> On Wed, Mar 4, 2020 at 3:18 AM <abrosich@inogs.it> wrote:
> > 
> > Hello,
> > I installed also the latest version of cifs-utils from source but nothing
> > changed.
> > 
> > Kernel: 5.6.0-rc4
> > cifs.upcall: version: 6.10
> > keyutils: keyctl from keyutils-1.6.1 (Built 2020-02-10)
> > sssd: 2.2.3
> > cifs module: 2.25
> > 
> > Best regards
> > 
> > Alberto
> > 
> > On Tue, 2020-03-03 at 16:40 +0100, abrosich@inogs.it wrote:
> > > Hello,
> > > 
> > > I installed kernel version 5.6-rc4 but nothing changed.
> > > 
> > > This is the command line:
> > > 
> > > sudo kinit domainuser
> > > sudo mount --type cifs --verbose //server.domain/share /mnt/cifs --options
> > > sec=krb5i,username=domainuser,domain=AD.DOMAIN
> > > 
> > > And these are the dmesg logs:
> > > 
> > > [  374.413601] fs/cifs/cifsfs.c: Devname: //server.domain/share flags: 0
> > > [  374.413627] fs/cifs/connect.c: Domain name set
> > > [  374.413633] No dialect specified on mount. Default has changed to a
> > > more
> > > secure dialect, SMB2.1 or later (e.g. SMB3), from CIFS (SMB1). To use the
> > > less
> > > secure SMB1 dialect to access old servers which do not support SMB3 (or
> > > SMB2.1)
> > > specify vers=1.0 on mount.
> > > [  374.413635] fs/cifs/connect.c: Username: domainuser
> > > [  374.413639] fs/cifs/connect.c: file mode: 0755  dir mode: 0755
> > > [  374.413643] fs/cifs/connect.c: CIFS VFS: in mount_get_conns as Xid: 2
> > > with
> > > uid: 0
> > > [  374.413645] fs/cifs/connect.c: UNC: \\server.domain\share
> > > [  374.413670] fs/cifs/connect.c: Socket created
> > > [  374.413673] fs/cifs/connect.c: sndbuf 16384 rcvbuf 131072 rcvtimeo
> > > 0x6d6
> > > [  374.414805] fs/cifs/fscache.c: cifs_fscache_get_client_cookie:
> > > (0x000000001802b6c5/0x00000000a61d46cb)
> > > [  374.414810] fs/cifs/connect.c: CIFS VFS: in cifs_get_smb_ses as Xid: 3
> > > with
> > > uid: 0
> > > [  374.414812] fs/cifs/connect.c: Existing smb sess not found
> > > [  374.414818] fs/cifs/smb2pdu.c: Negotiate protocol
> > > [  374.414840] fs/cifs/transport.c: Sending smb: smb_len=252
> > > [  374.414898] fs/cifs/connect.c: Demultiplex PID: 969
> > > [  374.415589] fs/cifs/connect.c: RFC1002 header 0x134
> > > [  374.415599] fs/cifs/smb2misc.c: SMB2 data length 120 offset 128
> > > [  374.415601] fs/cifs/smb2misc.c: SMB2 len 248
> > > [  374.415603] fs/cifs/smb2misc.c: length of negcontexts 60 pad 0
> > > [  374.415620] fs/cifs/transport.c: cifs_sync_mid_result: cmd=0 mid=0
> > > state=4
> > > [  374.415627] fs/cifs/misc.c: Null buffer passed to
> > > cifs_small_buf_release
> > > [  374.415630] fs/cifs/smb2pdu.c: mode 0x1
> > > [  374.415632] fs/cifs/smb2pdu.c: negotiated smb3.1.1 dialect
> > > [  374.415637] fs/cifs/asn1.c: OID len = 10 oid = 0x1 0x3 0x6 0x1
> > > [  374.415640] fs/cifs/asn1.c: OID len = 7 oid = 0x1 0x2 0x348 0xbb92
> > > [  374.415642] fs/cifs/asn1.c: OID len = 7 oid = 0x1 0x2 0x348 0x1bb92
> > > [  374.415644] fs/cifs/asn1.c: OID len = 8 oid = 0x1 0x2 0x348 0x1bb92
> > > [  374.415646] fs/cifs/asn1.c: OID len = 10 oid = 0x1 0x3 0x6 0x1
> > > [  374.415648] fs/cifs/smb2pdu.c: decoding 2 negotiate contexts
> > > [  374.415650] fs/cifs/smb2pdu.c: decode SMB3.11 encryption neg context of
> > > len
> > > 4
> > > [  374.415652] fs/cifs/smb2pdu.c: SMB311 cipher type:2
> > > [  374.415655] fs/cifs/connect.c: Security Mode: 0x1 Capabilities:
> > > 0x300067
> > > TimeAdjust: 0
> > > [  374.415657] fs/cifs/smb2pdu.c: Session Setup
> > > [  374.415659] fs/cifs/smb2pdu.c: sess setup type 5
> > > [  374.415664] fs/cifs/cifs_spnego.c: key description =
> > > ver=0x2;host=server.domain;ip4=xxx.xxx.xxx.xxx;sec=krb5;uid=0x0;creduid=0x
> > > 0;us
> > > er
> > > =domainuser;pid=0x3c7
> > > [  374.431889] CIFS VFS: \\server.domain Send error in SessSetup = -126
> > > [  374.431898] fs/cifs/connect.c: CIFS VFS: leaving cifs_get_smb_ses (xid
> > > = 3)
> > > rc = -126
> > > [  374.431903] fs/cifs/connect.c: build_unc_path_to_root:
> > > full_path=\\server.domain\share
> > > [  374.431906] fs/cifs/connect.c: build_unc_path_to_root:
> > > full_path=\\server.domain\share
> > > [  374.431909] fs/cifs/connect.c: build_unc_path_to_root:
> > > full_path=\\server.domain\share
> > > [  374.431913] fs/cifs/dfs_cache.c: __dfs_cache_find: search path:
> > > \server.domain\share
> > > [  374.431917] fs/cifs/dfs_cache.c: get_dfs_referral: get an DFS referral
> > > for
> > > \server.domain\share
> > > [  374.431921] fs/cifs/dfs_cache.c: dfs_cache_noreq_find: path:
> > > \server.domain\share
> > > [  374.431932] fs/cifs/fscache.c: cifs_fscache_release_client_cookie:
> > > (0x000000001802b6c5/0x00000000a61d46cb)
> > > [  374.431944] fs/cifs/connect.c: CIFS VFS: leaving mount_put_conns (xid =
> > > 2)
> > > rc
> > > = 0
> > > [  374.431946] CIFS VFS: cifs_mount failed w/return code = -2
> > > 
> > > 
> > > Best regards
> > > 
> > > Alberto
> > > 
> > > On Mon, 2020-03-02 at 13:19 -0300, Paulo Alcantara wrote:
> > > > abrosich@inogs.it writes:
> > > > 
> > > > > 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
> > > > 
> > > > I'd guess the following commit would fix your issue:
> > > > 
> > > >     5739375ee423 ("cifs: Fix mount options set in automount")
> > > > 
> > > > but could you please try it with 5.6-rc4?
> > > > 
> > > > Provide full dmesg logs as well.
> 
> 


      reply	other threads:[~2020-03-05 15:08 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-27 12:20 Permission denied mounting a DFS share with multiuser options abrosich
2019-12-03 22:16 ` Steve French
2020-03-02 14:11   ` abrosich
2020-03-02 16:19     ` Paulo Alcantara
2020-03-03 15:40       ` abrosich
2020-03-04  9:17         ` abrosich
2020-03-04 21:11           ` Steve French
2020-03-05 15:07             ` abrosich [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5d4bb5621aa6d204c9d1ab668224b55edfe01009.camel@inogs.it \
    --to=abrosich@inogs.it \
    --cc=linux-cifs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).