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 >> > >> > >> > >> >
