Using Winbind with Samba Domain Member Servers


Winbind is a component of the Samba suite of programs that allows the integration of 'Nix OSs and Microsoft Windows through a unified logon. Winbind uses a 'Nix implementation of Microsoft RPC calls, Pluggable Authentication Modules(PAM) and the Name Service Switch(NSS) to allow Windows NT/Active Directory(AD) domain users to appear and operate as 'Nix users on a 'Nix machine.
Winbind unifies 'Nix and Windows NT/AD account management by allowing a 'Nix box to become a full member of an NT/AD domain. Once this is done, the 'Nix box will see NT/AD users and groups as if they were “native” 'Nix users and groups, allowing the NT/AD domain to be used in much the same manner that NIS+ is used within 'Nix-only environments.
Winbind can also be used in conjunction with a Samba PDC, thus eliminating the need for a Microsoft server on the network. This can provide a simple to implement means of a single source of login on an all 'Nix network.
When I refer to a domain in this article, it can be an NT PDC, a Win2k/Win2k3 AD domain or a Samba PDC.


Using winbind on the Samba Member Server eliminates the need to create local 'Nix user accounts on the server other than root. Permissions and ownership can be assigned to local files and directories using the user and group accounts in the domain. Whenever Samba asks the operating system to lookup a user or group name to check permissions, the query will be resolved by asking the Domain Controller for the specified domain to do the lookup, not the local 'Nix user accounts.

The result of this is that the vast majority of administrative overhead needed to maintain a Samba server is eliminated. Once Samba is configured and file system permissions are assigned, the server is ready. No user account maintenance is needed. It's all done on the Domain Controller. The only obvious indication that Winbind is being used is that user and group names may take the form DOMAIN\user and DOMAIN\group.

Additionally, Winbind provides an authentication service that hooks into the PAM system to provide authentication via a domain to any PAM-enabled applications. It can be used to control console login, telnet, ftp, ssh and others.

This article will only cover the use of winbind for Samba authentication on a Samba Member Server. Using winbind to control console and other logon will be covered in another article.


This article is targeted towards those who already have a Samba server configured and working using the domain or ADS security modes, or know how to configure one. There is plenty of help available on using security = domain to create a Samba Member Server. For help on using security = ADS with Samba 3.0, see this article:

in the Justlinux Help File Library.

My experience with winbind has been on Red Hat 9 machines and that's what this article is geared toward. However, the principles should be the same for any Linux distribution.


This is the setup on my network:

