United States (change)
Shortcuts: Downloads Fedora Red Hat Network
Account Links: Cart Your Account Logout
While joining a Samba server to the domain does alleviate the server's need to have local Samba passwords set, Samba still must have a local system user to map a connecting network user to. This is necessary in order for Samba to determine whether to grant or deny access to the resources requested by the connecting user, based on the mapped local user's uid and group memberships, as well as the share and filesystem permissions.
Fortunately, Samba has two methods of dynamically adding system user accounts, so that the sysadmin does not have to manually create them for each domain user that will connect to the Samba server.
Using add user script is probably the simplest option of the two, as it only requires one configuration option.
The add user script Samba configuration option can be used in the [global] section of the /etc/samba/smb.conf file.
Some examples are given below:
# if you only want the accounts created but do not want the users to have a real # login shell or their own home directory on the server, use something like this: # add user script = /usr/sbin/useradd -g smbusers -s /bin/false -d /dev/null -M %u # if you want to the domain users to have a real login shell and a home directory # on the server, use something like this instead: add user script = /usr/sbin/useradd -g smbusers -s /bin/bash %u
The add user script function will create a connecting user's system account with if can they successfully authenticate first and the account does not already exist in /etc/passwd. Unless configured otherwise (such as in the first example above), the user's home directory will be created as /home/<username>.
Note that the examples shown above instruct Samba to set the created user's primary group to a group named smbusers, which is not a group that exists by default on a Red Hat Enterprise Linux server. This can be changed to any valid group name on your server or you can create a group on the server with the groupadd command, such as groupadd smbusers.
Also note that this functionality will not set a system password for the user's account, which would be necessary before such a user could actually login on the server in non-Samba ways (Samba uses their domain account password for authentication, which is authenticated by the domain controller). If the sysadmin desires the user to have a system password, one will need to be set with the passwd utility. See the passwd man page for details, man passwd.
Winbind is often considered the more elegant method of automating the creation of account information on the system for domain users and groups, although it should be pointed out that Winbind does not actually create these users and groups by adding them to /etc/passwd and /etc/group respectively. Simply described, it "inserts" them into the list of system users and groups instead with its own NSS (Name Service Switch) module, provided that the /etc/nsswitch.conf file has been edited appropriately. The users and groups do not actually exist on the system, but they can be used in Samba-related ways such as share permissions and file and directory ownership as if they actually are system users and groups.
Winbind is a separate service and must be properly configured by editing the /etc/samba/smb.conf and /etc/nsswitch.conf files appropriately. Other articles exist in the Red Hat Knowledgebase which contain detailed information on how to set up the Winbind service.
Each of these two options have their merits.
With all of these factors considered, add user script may be the best option overall, especially if domain users need real logins and home directories on the Samba server.
For more information regarding Samba and Winbind configuration, we would recommend the following sources of information: