Yeah, being able to SSH in as a domain user without having a local linux account is handy. Or you could also use Linux workstations that use the same authentication as the windows clients.
-- Trevor Lauder Web: http://www.thelauders.net E-Mail: [EMAIL PROTECTED] > 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 >> >> > >> >> > >> >> > >> >> >
