From 58b37572718ed65d1b143f44de16aa5efb512f11 Mon Sep 17 00:00:00 2001 From: vorlon Date: Wed, 21 Nov 2007 17:29:21 +0000 Subject: Load samba-3.0.27a into branches/upstream. git-svn-id: svn://svn.debian.org/svn/pkg-samba/branches/upstream@1583 fc4039ab-9d04-0410-8cac-899223bdd6b0 --- docs/htmldocs/Samba3-ByExample/Big500users.html | 1164 +++++++++++++++++++++++ 1 file changed, 1164 insertions(+) create mode 100644 docs/htmldocs/Samba3-ByExample/Big500users.html (limited to 'docs/htmldocs/Samba3-ByExample/Big500users.html') diff --git a/docs/htmldocs/Samba3-ByExample/Big500users.html b/docs/htmldocs/Samba3-ByExample/Big500users.html new file mode 100644 index 0000000000..284129f125 --- /dev/null +++ b/docs/htmldocs/Samba3-ByExample/Big500users.html @@ -0,0 +1,1164 @@ +Chapter 4. The 500-User Office
Chapter 4. The 500-User Office
Prev Part I. Example Network Configurations Next

Chapter 4. The 500-User Office

Table of Contents

Introduction
Assignment Tasks
Dissection and Discussion
Technical Issues
Political Issues
Implementation
Installation of DHCP, DNS, and Samba Control Files
Server Preparation: All Servers
Server-Specific Preparation
Process Startup Configuration
Windows Client Configuration
Key Points Learned
Questions and Answers

+ The Samba-3 networking you explored in ??? covers the finer points of + configuration of peripheral services such as DHCP and DNS, and WINS. You experienced + implementation of a simple configuration of the services that are important adjuncts + to successful deployment of Samba. +

+ An analysis of the history of postings to the Samba mailing list easily demonstrates + that the two most prevalent Samba problem areas are +

  • + Defective resolution of a NetBIOS name to its IP address +

  • + Printing problems +

+ The exercises + so far in this book have focused on implementation of the simplest printing processes + involving no print job processing intelligence. In this chapter, you maintain + that same approach to printing, but ??? presents an opportunity + to make printing more complex for the administrator while making it easier for the user. +

+ + + + ??? demonstrates operation of a DHCP server and a DNS server + as well as a central WINS server. You validated the operation of these services and + saw an effective implementation of a Samba domain controller using the + tdbsam passdb backend. +

+ The objective of this chapter is to introduce more complex techniques that can be used to + improve manageability of Samba as networking needs grow. In this chapter, you implement + a distributed DHCP server environment, a distributed DNS server arrangement, a centralized + WINS server, and a centralized Samba domain controller. +

+ A note of caution is important regarding the Samba configuration that is used in this + chapter. The use of a single domain controller on a routed, multisegment network is + a poor design choice that leads to potential network user complaints. + This chapter demonstrates some successful + techniques in deployment and configuration management. This should be viewed as a + foundation chapter for complex Samba deployments. +

+ As you master the techniques presented here, you may find much better methods to + improve network management and control while reducing human resource overheads. + You should take the opportunity to innovate and expand on the methods presented + here and explore them to the fullest. +

Introduction

+ Business continues to go well for Abmas. Mr. Meany is driving your success and the + network continues to grow thanks to the hard work Christine has done. You recently + hired Stanley Soroka as manager of information systems. Christine recommended Stan + to the role. She told you Stan is so good at handling Samba that he can make a cast + iron rocking horse that is embedded in concrete kick like a horse at a rodeo. You + need skills like his. Christine and Stan get along just fine. Let's see what + you can get out of this pair as they plot the next-generation networks. +

+ Ten months ago Abmas closed an acquisition of a property insurance business. The + founder lost interest in the business and decided to sell it to Mr. Meany. Because + they were former university classmates, the purchase was concluded with mutual assent. + The acquired business is located at the other end of town in much larger facilities. + The old Abmas building has become too small. Located on the same campus as the newly + acquired business are two empty buildings that are ideal to provide Abmas with + opportunity for growth. +

+ Abmas has now completed the purchase of the two empty buildings, and you are + to install a new network and relocate staff in nicely furnished new facilities. + The new network is to be used to fully integrate company operations. You have + decided to locate the new network operations control center in the larger building + in which the insurance group is located to take advantage of an ideal floor space + and to allow Stan and Christine to fully stage the new network and test it before + it is rolled out. Your strategy is to complete the new network so that it + is ready for operation when the old office moves into the new premises. +

Assignment Tasks

+ The acquired business had 280 network users. The old Abmas building housed + 220 network users in unbelievably cramped conditions. The network that + initially served 130 users now handles 220 users quite well. +

+ The two businesses will be fully merged to create a single campus company. + The Property Insurance Group (PIG) houses 300 employees, the new Accounting + Services Group (ASG) will be in a small building (BLDG1) that houses 50 + employees, and the Financial Services Group (FSG) will be housed in a large + building that has capacity for growth (BLDG2). Building 2 houses 150 network + users. +

+ You have decided to connect the building using fiber optic links between new + routers. As a backup, the buildings are interconnected using line-of-sight + high-speed infrared facilities. The infrared connection provides a + secondary route to be used during periods of high demand for network + bandwidth. +

+ The Internet gateway is upgraded to 15 Mb/sec service. Your ISP + provides on your premises a fully managed Cisco PIX firewall. You no longer need + to worry about firewall facilities on your network. +

+ Stanley and Christine have purchased new server hardware. Christine wants to + roll out a network that has whistles and bells. Stan wants to start off with + a simple to manage, not-too-complex network. He believes that network + users need to be gradually introduced to new features and capabilities and not + rushed into an environment that may cause disorientation and loss of productivity. +

+ Your intrepid network team has decided to implement a network configuration + that closely mirrors the successful system you installed in the old Abmas building. + The new network infrastructure is owned by Abmas, but all desktop systems + are being procured through a new out-source services and leasing company. Under + the terms of a deal with Mr. M. Proper (CEO), DirectPointe, Inc., provides + all desktop systems and includes full level-one help desk support for + a flat per-machine monthly fee. The deal allows you to add workstations on demand. + This frees Stan and Christine to deal with deeper issues as they emerge and + permits Stan to work on creating new future value-added services. +

