I could write my own reply, but... Shamelessly copied from TechRepublic.com. Written by Scott Lowe
Rather than forwarding the article via mail to the group, I'll just cut and paste. ++++++++++++++++++++++++++++++++++++++++++++++ Many administrators would like to roll out a Samba installation into an already existing Windows NT or Windows 2000 domain, but that would require creating user accounts for every incoming Windows user. It would seem that there must be a better way, and there is-winbind. The winbind utility is a part of the Samba 2.2.2 distribution; it doesn't come with previous distributions. By building winbind support into a Samba installation and configuring its various components, you'll be able to connect to a Samba share using a Windows domain account without having to create a separate UNIX account. If you don't have PAM, forget about it If you're running a Linux system that doesn't support PAM, you won't be able to use winbind. Using winbind for easy user administration If you're planning to install a Samba server as a supplement to an existing Windows domain, you'll probably prefer to continue managing your users centrally using Windows' built-in utilities. Winbind provides a mechanism for unified logons between Windows NT/2000 and UNIX. It creates a single point of administration by supplementing Samba's ability to become a member of a Windows domain and to allow the UNIX box to see Windows users and native UNIX users. Best of all, the entire process is completely transparent to the users. You can also extend this capability beyond Samba to other system functions, such as incoming telnet, ssh, and ftp. Here, I'll demonstrate how to get Samba up and running, install winbind, and get authentication working between a Samba server on Red Hat Linux 7.1 and a Windows 2000 server acting as the domain controller. Caution You shouldn't perform certain actions in a production environment, and that' s especially true here. If you make mistakes while modifying system logon files, you run the risk of not being able to access your system at all. For that reason, it's imperative that you test this in a lab first. Before you begin, whether or not you have a working Samba system, you need to recompile the package to add support for winbind. I'm going to assume that you've downloaded Samba 2.2.2, are logged on as a root user, and have extracted it to /usr/local/samba-2.2.2 by using the following while in /usr/local: gunzip -dc samba-2.2.2.tar.gz tar xvf -" To compile Samba with winbind support, you need to specify a --with-winbind option to the configure command. You'll also build in support for smbwrapper, which I'll discuss further in a future article. First, change to the newly created directory with cd /usr/local/samba-2.2.2/source. The next step is to prepare the source for compilation by running this command. Then, build the application binary with these two commands: Make make install Now, you need to copy the libraries created during the installation to the locations that will make them useful for a real Samba installation. Table A shows the commands to copy the correct libraries and a description of what each command is doing. Table A Command Description cp /usr/local/samba-2.2.2/source/nsswitch/libnss_winbind.so /lib This copies the NSS winbind module to the /lib directory. ln -s /lib/libnss_winbind.so /lib/libnss_winbind.so.2 This step was recommended by the Samba 2.2.2 documentation to allow nsswitch to find the winbind libraries. cp /usr/local/samba-2.2.2/source/nsswitch/pam_winbind.so /lib/ security This copies the PAM authentication module to the /lib/security directory. To make the new module available to winbind, type the following: /sbin/ldconfig -v Creating the smb.conf file You first need a basic /usr/local/samba/lib/smb.conf file, which Samba uses for all of its configuration parameters. Use your favorite text editor (mine is Pico) to create this file; some GUI utilities, such as SWAT (which comes with most Samba installations) and Webmin, can allow you to do this via a browser, but you'll have more control over your smb.conf file if you create it by hand. While you're working, remember that the lines marked with an asterisk (*) at the beginning need to be modified to fit your environment. The asterisk should not be placed into the smb.conf file. Table B shows the lines I put into my smb.conf file. Table B [global] Explanation (*)netbios name = pear This is the NetBIOS name of the Samba server. (*)workgroup = slowe This is the name of the domain that the Samba server is to join. encrypt passwords = yes This is required for machines with Windows 95 OSR2 and above and Windows NT 4.0 machines with SP4 or later. security = domain This specifies that accounts will be looked up via the domain controller. password server = *-- This is an asterisk An asterisk (*) indicates that the password server is the domain controller. winbind separator = + This specifies the separator that winbind will place between the domain and the username. winbind uid = 10000-20000 This specifies what UNIX user IDs winbind should use. winbind gid = 10000-20000 This specifies what UNIX group IDs winbind should use. winbind enum users = yes This allows user enumeration, which is important for programs such as finger, which need access to the full user list. winbind enum groups = yes This is the same as winbind enum users, except for groups. template shell = /bin/bash This specifies what shell Windows users will get when they telnet to a Samba box that is running winbind. If you haven't created a NETLOGON share, you should. This allows Windows 9x users to access your Samba server. (See Table C.) Table C [NETLOGON] path = /usr/local/samba/netlogon You'll need to create this directory manually. It's used by Windows 9x machines to connect to Samba. read only = yes After creating the smb.conf file or modifying the one you're using, you need to join your Samba server to an existing Windows domain. This sidebar shows the line that accomplishes this. In my example, I'm adding my Linux Samba server to a Windows 2000 domain named slowe with a domain controller named scott-2ks; you should make the appropriate changes to these names for your system. Once you type this line, you'll be prompted for the administrator password for the Windows 2000 domain. If you type the correct password and everything is properly set up, you'll get a response indicating that the addition to the domain was successful. Once that's complete, it's time to test your handiwork and start winbind. To do so, type /usr/local/samba/sbin/winbindd at the command line. To test whether winbind is working properly, you can try to get a list of users from the Windows domain. To do this, type /usr/local/samba/bin/wbinfo -u at the command line. When I typed this, I got the following results, which show that winbind is working as anticipated: SLOWE+Administrator SLOWE+Guest SLOWE+IUSR_SCOTT-2KS SLOWE+IWAM_SCOTT-2KS SLOWE+krbtgt SLOWE+NetShowServices SLOWE+root SLOWE+slowe SLOWE+TsInternetUser SLOWE+tuser SLOWE+windowsuser Notice that the plus sign (+) appears between the domain and username, as specified in the smb.conf file. For winbind to run properly when Samba is also running, Samba must be started first. So you'll now kill the winbind process. First, you need to discover the PID of winbind with the following command: ps -ef | grep winbind In my case, this command returns 1108, so I can kill that process with this command: kill -9 1108 Now, restart Samba with the following two commands: /usr/local/samba/sbin/smbd -D /usr/local/samba/sbn/nmbd -D Finally, start winbind with this command: /usr/local/samba/sbin/winbindd At this point, you have a winbind system that can talk to the Windows 2000 domain controller and get user information and more. But it's not fully integrated into the operating system yet; that is, you can't connect to a Samba share and use a Windows login. Make them play well together To set up the integration, you need to modify some of the system startup files. Make sure that you back these up before modifying them. An emergency boot disk might be a good idea as well. Keep in mind that my test installation is on a Red Hat 7.1 system. Your system may differ slightly, and you should make the appropriate modifications. First, I changed the /etc/pam.d/ samba file so that it had the contents shown below. (I added only the two lines that call pam_winbind.so-the first and third lines; the other two lines were already there.) auth required /lib/security/pam_winbind.so auth required /lib/security/pam_pwdb.so nullok shadow account required /lib/security/pam_winbind.so account required /lib/security/pam_pwdb.so Next, modify the /etc/nsswitch.conf file. For this modification, find the uncommented lines that start with passwd, shadow, and group, and add winbind as the second option on the list, right after files. For example: passwd: files winbind nisplus shadow: files winbind nisplus group: files winbind nisplus Now, modify the contents of the /etc/pam.d/login file and add the three lines that are highlighted in this sidebar. Now, restart xinetd, like this: /etc/init.d/xinetd restart What have you accomplished? A lot, actually. If you have telnet enabled on your Red Hat server, you can now log in to a shell account using nothing more than a Windows user account from your domain with the format DOMAIN+username (for example, slowe+administrator, to log in as the domain administrator on my system). Testing a share Let's test a share in Samba to see if we can connect to it using an account in the Windows domain that doesn't exist in the UNIX user database. For testing purposes, I've created a user named windowsuser in my domain, which is named slowe. I'm assuming that this is a new Samba installation and that no users have been created in the smbpasswd file yet. If this is an existing installation and you already have users created, you may need to do some cleanup work to remove the Windows-only users from your smbpasswd file before you have a true central point of administration. First, we need to create a share. We'll share out the Samba directory in a read-only state for this example. We'll add the following lines to the smb.conf file: [SAMBA] path = /usr/local/samba read only = no We'll wait a minute or so to let Samba refresh its configuration before we try to connect to it. Then, we'll connect to \\server\samba from the Windows machine using domain/username, where domain is your actual domain name and username is your actual username; type the password. If all goes well, we should get the contents of the Samba directory in a window. Moving back to the command line on the Samba server, we can type /usr/local/samba/bin/smbstatus to find out who is connected to the Samba machine. As you can see from this output from my system, I am indeed logged in to the Samba server as a Windows domain user. Nuts and bolts What is happening behind the scenes? When you connect to the Samba server using a Windows domain account, the UNIX system needs to have some way of mapping files back to a user ID and group ID. When we set up the initial smb.conf file in the /usr/local/samba/lib directory, we specified winbind uid and winbind gid parameters of 10000-20000 for this purpose. Upon a successful connection, the next available UID and GID are assigned to the incoming Windows user, and these results are stored in a small database located in /usr/local/samba/ var. Now, when you create files on the UNIX system while logged in as a Windows user, that user will have domain+username ownership. For example, I created a small temporary file called Testing in /usr/local/samba via a Windows share and while logged in as slowe/windowsuser. When I do an ls -al, the line for that file reads this way. To see the UID and GID, I issue ls -ln and get these results. The two IDs match what we put in the smb.conf file earlier. Summary While these steps are fairly complicated and involve modifying a number of system files, the end result is a Linux Samba installation that is tightly integrated into your Windows domain. With the installation presented above, any PAM-enabled applications on your Linux system can use the Windows user database for authentication. ----- Original Message ----- From: "Richard Jenniss" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, December 03, 2002 3:07 PM Subject: Re: (clug-talk) A Real World Windows/Linux Integration Issue > Have you added the users to your smbpasswd file? > > smbpasswd -a username > should do this. > > Anyone know how to get Linux to work with a domain, so you do not have to add users, on every host? > > On Tue, 03 Dec 2002 22:05:13 -0700 > Johnny Stork <[EMAIL PROTECTED]> wrote: > > > Ok all you Linux gurus, lets see how well we can get through a real world, and typical example of a Windows Network Administrator who just plugged in a Linux/Samba box to play PDC and Print server, and now needs to see how well the "community" can help stop his 500 users from ganging up on him cause they cant print. (This is all fictitous but this example is surely a very, very typical one) > > > > For now Samba/PDC is RH 8, clients are Windows 2000 > > > > 1: Previously had the Samba working fine as PDC with some login scripts and home share mounts. > > > > 2: Previously had an old HP Deskjet hooked up and shared out from samba and using cups. Was working/printing fine from Linux and Windows clients. > > > > > > Just installed a nice new Samsung ML-1450 Laser. Removed the Deskjet from the Samba server, installed new Samsung. Printing from Linux clients through remote cups works fine. Cant get 1200dpi yet, but I can wait. > > > > I can install the samsung under Windows clients, and using newest local drivers from Samsung. Hovering over printer icon gives "Access denied, unable to connect" but through the nights fiddling, at one time I did get a "ready" but trying to print and nothing happened. > > > > Been checking out FAQs, samba lists and help sites for 2 hours and have tried a variety of suggestions and nothing works. > > > > So for now, here is my current smb.conf > > > > > > # Global parameters > > [global] > > workgroup = ACADEMIC > > netbios name = PENGUIN > > encrypt passwords = Yes > > passwd program = /usr/bin/passwd %u > > passwd chat = local master = yes > > unix password sync = Yes > > time server = Yes > > socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192 > > printcap name = cups > > domain admin group = @adm > > logon script = logon.cmd > > logon path = \\%L\%u\Profile > > logon drive = Z: > > logon home = \\%L\%u > > domain logons = Yes > > os level = 65 > > domain master = True > > printing = cups > > > > [Netlogon] > > comment = Network Logon Services > > path = /home/netlogon > > guest ok = Yes > > locking = No > > > > [homes] > > comment = Home Directories > > path = /home/%U > > valid users = %U Administrator > > force user = %U > > read only = No > > create mask = 0600 > > directory mask = 0700 > > > > [Printers] > > comment = All Printers > > path = /var/spool/samba > > guest ok = Yes > > printable = Yes > > browseable = No > > writeable = yes > > public = yes > > use client driver = yes > > > > [Data] > > comment = Data > > path = /mnt/Data > > > > [Samsung] > > comment = Samsung ML-1450 > > path = /var/spool/samba > > read only = No > > guest ok = Yes > > printable = Yes > > writeable = yes > > public = yes > > printer name = Samsung > > oplocks = No > > > > > > ________________________________ > > Open Enterprise Solutions > > Open Solutions for an Open World > > > > Johnny Stork, BA > > Calgary, AB > > Canada > > > > http://www.openenterprise.ca > > http://www.open-solutions.ca > > > > > > > > > >
