Site Administration Page 4 - Handling User Accounts in Samba |
The complaint with Samba in regard to user accounts is that its user passwords must be maintained separately from the from the Unix or Linux system passwords. To help alleviate the pain of managing multiple passwords for each user, Samba provides a mechanism to synchronize the user’s Unix password entry when a CIFS client requests that the LanMan and NT password hashes be changed. Of course, this solution does not help when the user changes the password by means other than the SMB/CIFS protocol, such as using the passwd command or writing to the passdb storage directly using pdbedit. The only prerequisite of using this feature is for the root user to able to reset a user’s password without knowing the old password. The reason for this requirement is that the client encrypts the new password with the old password hash as the key. The clear text of the old password is never sent. Password hashes are one-way, so there is no way to derive the clear text of the password from the old password hash.
The smbd daemon currently supports three mechanisms for changing a user’s Unix password:
The simplest option of the three, the ldap password sync option (sometimes called ldap passwd sync ), instructs smbd to send a ModifyPassword extended request to the directory service, which then updates the userPassword attribute on behalf of the user. This option currently works only when Samba is using the ldapsam passdb module and when the LDAP directory service is running a recent version of OpenLDAP. To enable password synchronization, with all these prerequisites in place, add ldap password sync = yes to the [global] section of smb.conf. If you can’t make use of this optimal solution, the next option is to enable the unix password sync option and then choose which of the first two mutually exclusive password change mechanisms you wish to use. Relying on an external program is the older method. In this case, you must define a value for the passwd program parameter and then specify a passwd chat conversation string.* The chat value is a special string generally called an “expect string” or “chat string”; it lists pairs of strings in which the first of each pair is the text that you expect the external program to output, and the second is the text that the external program expects the user to enter. With an expect string, an automated system can interact with a program that was designed for a human user. In this case, Samba is pretending to be the root user and is interacting with a password change program. The Samba expect string is case-insensitive and can contain wildcards ( * ) to eat a variable number of characters when evaluating the output from the program in the passwd program parameter. Remember that the passwd program executable is run as root, so be sure to pass the Unix user name ( %u ) as a command-line argument, or else you will be stuck just changing root’s credentials. The following example works on most recent versions of Linux from Novell or Red Hat: [global] Deriving passwd chat values is not extremely difficult. This one was developed by examining the output from running /usr/bin/passwd from a shell prompt, as shown here: root# passwd lizard Notice that the expect string collapses the first line of output to a single * character. The pam password change Boolean parameter replaces the invocation of an external command with a series of calls to the system’s PAM library. The passwd chat param eters plays the same role as before, providing a means by which smbd is able to interact with the PAM password change interface. This requires that the Samba PAM service has been correctly configured in either /etc/pam.conf or /etc/pam.d/samba. The following is a basic PAM password change stack that performs strengths checks on the new password, and finally hands it off to the pam_unix.so library to actually update the user’s credentials: password required pam_pwcheck.so nullo k Next, we can update the previous example to make use of the new PAM configura tion file: [global] If desired, password strength checking can be performed using an external utility specified by the check password script parameter. This directive should point to a tool or script that accepts the new password as its single argument and returns 0 for valid passwords and a nonzero value if the strength check fails. Table 5-13 summarizes all of the password synchronization options we have discussed in this section. Table 5-13. Password synchronization parameters
Please check back next week for the continuation of this article.
blog comments powered by Disqus |