## Samba and the FreeBSD Administrator ## Lanny Baron In this article on Samba, it is my intent to point out what I feel is a benefit to business users, the FreeBSD community and the potential of a FreeBSD System Administrator. Having read previous articles on the Samba suite, I feel that the following, What Samba Does, might well be worth your reading. The source is from the Samba site. What Samba Does Samba consists of two key programs, plus a bunch of other stuff that we'll get to later. The two key programs are smbd and nmbd. Their job is to implement the four basic modern-day CIFS services, which are: o File & print services o Authentication and Authorization o Name resolution o Service announcement (browsing) File and print services are, of course, the cornerstone of the CIFS suite. These are provided by smbd, the SMB Daemon. Smbd also handles "share mode" and "user mode" authentication and authorization. That is, you can protect shared file and print services by requiring passwords. In share mode, the simplest and least recommended scheme, a password can be assigned to a shared directory or printer (simply called a "share"). This single password is then given to everyone who is allowed to use the share. With user mode authentication, each user has their own username and password and the System Administrator can grant or deny access on an individual basis. The Windows NT Domain system provides a further level of authentication refinement for CIFS. The basic idea is that a user should only have to log in once to have access to all of the authorized services on the network. The NT Domain system handles this with an authentication server, called a Domain Controller. An NT Domain (which should not be confused with a Domain Name System (DNS) Domain) is basically a group of machines which share the same Domain Controller. The NT Domain system deserves special mention because, until the release of Samba version 2, only Microsoft owned code to implement the NT Domain authentication protocols. With version 2, Samba introduced the first non-Microsoft-derived NT Domain authentication code. The eventual goal, of course, it to completely mimic a Windows NT Domain Controller. The other two CIFS pieces, name resolution and browsing, are handled by nmbd. These two services basically involve the management and distribution of lists of NetBIOS names. Name resolution takes two forms; broadcast and point-to-point. A machine may use either or both of these methods, depending upon its configuration. Broadcast resolution is the closest to the original NetBIOS mechanism. Basically, a client looking for a service named Trillian will call out "Yo! Trillian! Where are you?", and wait for the machine with that name to answer with an IP address. This can generate a bit of broadcast traffic (a lot of shouting in the streets), but it is restricted to the local LAN so it doesn't cause too much trouble. The other type of name resolution involves the use of an NBNS (NetBIOS Name Service) server. (Microsoft called their NBNS implementation WINS, for Windows Internet Name Service, and that acronym is more commonly used today.) The NBNS works something like the wall of an old fashioned telephone booth (remember those?). Machines can leave their name and number (IP address) for others to see. Hi, I'm node Voomba. Call me for a good time! 192.168.100.101 It works like this; the clients send their NetBIOS names & IP addresses to the NBNS server, which keeps the information in a simple database. When a client wants to talk to another client, it sends the other client's name to the NBNS server. If the name is on the list, the NBNS hands back an IP address. You've got the name, look up the number. Clients on different subnets can all share the same NBNS server so, unlike broadcast, the point-to-point mechanism is not limited to the local LAN. In many ways the NBNS is similar to the DNS, but the NBNS name list is almost completely dynamic and there are few controls to ensure that only authorized clients can register names. Conflicts can, and do, occur fairly easily. Finally, there's browsing. This is a whole 'nother kettle of worms, but Samba's nmbd handles it anyway. This is not the web browsing we know and love, but a browseable list of services (file and print shares) offered by the computers on a network. On a LAN, the participating computers hold an election to decide which of them will become the Local Master Browser (LMB). The "winner" then identifies itself by claiming a special NetBIOS name (in addition to any other names it may have). The LMBs job is to keep a list of available services, and it is this list that appears when you click on the Windows "Network Neighborhood" icon. In addition to LMBs, there are Domain Master Browsers (DMBs). DMBs coordinate browse lists across NT Domains, even on routed networks. Using the NBNS, an LMB will locate its DMB to exchange and combine browse lists. Thus, the browse list is propagated to all hosts in the NT Domain. Unfortunately, the synchronization times are spread apart a bit. It can take more than an hour for a change on a remote subnet to appear in the Network Neighborhood. Samba and the FreeBSD Admin in a business environment. Whether you are a person like myself, who loves FreeBSD or not, Windows is here to stay. Period. In addition, Windows has its place in the business world. A big place. Then again, most large corporations use a flavor of Unix as the "backbone" of their systems. So where does FreeBSD come into play in all this? The following will demonstrate the combination of FreeBSD with Samba. Let's start from scratch. A small company or firm wishes to get on the "net" and wants to have what is known as an Intranet (according to Greg Lehey, an Intranet is an MS term.. I won't argue with a man I love dearly). Well there are several solutions. One is to get the latest and greatest by Microsoft. In addition one may venture out and buy the Novell solution. Either is do-able. But rather expensive. There is yet another solution. The GREAT solution. The FreeBSD/Samba solution, which happens to be the least costly of all. Ok, How do I, the business person choose? Assume for a moment that you, the happy-go-lucky FreeBSD knowledgeable person gets a "shot" at the job. Since you are like me, and you have your trusty FreeBSD box with a Intel Pentium II 266 machine handy, you suggest to the business owner that a demonstration could quickly be arranged. Unfortunately the firm is not yet connected to the Internet. Although the owner has a modem, speed on installation of various large windows based programs is going to play a factor. So we won't dial in to our FreeBSD/Samba server just yet. Let's install MS Office 2000 for him/her. Make a directory that is writable by the group you put him in. On his Windows 9.x box make sure you have double-clicked on 'Client for Microsoft Networks' in Control Panel. Put in a name where it says logon to NT DOMAIN. Check logon and restore network connections. Click OK. Click on the Identification tab. Enter the same name you used in the logon to NT DOMAIN in the WORKGROUP box. Click ok. The windows 9x box will then want to reboot. When it comes back up, put in a username and password for the person in the win 9x box. In your smb.conf on your FreeBSD/Samba server, make sure that you have put the same name for workgroup = if not, none of this will work. Further down you will see what the setup of smb.conf will look like. Let us assume for a minute that our future "boss" is interested and does not have an NT or Novell network. The reason I say that is due to the fact that it will take me hours more to explain NT-DOM, or how to configure Samba to run with a PDC controlled by NT. That will be for another article. For those that don't know what a PDC is, it stands for Primary Domain Controller. It is the SAM database ...Security Administration Manager. Sort of like /etc/passwd. But different. We need to have domain logons available. That means that the Windows 9x boxes will logon to the FreeBSD/Samba server. This will give the user his home directory, which is /home/username, amongst other things. The owner must put in a username and password on his win9x box. Of course you will have to add the person to the FreeBSD/Samba server. I use the adduser program. After rebooting, and if on a LAN, the person will get a box saying "Windows NT login" which lasts for about 1/8 a minute. The user of the windows 9.x will now be part of our Samba run domain. Do not confuse the domain with what the Internet calls a domain. The meanings are quite different. The following will show you a plain smb.conf file of which we will make the changes to reflect the way we want it to run for our demonstration. We will add the share for the MS Office installation. # Any line which starts with a ; (semi-colon) or a # (hash) # is a comment and is ignored. In this example we will use a # # for commentary and a ; for parts of the config file that you # may wish to enable # # NOTE: Whenever you modify this file you should run the command "testparm" # to check that you have not many any basic syntactic errors. # #======================= Global Settings ======================= [global] # workgroup = NT-Domain-Name or Workgroup-Name, eg: REDHAT4 workgroup = BLAH # server string is the equivalent of the NT Description field server string = FreeBSD/Samba Server 1 # This option is important for security. It allows you to restrict # connections to machines which are on your local network. The # following example restricts access to two C class networks and # the "loopback" interface. For more examples of the syntax see # the smb.conf man page ; hosts allow = 192.168.1. 192.168.2. 127. # If you want to automatically load your printer list rather # than setting them up individually then you'll need this load printers = yes # you may wish to override the location of the printcap file printcap name = /etc/printcap # on SystemV system setting printcap name to lpstat should allow # you to automatically obtain a printer list from the SystemV spool # system ; printcap name = lpstat # It should not be necessary to specify the print system type unless # it is non-standard. Currently supported print systems include: # bsd, sysv, plp, lprng, aix, hpux, qnx printing = bsd # Uncomment this if you want a guest account, you must add this to # /etc/passwd otherwise the user "nobody" is used guest # account = ftp. i use the ftp permissions, you can use # something else like pcguest. # this tells Samba to use a separate log file for each machine # that connects log file = /usr/local/samba/var/log.%m # Put a capping on the size of the log files (in Kb). max log size = 50 # Security mode. Most people will want user level security. See # security_level.txt for details. security = user # Use password server option only with security = server ; password server = # You may wish to use password encryption. Please read # ENCRYPTION.txt, Win95.txt and WinNT.txt in the Samba documentation. # Do not enable this option unless you have read those documents encrypt passwords = yes #since my win98 box uses encrypted passwords i have uncommented the line. # Using the following line enables you to customize your configuration # on a per machine basis. The %m gets replaced with the netbios name # of the machine that is connecting ; include = /usr/local/samba/lib/smb.conf.%m # Most people will find that this option gives better performance. # See speed.txt and the manual pages for details socket options = TCP_NODELAY # Configure Samba to use multiple interfaces # If you have multiple network interfaces then you must list them # here. See the man page for details. ; interfaces = 192.168.12.2/24 192.168.13.2/24 # Browser Control Options: # set local master to no if you don't want Samba to become a master # browser on your network. Otherwise the normal election rules apply # local master = Yes # we want our FreeBSD/Samba server to be # the domain controller for our non-NT domain # OS Level determines the precedence of this server in master browser # elections. The default value should be reasonable os level = 33 # Domain Master specifies Samba to be the Domain Master Browser. This # allows Samba to collate browse lists between subnets. Don't use this # if you already have a Windows NT domain controller doing this job domain master = yes # Preferred Master causes Samba to force a local browser election on # startup and gives it a slightly higher chance of winning the # election preferred master = yes # Use only if you have an NT server on your network that has been # configured at install time to be a primary domain controller. ; domain controller = # Enable this if you want Samba to be a domain logon server for # Windows95 workstations. domain logons = yes # if you enable domain logons then you may want a per-machine or # per user logon script # run a specific logon batch file per workstation (machine) ; logon script = %m.bat # run a specific logon batch file per username logon script = %U.pds # i use a file called netlogin.pds. You can use a .bat file. # Where to store roving profiles (only for Win95 and WinNT) # %L substitutes for this servers netbios name, %U is username # You must uncomment the [Profiles] share below logon path = \\%L\Profiles\%U # i have used \\%N\%U\Profiles which corresponds to # /home/user/Profiles since I allow each each computer to use # their own desktop settings. In the example shown, everyone # gets the same desktop. # Windows Internet Name Serving Support Section: # WINS Support - Tells the NMBD component of Samba to enable it's WINS # Server wins support = yes # WINS Server - Tells the NMBD components of Samba to be a WINS Client # Note: Samba can be either a WINS Server, or a WINS Client, but # NOT both ; wins server = w.x.y.z # WINS Proxy - Tells Samba to answer name resolution queries on # behalf of a non WINS capable client, for this to work there must be # at least one WINS Server on the network. The default is NO. wins proxy = yes # DNS Proxy - tells Samba whether or not to try to resolve NetBIOS # names via DNS nslookups. The built-in default for versions # 1.9.17 is yes, this has been changed in version 1.9.18 to no. dns proxy = no username map = /usr/local/samba/lib/username.map # to map dos names to valid unix names i.e. root = Administrator #======================= Share Definitions ======================= [homes] comment = Home Directories browseable = no writable = yes # Un-comment the following and create the netlogon directory for # Domain Logons [netlogon] comment = Network Logon Service path = /usr/local/samba/lib/netlogon guest ok = yes writable = no share modes = no # Un-comment the following to provide a specific roving profile share # the default is to use the user's home directory ;[Profiles] ; path = /usr/local/samba/profiles ; browseable = no; guest ok = yes # NOTE: If you have a BSD-style print system there is no need to # specifically define each individual printer [printers] comment = All Printers path = /usr/spool/samba browseable = no # Set public = yes to allow user 'guest account' to print guest ok = no writable = no printable = yes # This one is useful for people to share files [tmp] comment = Temporary file space path = /tmp read only = no public = yes # If the above was done right. The owner can now click on the # share which will be in the Network Neighborhood icon, in the # PC that is named BLAH [MSOfinst] comment = MS-Ofice 2000 Install directory path = /home/office2000inst read list = @user, @staff, lnb, Administrator write list = @user, @staff, lnb, Administrator read only = No [office] comment = MsOffice working Directory path = /home/msoffice valid users = @staff, @www mrsmith joey write list = @staff, @www joey mrsmith read only = No ## end of smb.conf file In the above you see the "@" signs. They are saying "anyone who is in the groups user and staff in /etc/group. It's a lot easier to do it this way if you have quite a few users in an office or business. The owner can now click on Network Neighborhood and then the computer you have named that contains the share MSOfinst. If you have installed MSOffice correctly from an administrative point of view, it can now be installed on each workstation yet be run from the FreeBSD/Samba server. Without going into the gory details of explaining how to set up MS Office 2000 on the FreeBSD/Samba server, it will be assumed for this article that you have made the Administrative setup for MS Office on the FreeBSD/Samba server. One second, I am told Windows NT will do the same thing. Yes it will. Two things pop up in my humble mind though. One is that it will be a LOT slower on the NT box, and 2nd, it will cost a lot more. There is no charge to access your FreeBSD/Samba server, while it costs about $70.00 per license or seat to access your NT box. Ok, what else can the FreeBSD/Samba Server do? Well sir, we have not talked about your workstations. You have how many? I have 30. Ok sir, no problem the FreeBSD/Samba server will handle all that plus, do your web serving for your company web site, allow your chosen employee's to dial-in to do work from home (yes kill those poor guys and gals), run all your mail for both in the office (intranet) and to the world (Internet?), run your SQL server needs... shall I go on and on? By now, your demo should be done and the person may just hire you on. He/she will be very impressed. You have now become the system admin for a FreeBSD/Samba Server. Go and setup mail services and httpd services amongst others. We have now beaten (for a lack of a better word) MS at their own game. - Lanny $Id: samba.txt,v 1.1 2000/02/16 08:07:53 jim Exp $