NTLM is the challenge/response authentication algorithm developed by Microsoft and utilized by Windows and other CIFS clients and servers. In the original implementations of NTLM, the client uses a hashed version of the user’s password to generate a 24-byte response to a challenge returned by the server in the negotiate protocol reply. The actual details of the algorithm are not important from the point of view of a systems administrator.* The key facts to remember are:

1. The hashed password is never sent over the wire.
   
2. The user’s password hash is a shared secret used to calculate the response. If the client’s and the server’s calculated response match, it proves that both knew the same initial password hash.
   
3. Both the LanManager and NT password hashing algorithms do not use any salt. Therefore a string always produces the same LanMan and NT hashes.

The last point is important to remember, because it implies that the password hash is a plain-text equivalent. If an attacker were to uncover a user’s password hash, he could impersonate that user without deriving the original clear-text string. Even so, many users reuse a single password for multiple services (email, banking accounts, and so on). Given that the LanMan password is limited to 14 uppercase characters and possesses a very weak hashing algorithm, protecting Samba’s account database becomes extremely important.

Enabling NTLMv1 authentication in Samba is as simple as setting encrypt passwords = yes in the [global] section of smb.conf and then creating user accounts using either smbpasswd or the pdbedit utility, introduced in Chapter 2. When adding a new user, if the password is less than or equal to 14 characters in length, Samba stores two password hashes. Following is an entry from an smbpasswd file for a user named lizard with a password of test. The first string of hexadecimal digits is the LanMan hash followed by the NT password hash. Each field is separated by a colon. The line has been wrapped due to space limitations and appears as one line in your smbpasswd file.

 lizard:1004:01FC5A6BE7BC6929AAD3B435B51404EE :
   0CB6948805F797BF2A82807973B89537:[U        ]:LCT-44528BD2:

If the user’s password is longer than 14 characters, the LanMan hash is disabled so that the security value of the password is not degraded by storing a truncated version. A dis abled password is represented by a string of Xs. This is what lizard’s smbpasswd entry would look like with a password of somepasswordstringlongerthanfourteen:

 lizard:1009:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX :
   0FF1DFDA18B63EC50E1FD9ECFCDFDE05:[U        ]:LCT-44528C6B:

It is possible to disable a Samba server’s use of LanManager passwords altogether by setting the lanman auth option to no in the [global] service.

Table 5-6 summarizes the smb.conf parameters related to NTLMv1 authentication.

Table 5-6. NTLMv1-related parameters

Parameter	Value	Description	Default	Scope
encrypt passwords	boolean	Controls whether Samba advertises support for NTLM authentication.	yes	Global
lanman auth	boolean	Determines whether smbd should attempt to validate NTLM responses using the LanManager password hash.	yes	Global

NTLMv2

NTLMv2 is a variant of the original NTLM authentication scheme, and was introduced in Windows NT 4.0 SP4. However, it has seemed to gain any semblance of widespread adoption only in conjunction with Active Directory deployments. Its main advantage over NTLMv1 is protection against man-in-the-middle and replay attacks. As with NTLMv1, the actual protocol details are unimportant for day-to-day system administration duties.

Supporting NTLMv2 on Samba servers is a process of disabling support for the older authentication protocols. The following [global] section snippet illustrates the use of the lanman auth and ntlm auth parameters:

  [global]
      ## Enable support for only NTLMv2 on the server
      encrypt passwords = yes
      lanman auth = no
      ntlm auth = no

Unlike many other client and server capabilities, support for NLTMv2 cannot be negotiated. If a client sends an NTLMv2 response, Samba always uses that. However, unless the older, less secure authentication schemes are disabled on the clients as well, NTLMv2 does very little to help improve the overall security of a system, primarily because both the NTLMv1 and NTLMv2 client responses are created using the NT password hash. The situation is comparable to restricting 9 out of your 10 hosts to SSH access but allowing Telnet access to the remaining tenth host. Security is only as strong as its weakest link.

Table 5-7 summarizes the parameters needed to restrict access to using NTLMv2 authentication only.

Table 5-7. NTLMv2-related parameters

Parameter	Value	Description	Default	Scope
ntlm auth	boolean	Controls whether Samba should validating using the NTLMv1 24-byte response. This parameter should be disabled, along with the lanman auth option, to enforce use of NTLMv2.	yes	Global