NetServer Authentication and Security Considerations

Resolving The Problem

LMCompatibilityLevel is a Windows setting (available in Microsoft Windows NT 4.0 and above) that can be used to restrict the sending of LANMAN challenge and response passwords (hashes) over the network. A client at LMCompatibilityLevel 0 or 1 sends LANMAN and NTLM hashes. At LMCompatibilityLevel 2, only the NTLM hash is sent. At LMCompatibilityLevel 4 both LANMANv2 and NTLMv2 hashes may be sent.

Note: Windows 7, Windows 2008 Server, and above, completely disabled the use of LANMANv1 (LM) password encryption. As a result, a case-insensitive password can not be sent from Windows 7.

Note: At QPWDLVL 1 and 3, NetServer cannot support LANMAN authentication because the hash is not stored locally.

Note: The QZLSPWDANY$ hidden share was originally designed as a switch that would allow IBM i NetServer to either support LANMAN authentication, or not. If QZLSPWDANY$ existed, then LANMAN was supported. If QZLSPWDANY$ did not exist, then LANMAN was not supported. At current IBM i OS versions, a NetServer configuration option 'Allow authentication with LAN Manager password hash' exists in NetServer properties. Setting 'Allow authentication with LAN Manager password hash' ON causes the same results as creating a QZLSPWDANY$ hidden share. However, if a QZLSPWDANY$ exists, NetServer will use that and will ignore the 'Allow authentication with LAN Manager password hash' setting (Meaning if the share exists, but 'Allow authentication with LAN Manager password hash' is set OFF, then the use of LANMAN authentication will be allowed).

Note: LMCompatibilityLevel is set in the Local Security Policy, accessible by running secpol.msc then going into Local Policies, Security Options. The specific setting is: "Network security:LAN Manager authentication level"

NetServer accepts all but LANMANv2 (given the right conditions). The chart below shows this.

Table 1 displays the type of hash that is accepted based on the following:

o	QPWDLVL setting
o	Existence of QZLSPWDANY$ share (or the option to 'Allow authentication with LAN Manager password hash' checked in NetServer properties, when connecting to IBM i operating system at V5R4 and above)
o	LMCompatibilityLevel

Table 1:

If QPWDLVL / QZLSPWDANY$ is set at: Exists OR NetServer is configured to allow LANMAN authentication	At LMCompatibilityLevel 0	At LMCompatibilityLevel 1	At LMCompatibilityLevel 2	At LMCompatibilityLevel 3	At LMCompatibilityLevel 4	At LMCompatibilityLevel 5
0 / No	mono-case only	mono-case only	mono-case only	mono-case only	mono-case only	mono-case only
0 / Yes	mixed-case with LANMAN	mixed-case with LANMAN	mono-case only	mono-case only	mono-case only	mono-case only
1 / No	mono-case only	mono-case only	mono-case only	mono-case only	mono-case only	mono-case only
1 / Yes	mono-case only	mono-case only	mono-case only	mono-case only	mono-case only	mono-case only
2 / No	mixed-case with NTLM	mixed-case with NTLM	mixed-case with NTLM	mixed-case with NTLMv2	mixed-case with NTLMv2	mixed-case with NTLMv2
2 / Yes	mixed-case with NTLM	mixed-case with NTLM	mixed-case with NTLM	mixed-case with NTLMv2	mixed-case with NTLMv2	mixed-case with NTLMv2
3 / No	mixed-case with NTLM	mixed-case with NTLM	mixed-case with NTLM	mixed-case with NTLMv2	mixed-case with NTLMv2	mixed-case with NTLMv2
3 / Yes	mixed-case with NTLM	mixed-case with NTLM	mixed-case with NTLM	mixed-case with NTLMv2	mixed-case with NTLMv2	mixed-case with NTLMv2

If a client provides a LANMAN and an NTLM hash, only the NTLM hash is used unless the QZLSPWDANY$ share exists (or NetServer is configured to allow LANMAN authentication). This is because the NTLM hash is more secure. If only a LANMAN hash is provided (as was done by Windows 9x), that hash is used. NetServer does not support LMv2 hashes; therefore, LMV2 always fails. NTLM and NTLMv2 hashes are always accepted (with the restrictions in the table above) unless NetServer is configured for Kerberos-only authentication.

The QPWDLVL of the system does not affect the hashes that NetServer can accept. The thing that it does do is make the NTLM style hashes work with mixed-case Windows passwords. This is possible with QPWDLVL 2 and 3 because the system password can be mixed-case.

NetServer does not indicate to Windows to send a specific type of encryption. The only thing the server tells the client during the Negotiate is if extended security is supported by the server. The client will then try to negotiate whether to use Kerberos or password hashes. At no point does NetServer tell the client what form of password hash to use nor is there any way that NetServer could tell the client what form to use.

NetServer Authentication Q&A:

Question: Does NetServer store domain names in the encrypted passwords? If so, which domains does it store for each authentication type and how does that vary between various QPWDLVL settings? If not, why do some Domain/UserID combinations work and others fail?

Answer: The domain name is not part of any password hash except for NTLMv2. The domain name is not stored. Rather, it is provided by the client in the Session Setup request. It should not have any effect on the NTLM hash; however, Microsoft does seem to use it to correctly compute the hash in the case where a matching user exists on the domain and on the server but where the passwords are not the same. This is not indicated in any CIFS specification, and only Microsoft knows why, how, or when this is done.

Question: Will NtlmMinClientSec and NtlmMinServerSec (found in HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0) effect NetServer Authentication?

Note: NtlmMinClientSec and NtlmMinServerSec specific the minimum required security setting of client-side network connections for applications using the NTLM security support provider (SSP).

Answer: Development believes that as of V5R4, NetServer can work with a client with NtlmMinClientSec set to 0x10 (Integrity) if message authentication is turned on. This has not been tested, and no support is provided by IBM. Releases prior to V5R4 will likely fail if anything other than 0x0 is set for NtlmMinClientSec.

We currently have no information on whether NtlmMinServerSec affects NetServer connections.

Question: Can every version of Windows provide a LANMAN hash?

Answer: Every version of Windows prior to Windows 7 can provide a LANMAN hash. Windows 7 (and above) removed the capability to send a LANMAN hash.

Updates:

This document will be updated periodically as we collect additional information about how various Windows Settings can affect NetServer Connectivity. The information in the document has been confirmed by NetServer development to be current and correct at OS 720.