Bug 662626

This request was evaluated by Red Hat Product Management for inclusion
in a Red Hat Enterprise Linux maintenance release. Product Management has 
requested further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed 
products. This request is not yet committed for inclusion in an Update release.

The first thing to check is that sec=ntlmssp actually works. Earlier RHEL6 kernels did accept a sec=ntlmssp(i) option, but they then tried to use kerberos to mount if it was specified. Assuming that you don't have everything set up for kerberized cifs, simply doing this should get you an error:

# mount -t cifs //server/export /mnt/server -o user=testuser,pass=testuser,sec=ntlmssp
mount error(126): Required key not available
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)

With the patchset in place, the above should work (assuming that the username and password are correct).

Also, earlier kernels did not show the sec= option at all. Support for that is added to this one. Once you verify that the above works, you should be able to
mount using various different values for the sec= option and have them show up in /proc/mounts.

Hi Jeff,
Could this bug be tested in this way?
 a. setup win2k8 as server , create a user, make sure ntlmssp service running
 b. mount from rhel6 using sec=ntlmssp option.
If I was wrong, please give me some suggestion, thanks.

As this patchset effects lots source code, does it needed some regression test?(I am preparing CIFS test plan, your suggestion should be of great help.)

change state to QA_ACK+.

(In reply to comment #4)
> The first thing to check is that sec=ntlmssp actually works. Earlier RHEL6
> kernels did accept a sec=ntlmssp(i) option, but they then tried to use kerberos
> to mount if it was specified. Assuming that you don't have everything set up
> for kerberized cifs, simply doing this should get you an error:
> 
> # mount -t cifs //server/export /mnt/server -o
> user=testuser,pass=testuser,sec=ntlmssp
> mount error(126): Required key not available
> Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
> 
> With the patchset in place, the above should work (assuming that the username
> and password are correct).
> 
> Also, earlier kernels did not show the sec= option at all. Support for that is
> added to this one. Once you verify that the above works, you should be able to
> mount using various different values for the sec= option and have them show up
> in /proc/mounts.

(In reply to comment #6)
> Hi Jeff,
> Could this bug be tested in this way?
>  a. setup win2k8 as server , create a user, make sure ntlmssp service running
>  b. mount from rhel6 using sec=ntlmssp option.
> If I was wrong, please give me some suggestion, thanks.
> 
> As this patchset effects lots source code, does it needed some regression
> test?(I am preparing CIFS test plan, your suggestion should be of great help.)
> 

Yes, testing in that way should be fine. A full-scale regression test for CIFS on this cycle would be a good thing. Note that there are several BZ's that involve cifs backports so it may be best to wait until they are all merged before you do any involved testing. See also:

654198
668791
692709
708000
711400

Patch(es) available on kernel-2.6.32-168.el6

Hi Jeff,
I have some problem when test sec=ntlmssp, would you please give me some suggestions about how to config 'windows' as a CIFS server?  Test detail is listed below:


I have setup AD on window 2003, and add user test.
[root@server-71]$mount.cifs //192.168.122.237/share /mnt/test -o user=test,pass='REDhat!@#456',sec=ntlmssp -vvv
mount.cifs kernel mount options: ip=192.168.122.237,unc=\\192.168.122.237\share,sec=ntlmssp,ver=1,user=test,pass=********
mount error(95): Operation not supported
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)

[root@server-71]$dmesg
**snip**
fs/cifs/cifssmb.c: NTLMSSP only mechanism, enable extended security
fs/cifs/transport.c: For smb_command 114
fs/cifs/transport.c: Sending smb:  total_len 82
fs/cifs/connect.c: Demultiplex PID: 12062
fs/cifs/connect.c: rfc1002 length 0xc1
fs/cifs/transport.c: cifs_sync_mid_result: cmd=114 mid=1 state=4
fs/cifs/cifssmb.c: Dialect: 2
fs/cifs/asn1.c: OID len = 7 oid = 0x1 0x2 0x348 0xbb92
fs/cifs/asn1.c: OID len = 7 oid = 0x1 0x2 0x348 0x1bb92
fs/cifs/asn1.c: OID len = 8 oid = 0x1 0x2 0x348 0x1bb92
fs/cifs/asn1.c: OID len = 10 oid = 0x1 0x3 0x6 0x1
fs/cifs/asn1.c: Need to call asn1_octets_decode() function for root-5a55c86d5b$@TEST.REDHAT.COM
fs/cifs/cifssmb.c: Signing disabled
CIFS VFS: Server requires packet signing to be enabled in /proc/fs/cifs/SecurityFlags.
fs/cifs/cifssmb.c: negprot rc -95
fs/cifs/connect.c: CIFS VFS: leaving cifs_get_smb_ses (xid = 108) rc = -95
fs/cifs/connect.c: CIFS VFS: leaving cifs_mount (xid = 107) rc = -95
CIFS VFS: cifs_mount failed w/return code = -95

thanks.

(In reply to comment #8)
> (In reply to comment #6)
> > Hi Jeff,
> > Could this bug be tested in this way?
> >  a. setup win2k8 as server , create a user, make sure ntlmssp service running
> >  b. mount from rhel6 using sec=ntlmssp option.
> > If I was wrong, please give me some suggestion, thanks.
> > 
> > As this patchset effects lots source code, does it needed some regression
> > test?(I am preparing CIFS test plan, your suggestion should be of great help.)
> > 
> 
> Yes, testing in that way should be fine. A full-scale regression test for CIFS
> on this cycle would be a good thing. Note that there are several BZ's that
> involve cifs backports so it may be best to wait until they are all merged
> before you do any involved testing. See also:
> 
> 654198
> 668791
> 692709
> 708000
> 711400

(In reply to comment #12)
> Hi Jeff,
> I have some problem when test sec=ntlmssp, would you please give me some
> suggestions about how to config 'windows' as a CIFS server?  Test detail is
> listed below:
> 

[...]

> fs/cifs/cifssmb.c: Signing disabled
> CIFS VFS: Server requires packet signing to be enabled in
> /proc/fs/cifs/SecurityFlags.

This server seems to require signing to be enabled. You can either set the above file in /proc to 1, or mount with sec=ntlmsspi. It's usually possible to disable that requirement on the server, but it often involves some registry tweaking and I'm not sure where that knob is on win2k3.

As an alternative, you can wait until they merge the patches for bug 729437 and test this against samba. The global setting there is "server signing".

Hi Jeff,
I am testing CIFS with samba, mounting w/ sec=ntlmssp(i) works ok, the same to ntlm(i), BUT mounting w/ ntlmv2(i) doesn't work, do I ignore some special configuration of samba?
Debug info says:
mount error(95): Operation not supported.

when sec=ntlmssp is used, which of ntlm and ntlmv1 is used to deal usr's password? There is no reference of 'sec=ntlmssp' in cifs.mount's manual now.

*sigh* -- known bug. Samba rejects ntlmv2(i) auth from the current RHEL6 code as it formats the ntlmv2 response incorrectly. Windows servers don't seem to care about this however so sec=ntlmv2(i) should work against those servers.

We can fix this with the following patch that's in Steve F's tree but not in mainline yet:

commit 3b651dba4865f906eb383dbd5d637c969fd57a64
Author: Shirish Pargaonkar <shirishpargaonkar>
Date:   Wed Aug 24 23:05:46 2011 -0500

    cifs: Fix broken sec=ntlmv2/i sec option (try #2)

...it's probably safe enough, but the fact that it's not in mainline held me back from proposing it. If it's causing QA problems though, we probably should. Thoughts?

Oh and to answer your other question. NTLMSSP auth uses NTLMv2 encryption (the more secure of the two).

You're also correct that there's no mention of sec=ntlmssp in the manpage. I'll see about writing a patch to add that.

Hi jeff,
thanks for reply, I will also run cthon with sec option for this bug.

cthon test mounting with option "ntlm,ntlmi,ntlmgss,ntlmgssi,ntlmv1", cifs works well.
https://beaker.engineering.redhat.com/jobs/134548

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHSA-2011-1530.html