Quick-Take: NexentaStor 3.1.3 New AD Group Feature, Can Break AD Shares
June 12, 2012The latest update of NexentaStor may not go too smoothly if you are using Windows Server 2008 AD servers and delegating shares via NexentaStor. While the latest update includes a long sought after fix in AD capabilities (see pull quote below) it may require a tweak to the CIFS Server settings to get things back on track.
Domain Group Support
It is now possible to allow Domain groups as members of local groups. When a Windows client authenticates with NexentaStor using a domain account, NexentaStor consults the domain controller for information about that user’s membership in domain groups. NexentaStor also computes group memberships based on its _local_ groups database, adding both local and domain groups based on local group memberships, which are allowed to be indirect. NexentaStor’s computation of group memberships previously did not correctly handle domain groups as members of local groups.
In the past, some of NexentaStor’s in-place upgrades have reset the “lmauth_level” of the associated SMB share server from its user configured value back to a “default” of four (4). This did not work very well in an AD environment where the servers were Windows Server 2008 and running their native authentication mode. The fix was to change the “lmauth_level” to two (2) via the NMV or NMC (“sharectl set -p lmauth_level=2 smb”) and restart the service. If you have this issue, the giveaway kernel log entries are as follows:
smbd[7501]: [ID 702911 daemon.notice] smbd_dc_update: myad.local: locate failed
smbd[7501]: [ID 702911 daemon.notice] smbd_dc_monitor: domain service not responding
However, the rules have changed in some applications; Nexenta’s new guidance is:
Summary Description CIFS Issue
A recent patch release by Microsoft has necessitated a changed to the CIFS authorization setting. Without changing this setting, customers will see CIFS disconnects or the appliance being unable to join the Active Directory domain. If you experience CIFS disconnects or problems joining your Active Directory domain, please modify the ‘lmauth_level’ setting.
# sharectl set -p lmauth_level=4 smb
– NexentaStor 3.1.3 Release Notes
While this may work for others out there it does not universally work for any of my tested Windows Server 2008 R2, native AD mode servers. Worse, it appears to work with some shares, but not all; this can lead to some confusion about the actual cause (or resolution) of the problem based on the Nexenta release notes. Fortunately (or not, depending on your perspective), the genesis of NexentaStor is clearlyheading toward an intersection with Illumos although the current kernel is still based on Open Solaris (134f), and a post from OpenIndiana points users to the right solution.
(Jonathan Leafty) I always thought it was weird that lmauth_level had to be set to 2 so I bumped it back to the default of 3 and restarted smb and it worked... (Gordon Ross) Glad you found that. I probably should have sent a "heads-up" when the "extended security outbound" enhancement went in. People who have adjusted down lmauth_level should put it back the the default.– CIFS in Domain Mode (AD 2008), OpenIndiana Discussion Group (openindiana-discuss@openindiana.org)
Following the advice for OpenIndiana re-enabled all previously configured shares. This mode is also the default for Solaris, although NexentaStor continues to use a different one. According to the man pages for smb on Nexenta (‘man smb(4)’) the difference between ‘lmauth_level=3’ and ‘lmauth_level=4’ is as follows:
lmauth_level
Specifies the LAN Manager (LM) authentication level. The LM compatibility level controls the type of user authentication to use in workgroup mode or
domain mode. The default value is 3.The following describes the behavior at each level.
2 – In Windows workgroup mode, the Solaris CIFS server accepts LM, NTLM, LMv2, and NTLMv2 requests. In domain mode, the SMB redirector on
the Solaris CIFS server sends NTLM requests.3 – In Windows workgroup mode, the Solaris CIFS server accepts LM, NTLM, LMv2, and NTLMv2 requests. In domain mode, the SMB redirector on
the Solaris CIFS server sends LMv2 and NTLMv2 requests.4 – In Windows workgroup mode, the Solaris CIFS server accepts NTLM, LMv2, and NTLMv2 requests. In domain mode, the SMB redirector on the
Solaris CIFS server sends LMv2 and NTLMv2 requests.5 – In Windows workgroup mode, the Solaris CIFS server accepts LMv2 and NTLMv2 requests. In domain mode, the SMB redirector on the Solaris
CIFS server sends LMv2 and NTLMv2 requests.
This illustrates either a continued dependency on LAN Manager (absent in ‘lmauth_level=4’) or a bug as indicated in the OpenIndiana thread. Either way, more testing to determine if this issue is unique to my particular 2008 AD environment or this is a general issue with the current smb/server facility in NexentaStor…
SOLORI’s Take: So while NexentaStor defaults back to ‘lmauth_level=4’ and ‘lmauth_level=2’ is now broken (for my environment), the “default” for OpenIndiana and Solaris (‘lmauth_level=3’) is a winner; as to why – that’s a follow-up question… Meanwhile, proceed with caution when upgrading to NexentaStor 3.1.3 if your appliance is integrated into AD – testing with the latest virtual appliance for the win.
SolutionOriented Blog 
Our experience is that the default setting (lmauth_level=4) works well with 3.1.3. Most of the confusion around lmauth_level came from the fact that in _earlier_ releases, customers often had to set lmauth_level=2, and when that setting is carried through in an upgrade, it actually causes things to not work after the upgrade.
It’s in the release notes now, that if you’ve previously set lmauth_level=2, change it back to 4 when you upgrade to 3.1.3.
LikeLike
Gordon,
Thanks for the input. In my particular case the share access was not consistent unless lmauth_level=3 was set. Historically I’ve had to use 2 when using 2008 AD and in the past, NexentaStor upgrades have reverted to 4 breaking the shares in those environments.
I’m interested in the bug you referred to in the community post: can you detail it for me? Do you have insight into why NexentaStor uses 4 as default when OI and Solaris default to 3?
LikeLike
Actually, yes, lmauth_level at either 3 or 4 should be OK, but be warned that 3 allows using the less secure “plain NTLM” hash for inbound authentication, where 4 requires NTLMv2 for inbound authentication.
LikeLike
Hey thanks so much for this post, it’s helped out a huge amount while I was trying to diagnose some similar problems.. Particularly collating the secitons from the man pages and notes on mailing lists.
I had similar problems and it turned out to be AD on Windows 2008R2 SP1, after I installed SP2 I could join the domain
So in summary, all of the settings I had made are as follows:
In AD, Default Domain Controller Security Policy, the following settings are defined
Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options
Network Security: LAN Manager authentication level: Send NTLMv2 response only
Network Security: Minimum session security for NTLM SSP based (including secure RPC) clients
Define, Uncheck both boxes
Network security: Minimum session security for NTLM SSP based (including secure RPC) servers
Define, Uncheck both boxes
On Nexenta
run “setup network service cifs-server unconfigure”
run “setup network service cifs-server configure”
Set the LM Authentication level to 4
Enable or Disable DNS updates
run setup network service cifs-server join_ads”
LikeLike
Great contribution Ross, thanks!
LikeLike