Red Hat 9 with Samba 3.0 installed from the RPM package from, not from the RH CDs.
host/NetBIOS name - delldim(
Samba server is set up using security = ADS and uses the Win2k AD DC for authentication.

Win2k AD DC running SP4
Machine name - pe500sc(
Second Win2k AD DC named mainnt(
AD domain name -
Network domain name -
Running DNS for the entire network
Running WINS for the entire network


You should make a backup copy of your working smb.conf file before you make any changes to it. You do not need to stop Samba on your existing Member Server to make the configurations necessary for winbind.

Configuring Samba to use winbind is just a matter of adding several lines to your smb.conf file. Here's my original smb.conf for using security = ads before winbind:


workgroup = the_cowans
netbios name = delldim
server string = Dell Dimension 8200
security = ads
password server =
encrypt passwords = yes

load printers = yes
printing = cups
printcap name = cups

log file = /var/log/samba/%m.log
max log size = 0

socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192

local master = no
domain master = no
preferred master = no
wins server =
dns proxy = no

#============================ Share Definitions ==============================
# Any authenticated user can view or download files from this share
path = /sharefile
browseable = yes
writeable = no
write list = rlcowan
guest ok = no

# Free for all share any authenticated user can read or write to
path = /public
browseable = yes
writeable = yes
guest ok = no

comment = All Printers
path = /var/spool/samba
browseable = yes
guest ok = yes
writable = no
printable = yes

To add support for winbind, I added these lines to the global section:

winbind separator = +

This winbind parameter is used to separate the domain and username with '+', like THE_COWANS+rlcowan. If you don't use this line, the default separator is \ like is normally used on Windows machines to separate the domain and user name. The problem I ran in to with this is that the \ can be interpreted as an escape character. In certain situations, you have to use more than one \ (for example: THE_COWANS\\rlcowan) as the separator or a command will fail. This can be very confusing for inexperienced users. I recommend you use something besides \ for the separator. The + works fine.

winbind uid = 10000-20000

'Nix OS's use user and group ID's for authentication. This winbind parameter specifies the range of user ids that are allocated by the winbind daemon. This range of IDs should have no existing local or NIS users within it as strange conflicts can occur otherwise. The use of uids from 10000 to 20000 for domain users is usually a safe bet.

winbind gid = 10000-20000

This winbind parameter specifies the range of group IDs. Once again, the use of uids from 10000 to 20000 for domain groups is usually a safe bet.

winbind enum users = yes
winbind enum groups = yes

This winbind parameter allows the enumeration of winbind users and groups. Only in rare situations should you ever need to set these to no.

winbind use default domain = yes

This winbind parameter eliminates the need to use the domain name with the user/group name. The domain name plus the separator will automatically be prepended to the user name.

These are the only additions to smb.conf you need to make for Samba to use winbind.


The only other configuration file that needs to be modified for winbind to work is /etc/nsswitch.conf. This allows user and group entries to be visible from the winbindd daemon. You should make a backup copy of your nsswitch.conf file before making any modifications. The only lines that need to be modified are:

passwd: files winbind
group: files winbind

All you need to do is add winbind to the end of those lines.

Next you need to be sure the library needed to run the winbindd daemon through nsswitch,, is in the proper location, which is /lib. By default, this should already be there unless you installed Samba from source. If it's not there, copy the file from the samba/source/nsswitch directory where your Samba source is located.

I also found it necessary to make the following symbolic link:

root# ln -s /lib/ /lib/

Without this symbolic link, some of the commands used to test winbind will work and some won't.

The libraries needed by the winbindd daemon will be automatically entered into the ldconfig cache the next time your system reboots, but it is faster (and you do not need to reboot) if you do it manually now:

root# /sbin/ldconfig -v | grep winbind

This makes libnss_winbind available to winbindd and echoes back a check to you of: ->


After all of the configuration changes are made, you need to start the services. You need to start Samba first and then winbind. On Red Hat, you can execute:

service smb start(or restart if it's already running)
service winbind start

If you are not using Red Hat, you can start or restart Samba in your normal way. If you have no script available to start winbind, you can start it by just executing winbindd at the command line. You may find it in /usr/sbin/ or possibly in /usr/local/samba/bin/. It depends on your distribution and how you installed Samba.

To start it at boot up, just place the command in a start up script, possibly /etc/rc.d/rc.local.


Once you have Samba and winbind started, it's time to test it. There are 4 commands listed here you can use to insure that it is operating correctly. I have seen it take 20-30 seconds after winbindd is started before these test commands return the proper information so don't be alarmed if they don't work immediately.

wbinfo -u

This should echo back a list of users in your domain. For example, I get the following response:

[rlcowan@delldim rlcowan]$ wbinfo -u

Note that if I wasn't using the "winbind use default domain = yes" line in smb.conf, the output would look like this:


You can do the same sort of thing to get group information with:

wbinfo -g

This should echo back the groups in your domain. For example, I get:

[rlcowan@delldim rlcowan]# wbinfo -g
Domain Users
Domain Guests
Domain Computers
Domain Controllers
Cert Publishers
Domain Admins
Enterprise Admins
Schema Admins
Group Policy Creator Owners
MTS Trusted Impersonators
_Web Anonymous Users
_Web Applications

To get a list that looks like your /etc/passwd list followed by the domain users with their new UIDs, GIDs, home directories and default shells execute:

getent passwd

The results of this should be something like:

[rlcowan@delldim rlcowan]$ getent passwd


I left out the local users to keep this article short. You can see that this lists all of the users in /etc/passwd plus all of the domain users at the end. If you executed this command against a large domain, it could take quite a while to print out.
Notice that the home directory for the domain users is listed as /home/THE_COWANS/username. This is the default if you don't specify a home directory with the "template homedir =" option in smb.conf. Since I'm not interested in providing users a home directory on this server, I'm not using this option. If I wanted to provide my users with a home directory on this server located in the normal location for Red Hat, I would add the line "template homedir = /home/%U" to smb.conf. Each user would then be listed with a home directory of /home/username. However, these home directories would not be automatically created on the server. You would need to create them manually and assign the proper permissions for the users to use them. You would also need to create a [homes] share. In my case, the user's home directories are on the DC where they are automatically created.

Also notice that the domain users default shell is listed as /bin/false, which is the default. This prevents these users from logging in from the console. The "template shell =" option is used in smb.conf to specify a shell for the users. Using that option is beyond the scope of this article.

To see the same thing for your groups, execute:

getent group

The results of this should be something like:

[rlcowan@delldim rlcowan]$ getent group
Domain Users:x:10002:rlcowan
Domain Guests:x:10000:
Domain Computers:x:10003:
Domain Controllers:x:10004:
Cert Publishers:x:10005:
Domain Admins:x:10001:Administrator
Enterprise Admins:x:10006:Administrator
Schema Admins:x:10007:Administrator
Group Policy Creator Owners:x:10008:Administrator
MTS Trusted Impersonators:x:10009:
Family:x:10010:household,cmcowan,kmcowan,crcowan,r lcowan
_Web Anonymous Users:x:10012:IUSR_NT_SERVER
_Web Applications:x:10013:IWAM_MAINNT

Once again, I've only shown the domain groups at the end.

If you don't get the proper results from the wbinfo and getent commands, your system is not configured properly for winbind. You can:

- check smb.conf and nsswitch.conf for mistakes
- make sure is located in /lib
- make sure the symbolic link shown above is in /lib

Then restart winbind and Samba and test again.

Once you do get the proper response from these test commands, you are ready to assign file system and Samba share permissions on your server. Just assign these permissions to the users and groups in your domain, not to user or group accounts on your local machine. Then connect to the Samba shares from a network computer and test the permissions.

You can also test domain authentication from the local command line with smbclient. Execute:

smbclient -L localhost -U username

Use a user account from your domain. It should prompt you for a password and then respond with a list of the shares on your server. You can also try it against your domain controller.
On my machine I get:

[rlcowan@delldim rlcowan]$ smbclient -L localhost -U rlcowan
        Sharename      Type      Comment
        ---------      ----      -------
        sharefile      Disk
        public         Disk
        IPC$           IPC       IPC Service (Dell Dimension 8200)
        ADMIN$         IPC       IPC Service (Dell Dimension 8200)
        HP2200Raw      Printer   Created by redhat-config-printer 0.6.x
        HP890Raw       Printer   Created by redhat-config-printer 0.6.x
        HPDJ890        Printer   Created by redhat-config-printer 0.6.x
        HPLJ2200       Printer   Created by redhat-config-printer 0.6.x
        Server               Comment
        ---------            -------
        DELLDIM              Dell Dimension 8200
        Workgroup            Master
        ---------            -------
        THE_COWANS           PE500SC
rlcowan is an account in my AD domain.

If your server passes all of these tests, you can be sure that Samba and winbind are working properly together.


If you are not going to allow users to log on locally to the console of your Samba server, for security reasons you should delete any existing local user accounts(and there associated group accounts if they exist) that you have created. They will no longer be needed. This does not include the user accounts that exist for certain services to run(such as named and ftp). Don't delete them. On a Red Hat machine, the user accounts that you have created will normally have a uid of 500 and above.

The only local user account you will need is root. Since always logging on as root is not an acceptable practice security wise, you may want to keep one additional local user account to log in with.


Even when using winbind, you still need to be sure to have the proper file/directory ownership and permissions set on any directory you share out. You still use the chown and chgrp commands to assign file/directory ownership. However, the syntax may vary a little.

If you have "winbind use default domain = yes" in smb.conf, then the syntax doesn't change. If you wanted to assign the domain user rlcowan and the domain group finance as the owners of the /finance directory, the command would be:

chown /finance

If you have "winbind use default domain = no" then the syntax would change. You need to include the domain name and the separator in the command. In my case, assigning the above ownership would look like this:

chown THE_COWANS+rlcowan.THE_COWANS+finance /finance


When using winbind and ADS security, I found assigning share permissions in smb.conf a little strange. To make a share read only to all users except rlcowan, the share definition would normally look like this:

# Any authenticated user can view or download files from this share
path = /sharefile
browseable = yes
writeable = no
write list = rlcowan
guest ok = no

However, to accomplish the same thing using winbind with ADS security, I had to change the share definition to this:

# Any authenticated user can view or download files from this share
path = /sharefile
browseable = yes
writeable = no
write list = THE_COWANS.COM+rlcowan
guest ok = no

This was true whether I had "winbind use default domain" set to yes or no. This suprised me. At the most, I would have expected to have to use THE_COWANS+rlcowan but if I didn't add the .COM to the domain name, it wouldn't work.

The same principle would apply for assigning a group in the write list. For the finance group, the syntax would be "write list = @THE_COWANS.COM+finance". If you wanted to allow both user rlcowan and group finance to write to the share, you would use "write list = @THE_COWANS.COM+finance, THE_COWANS.COM+rlcowan"


The next logical step is to configure the Linux machine to use winbind to control authentication for other services, such as console logon, telnet, ftp, ssh and others. I'll save that for another article.