Installing the server operating system 2. Installing any required drivers Installing any required service packs 4. Installing any required hotfixes or security patches Installing the backup software 6. Installing any required patches to the backup soft

Previous Table of Contents Next Copyr ight © Sybex, I nc. FIGURE 12.5 Octopus can be used to back up multiple NT servers to a remote location. We have also addressed the availability issue. If any one of your sites should go down, the data normally stored at that site would still be available. This is because the Octopus target would detect the server outage and step in for the missing system. Any network still functioning would be able to access the mirrored copy of the shares from the target server. In short, an entire facility could be swallowed up by the earth, and from a share access perspective, you would never know the difference. Installing Octopus Octopus must be installed on every system that will act as an Octopus target or an Octopus source. To begin the installation process, insert the CD into an NT server and launch the Setup executable. This will produce the Site Select dialog box, shown in Figure 12.6, which prompts you to enter the Microsoft machine name of the system on which you wish to install Octopus. You can type in the server name as I have done in the figure or you can click the Get button in order to search the network for NT Servers. The Network Sites section of the dialog box allows you to customize the amount of information that is reported during a Get. Once you have entered the correct server name, click Continue. FIGURE 12.6 The Octopus Site Select dialog box Using Get to search the network for NT servers is an extremely slow process. You should type in the server name directly whenever possible . You are next prompted to select a path for the program and data files, as shown in Figure 12.7. These FIGURE 12.7 The Install Paths dialog box The final dialog box will prompt you for your license key. You need to visit the Qualix Group Web site http:www.octopustech.com or contact the Qualix Group directly with your product’s serial number in order to generate a license key. Once you have entered this key, the program files will be copied to your hard drive and you will be prompted to reboot the NT server. Remember that you must install a copy of Octopus on every NT server that will be acting as either a source or a target . Configuring Octopus When you log on to the NT server and launch the Octopus icon, you will be presented with the Octopus console shown in Figure 12.8. All share replication is configured from the Octopus source, so if you are not currently sitting at the source’s console, you can connect to the source system by selecting Functions Attach from the console menu. This will produce the same Site Select dialog box you worked with during the product installation. You can either type in the name of the Octopus source NT server you wish to connect to or use the Get button to search the network for NT Servers which have Octopus installed. Once you select the source you wish to work with, the console will become active for that system. FIGURE 12.8 The Octopus console screen Next you need to add a specification that identifies which information you wish to replicate and to which source. Select Maintenance Add Specification from the Octopus console menu. This will produce the Specifications screen shown in Figure 12.9. You should first configure your system to replicate all share information. This is performed by selecting the Mirror Shares radio button at the top of the screen. Octopus can only mirror unique share names. This means that two Octopus sources sharing the same target must not have any shares with the same name. If they do, one of the shares will be disabled on the target system in order to avoid conflicts . FIGURE 12.9 Replicating shares with the Specifications screen The Exclude Shares field allows you to specify certain shares that you do not wish to replicate. To save all shares except for the administrative shares, leave this option blank. The Target Site field allows you to identify the Octopus target where this share information will be saved. Finally, selecting the Synchronize check box will cause this information to be immediately replicated to the target system. When all of your options are set, click the OK button. You also need to identify which directories you wish to replicate. This is done by adding another specification, but this time you will select the Mirror Files radio button at the top of the Specification screen, as shown in Figure 12.10. This activates the Source Spec and Target Spec fields so that directory paths may be entered. You can only specify one directory path per specification. If you need to replicate multiple directories, simply create additional specifications. Checking the Sub Tree box will cause Octopus to replicate all directories located under the specified source directory. FIGURE 12.10 Replicating files with the Specifications screen You also need to specify a target system and a target directory. This should be the same target system that will hold the shares, but you can locate the directory information anywhere you choose. Once you have finished, click OK and add shares as required. Your Octopus console screen should now appear similar to Figure 12.11. The top windows of the Octopus console show that the Octopus source WWW is set up to replicate to the target system LAB31 . The green traffic lights tell you that these systems are still able to communicate with each other. Under the target systems, you can see all the specifications you have configured. In this example, we are replicating the share information and the directories hotfix and i386 . The bottom pane shows the current replication status of the specification highlighted in the top pane. In Figure 12.11, you can see that Octopus found and replicated 2,576 files within the i386 directory. Now that your share and file information is being replicated, you need to tell your Octopus systems how they should respond when a failure occurs. This is done by selecting Clustering Source Options from the Octopus console screen. This displays the Source Options dialog box, as shown in Figure 12.12. FIGURE 12.12 The Clustering Source Options window Previous Table of Contents Next Copyr ight © Sybex, I nc. The Timeouts tab allows you to set up communication parameters between the source and target system. The settings in Figure 12.12 tell the source to transmit a heartbeat every 15 seconds. The target is configured so as not to assume that the source is offline unless 60 seconds pass in which the target receives no heartbeat transmission. These settings help to insure that one or two lost packets do not trigger the fail over process. If you click the IP Addresses to Forward tab, you can specify whether the target system should assume the IP address of the source system when it fails. You can even specify multiple network cards. This insures that systems that use DNS or WINS to locate the source system will be directed to the target system after a failure. Remember that the target can only assume the IP address of the source if the two systems are located on the same logical network . The final tab, Cluster to, allows you to specify the target system. If you have created a specification as we did earlier in this configuration, this value should be filled in for you and should not need to be changed. Once you have configured your Source Options, you can click OK to save your changes. Finally, you need to configure the options for your target system. To do this, select Clustering Target Options from the Octopus console screen. This will produce the clustering Target Options dialog box, as shown in Figure 12.13. FIGURE 12.13 The Clustering Target Options window The Options tab lets you configure how the target responds when it needs to stand in for another system. You can define executables or batch processes to run when a target stands in, as well as when the source returns to operation. You can also specify whether the target should replace its IP address with that of the source or whether it should use both addresses simultaneously. If you click the Take Over tab, you will see any current sources that this target has taken over. The Services tab allows you to specify which services should be run on the target system once a fail over has taken place. By default, all services on the target system are restarted when the target needs to stand in for a source. This allows the Octopus target to assume machine names and IP addresses as required. You can, however, specify that certain services are not to be restarted and even set certain services to be run only once a fail over takes place. The Account tab is for entering authentication information. This is only required if the source is a stand-alone server and the target needs to provide a new System ID SID. If the source is a PDC or a BDC, this information is not required. The Notification tab allows you to specify who should be notified when the target needs to stand in for the source. An alert can be sent to an e-mail address, to an NT logon name as a pop-up message, or even to an entire domain. Once you have finished configuring your target options, click OK to save your changes. Your source and target systems are now configured to provide server-level fault tolerance in case of disaster. Testing Octopus In order to show you how a fail over would look to the average end-user, I have configured three Octopus systems for testing. Two of them www and holnt200 are Octopus sources, while the third lab31 is set up as the Octopus target. Table 12.2 shows the share names being used by each system. TABLE 12.2:Share Names Used on the Octopus Test Systems Host Configuration Shares www Octopus source hotfix, i386 holnt200 Octopus source accounting, marketing, last_share lab31 Octopus target none Each system was set up as described in the “Configuring Octopus” section of this chapter. Once the sources were configured, the systems were allowed to sit until replication was complete. The replication process took less than 10 minutes. Once this process was complete, lab31 had a copy of every share located on the two Octopus sources. A Network Neighborhood view of these shares is shown in Figure 12.14. FIGURE 12.14 Lab31 with a copy of all shares I then pulled the power plug literally on servers www and holnt200 and allowed one minute to elapse for the target to figure out that these two source systems were offline this was the configured stand- lab31 had in fact stepped in for www and holnt200 . As shown in Figure 12.15, this process had already been completed. The Added Names field shows us what source systems the target has stepped in for. FIGURE 12.15 The Target Options Take Over tab To confirm that the target had stepped in for the source systems, I launched Network Neighborhood from a Windows 95 test system. As shown in Figure 12.16, the client Hellsfarr was fooled into thinking that all the servers were still online and functional. Response time for the Neighbor-hood search was no longer than when the servers were actually online. FIGURE 12.16 Lab31 standing in for www and holnt200 Finally, both www and holnt200 were checked to insure that the correct share names were associated with the correct systems. As shown in Figure 12.17, lab31 associated the correct share names with the system www . Opening up each share produced the expected list of files. FIGURE 12.17 Lab31 advertising the correct shares for www Summary I n this chapter, you saw what disaster prevention and disaster recovery options are available for protecting your network. We discussed network-based disasters and server-based disasters. We also discussed the importance of testing and documenting your disaster recovery procedures. Finally, you took a look at a product designed to provide redundant-server fault tolerance in an NT server environment. Previous Table of Contents Next Copyr ight © Sybex, I nc.

