The proof of identity in the session setup request can take several forms. We group the mechanisms supported by Samba into three categories:
The first two areas are covered here. Kerberos authentication will be covered in the context of Active Directory domain membership in Chapter 10.
Much of Samba is surrounded by urban legends and common misunderstandings. One such myth is that older versions of Windows did not support password encryption or the NTLM
challenge/response authentication mechanism. The confusion arises from the behavior of pre-Windows NT 4.0 SP3 clients and the original versions of Windows 95. These clients would happily transmit the password’s clear text to a server if the negprot response indicated that password encryption was not supported. Such behavior is open to abuse, as you can imagine.
The result was that Microsoft decided that Windows clients must refuse to downgrade to sending clear-text passwords to servers that report lack of support for NTLM. This move was valid, as all Microsoft servers have long supported NTLM. Samba has also supported NTLM for many years, but it was not the default password setting until the 3.0.0 release.
All recent Microsoft clients, including the MS-DOS LanMan client, Windows for Workgroups, and the original Windows 95 releases, prefer to use encrypted passwords if supported by the server. Therefore, if you change a Samba host from encrypt passwords = no to yes , Windows clients automatically begin to use the NTLM authentication algorithm. You might want to configure the clients to never downgrade to clear-text authentication at this point, just to prevent clever attackers masquerading as SMB/CIFS servers. But no client-side changes are required to have the new server functionality utilized.