+ DirectPointe Inc. receives from you a new standard desktop configuration + every four months. They automatically roll that out to each desktop system. + You must keep DirectPointe informed of all changes. +

+ The new network has a single Samba Primary Domain Controller (PDC) located in the + Network Operation Center (NOC). Buildings 1 and 2 each have a local server + for local application servicing. It is a domain member. The new system + uses the tdbsam passdb backend. +

+ Printing is based on raw pass-through facilities just as it has been used so far. + All printer drivers are installed on the desktop and notebook computers. +

Dissection and Discussion

+ + The example you are building in this chapter is of a network design that works, but this + does not make it a design that is recommended. As a general rule, there should be at least + one Backup Domain Controller (BDC) per 150 Windows network clients. The principle behind + this recommendation is that correct operation of MS Windows clients requires rapid + network response to all SMB/CIFS requests. The same rule says that if there are more than + 50 clients per domain controller, they are too busy to service requests. Let's put such + rules aside and recognize that network load affects the integrity of domain controller + responsiveness. This network will have 500 clients serviced by one central domain + controller. This is not a good omen for user satisfaction. You, of course, address this + very soon (see ???). +

Technical Issues

+ Stan has talked you into a horrible compromise, but it is addressed. Just make + certain that the performance of this network is well validated before going live. +

+ Design decisions made in this design include the following: +

  • + + + + A single PDC is being implemented. This limitation is based on the choice not to + use LDAP. Many network administrators fear using LDAP because of the perceived + complexity of implementation and management of an LDAP-based backend for all user + identity management as well as to store network access credentials. +

  • + + + Because of the refusal to use an LDAP (ldapsam) passdb backend at this time, the + only choice that makes sense with 500 users is to use the tdbsam passwd backend. + This type of backend is not receptive to replication to BDCs. If the tdbsam + passdb.tdb file is replicated to BDCs using + rsync, there are two potential problems: (1) data that is in + memory but not yet written to disk will not be replicated, and (2) domain member + machines periodically change the secret machine password. When this happens, there + is no mechanism to return the changed password to the PDC. +

  • + All domain user, group, and machine accounts are managed on the PDC. This makes + for a simple mode of operation but has to be balanced with network performance and + integrity of operations considerations. +

  • + + A single central WINS server is being used. The PDC is also the WINS server. + Any attempt to operate a routed network without a WINS server while using NetBIOS + over TCP/IP protocols does not work unless on each client the name resolution + entries for the PDC are added to the LMHOSTS. This file is + normally located on the Windows XP Professional client in the + C:\WINDOWS\SYSTEM32\ETC\DRIVERS directory. +

  • + At this time the Samba WINS database cannot be replicated. That is + why a single WINS server is being implemented. This should work without a problem. +

  • + + BDCs make use of winbindd to provide + access to domain security credentials for file system access and object storage. +

  • + + + Configuration of Windows XP Professional clients is achieved using DHCP. Each + subnet has its own DHCP server. Backup DHCP serving is provided by one + alternate DHCP server. This necessitates enabling of the DHCP Relay agent on + all routers. The DHCP Relay agent must be programmed to pass DHCP Requests from the + network directed at the backup DHCP server. +

  • + All network users are granted the ability to print to any printer that is + network-attached. All printers are available from each server. Print jobs that + are spooled to a printer that is not on the local network segment are automatically + routed to the print spooler that is in control of that printer. The specific details + of how this might be done are demonstrated for one example only. +

  • + The network address and subnetmask chosen provide 1022 usable IP addresses in + each subnet. If in the future more addresses are required, it would make sense + to add further subnets rather than change addressing. +

Political Issues

+ This case gets close to the real world. You and I know the right way to implement + domain control. Politically, we have to navigate a minefield. In this case, the need is to + get the PDC rolled out in compliance with expectations and also to be ready to save the day + by having the real solution ready before it is needed. That real solution is presented in + ???. +

Implementation

+ The following configuration process begins following installation of Red Hat Fedora Core2 on the + three servers shown in the network topology diagram in ???. You have + selected hardware that is appropriate to the task. +

Figure 4.1. Network Topology 500 User Network Using tdbsam passdb backend.

Network Topology 500 User Network Using tdbsam passdb backend.

Installation of DHCP, DNS, and Samba Control Files

+ Carefully install the configuration files into the correct locations as shown in + ???. You should validate that the full file path is + correct as shown. +

+ The abbreviation shown in this table as {VLN} refers to + the directory location beginning with /var/lib/named. +

Table 4.1. Domain: MEGANET, File Locations for Servers

File InformationServer Name
SourceTarget LocationMASSIVEBLDG1BLDG2
???/etc/samba/smb.confYesNoNo
???/etc/samba/dc-common.confYesNoNo
???/etc/samba/common.confYesYesYes
???/etc/samba/smb.confNoYesNo
???/etc/samba/smb.confNoNoYes
???/etc/samba/dommem.confNoYesYes
???/etc/dhcpd.confYesNoNo
???/etc/dhcpd.confNoYesNo
???/etc/dhcpd.confNoNoYes
???/etc/named.conf (part A)YesNoNo
???/etc/named.conf (part B)YesNoNo
???/etc/named.conf (part C)YesNoNo
???{VLN}/master/abmas.biz.hostsYesNoNo
???{VLN}/master/abmas.us.hostsYesNoNo
???/etc/named.conf (part A)NoYesYes
???/etc/named.conf (part B)NoYesYes
???{VLN}/localhost.zoneYesYesYes
???{VLN}/127.0.0.zoneYesYesYes
???{VLN}/root.hintYesYesYes

Server Preparation: All Servers

+ The following steps apply to all servers. Follow each step carefully. +

Procedure 4.1. Server Preparation Steps

  1. + Using the UNIX/Linux system tools, set the name of the server as shown in the network + topology diagram in ???. For SUSE Linux products, the tool + that permits this is called yast2; for Red Hat Linux products, + you can use the netcfg tool. + Verify that your hostname is correctly set by running: +

    +root#  uname -n