CHAPTER 13 NetWare

R eleased in 1983, Novell NetWare has become the mainstay for a majority of networks in providing file and print services. As of version 4.11, Novell has included a number of IP applications which are designed to facilitate the construction of an internal Internet, known as an intranet. An intranet provides many of the connectivity options usually associated with the Internet HTTP, FTP, and so on, except access to these resources is restricted to internal personnel only. As of version 5.0, NetWare includes native support for the IP protocol. While NetWare has supported client communication under IP for a while using NetWareIP, NetWareIP was simply an IP tunnel carrying IPX traffic. NetWare version 5.0 allows you to remove IPX from the picture entirely. The default security posture of a NetWare server is pretty tight. The file system supports a detailed level of permissions, and users are provided very little access to system resources by default. There are still a few things you can do, however, to increase security. NetWare Core OS T he core of NetWare is a 32-bit, multitasking, multithreaded kernel. Symmetrical multiprocessor support is included with the core OS. The kernel is designed to be modular. This means that applications and support drivers can be loaded and unloaded on the fly. It also means that most of the changes can be made without rebooting the system. Need to change an IP address? This can be done with two commands at the command prompt and takes effect immediately. This can be a lifesaver for environments that cannot afford to reboot a server every time a change has been made. As of version 5.0, NetWare includes support for Java. The Novell Java Virtual Machine JVM allows the server to support the execution of Java scripts. This lets you develop or run Java-based applications directly off the server. NetWare versions up to 4.x were designed to run completely within the physical memory installed on the server. In other words, swap space or virtual memory was not supported. This means that the total memory available to the operating system is what was physically installed on the server. Memory never goes to waste on a NetWare server. Any memory that remains after the core OS, supporting applications, and drivers have been loaded goes to caching frequently accessed files. The more available memory, the more files can be cached. This means that when a user requests a commonly used file, the server can access the information from faster memory instead of disk. When the operating system requires additional memory, it takes that memory from the file-caching pool. Novell has also improved recovery from critical system errors, called abnormal ends or ABENDs. In previous versions of NetWare, an ABEND would cause a server to stop all processing. The only forms of recovery were to restart the server through the online debugger or to hit the power switch. NetWare also has the ability to restart the server after a predetermined period of time if an ABEND occurs. You can even select what kind of an ABEND causes a server to restart. For example, you can set the server to simply recover from application ABENDs but to perform a system restart if the failure mode is hardware related. NetWare includes a garbage collection setting. While this will not stop by your cubicle and empty your trash, it can recover server memory from unloaded processes. With earlier versions of NetWare, if a poorly coded application was unloaded from memory, the application might not have returned all the memory it was using to the free memory pool. This is a common problem with applications running on any operating system. The garbage collection process scans for these memory areas that are no longer in use. When it finds them, the pointers are deleted and the space is returned to the free memory pool for use by other applications. New features have been added to insure that applications do not tie up the processors for an excessive amount of time. NetWare includes a relinquish control alert setting that produces an error message when an application refuses to play fair and share the available CPU cycles. There is also a CPU hog timeout setting, which allows the system to automatically kill any process monopolizing all of the server’s processor time. C2 Certification NetWare is the only distributed network operating system to receive C2 certification as a trusted network component from the National Computer Security Center NCSC. While NT is also C2 certified, at the time of this writing it is not approved as a trusted network, only as an operating system. Even then, it is only certified as a stand-alone workstation with no removable media or network connection. NetWare is also being evaluated for Electronic Data’s E2 rating. E2 is the European counterpart to C2. The specifications of each are very similar. Copyr ight © Sybex, I nc. C2 Specifications In order to be approved as a C2 trusted network component by the NCSC, a product is expected to meet the following specifications: • The system must be able to uniquely identify every system user. • The system must be able to selectively track user logons and object changes. • The system must be able to maintain an audit log. • The system’s audit log must identify the source of all entries which remote system, terminal, or server console. • The system administrator must be able to restrict access to the audit log. • The system must have a method of setting individual and group access control. • The system administrator must have a method of limiting the propagation of access control rights. • The system administrator must have a method of validating that the system is functioning correctly. • The system must include a manual describing all security features. • The security features must be tested by the NCSC and found to have no obvious flaws. It is the final specification no obvious flaws that seems to trip up most systems submitted for C2 trusted network approval. C2 certification does not guarantee that your system will be impenetrable. It does, however, tell you that the product has been designed with security in mind and that these security precautions have been accepted by a third-party government agency. NetWare Directory Services F or access control, NetWare uses NetWare Directory Services NDS, which provides a hierarchical approach to assigning and managing network access rights. This allows an entire networking environment to be managed through a single console. NDS also provides an extremely detailed level of control over user access to network resources. An organization’s NDS structure is commonly referred to as the NDS tree. The structure of NDS is similar to the directory structure on a hard drive. Subdirectories known as Organizational Units OU, or containers, can be defined off the root. Access rights can be set on each of the containers so that users only have access to the resources they need. You can define more containers to organize user access even further. Network access is also centralized. When a user logs in to the network, she authenticates to the entire NDS tree, not just a specific server or portion of the tree. This means that she automatically receives access to all network resources that have been assigned to her—even if that resource exists on a remote portion of the tree such as a printer in a remote field office. NDS Design For an example of how an NDS tree may be configured, take a look at Figure 13.1. The organization Geek-Speak has been broken up into four geographic locations: Portland, Corporate, New York, and Boston. Any user assigned access to the geographic containers can be granted access privileges to all resources at that location. If each location has its own IS staff, this is where you would create IS staff accounts. By defining these administrators within the geographic containers, you can give them access to all on-site resources while insuring that they have no access to resources at other locations. Further, you could create a small number of user accounts directly under the Geek-Speak container which would allow these administrators to manage the entire tree. At each geographic location, you could define further containers in order to structure your resources by department. This allows you to organize your network resources beyond geographic location. For example, look at the HR container in Figure 13.1. Within the HR container, we have defined a number of user groups as well as the printer, file, and application resources these user groups will need access to. This simplifies security management: you can organize network objects based on their access requirements. NDS can even deal with specialized cases in which users need access to multiple containers within the tree. For example, let’s say that Bob is the VP of Human Resources for Geek-Speak and requires access to HR resources at every facility. You do not wish to grant Bob access to the entire NDS tree, however, because Bob has been known to poke around where he does not belong. FIGURE 13.1 An example NDS tree In Bob’s case, you could simply create a user object for him under one of the HR containers such as the one under Corporate, which is not shown in the figure, then alias his user object within the other HR containers where he requires access. The Bob object in Figure 13.1 is simply an alias that points back to the original. This allows you to make access control changes and have them linked to all of