Winbind lets Samba create Unix user IDs on the fly for users, and generally allows NT and Linux authentication be mixed. Maybe it's overkill, especially if there are only a few users, or if the users only use the Linux box for Samba. If, on the other hand, users want full access to the Linux box then I'd use Winbind.
I've actually never had a mixed network where we used a legacy server as the PDC. I do have a legacy server connected into the network I'm on now, but I hope to be rid of it within a week or two. Kev. ----- Original Message ----- From: "Trevor Lauder" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, December 04, 2002 11:24 AM Subject: Re: (clug-talk) A Real World Windows/Linux Integration Issue > If all you want to do is add a Samba server to a Windows NT or Windows > 2000 domain that already has a PDC then using winbind is a little over > kill. winbind is mainly usefull when the Samba server is the PDC. If > it's not then using the options: > > password server = <Domain Controller> > > and either > > security = user or security = domain > > would accomplish the same effect with much less work. > > -- > Trevor Lauder > Web: http://www.thelauders.net > E-Mail: [EMAIL PROTECTED] > > > 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 > >> > > >> > > >> > > >> > > > > > >
