Microsoft Windows Services for Unix 3.0
Microsoft Windows Services for Unix 3.0Instead of trying to tackle the enormous job of developing still more applications to make it easier to integrate Unix and Windows into a cohesive network, Microsoft chose to take advantage of developments by other vendors and instead released the Windows NT Services for Unix Add-On Pack. This set of applications contains in-house applications developed by Microsoft as well as products licensed and bought from other companies. Now simply called Services for Unix (SFU) Version 3.0, this optional software, which sells for about $100, contains applications that were developed by Microsoft and other vendors , but that can be bought as a single package. Not all the services available in SFU 3.0 are discussed in this chapter, but Table 61.1 can give you an idea of what types of software are available in SFU 3.0 and which platforms they can be used on. Table 61.1. Services Provided by the SFU 3.0 Package
In addition, you'll find many other components , such as support for Sun's Network Information System (NIS) among others. SFU 3.0 can be run on Windows NT 4.0 (with Service Pack 6a installed), Windows 2000 and 2003, and even Windows XP Professional (which was a surprise to me). In this chapter, Windows XP will be the example. Perhaps the best thing about SFU, besides its price, is that you can install it on as many computers in your network as you want . You don't have to buy a license or additional copies of the software for each computer. Installing SFU 3.0Installing SFU 3.0 is a simple task, as explained in this section. Note that some of the dialog boxes and steps in the following text might not appear during your installation. This example is based on installing all components of SFU 3.0. If you select less than all components, only dialog boxes for those components will appear. To begin the installation:
After the installation has finished, you have to restart your server to make all components available. Network File SystemThe NFS client allows Windows clients to connect to NFS file systems hosted on Unix servers. The client can connect to the file system exported by a Unix server using several methods . The simplest method is to use the Windows Explorer Accessory; click on My Network Places, and select the server you want to connect to from the right-side pane. Then use Tools, Map Network Drive to make a drive letter to the NFS file share. You also can use the command line to connect to NFS file systems. To make matters simpler for a network that's composed of both Unix and Windows users, several syntaxes are supported:
In the preceding syntax examples, the asterisk character causes the next available drive letter to be assigned to the resource. You also can specify a particular drive letter. In either case, after the connection has been made to the NFS resource, you can then use Windows applications to access files on the resource just as if they were Windows file shares. SFU also provides for these:
Using these components, you can grant access to both sets of clientsUnix or Windowsto files stored on the other's systems. One limitation you should note for the gateway service is that you're still stuck with the drive letter limitation. Suppose that your network has a large number of Unix servers and each exports an NFS file system. For each connection, the gateway server will use one of its drive letters that could normally be mapped to a regular Windows file share. The Korn ShellThe Korn Shell commands that SFU gives to Windows NT/2000/2003 and Windows XP enable you to use existing script files that run on Unix systems. For users trained on Unix systems, the Korn Shell commands make it much easier to add Windows computers to their flock of computers that must be administered. Table 61.2 lists the most useful commands provided by SFU. Table 61.2. Korn Shell Unix Commands Provided by the Add-On Pack
Some of these commands, such as mkdir and find , are already familiar to Windows NT users. However, their functions in the Korn Shell might differ from those provided by the standard Windows implementation. For Unix administrators, the addition of these commands can make moving into managing Windows NT and Windows 2000/2003 computers a simpler transition. You can use the Unix commands listed in Table 61.1 and, at the same time, become familiar with the Windows Script Host (WSH). WSH enables you to create scripts using VBScript or JScript so that you aren't stuck using only the familiar MS-DOS commands that have been the mainstay for creating script files on Windows systems for more than 20 years . In addition, SFU provides an implementation of Perl that can be used with WSH. Password SynchronizationIn Version 1 of SFU, the password synchronization feature enabled you to configure a group of Unix servers so that when a user's password was changed on a Windows NT server, the change was propagated to the user's accounts on those target Unix servers. Because the application ran only on the Windows NT computer, it was a one-way service. That is, changes made on the Unix servers were not sent back to the Windows NT computer. Versions 2 and 3 of SFU now make this functionality a two-way street. To use this SFU component, you'll need to load the Password Synchronization service on the Windows 2000/2003 Server (or NT) and, additionally, you'll have to run a daemon (called a Single Sign-On Daemon, or SSOD for short) on each Unix box that will participate in the password-update process. SFU Version 3 comes with versions of the daemon that have been compiled for the following variants of Unix:
However, if your Unix isn't in this list, you can still use the synchronization daemon. SFU comes with the source code and makefiles that you can use to compile a version for your particular system. The SSOD daemon is the background process that receives password changes from Windows computers. Another program, called the Password Authentication Manager (PAM), is used on the Unix server to send password changes made on the Unix system to Windows systems. There are a few things about the synchronization process to consider before you deploy this service in your network. First, if your Windows computers are participating in a domain, you'll have to run the service on all the domain controllers in that domain. If you use Windows NT or Windows 2000 in a workgroup (or simply as standalone computers), you'll have to run the service on each computer if you want the passwords to stay synchronized among all the Windows computers.
Another caveat you must keep in mind is that Unix account names and passwords are case sensitive. Therefore, you'll have to create accounts on your Windows and Unix systems that are exactly the same. If you already have accounts set up in your network that have users with different account names on different systems, you'll have to pick a single account name for the user and then re-create the account on each computer so that they all match. Finally, in addition to providing the capability to synchronize passwords between the Windows systems and those that are stored on individual Unix computers (in the /etc/passwd file, for example), you also can synchronize passwords with Unix networks that use the Network Information Service (NIS). Just install the SSOD on a master NIS or NIS+ server. User Name MappingIf you have an environment in which users already have accounts on both Unix and Windows NT/2000/2003 servers that aren't the same, SFU provides a component that can be used to map the different usernames. You can map usernames in a one-to-one manner or in a one-to-many manner. For example, you can create an entry that maps the name togletree to TOGLETREE . Or if you want the user to be able to access multiple user accounts, you can map the user's account name to several different account names. This second feature proves very useful if you have an assortment of Unix servers and each server has a different name used for an administrative account. You can map a single Windows NT/2000/2003 user account name to each of the user accounts on the various Unix servers. Or you can use this multiple-mapping feature to map the typical Unix account called root to more than one Windows administrative account. The advantages of multiple mappings might not seem very intuitive at first, but let's consider an example. Suppose that you want to enable the Unix administrator in your network to manage some, but not all, of your Windows-based systems. You can create a user account on each Windows computer and grant it the necessary rights and permissions. Then map the root account to these new account names. That way you don't have to simply map root to Administrator, which would give access to all computers in the domain. One final note about username mapping: It isn't a substitute for password synchronization. Remember that password synchronization, discussed in the previous section, requires that user account names be exactly the same on the computers that are participating in the synchronization process. User Name Mapping is simply another tool you can use to manage users who have accounts on both systems. If you're creating a network from scratch or if you can easily create user accounts on all of your systems that are the same, you probably won't need to use User Name Mapping and simply can let the users have a single account name on all systems, keeping passwords synchronized. Password synchronization will not work to synchronize passwords for accounts that are linked using User Name Mapping! New Telnet Server and ClientSFU also includes a Telnet server for Windows servers, and a character-cellstyle client application that greatly improves on the simple GUI Telnet client that comes with the standard Windows client operating systems. That makes it easy to use Telnet to log in to Windows server computers to perform system administration tasks or run character- cell based user applications. However, if you're using Windows 2000/2003 computers, this new Telnet client is already on your computer. It's now the standard client for Windows 2000 computers. Simply use the telnet command at the Command Prompt. Alternatively, click Start, Run, enter telnet , and click OK. If you use the telnet command at the Command Prompt, you can specify a target computer on which you want to establish a session. If you use the Start, Run method, you'll find the client starts up in console mode, as shown in Figure 61.13. Figure 61.13. The new Telnet client will start in console mode if you use the Start/Run method to start the program. For those not familiar with console mode, it simply means that the client is ready to accept configuration commands or open a session with a remote system. In Figure 61.13, you can see that the ? character has been used to display the help text that you can access while in console mode. If you simply want to telnet to a remote system, use the open < remotesystem > command. After you exit the remote system, you can return to console mode by holding down Ctrl and then the right- bracket (]) key.
Some users who are accustomed to using the GUI Telnet client might not appreciate you giving them a simple character cell type of Telnet client. However, the new version is actually faster than the older GUI client and offers more features than its predecessor. Although Windows server operating systems come with an excellent Telnet server (as described earlier in this chapter), SFU also provides a Telnet server that will run on Windows NT/2000/2003 servers. The new server also supports logging to the Windows event log or to a separate log file, and you can choose which events you want to store in the log file. Instead of using the Internet Services Manager to manage and configure the Telnet server, you can load the SFU snap-in for the Microsoft Management Console (MMC) or you can use a command-line utility, tnadmin . Both methods enable you to configure the standard options discussed earlier in this chapter. This includes selecting which authentication method to use, enabling logging, setting the maximum number of connections (remember that the Windows server versions allow for only 2 simultaneous connections, whereas this SFU version allows for up to 63), and other parameters. ActiveState ActivePerl 5.6Web site administrators will be glad to see this SFU component because it's used on a lot of Web servers. Additionally, Perl can be used for other functions, such as automating system management procedures. The version included with SFU is Perl 5.6, ported to the Windows NT/2000/2003 platform. Your Windows clients also will be pleased because this port of Perl provides support for the Windows Script Host (WSH). By including Perl with the SFU package, it becomes easier for Unix or Web administrators who are already familiar with the language to manage systems or Web sites that run on Windows servers. WSH enables those coming from the Windows camp to continue to use JScript, VBScript, and other procedural languages with which they are used to working. |
EAN: 2147483647
Pages: 434