If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Using Winbind with Samba Domain Member Servers

Using Winbind with Samba Domain Member Servers

WHAT IS WINBIND?

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.

WHY WOULD I WANT TO USE THIS?

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.

TARGET AUDIENCE

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:

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.

NETWORK SETUP

This is the setup on my network:

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

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:

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.

ADDITIONAL CONFIGURATION

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, libnss_winbind.so, 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/libnss_winbind.so /lib/libnss_winbind.so.2

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:

libnss_winbind.so -> libnss_winbind.so

START SERVICES

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:

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.

TEST

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:

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.

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 libnss_winbind.so 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:

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

CLEANING UP

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.

ASSIGNING FILE/DIRECTORY OWNERSHIP

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 rlcowan.finance /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

ASSIGNING SAMBA SHARE PERMISSIONS

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:

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"

WHAT'S NEXT?

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.

If God hadn't meant for us to use GUI tools, there wouldn't have been a Xerox PARC.