+

    + An alternate method to verify the hostname is: +

    +root#  hostname -f
+

    +

  2. + + + Edit your /etc/hosts file to include the primary names and addresses + of all network interfaces that are on the host server. This is necessary so that during + startup the system is able to resolve all its own names to the IP address prior to + startup of the DNS server. You should check the startup order of your system. If the + CUPS print server is started before the DNS server (named), you + should also include an entry for the printers in the /etc/hosts file. +

  3. + + All DNS name resolution should be handled locally. To ensure that the server is configured + correctly to handle this, edit /etc/resolv.conf so it has the following + content: +

    +search abmas.us abmas.biz
+nameserver 127.0.0.1
+

    + This instructs the name resolver function (when configured correctly) to ask the DNS server + that is running locally to resolve names to addresses. +

  4. + + + Add the root user to the password backend: +

    +root#  smbpasswd -a root
+New SMB password: XXXXXXXX
+Retype new SMB password: XXXXXXXX
+root# 
+

    + The root account is the UNIX equivalent of the Windows domain administrator. + This account is essential in the regular maintenance of your Samba server. It must never be + deleted. If for any reason the account is deleted, you may not be able to recreate this account + without considerable trouble. +

  5. + + + Create the username map file to permit the root account to be called + Administrator from the Windows network environment. To do this, create + the file /etc/samba/smbusers with the following contents: +

    +####
+# User mapping file
+####
+# File Format
+# -----------
+# Unix_ID = Windows_ID
+#
+# Examples:
+# root = Administrator
+# janes = "Jane Smith"
+# jimbo = Jim Bones
+#
+# Note: If the name contains a space it must be double quoted.
+#       In the example above the name 'jimbo' will be mapped to Windows
+#       user names 'Jim' and 'Bones' because the space was not quoted.
+#######################################################################
+root = Administrator
+####
+# End of File
+####
+

    +

  6. + Configure all network-attached printers to have a fixed IP address. +

  7. + Create an entry in the DNS database on the server MASSIVE + in both the forward lookup database for the zone abmas.biz.hosts + and in the reverse lookup database for the network segment that the printer is + located in. Example configuration files for similar zones were presented in ???, + ??? and ???. +

  8. + Follow the instructions in the printer manufacturer's manuals to permit printing + to port 9100. Use any other port the manufacturer specifies for direct mode, + raw printing. This allows the CUPS spooler to print using raw mode protocols. + + +

  9. + + Only on the server to which the printer is attached configure the CUPS Print + Queues as follows: +

    +root#  lpadmin -p printque -v socket://printer-name.abmas.biz:9100 -E
+

    + + This step creates the necessary print queue to use no assigned print filter. This + is ideal for raw printing, that is, printing without use of filters. + The name printque is the name you have assigned for + the particular printer. +

  10. + Print queues may not be enabled at creation. Make certain that the queues + you have just created are enabled by executing the following: +

    +root#  /usr/bin/enable printque
+

    +

  11. + Even though your print queue may be enabled, it is still possible that it + does not accept print jobs. A print queue services incoming printing + requests only when configured to do so. Ensure that your print queue is + set to accept incoming jobs by executing the following command: +

    +root#  /usr/bin/accept printque
+

    +

  12. + + + + This step, as well as the next one, may be omitted where CUPS version 1.1.18 + or later is in use. Although it does no harm to follow it anyway, and may + help to avoid time spent later trying to figure out why print jobs may be + disappearing without a trace. Look at these two steps as insurance + against lost time. Edit file /etc/cups/mime.convs to + uncomment the line: +

    +application/octet-stream     application/vnd.cups-raw      0     -
+

    +

  13. + + Edit the file /etc/cups/mime.types to uncomment the line: +

    +application/octet-stream
+

    +

  14. + Refer to the CUPS printing manual for instructions regarding how to configure + CUPS so that print queues that reside on CUPS servers on remote networks + route print jobs to the print server that owns that queue. The default setting + on your CUPS server may automatically discover remotely installed printers and + may permit this functionality without requiring specific configuration. +

  15. + As part of the roll-out program, you need to configure the application's + server shares. This can be done once on the central server and may then be + replicated using a tool such as rsync. Refer to the man + page for rsync for details regarding use. The notes in + ??? may help in your decisions to use an application + server facility. +

Note

+ Logon scripts that are run from a domain controller (PDC or BDC) are capable of using semi-intelligent + processes to automap Windows client drives to an application server that is nearest to the client. This + is considerably more difficult when a single PDC is used on a routed network. It can be done, but not + as elegantly as you see in the next chapter. +

Server-Specific Preparation

+ There are some steps that apply to particular server functionality only. Each step is critical + to correct server operation. The following step-by-step installation guidance will assist you + in working through the process of configuring the PDC and then both BDC's. +

Configuration for Server: MASSIVE

+ The steps presented here attempt to implement Samba installation in a generic manner. While + some steps are clearly specific to Linux, it should not be too difficult to apply them to + your platform of choice. +

Procedure 4.2. Primary Domain Controller Preparation

  1. + + + The host server acts as a router between the two internal network segments as well + as for all Internet access. This necessitates that IP forwarding be enabled. This can be + achieved by adding to the /etc/rc.d/boot.local an entry as follows: +

    +echo 1 > /proc/sys/net/ipv4/ip_forward
+

    + To ensure that your kernel is capable of IP forwarding during configuration, you may wish to execute + that command manually also. This setting permits the Linux system to act as a router. +

  2. + This server is dual hosted (i.e., has two network interfaces) one goes to the Internet + and the other to a local network that has a router that is the gateway to the remote networks. + You must therefore configure the server with route table entries so that it can find machines + on the remote networks. You can do this using the appropriate system tools for your Linux + server or using static entries that you place in one of the system startup files. It is best + to always use the tools that the operating system vendor provided. In the case of SUSE Linux, the + best tool to do this is YaST (refer to SUSE Administration Manual); in the case of Red Hat, + this is best done using the graphical system configuration tools (see the Red Hat documentation). + An example of how this may be done manually is as follows: +

    +root#  route add net 172.16.4.0 netmask 255.255.252.0 gw 172.16.0.128
