[linux-cifs-client] Using mount.cifs with krb5/SPNEGO Win2k3 share
Seb James
seb at esfnet.co.uk
Tue Feb 5 14:15:56 GMT 2008
On Tue, 2008-02-05 at 07:52 -0500, Jeff Layton wrote:
> On Tue, 05 Feb 2008 12:21:55 +0000
> Seb James <seb at esfnet.co.uk> wrote:
>
> > Hi List,
> >
> > I'm having a real problem mounting a share on a Windows 2003 server, and
> > the problem seems related to the authentication methods available on the
> > server.
> >
> > Symptoms:
> > The call to mount.cifs appears to mount the share, and df -h shows the
> > share, but I cannot write any data to the share.
> >
> > Server Setup:
> > The share has been set up on the Win2k3 server with write access
> > allowed for this user - I have been sent a screenshot of the share's
> > "Properties" window. I don't have any control over the Win2k3 server
> > myself. I don't have any info from the admin about what authentication
> > methods they are using.
> >
> > Client software versions:
> > root at cifsclient:root # mount.cifs --version
> > mount.cifs version: 1.10-3.0.24
> > Linux kernel version is 2.6.11 (yes, I know it's old).
> >
>
> SPNEGO support is very new. It just went in in 2.6.24 -- you'll also
> need the cifs.spnego upcall program to use it.
>
> > Reading the Manual:
> > I seem to have discovered (by reading the Linux CIFS Client Guide)
> > that this is an authentication/kerberos issue - the site certainly
> > uses Active Directory to a fairly great extent and I suspect they are
> > using krb5/spnego authentication. Do the attached logs bear this out?
> > (Aside: What does spnego stand for?)
> >
> > Questions:
> > * Should I be able to use NTLMv2 with this site if I (use the) backport
> > version 1.47 (or later) of the cifs client into my 2.6.11 kernel?
>
> IIRC, it depends on the server's security policy.
>
> > * Is Kerberos support available in cifs version 1.50 (The latest
> > mainline version as I write this)?
>
> I don't believe so -- 1.52, I believe. If you really want kerberos
> support for that old kernel, then you'll probably want to use Steve's
> backported source tarballs and then backport patches out of the
> cifs-2.6 git tree until you have Kerberos support.
I decided to find more information on SPNEGO. Wikipedia helped here.
Seems SPNEGO (Simple and Protected GSSAPI Negotiation Mechanism) is a
mechanism for client and server to decide what authentication mechanism
to use, whether it be Kerberos, NTLM or something else.
I have to say, I don't relish the job of backporting all the Kerberos
patches back to 2.6.11.
> > * What should I look for in the cifsFYI (or smbclient debug) output to
> > work out what authentication schemes the server provides/requires?
> >
>
> I usually sniff traffic and look for the Negotiate Protocol packets,
> but it may show up in debug info too.
>
> > Debug Output:
> > I've appended the cifsFYI output from the cifsclient syslog here, for
> > the mount/attempt-to-create-file/unmount actions.
> >
> > The machine running the mount.cifs command is called "cifsclient".
> > The domain is SRVDOM and the share name is LOGSPACE. The username for
> > this share is LOGSPACE also and the password is 12345.
> >
> > In DebugData, I think I need to understand this:
> > Capabilities: 0x1f3fd
>
> I believe that's the bitmask of capabilities for the server (stuff like
> posix extensions, etc).
>
> > and also this:
> > 1) \\172.20.3.62\logspace Uses: 1 Type: NTFS Characteristics: 0x20 Attributes: 0x700ff
> > - in particular the Attributes.
> >
>
> Don't recall, though I don't believe that's the security mask.
No, it doesn't appear to be. I'll come back to that.
> > I will go and have a look at the kernel source to figure these out..
> >
> > Many thanks for reading,
> >
> > Seb James
> >
> >
> >
> >
> >
> > First we mount the share:
> >
> > root at cifsclient:/tmp # mount.cifs \\\\172.20.3.62\\logspace /tmp/log -o user='SRVDOM\LOGSPACE',pass='12345',ip=172.20.3.62
> > root at cifsclient:/tmp #
> >
> > Output in syslog (/proc/fs/cifs/cifsFYI is set to "1"):
> > -------------------
> > Feb 5 10:50:54 cifsclient kernel: fs/cifs/cifsfs.c: Devname: //172.20.3.62/logspace flags: 64
> > Feb 5 10:50:54 cifsclient kernel: fs/cifs/connect.c: CIFS VFS: in cifs_mount as Xid: 79 with uid: 0
> > Feb 5 10:50:54 cifsclient kernel: fs/cifs/connect.c: Domain name set
> > Feb 5 10:50:54 cifsclient kernel: fs/cifs/connect.c: Username: LOGSPACE
> > Feb 5 10:50:54 cifsclient kernel: fs/cifs/connect.c: UNC: \\172.20.3.62\logspace ip: 172.20.3.62
> > Feb 5 10:50:54 cifsclient kernel: fs/cifs/connect.c: Socket created
> > Feb 5 10:50:54 cifsclient kernel: fs/cifs/connect.c: Existing smb sess not found
> > Feb 5 10:50:54 cifsclient kernel: fs/cifs/transport.c: For smb_command 114
> > Feb 5 10:50:54 cifsclient kernel: fs/cifs/transport.c: Sending smb of length 47
> > Feb 5 10:50:54 cifsclient kernel: fs/cifs/connect.c: Demultiplex PID: 716
> > Feb 5 10:50:54 cifsclient kernel: fs/cifs/connect.c: Peek length rcvd: 0x24 beginning 0x77)
> > Feb 5 10:50:54 cifsclient kernel: fs/cifs/connect.c: Mid 0x70 matched - waking up
> > Feb 5 10:50:54 cifsclient kernel: fs/cifs/connect.c: Security Mode: 0xf Capabilities: 0x1f3fd Time Zone: 0
>
> I think the Security Mode printk here might be a good place to start.
> Note that negotiating security in CIFS is rather tricky since the
> server and client have to agree on a set of options. The code to do
> that is somewhat less than straightforward.
Ok, in fs/cifs/cifspdu.h:
/* SecurityMode bits */
#define SECMODE_USER 0x01 /* off indicates share level security */
#define SECMODE_PW_ENCRYPT 0x02
#define SECMODE_SIGN_ENABLED 0x04 /* SMB security signatures enabled */
#define SECMODE_SIGN_REQUIRED 0x08 /* SMB security signatures required */
"Security Mode: 0xf" means that my server has all these bits set, so you
were right to say that the server requires signing, and I haven't
enabled it.
Also in cifspdu.h are the capabilities:
/* Negotiate response Capabilities */
#define CAP_RAW_MODE 0x00000001
#define CAP_MPX_MODE 0x00000002
#define CAP_UNICODE 0x00000004
#define CAP_LARGE_FILES 0x00000008
#define CAP_NT_SMBS 0x00000010 /* implies CAP_NT_FIND */
#define CAP_RPC_REMOTE_APIS 0x00000020
#define CAP_STATUS32 0x00000040
#define CAP_LEVEL_II_OPLOCKS 0x00000080
#define CAP_LOCK_AND_READ 0x00000100
#define CAP_NT_FIND 0x00000200
#define CAP_DFS 0x00001000
#define CAP_INFOLEVEL_PASSTHRU 0x00002000
#define CAP_LARGE_READ_X 0x00004000
#define CAP_LARGE_WRITE_X 0x00008000
#define CAP_UNIX 0x00800000
#define CAP_RESERVED 0x02000000
#define CAP_BULK_TRANSFER 0x20000000
#define CAP_COMPRESSED_DATA 0x40000000
#define CAP_EXTENDED_SECURITY 0x80000000
My 0x1f3fd says that all of these are set except the flags over 0x8000
and CAP_MPX_MODE (0x2). 1f3fd also contains 0x10000 which is not
mentioned in these Negotiate response Capabilities.
> > Feb 5 10:50:54 cifsclient kernel: fs/cifs/connect.c: In sesssetup
> > Feb 5 10:50:54 cifsclient kernel: fs/cifs/transport.c: For smb_command 115
> > Feb 5 10:50:54 cifsclient kernel: fs/cifs/transport.c: Sending smb of length 286
> > Feb 5 10:50:54 cifsclient kernel: fs/cifs/connect.c: Peek length rcvd: 0x24 beginning 0xcb)
> > Feb 5 10:50:54 cifsclient kernel: fs/cifs/connect.c: Mid 0x71 matched - waking up
> > Feb 5 10:50:54 cifsclient kernel: fs/cifs/transport.c: Unexpected signature received from server
> > Feb 5 10:50:54 cifsclient kernel: fs/cifs/connect.c: UID = 34819
> > Feb 5 10:50:54 cifsclient kernel: fs/cifs/connect.c: CIFS Session Established successfully
> > Feb 5 10:50:54 cifsclient kernel: fs/cifs/connect.c: file mode: 0x7f7 dir mode: 0x1ff
> > Feb 5 10:50:54 cifsclient kernel: fs/cifs/transport.c: For smb_command 117
> > Feb 5 10:50:54 cifsclient kernel: fs/cifs/transport.c: Sending smb of length 94
> > Feb 5 10:50:54 cifsclient kernel: fs/cifs/connect.c: Peek length rcvd: 0x24 beginning 0x42)
> > Feb 5 10:50:54 cifsclient kernel: fs/cifs/connect.c: Mid 0x72 matched - waking up
> > Feb 5 10:50:54 cifsclient kernel: fs/cifs/transport.c: Unexpected signature received from server
>
> ^^^
> Sounds like you didn't have signing enabled, but the server requires it
Yes - and the SecurityMode bits tell me this. I need to set sec=ntlmi or
sec=ntlmv2i - NTLM(v2) Password hashing with signing. Trouble is, my
version of cifs.ko doesn't support the sec switch. In /proc/fs/cifs/ I
have PacketSigningEnabled (set to 1). The linux-2.6.11/fs/cifs/README
file says that PacketSigningEnabled should switch signing on. It
defaults to 1, so was set to 1 when I generated the logs above.
Does anyone remember how to switch on signing in the days of kernel
2.6.11?
Seb
More information about the linux-cifs-client
mailing list