Re: Re: (clug-talk) A Real World Windows/Linux Integration Issue

[Johnny Stork]

Yeah thats how I currently have it setup. > > > -----Original message----- > From: "Trevor Lauder" <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Date: 12/04/2002(Wed) 11:24am > 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 = > > 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" > > To: > > 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 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 > >> > > >> > > >> > > >> > > > > > > ________________________________ Open Enterprise Solutions Open Solutions for an Open World Johnny Stork, BA Calgary, AB Canada http://www.openenterprise.ca http://www.open-solutions.ca