+root#  route add net 172.16.8.0 netmask 255.255.252.0 gw 172.16.0.128
+

    + If you just execute these commands manually, the route table entries you have created are + not persistent across system reboots. You may add these commands directly to the local + startup files as follows: (SUSE) /etc/rc.d/boot.local, (Red Hat) + /etc/rc.d/init.d/rc.local. +

  3. + + The final step that must be completed is to edit the /etc/nsswitch.conf file. + This file controls the operation of the various resolver libraries that are part of the Linux + Glibc libraries. Edit this file so that it contains the following entries: +

    +hosts:      files dns wins
+

    +

  4. + + Create and map Windows domain groups to UNIX groups. A sample script is provided in + ???. Create a file containing this script. You called yours + /etc/samba/initGrps.sh. Set this file so it can be executed + and then execute the script. An example of the execution of this script as well as its + validation are shown in Section 4.3.2, Step 5. +

  5. + + + + For each user who needs to be given a Windows domain account, make an entry in the + /etc/passwd file as well as in the Samba password backend. + Use the system tool of your choice to create the UNIX system account, and use the Samba + smbpasswd to create a domain user account. +

    + + + + There are a number of tools for user management under UNIX, such as + useradd, adduser, as well as a plethora of custom + tools. With the tool of your choice, create a home directory for each user. +

  6. + Using the preferred tool for your UNIX system, add each user to the UNIX groups created + previously as necessary. File system access control is based on UNIX group membership. +

  7. + Create the directory mount point for the disk subsystem that is to be mounted to provide + data storage for company files, in this case, the mount point indicated in the smb.conf + file is /data. Format the file system as required and mount the formatted + file system partition using appropriate system tools. +

  8. + + Create the top-level file storage directories for data and applications as follows: +

    +root#  mkdir -p /data/{accounts,finsvcs,pidata}
+root#  mkdir -p /apps
+root#  chown -R root:root /data
+root#  chown -R root:root /apps
+root#  chown -R bjordan:accounts /data/accounts
+root#  chown -R bjordan:finsvcs /data/finsvcs
+root#  chown -R bjordan:finsvcs /data/pidata
+root#  chmod -R ug+rwxs,o-rwx /data
+root#  chmod -R ug+rwx,o+rx-w /apps
+

    + Each department is responsible for creating its own directory structure within the departmental + share. The directory root of the accounts share is /data/accounts. + The directory root of the finsvcs share is /data/finsvcs. + The /apps directory is the root of the apps share + that provides the application server infrastructure. +

  9. + The smb.conf file specifies an infrastructure to support roaming profiles and network + logon services. You can now create the file system infrastructure to provide the + locations on disk that these services require. Adequate planning is essential + because desktop profiles can grow to be quite large. For planning purposes, a minimum of + 200 MB of storage should be allowed per user for profile storage. The following + commands create the directory infrastructure needed: +

    +root#  mkdir -p /var/spool/samba
+root#  mkdir -p /var/lib/samba/{netlogon/scripts,profiles}
+root#  chown -R root:root /var/spool/samba
+root#  chown -R root:root /var/lib/samba
+root#  chmod a+rwxt /var/spool/samba
+

    + For each user account that is created on the system, the following commands should be + executed: +

    +root#  mkdir /var/lib/samba/profiles/'username'
+root#  chown 'username':users /var/lib/samba/profiles/'username'
+root#  chmod ug+wrx,o+rx,-w /var/lib/samba/profiles/'username'
+

    +

  10. + + + Create a logon script. It is important that each line is correctly terminated with + a carriage return and line-feed combination (i.e., DOS encoding). The following procedure + works if the right tools (unxi2dos and dos2unix) are installed. + First, create a file called /var/lib/samba/netlogon/scripts/logon.bat.unix + with the following contents: +

    +net time \\massive /set /yes
+net use h: /home
+

    + Convert the UNIX file to a DOS file: +

    +root#  dos2unix < /var/lib/samba/netlogon/scripts/logon.bat.unix \
+        > /var/lib/samba/netlogon/scripts/logon.bat
+

    +

  11. + There is one preparatory step without which you cannot have a working Samba network + environment. You must add an account for each network user. You can do this by executing + the following steps for each user: +

    +root#  useradd -m username
+root#  passwd username
+Changing password for username.
+New password: XXXXXXXX
+Re-enter new password: XXXXXXXX
+Password changed
+root#  smbpasswd -a username
+New SMB password: XXXXXXXX
+Retype new SMB password: XXXXXXXX
+Added user username.
+

    + You do, of course, use a valid user login ID in place of username. +

  12. + Follow the processes shown in ??? to start all services. +

  13. + Your server is ready for validation testing. Do not proceed with the steps in + ??? until after the operation of the server has been + validated following the same methods as outlined in ???, ???. +

Configuration Specific to Domain Member Servers: BLDG1, BLDG2

+ The following steps will guide you through the nuances of implementing BDCs for the broadcast + isolated network segments. Remember that if the target installation platform is not Linux, it may + be necessary to adapt some commands to the equivalent on the target platform. +

Procedure 4.3. Backup Domain Controller Configuration Steps

  1. + + The final step that must be completed is to edit the /etc/nsswitch.conf file. + This file controls the operation of the various resolver libraries that are part of the Linux + Glibc libraries. Edit this file so that it contains the following entries: +

    +passwd:     files winbind
+group:      files winbind
+hosts:      files dns wins
+

    +

  2. + Follow the steps outlined in ??? to start all services. Do not + start Samba at this time. Samba is controlled by the process called smb. +

  3. + + You must now attempt to join the domain member servers to the domain. The following + instructions should be executed to effect this: +

    +root#  net rpc join 
+

    +

  4. + + You now start the Samba services by executing: +

    +root#  service smb start
+

    +

  5. + Your server is ready for validation testing. Do not proceed with the steps in + ??? until after the operation of the server has been + validated following the same methods as outlined in ???. +

Example 4.1. Server: MASSIVE (PDC), File: /etc/samba/smb.conf

