be a problem, but it is generally not good administrative practice. This would 

mean that adding an account to the domain would mean adding an account to all 

clients. That sort of takes the advantage out of using a domain.

In this section we describe how to use winbind to avoid creating domain 

accounts locally. The winbind daemon will take care of translating domain 

accounts to uids and gids to the client OS.

The winbind daemon will read its settings from the smb.conf file. The lines in 

Example 7 5 have to be added to the smb.conf to enable winbind to function.

Example 7 5   Lines added to smb.conf for winbind

[global]

winbind separator = +

idmap uid = 10000 20000

idmap gid = 10000 20000

winbind enum users = yes

winbind enum groups = yes

template homedir = /home/%D+%U

template shell = /bin/bash

The separator means that accounts will be written as  AD6380+Administrator  for 

the Administrator account in the domain AD6380. The other entries give the uid 

and gid range to use for domain accounts and what to use as shell and home 

directory in case of actual logon. We have found that a plus sign (+) as a winbind 

separator will work most successfully within the Linux environment.

Important:

 If you have a very large domain, you may not be able to 

incorporate all users in your idmap uid range. This is only problematic if you 

use winbind on a domain client, which all users use via the network.

After these changes the winbind daemon has to be started. Make sure the 

winbind daemon starts on system boot. On most distributions (certainly on Red 

Hat and Novell/SuSE) this is done using the following command:

chkconfig winbind on

The winbind functionality can be tested by using the 

wbinfo

 command. Executing 

with the  u option will show all domain accounts translated and the  g option will 

show all domain groups.

Example 7 6   Example output of wbinfo command

[root@client1 root]# wbinfo  u

AD6380+Administrator

AD6380+Guest

 Chapter 7. Integration how tos 

137