Using clear-text passwords has many disadvantages in modern networks. The lack of security is the most serious of these; plus, no current CIFS clients support this in their default configurations. But clear-text authentication has one alluring feature that still entices some systems administrators even today: having smbd authenticate users against an NIS map or local /etc/passwd file.
Sambaís domain controller functionality cannot be used with encrypt passwords = no .
If you choose this route, the first requirement is to configure the Windows clients to send the clear-text password, which can be done by importing the appropriate file from the docs/registry/ directory of the Samba source distribution into the clientís local registry. The operating system name is part of the filename. So for a Windows XP client, use the file called WinXP_PlainPassword.reg. After you import the correct file, a reboot of the client is required to make the change effective.
The second step is to set encrypt passwords = no in the [global] section of smb.conf. This setting instructs Samba to ignore any smb.conf passdb backend directives when authenticating users, and instead to validate each user by hashing the transmitted password and comparing it against the entry returned from the system account list.
There are a few subtleties of which you should be aware. Although Windows NT-based clients send the clear text password as it was typed by the user, Windows 9x/Me hosts do not. These clients transmit the clear-text password in all uppercase. You must inform Samba as to how many permutations of that password it should attempt to validate before giving up and reporting failure. The password level option accepts a positive numeric value that represents the maximum number of uppercase letters in password test cases. For example, if the client transmitted a password of ďcow,Ē a password level of 1 would result in the follow variations being tested: COW, cow, Cow, cOw, and coW. The first two combinations shown are tried irrespective of the password level. Samba always tries the password as transmitted first, followed by an all-lowercase version and an all-uppercase version of the string (assuming the originally transmitted password had mixed case). The password level option defaults to 0, because as the number of combinations to be tested increases, a proportional amount of CPU and time is needed for the authentication process.
If your serverís operating system uses DES password hashes, setting a password level of 8 characters effectively makes the passwords case-insensitive, because DES limits the password to 8 characters.
Here is a basic smb.conf that allows users to authenticate against /etc/passwd, as long as passwords contain at most four uppercase characters. If there are no users with Windows 9x/Me clients that will require access to the server, the password level option can be removed altogether.
[global] encrypt passwords = no password level = 4
In some extreme cases, it may be necessary to have Samba perform the same type of case permutations to a userís login name, because Windows 9x/Me clients also convert the login name to uppercase before sending to the server. Unix platforms have historically presented usernames as case-sensitive. This is yet another point of contention between Windows and Unix hosts. Internally, Samba first looks for the name in all lowercase, as this is the most common case on Unix hosts, followed by string as transmitted from the client, and finally in all uppercase. If no user by any of the names can be found, Samba then attempts a round of upper- and lowercase combinations controlled by the value of username level . Only when a userís name is stored in mixed case in the serverís list of accounts should you even consider changing the username level from its default of 0.
The username and password level options are summarized in Table 5-4.
Table 5-4. Username- and password-level parameters
Number of case permutations to test when validating a clear text password.
Number of case permutations to test when searching for the login name sent in a connection request.
Please check back next week for the continuation of this article.