# Global parameters
[global]
workgroup = MEGANET
netbios name = MASSIVE
interfaces = eth1, lo
bind interfaces only = Yes
passdb backend = tdbsam
smb ports = 139
add user script = /usr/sbin/useradd -m '%u'
delete user script = /usr/sbin/userdel -r '%u'
add group script = /usr/sbin/groupadd '%g'
delete group script = /usr/sbin/groupdel '%g'
add user to group script = /usr/sbin/usermod -G '%g' '%u'
add machine script = /usr/sbin/useradd -s /bin/false -d /var/lib/nobody '%u'
preferred master = Yes
wins support = Yes
include = /etc/samba/dc-common.conf
[accounts]
comment = Accounting Files
path = /data/accounts
read only = No
[service]
comment = Financial Services Files
path = /data/service
read only = No
[pidata]
comment = Property Insurance Files
path = /data/pidata
read only = No

Example 4.2. Server: MASSIVE (PDC), File: /etc/samba/dc-common.conf

# Global parameters
[global]
shutdown script = /var/lib/samba/scripts/shutdown.sh
abort shutdown script = /sbin/shutdown -c
logon script = scripts\logon.bat
logon path = \%L\profiles\%U
logon drive = X:
logon home = \%L\%U
domain logons = Yes
preferred master = Yes
include = /etc/samba/common.conf
[homes]
comment = Home Directories
valid users = %S
read only = No
browseable = No
[netlogon]
comment = Network Logon Service
path = /var/lib/samba/netlogon
guest ok = Yes
locking = No
[profiles]
comment = Profile Share
path = /var/lib/samba/profiles
read only = No
profile acls = Yes

Example 4.3. Common Samba Configuration File: /etc/samba/common.conf

