EL6 mount.cifs and Windows Server 2008 R2
A project related to mine is pushing ahead with rolling out Windows 2008R2 into production. Right now, it seems to be creating compatibility problems with filesharing between these new hosts and our EL6 systems that want to use CIFS to pull files from those servers. From Googling about, it appears that Windows 2008R2 ratchets up the dial on the security-settings for CIFS authentication. Result: doing a mount -t cifs -o domain=DOMAIN,user=USER "//win2k8r2srvr/share/" /mnt/cifs gives a permission denied (errno 13).
Upping the debug level on the connection-attempt indicates that cifs is trying ver=1 (the mount.cifs man pages indicate this is vanilla NTLM). I tried altering the security mode used by the Linux client (tried ntlmv2, ntlmv2i, ntlmssp and ntlmsspi - even tried krb5), which only resulted in changing my error code to a 95.
Not able to tackle it client side, I tried altering settings at the server. I tried the fixes suggested in in http://support.microsoft.com/kb/957441 and http://technet.microsoft.com/en-us/library/cc960646.aspx, but saw no joy from those tweaks, either.
Anyone run into this and found a fix?
Responses
@Tom Jones:- Can yuo please give an example explaining the use of real name.?
Guru
6435 points
With ntlmsspi, the authentication method tries to match the name requested to the name returned by the file-server. If there's a mismatch (as would happen if the server's hostname didn't match what was passed via the mount request to service-alias), the auth will fail at the Windows server. You used to be able to work around this by setting DisableStrictNameChecking on the Windows-based CIFS server (described in http://support.microsoft.com/kb/926642).
Tom, or anyone, did you ever get the CIFS mount to work on RHEL6 with NTLMv2 enabled in the 2008R2 domain?
I've been searching for help with this but so far - no love. I know it works great in RHEL7, but I can't use that.
Thanks
Guru
6435 points
You've got two choices:
1. Use a per-mount option to set the security mode to enable client portion of packet-signing
2. Update your smb.conf to make packet-signing the default for the client.
And, whatever you do, don't try to access via CNAMEs if you've got StrictNameChecking enabled on the CIFS server.
Tom, thanks for the fast reply. I'm in a heavily "secured" environment.
As soon as the Windows admin changed the following options, I lost my ability to mount CIFS from RHEL 6.6.
He activated the settings in 2008R2:
* Lan Manager authentication levelL send NTMLv2 response only ; refuse LM/NTML
* Minimum session security for NTML SSP based clients/servers to "require NTMLv2 session security
* Domain Member: REquire Strong session Key: Enabled
In my /etc/samba/smb.conf file I do have "client signing = mandatory"
Also I've tried every CIFS mount security option (sec= ), including:
ntmlv2, ntmlv2i, ntlmssp and ntlmsspi
I normally get a "permission denied for them, except for ntlmv2i where I get "Operation not supported".
I've tried on both types of servers that are AD integrated via krb5/samba ADS and even via SSSD, which we're eventually going to migrate too for all servers (time permitting).
I'm all patched up on my RHEL6.6 as well. Kernel 2.6.32-504.12.2 and cifs-utils 4.8.1-19.
I've tried for a long time to get this to work without luck.
Any help is MUCH appreciated.
Well that's discouraging. There's something we're missing then. I'm probably missing some better way to troubleshoot the issue.
Thanks again Tom, We really appreciate the experience you provide the Community.
Just to report any minor successes we have in this post:
We were able to get a few non-DFS shares to mount with sec=ntlmssp option, but only AFTER we changed the SecurityFlags in memory with 0x04004. Found that code at Samba.Org. For some reason the DFS shares were problematic - I think I saw that mentioned somewhere on-line. More testing and researching is needed tomorrow. UHG!
echo 0x04004 > /proc/fs/cifs/SecurityFlags
We're getting closer though. I feel more secure everyday. :-)
There should be a new book series entitled:
"Windoze & Linux Integration in a Very, VERY Secured Enterprise for Complete Morons - The Saga Continues (Book 12)".
LOL
Guru
6435 points
DFS? Missed that nugget, previously. DFS support within the version of CIFS that ships with EL6 is next to non-existent. I'd run into that issue, previously, when someone complained about not being able to mount home shares. IIRC, it's one of the features that you generally need to upgrade the CIFS client for (i.e., don't use the one that's part of the standard EL6 packages), though, i vaguely recall that you actually had to go off the EL6 kernel to get the necessary extensions to get the DFS-supporting providers for your CIFS update.
Basically, you pretty far into "not supported" territory to try to overcome it.
For nearly a year we've had no issues mounting to DFS shares in the Win2008R2 environment. I don't have my notes in front of me, but I think this is all we've ever done to succeed. Works like a champ.
Just ensure keyutils is installed, add the two lines to /etc/request-key.conf and BAM, mount as needed. I'll double check when I'm at work tomorrow, but I'm sure this is all we ever done to all our CIFS clients on RHEL 6.6 servers and workstations.
http://mikemstech.blogspot.com/2012/10/how-to-mount-dfs-share-in-linux.html
We push a TON of data via a RHEL6 FTP server to our production storage, which is currently EMC NAS appliances.
Oh, I did go back and test all our mount CIFS requirements on a RHEL 7.0 host. Damn'd if it didn't just work with ntlmssp (no options selected). Shame I won't see that in production for at least 24 months - at best. Oh well.
Thanks!
Guru
6435 points
We'd run into the DFS issues with our RHEL 5 systems (RHEL 6 didn't start going into production datacenters until late 2013 - a few months after the v1 STIGs for EL6 went final), so, my memories may have been muddied by that.
With any luck, the EL7 STIG process will be as comparatively faster to the EL6 STIG process as the EL6 STIG process was to the EL5 STIG process. Then it'll just be a matter of getting a build through the certification process. :p
Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.