6.3. Managing Users

User name information for accessing a Samba server is obtained from the /etc/passwd system file. You can create separate accounts to be used for the Samba server only. These accounts will correspond to the system accounts but can only be used to log onto the Samba server and not onto the system.

Samba user names are described in the /etc/samba/ smbusers file. The name and location of the file can be changed using the username map parameter in the smb.conf file. The contents of the /etc/samba/smbusers file are similar to the following:

 # Unix_name = SMB_name1 SMB_name2 root = administrator admin nobody = guest pcguest smbguest

The list has several uses. For example, it can be used to map DOS or Windows user names to a Linux user name. For example, the maximum rights Window user, administrator or admin, can be mapped to the Linux user with the same function who goes by a different name: root. In this case, the mapping is done in the second entry of the example: root = administrator admin . Even though administrator and admin are different accounts, they will use the same password: the one of the root user.

The file's second function is to accumulate several user names under one user account. For example, you may have to assign the same rights to a group of users. This is done by creating a Linux nobody account, which users will use for their work. Next, Samba users guest, pcguest , and smbguest are created, which will be used to log onto the system.

The information about users allowed access is stored in the /etc/samba/smbpasswd file. Its location and name can be changed by means of the smb passwd file parameter of the smb.conf file. The following is an example of the contents of the smbpasswd file:

 flenov:0:813D6593C11F1173ED98178CA975D79:[UX     ]:LCT-41FA818F robert:500:813D6593C11F1173ED98178CA975D79:[UX     ]:LCT-41FA818F

It can be seen right away that it is somewhat similar to the contents of the /etc/passwd file. The information in it is divided into several colon -delimited fields. The most interesting of these fields are the first three: the user name, the Linux UID, and the password.

It is inconvenient to add users manually, because it is not easy to encrypt and enter the password into the file. To make this task easier, the Samba package includes the smbpasswd utility. It is used with the following options:

a Adds a user to the Samba system. The account should already exist in the /etc/passwd file. For example, the following command adds the user robert, which you worked with before:
```
 smbpasswd -a robert. 
```

In response, the program asks you to enter and confirm the password. This password has no relation to the system password and is only used to log onto Samba. Thus, the system and Samba passwords can differ . I recommend making them different. All Windows versions can store passwords, and this function is not implemented securely in Windows 9 x. If the Samba password is the same as the system password and falls into the wrong hands, the system will be compromised.

x Removes a user. For example, the following command removes the robert user from the system: smbpasswd -x robert .
d Deactivates a user. The following command temporarily deactivates a user without removing him or her from the system: smbpasswd -d robert . After the command is executed, the entry corresponding to the robert user looks as follows :
```
 robert:500:813D6593C11F1173ED98178CA975P79:[DUX ]:LCT-41FA818F 
```
Note that the letter "D" was prefixed to the contents of the fourth field. It indicates that this account has been deactivated. In this way, you can easily tell, which accounts are active and which are not.
e Activates a user. For example, executing the smbpasswd -d robert command activates the robert user.

Information about additional options for this utility can be found on its man page.

The /etc/samba/smbpasswd file is used if passwords are sent over the network encrypted. In this case, to allow all system users to access Samba, the smbpasswd command has to be executed for each of them. There are scripts to automate this task, but they are ineffective because they do not set a password. Moreover, most often they transfer all users, even including those who should not have access to the system, such as bin, adm, and daemon.