[global]
username map = /etc/samba/smbusers
log level = 1
syslog = 0
log file = /var/log/samba/%m
max log size = 50
smb ports = 139
name resolve order = wins bcast hosts
time server = Yes
printcap name = CUPS
show add printer wizard = No
shutdown script = /var/lib/samba/scripts/shutdown.sh
abort shutdown script = /sbin/shutdown -c
utmp = Yes
map acl inherit = Yes
printing = cups
veto files = /*.eml/*.nws/*.{*}/
veto oplock files = /*.doc/*.xls/*.mdb/
include =
# Share and Service Definitions are common to all servers
[printers]
comment = SMB Print Spool
path = /var/spool/samba
guest ok = Yes
printable = Yes
use client driver = Yes
default devmode = Yes
browseable = No
[apps]
comment = Application Files
path = /apps
admin users = bjordan
read only = No

Example 4.4. Server: BLDG1 (Member), File: smb.conf

# Global parameters
[global]
workgroup = MEGANET
netbios name = BLDG1
include = /etc/samba/dom-mem.conf

Example 4.5. Server: BLDG2 (Member), File: smb.conf

# Global parameters
[global]
workgroup = MEGANET
netbios name = BLDG2
include = /etc/samba/dom-mem.conf

Example 4.6. Common Domain Member Include File: dom-mem.conf

# Global parameters
[global]
shutdown script = /var/lib/samba/scripts/shutdown.sh
abort shutdown script = /sbin/shutdown -c
preferred master = Yes
wins server = 172.16.0.1
idmap uid = 15000-20000
idmap gid = 15000-20000
include = /etc/samba/common.conf

Example 4.7. Server: MASSIVE, File: dhcpd.conf

+# Abmas Accounting Inc.
+
+default-lease-time 86400;
+max-lease-time 172800;
+default-lease-time 86400;
+ddns-updates on;
+ddns-update-style interim;
+
+option ntp-servers 172.16.0.1;
+option domain-name "abmas.biz";
+option domain-name-servers 172.16.0.1, 172.16.4.1;
+option netbios-name-servers 172.16.0.1;
+option netbios-node-type 8;
+
+subnet 172.16.1.0 netmask 255.255.252.0 {
+        range dynamic-bootp 172.16.1.0 172.16.2.255;
+        option subnet-mask 255.255.252.0;
+        option routers 172.16.0.1, 172.16.0.128;
+        allow unknown-clients;
+	}
+subnet 172.16.4.0 netmask 255.255.252.0 {
+        range dynamic-bootp 172.16.7.0 172.16.7.254;
+        option subnet-mask 255.255.252.0;
+        option routers 172.16.4.128;
+        allow unknown-clients;
+	}
+subnet 172.16.8.0 netmask 255.255.252.0 {
+        range dynamic-bootp 172.16.11.0 172.16.11.254;
+        option subnet-mask 255.255.252.0;
+        option routers 172.16.4.128;
+        allow unknown-clients;
+	}
+subnet 127.0.0.0 netmask 255.0.0.0 {
+        }
+subnet 123.45.67.64 netmask 255.255.255.252 {
+        }
+

Example 4.8. Server: BLDG1, File: dhcpd.conf

+# Abmas Accounting Inc.
+
+default-lease-time 86400;
+max-lease-time 172800;
+default-lease-time 86400;
+ddns-updates on;
+ddns-update-style ad-hoc;
+
+option ntp-servers 172.16.0.1;
+option domain-name "abmas.biz";
+option domain-name-servers 172.16.0.1, 172.16.4.1;
+option netbios-name-servers 172.16.0.1;
+option netbios-node-type 8;
+
+subnet 172.16.1.0 netmask 255.255.252.0 {
+        range dynamic-bootp 172.16.3.0 172.16.3.255;
+        option subnet-mask 255.255.252.0;
+        option routers 172.16.0.1, 172.16.0.128;
+        allow unknown-clients;
+	}
+subnet 172.16.4.0 netmask 255.255.252.0 {
+        range dynamic-bootp 172.16.5.0 172.16.6.255;
+        option subnet-mask 255.255.252.0;
+        option routers 172.16.4.128;
+        allow unknown-clients;
+	}
+subnet 127.0.0.0 netmask 255.0.0.0 {
+        }
+

Example 4.9. Server: BLDG2, File: dhcpd.conf

+# Abmas Accounting Inc.
+
+default-lease-time 86400;
+max-lease-time 172800;
+default-lease-time 86400;
+ddns-updates on;
+ddns-update-style interim;
+
+option ntp-servers 172.16.0.1;
+option domain-name "abmas.biz";
+option domain-name-servers 172.16.0.1, 172.16.4.1;
+option netbios-name-servers 172.16.0.1;
+option netbios-node-type 8;
+
+subnet 172.16.8.0 netmask 255.255.252.0 {
+        range dynamic-bootp 172.16.9.0 172.16.10.255;
+        option subnet-mask 255.255.252.0;
+        option routers 172.16.8.128;
+        allow unknown-clients;
+	}
+subnet 127.0.0.0 netmask 255.0.0.0 {
+        }
+

Example 4.10. Server: MASSIVE, File: named.conf, Part: A

+###
+# Abmas Biz DNS Control File
+###
+# Date: November 15, 2003
+###
+options {
+	directory "/var/lib/named";
+	forwarders {
+		123.45.12.23;
+		123.45.54.32;
+		};
+	forward first;
+	listen-on {
+		mynet;
+		};
+	auth-nxdomain yes;
+	multiple-cnames yes;
+	notify no;
+};
+
+zone "." in {
+	type hint;
+	file "root.hint";
+};
+
+zone "localhost" in {
+	type master;
+	file "localhost.zone";
+};
+
+zone "0.0.127.in-addr.arpa" in {
+	type master;
+	file "127.0.0.zone";
+};
+
+acl mynet {
+	172.16.0.0/24;
+	172.16.4.0/24;
+	172.16.8.0/24;
+	127.0.0.1;
+};
+
+acl seconddns {
+        123.45.54.32;
+};
+

Example 4.11. Server: MASSIVE, File: named.conf, Part: B

+zone "abmas.biz" {
+	type master;
+	file "/var/lib/named/master/abmas.biz.hosts";
+	allow-query {
+		mynet;
+	};
+	allow-transfer {
+		mynet;
+	};
+	allow-update {
+		mynet;
+	};
+};
+
+zone "abmas.us" {
+        type master;
+        file "/var/lib/named/master/abmas.us.hosts";
+        allow-query {
+                all;
+        };
+        allow-transfer {
+                seconddns;
+        };
+};
+

Example 4.12. Server: MASSIVE, File: named.conf, Part: C

+zone "0.16.172.in-addr.arpa" {
+	type master;
+	file "/var/lib/named/master/172.16.0.0.rev";
+	allow-query {
+		mynet;
+	};
+	allow-transfer {
+		mynet;
+	};
+	allow-update {
+		mynet;
+	};
+};
+
+zone "4.16.172.in-addr.arpa" {
+	type master;
+	file "/var/lib/named/master/172.16.4.0.rev";
+	allow-query {
+		mynet;
+	};
+	allow-transfer {
+		mynet;
+	};
+	allow-update {
+		mynet;
+	};
+};
+
+zone "8.16.172.in-addr.arpa" {
+	type master;
+	file "/var/lib/named/master/172.16.8.0.rev";
+	allow-query {
+		mynet;
+	};
+	allow-transfer {
+		mynet;
+	};
+	allow-update {
+		mynet;
+	};
+};
+

Example 4.13. Forward Zone File: abmas.biz.hosts

+$ORIGIN .
+$TTL 38400	; 10 hours 40 minutes
+abmas.biz	IN SOA	massive.abmas.biz. root.abmas.biz. (
+				2003021833 ; serial
+				10800      ; refresh (3 hours)
+				3600       ; retry (1 hour)
+				604800     ; expire (1 week)
+				38400      ; minimum (10 hours 40 minutes)
+				)
+			NS	massive.abmas.biz.
+			NS	bldg1.abmas.biz.
+			NS	bldg2.abmas.biz.
+			MX	10 massive.abmas.biz.
+$ORIGIN abmas.biz.
+massive			A	172.16.0.1
+router0                 A       172.16.0.128
+bldg1                   A       172.16.4.1
+router4                 A       172.16.4.128
+bldg2                   A       172.16.8.1
+router8                 A       172.16.8.128
+

Example 4.14. Forward Zone File: abmas.biz.hosts

+$ORIGIN .
+$TTL 38400	; 10 hours 40 minutes
+abmas.us	IN SOA	server.abmas.us. root.abmas.us. (
+				2003021833 ; serial
+				10800      ; refresh (3 hours)
+				3600       ; retry (1 hour)
+				604800     ; expire (1 week)
+				38400      ; minimum (10 hours 40 minutes)
+				)
+			NS	dns.abmas.us.
+			NS	dns2.abmas.us.
+			MX	10 mail.abmas.us.
+$ORIGIN abmas.us.
+server			A	123.45.67.66
+dns2			A	123.45.54.32
+gw			A	123.45.67.65
+www			CNAME	server
+mail			CNAME	server
+dns			CNAME	server
+

Example 4.15. Servers: BLDG1/BLDG2, File: named.conf, Part: A

+###
+# Abmas Biz DNS Control File
+###
+# Date: November 15, 2003
+###
+options {
+	directory "/var/lib/named";
+	forwarders {
+		172.16.0.1;
+		};
+	forward first;
+	listen-on {
+		mynet;
+		};
+	auth-nxdomain yes;
+	multiple-cnames yes;
+	notify no;
+};
+
+zone "." in {
+	type hint;
+	file "root.hint";
+};
+
+zone "localhost" in {
+	type master;
+	file "localhost.zone";
+};
+
+zone "0.0.127.in-addr.arpa" in {
+	type master;
+	file "127.0.0.zone";
+};
+
+acl mynet {
+	172.16.0.0/24;
+	172.16.4.0/24;
+	172.16.8.0/24;
+	127.0.0.1;
+};
+
+acl seconddns {
+        123.45.54.32;
+};
+

Example 4.16. Servers: BLDG1/BLDG2, File: named.conf, Part: B

+zone "abmas.biz" {
+	type slave;
+	file "/var/lib/named/slave/abmas.biz.hosts";
+	allow-query {
+		mynet;
+	};
+	allow-transfer {
+		mynet;
+	};
+};
+
+zone "0.16.172.in-addr.arpa" {
+	type slave;
+	file "/var/lib/slave/master/172.16.0.0.rev";
+	allow-query {
+		mynet;
+	};
+	allow-transfer {
+		mynet;
+	};
+};
+
+zone "4.16.172.in-addr.arpa" {
+	type slave;
+	file "/var/lib/named/slave/172.16.4.0.rev";
+	allow-query {
+		mynet;
+	};
+	allow-transfer {
+		mynet;
+	};
+};
+
+zone "8.16.172.in-addr.arpa" {
+	type slave;
+	file "/var/lib/named/slave/172.16.8.0.rev";
+	allow-query {
+		mynet;
+	};
+	allow-transfer {
+		mynet;
+	};
+};
+

Example 4.17. Initialize Groups Script, File: /etc/samba/initGrps.sh

+#!/bin/bash
+
+# Create UNIX groups
+groupadd acctsdep
+groupadd finsrvcs
+groupadd piops
+
+# Map Windows Domain Groups to UNIX groups
+net groupmap add ntgroup="Domain Admins"  unixgroup=root type=d
+net groupmap add ntgroup="Domain Users"   unixgroup=users type=d
+net groupmap add ntgroup="Domain Guests"  unixgroup=nobody type=d
+
+# Add Functional Domain Groups
+net groupmap add ntgroup="Accounts Dept"       unixgroup=acctsdep type=d
+net groupmap add ntgroup="Financial Services"  unixgroup=finsrvcs type=d
+net groupmap add ntgroup="Insurance Group"     unixgroup=piops type=d
+

Process Startup Configuration

+ + + There are two essential steps to process startup configuration. A process + must be configured so that it is automatically restarted each time the server + is rebooted. This step involves use of the chkconfig tool that + created appropriate symbolic links from the master daemon control file that is + located in the /etc/rc.d directory to the /etc/rc'x'.d + directories. Links are created so that when the system run-level is changed, the + necessary start or kill script is run. +

+ + In the event that a service is provided not as a daemon but via the internetworking + super daemon (inetd or xinetd), then the chkconfig + tool makes the necessary entries in the /etc/xinetd.d directory + and sends a hang-up (HUP) signal to the super daemon, thus forcing it to + re-read its control files. +

+ Last, each service must be started to permit system validation to proceed. The following steps + are for a Red Hat Linux system, please adapt them to suit the target OS platform on which you + are installing Samba. +

Procedure 4.4. Process Startup Configuration Steps

  1. + Use the standard system tool to configure each service to restart + automatically at every system reboot. For example, + +

    +root#  chkconfig dhpc on
+root#  chkconfig named on
+root#  chkconfig cups on
+root#  chkconfig smb on
+root#  chkconfig swat on
+

    +

  2. + + + + Now start each service to permit the system to be validated. + Execute each of the following in the sequence shown: + +

    +root#  service dhcp restart
+root#  service named restart
+root#  service cups restart
+root#  service smb restart
+root#  service swat restart
+

    +

Windows Client Configuration

+ The procedure for desktop client configuration for the network in this chapter is similar to + that used for the previous one. There are a few subtle changes that should be noted. +

Procedure 4.5. Windows Client Configuration Steps

  1. + Install MS Windows XP Professional. During installation, configure the client to use DHCP for + TCP/IP protocol configuration. + + + DHCP configures all Windows clients to use the WINS Server address that has been defined + for the local subnet. +

  2. + Join the Windows domain MEGANET. Use the domain administrator + username root and the SMB password you assigned to this account. + A detailed step-by-step procedure for joining a Windows 200x/XP Professional client to + a Windows domain is given in ???, ???. + Reboot the machine as prompted and then log on using the domain administrator account + (root). +

  3. + Verify that the server called MEGANET is visible in My Network Places, + that it is possible to connect to it and see the shares accounts, + apps, and finsvcs, + and that it is possible to open each share to reveal its contents. +

  4. + Create a drive mapping to the apps share on a server. At this time, it does + not particularly matter which application server is used. It is necessary to manually + set a persistent drive mapping to the local applications server on each workstation at the time of + installation. This step is avoided by the improvements to the design of the network configuration + in the next chapter. +

  5. + Perform an administrative installation of each application to be used. Select the options + that you wish to use. Of course, you choose to run applications over the network, correct? +

  6. + Now install all applications to be installed locally. Typical tools include Adobe Acrobat, + NTP-based time synchronization software, drivers for specific local devices such as fingerprint + scanners, and the like. Probably the most significant application to be locally installed + is antivirus software. +

  7. + Now install all four printers onto the staging system. The printers you install + include the accounting department HP LaserJet 6 and Minolta QMS Magicolor printers, and you + also configure use of the identical printers that are located in the financial services department. + Install printers on each machine using the following steps: + +

    Procedure 4.6. Steps to Install Printer Drivers on Windows Clients

    1. + Click Start → Settings → Printers+Add Printer+Next. Do not click Network printer. + Ensure that Local printer is selected. +

    2. + Click Next. In the + Manufacturer: panel, select HP. + In the Printers: panel, select the printer called + HP LaserJet 6. Click Next. +

    3. + In the Available ports: panel, select + FILE:. Accept the default printer name by clicking + Next. When asked, “Would you like to print a + test page?”, click No. Click + Finish. +

    4. + You may be prompted for the name of a file to print to. If so, close the + dialog panel. Right-click HP LaserJet 6 → Properties. +

    5. + In the Network panel, enter the name of + the print queue on the Samba server as follows: \\BLDG1\hplj6a. + Click OK+OK to complete the installation. +

    6. + Repeat the printer installation steps above for both HP LaserJet 6 printers + as well as for both QMS Magicolor laser printers. Remember to install all + printers but to set the destination port for each to the server on the + local network. For example, a workstation in the accounting group should + have all printers directed at the server BLDG1. + You may elect to point all desktop workstation configurations at the + server called MASSIVE and then in your deployment + procedures, it would be wise to document the need to redirect the printer + configuration (as well as the applications server drive mapping) to the + server on the network segment on which the workstation is to be located. +

    +

  8. + When you are satisfied that the staging systems are complete, use the appropriate procedure to + remove the client from the domain. Reboot the system, and then log on as the local administrator + and clean out all temporary files stored on the system. Before shutting down, use the disk + defragmentation tool so that the file system is in optimal condition before replication. +

  9. + Boot the workstation using the Norton (Symantec) Ghosting disk (or CD-ROM) and image the + machine to a network share on the server. +

  10. + You may now replicate the image using the appropriate Norton Ghost procedure to the target + machines. Make sure to use the procedure that ensures each machine has a unique + Windows security identifier (SID). When the installation of the disk image is complete, boot the PC. +

  11. + Log onto the machine as the local Administrator (the only option), and join the machine to + the domain following the procedure set out in ???, ???. You must now set the + persistent drive mapping to the applications server that the user is to use. The system is now + ready for the user to log on, provided you have created a network logon account for that + user, of course. +

  12. + Instruct all users to log onto the workstation using their assigned username and password. +

Key Points Learned

+ The network you have just deployed has been a valuable exercise in forced constraint. + You have deployed a network that works well, although you may soon start to see + performance problems, at which time the modifications demonstrated in ??? + bring the network to life. The following key learning points were experienced: +

  • + The power of using smb.conf include files +

  • + Use of a single PDC over a routed network +

  • + Joining a Samba-3 domain member server to a Samba-3 domain +

  • + Configuration of winbind to use domain users and groups for Samba access + to resources on the domain member servers +

  • + The introduction of roaming profiles +

Questions and Answers

+

+ The example smb.conf files in this chapter make use of the include facility. + How may I get to see what the actual working smb.conf settings are? +
+ Why does the include file common.conf have an empty include statement? +
+ I accept that the simplest configuration necessary to do the job is the best. The use of tdbsam + passdb backend is much simpler than having to manage an LDAP-based ldapsam passdb backend. + I tried using rsync to replicate the passdb.tdb, and it seems to work fine! + So what is the problem? +
+ You are using DHCP Relay enabled on the routers as well as a local DHCP server. Will this cause a clash? +
+ How does the Windows client find the PDC? +
+ Why did you enable IP forwarding (routing) only on the server called MASSIVE? +
+ You did nothing special to implement roaming profiles. Why? +
+ On the domain member computers, you configured winbind in the /etc/nsswitch.conf file. + You did not configure any PAM settings. Is this an omission? +
+ You are starting SWAT up on this example but have not discussed that anywhere. Why did you do this? +
+ The domain controller has an auto-shutdown script. Isn't that dangerous? +

+ The example smb.conf files in this chapter make use of the include facility. + How may I get to see what the actual working smb.conf settings are? +

+ You may readily see the net compound effect of the included files by running: +

+root#  testparm -s | less
+

+

+ Why does the include file common.conf have an empty include statement? +

+ The use of the empty include statement nullifies further includes. For example, let's say you + desire to have just an smb.conf file that is built from the array of include files of which the + master control file is called master.conf. The following command + produces a compound smb.conf file. +

+root#  testparm -s /etc/samba/master.conf > /etc/samba/smb.conf
+

+ If the include parameter was not in the common.conf file, the final smb.conf file leaves + the include in place, even though the file it points to has already been included. This is a bug + that will be fixed at a future date. +

+ I accept that the simplest configuration necessary to do the job is the best. The use of tdbsam + passdb backend is much simpler than having to manage an LDAP-based ldapsam passdb backend. + I tried using rsync to replicate the passdb.tdb, and it seems to work fine! + So what is the problem? +

+ Replication of the tdbsam database file can result in loss of currency in its + contents between the PDC and BDCs. The most notable symptom is that workstations may not be able + to log onto the network following a reboot and may have to rejoin the domain to recover network + access capability. +

+ You are using DHCP Relay enabled on the routers as well as a local DHCP server. Will this cause a clash? +

+ No. It is possible to have as many DHCP servers on a network segment as makes sense. A DHCP server + offers an IP address lease, but it is the client that determines which offer is accepted, no matter how many + offers are made. Under normal operation, the client accepts the first offer it receives. +

+ The only exception to this rule is when the client makes a directed request from a specific DHCP server + for renewal of the lease it has. This means that under normal circumstances there is no risk of a clash. +

+ How does the Windows client find the PDC? +

+ The Windows client obtains the WINS server address from the DHCP lease information. It also + obtains from the DHCP lease information the parameter that causes it to use directed UDP (UDP Unicast) + to register itself with the WINS server and to obtain enumeration of vital network information to + enable it to operate successfully. +

+ Why did you enable IP forwarding (routing) only on the server called MASSIVE? +

+ The server called MASSIVE is acting as a router to the Internet. No other server + (BLDG1 or BLDG2) has any need for IP forwarding because they are attached only to their own network. + Route table entries are needed to direct MASSIVE to send all traffic intended for the remote network + segments to the router that is its gateway to them. +

+ You did nothing special to implement roaming profiles. Why? +

+ Unless configured to do otherwise, the default behavior with Samba-3 and Windows XP Professional + clients is to use roaming profiles. +

+ On the domain member computers, you configured winbind in the /etc/nsswitch.conf file. + You did not configure any PAM settings. Is this an omission? +

+ PAM is needed only for authentication. When Samba is using Microsoft encrypted passwords, it makes only + marginal use of PAM. PAM configuration handles only authentication. If you want to log onto the domain + member servers using Windows networking usernames and passwords, it is necessary to configure PAM + to enable the use of winbind. Samba makes use only of the identity resolution facilities of the name + service switch (NSS). +

+ You are starting SWAT up on this example but have not discussed that anywhere. Why did you do this? +

+ Oh, I did not think you would notice that. It is there so that it can be used. This is more fully discussed + in TOSHARG2, which has a full chapter dedicated to the subject. While we are on the + subject, it should be noted that you should definitely not use SWAT on any system that makes use + of smb.conf include files because SWAT optimizes them out into an aggregated + file but leaves in place a broken reference to the top-layer include file. SWAT was not designed to + handle this functionality gracefully. +

+ The domain controller has an auto-shutdown script. Isn't that dangerous? +

+ Well done, you spotted that! I guess it is dangerous. It is good to know that you can do this, though. +

Prev Up Next
Chapter 3. Secure Office Networking Home Chapter 5. Making Happy Users
-- cgit v1.2.3