| Click here to support our advertisers

SOFTWARE FOR SALE
BOOKS FOR SALE
SEARCH CENTRAL
JOB BANK
CLASSIFIEDS
DIRECTORIES
REFERENCE Online Library
LEARNING CENTER
JOURNAL
NEWS CENTRAL
DOWNLOADS
COMMUNITY
CALENDAR
ABOUT US
Journal:
Get the weekly email highlights from the most popular journal for developers! Current issue
> developer.com developerdirect.com htmlgoodies.com javagoodies.com jars.com intranetjournal.com javascripts.com | All Categories : C/C++ vcg19.htm Understanding Network Topology and Operations The Scope of PC Networks Workgroup Networks Departmental Networks Enterprise-Wide Networks Domains, Workgroups, Servers, and Workstations The Topology and Protocols Used in This Chapter's Examples Logging on to Servers and Joining Workgroups Server Redundancy and Backup Systems Network Adapter Cards and Operating Protocols The Network Driver Interface Specification and Network Adapter Card Drivers Network Protocol Stacks Included with Windows NT Server TCP/IP in Windows NT Server 3.51 and Windows NT Workstation 3.51 NetBIOS Over TCP/IP and the Windows Sockets API Hubs, Bridges, Routers, and Gateways Maintaining Database Security in a Network Environment Network Authority, Permissions, and Accounts Security Limitations of Workgroup Networks Supplementing Workgroup Security with Access Database Security Features Network Administrators, Operators, and Users File Permissions Using Windows NT File System Partitions Fathoming the Access Security System Assigning Access User Accounts and Securing Access Databases Securing Existing Database Files Granting and Revoking Access Permissions for Groups and Users Revoking Permissions from the User Group Creating a New Access Group and Assigning Group Permissions Summary # - 19 - Running Visual C++ Database Applications on a Network The majority of Visual C++ databases that you create are likely to be used in a multiuser environment. By definition—at least in the world of PCs running DOS, Windows, or Windows NT, and Macs running System 7+—a multiuser environment requires that all users of a database application be connected by a network in order to share one or more common files. Several surveys conducted in 1993 indicate that about 75 percent of all Windows database applications, excluding terminal-emulation applications for Windows, are installed on networked computers. In 1996, it can be expected that except for home systems and very small business systems, all computers will be networked in the business or commercial environment. Windows terminal-emulation applications, such as Wall Data's Rumba, let you communicate with mainframe computers by simulating a terminal, such as IBM's ubiquitous 3270, in conjunction with a terminal-emulation adapter card, such as DCA's IRMA product line. Developers who are migrating DOS database applications to Visual C++ applications running under Windows (both Windows 95 and Windows NT) need to understand how Windows fits into the network picture. Visual C++ developers whose applications have been limited to single-user products also need a grasp of networking methods and terminology. Access is designed specifically for creating multiuser database applications, but Visual C++ isn't "network-ready" when it comes to such issues as maintaining the security of Access or other desktop database files. Therefore, this chapter begins with a general discussion of network structures, network operating systems and applications, communication protocols, adapter cards, cabling, and other issues that face developers who need to get database applications up and running on a variety of networks. The remainder of this chapter is devoted to network security issues, primarily for desktop database file types. ### Understanding Network Topology and Operations In the world of computers, the term topology describes how computers are connected in a network. Users can be connected to the network by a variety of network interface cards (NICs), network operating protocols, and cables. A local-area network (LAN) consists of computers in a single facility that are connected by some form of cabling. You're not restricted to a copper (wire) or glass (fiber-optic) connection to the network; you also can connect using remote dial-up access through a conventional or cellular telephone equipped with a modem, a leased telephone line, a low-power wireless (radio-frequency or RF) connection, or even a satellite link. LANs in different locations can be connected into wide-area networks (WANs) by high-speed telephone lines using T1, ISDN, or ATM hardware and communication protocols. The concentrators, routers, bridges, gateways, and protocols that are used to create WANs are discussed later in this chapter. Both Windows 95 and Windows NT support dial-in network connections, which can provide usable performance when high-speed (28K or greater) modems are used. NOTE In late 1995, AT&T Paradyne introduced a new technology that makes it possible to transfer 6Mbps of data through ordinary copper phone lines. Dubbed GlobeSpan, this AT&T system uses an asymmetric digital subscriber line modem to achieve these speeds without requiring telephone companies to install a new infrastructure of fiber-optic and coaxial cable. If everything works as AT&T plans, all this high-speed bandwidth will be made accessible inexpensively by the end of 1996. AT&T says GlobeSpan could be available in most parts of the country at rates that are comparable to standard phone service. The following sections describe the topology of workgroup and client-server networks, the inner workings of a newly upgraded network operating system (Windows NT Server 3.5), and Transmission Control Protocol/Internet Protocol (TCP/IP), which has become a de facto industry standard for implementing wide-area PC networks. #### The Scope of PC Networks The primary classification of networks is by scope. The scope of a network is determined by the number and proximity of the computers connected to the network. The basic network scope classifications—workgroup, departmental, and enterprise-wide—are described in the following sections. ##### Workgroup Networks Workgroup networks connect a limited number of users (usually 25 or less) who share files, printers, and other computer resources. Microsoft's Windows 95 and Windows NT Workstation, Novell's NetWare Lite, and Artisoft's LANtastic networks are typical network operating systems (NOSs). Workgroup networks are usually self-administered; in other words, the members of the workgroup control permissions (also called authority) to share workgroup resources. Workgroup computers usually are connected by peer-to-peer networks and use a single network protocol. Any computer in a peer-to-peer network may share its resources, such as files and printers, with other computers in the workgroup. Access is designed specifically for workgroup computing. Figure 19.1 shows a five-member workgroup network using Ethernet adapter cards and cabling. One of the workgroup computers shares a fax modem and a printer with other members of the workgroup. Figure 19.1. A five-member workgroup network with a shared fax modem and laser printer. ##### Departmental Networks Departmental networks use dedicated server computers that provide resources to client workstations, usually within a single facility. Novell NetWare 3.x and 4.x, Microsoft LAN Manager and Windows NT Server 3.51, IBM's LAN Server, and Banyan VINES are examples of client-server NOSs. Departmental networks often include remote access services (RAS) that let users, such as field salespeople, to connect to the server with a modem-equipped computer. Servers fall into the following three classes: File servers let many users share files that contain data required by a common application. Typically, these files contain word-processing documents, worksheets, or desktop database tables. The applications that access the files are responsible for page or record locking to prevent two users from modifying the same record in a database. Word-processing and spreadsheet applications usually lock the entire file while a user has the file open. Application servers let users run applications from the server instead of a local fixed disk drive. Running the .EXE files and opening the DLLs of today's Windows mega apps from the network can cause severe network congestion. The advantage of using an application server is that all users work with the same version of the application, and updates and upgrades to applications are much easier to administer. A single server can provide both file- and application-sharing services. Database servers are computers that usually are devoted to running the back end of a client-server RDBMS. The performance of the RDBMS is degraded if the server computer also is used for file or application sharing. The database administrator (DBA) usually administers the RDBMS from a workstation. Database servers often run as NOS applications. For example, the Sybase version of SQL Server and Raima's Database Server are available as NetWare-loadable modules (NLMs) that run under NetWare 3.11 or higher. Microsoft SQL Server for Windows NT 6.0 (NTSQLS) runs under Windows NT 3.51, which is considered a NOS (as well as a general-purpose operating system) in this book. A variety of computer types (PCs, Macs, and UNIX workstations, for example), each of which uses a different network protocol (such as NetBEUI, IPX, and TCP/IP), may be connected as clients in a departmental network. Departmental networks use gateways to connect to mainframe computers. One or more full-time network administrators (NAs or NWAs) usually are assigned to manage departmental networks. Independent, self-administered workgroups may exist within the departmental network. Figure 19.2 shows a simple departmental network with a single file and/or application server. The server is equipped with a modem to provide remote access service. Figure 19.2. A simple departmental network with a shared printer and a RAS modem. NOTE Technically, of the examples of NOSs just listed, only NetWare 3.11 and Banyan VINES are true network operating systems. NOSs use proprietary operating systems rather than DOS, UNIX, OS/2, or Windows NT. LAN Manager, Windows NT Server, and LAN server are network applications (layers) that run under (or on top of, depending on your point of view) an operating system. LAN Manager 2.2 runs under Microsoft OS/2 version 1.3, Windows NT Server runs under Windows NT 3.51, and LAN Server runs under IBM OS/2 2+. After Windows 95 has started, most of the DOS components are no longer accessed except under special—exceptional—circumstances. For the sake of simplicity, this book uses the term NOS to describe any software product that lets computers share files. ##### Enterprise-Wide Networks Enterprise-wide networks connect departmental LANs, often across large distances. Figure 19.3 shows one of the departmental or headquarters LANs that makes up an enterprise-wide network. Most enterprise-wide networks use a variety of communication methods to link LANs into a WAN; the type of interconnection depends on the distance between the individual LANs. Concentrators, bridges, and routers are hardware devices that transfer packets of data between the LANs. Figure 19.3. A headquarters LAN that acts as the hub of a wide-area network. The LAN in Figure 19.3 uses Ethernet running the TCP/IP protocol and includes a connection to a mainframe computer through a gateway, as well as a bridge to a fiber-optic (FDDI) and copper token-ring network. Connections to North American LANs in the WAN are made through a T1 switch that provides access to high-speed telephone lines. Overseas subsidiaries communicate through a satellite link. Because of the complexity of WANs, most firms that operate enterprise-wide networks have a staff that manages the communications aspects of the WAN. #### Domains, Workgroups, Servers, and Workstations Early in the history of PC-based networks, the most common configuration was the departmental LAN (shown in Figure 19.2), a single server sharing its resources with a group of workstations. As the number of users in a LAN grows, additional servers are added to accommodate more shared files and applications, as well as expanding database files. When users number in the thousands and WANs span continents, the simple client-server model no longer suffices for network administration. Therefore, an additional tier, the domain, was added to the client-server hierarchy. Figure 19.4 shows the relationships between two domains (represented by the two domain controllers), servers, and workstations. The interconnection between the Ethernet backbone of each of the domains, represented by a lightning bolt in Figure 19.4, could be twisted-pair (10baseT) wire, coaxial cable (10base2), a fiber-optic link (FDDI), or a T1 data line. Only two workstations per domain are shown in this figure, but a single domain commonly supports 100 or more workstations. Domains are named, and users in one domain can share files that are stored on another domain's servers. Figure 19.4. Two interconnected network domains. The advantage of assigning servers and workstations to domains is that a workstation user can gain access to any server in the domain with a single logon operation. Network administrators don't need to create new user accounts for each server in a domain, because each user account is validated by the domain controller, not by the server(s) in the domain. The domain controller maintains the user account records for each person who is authorized to use a workstation in the domain. Domain controllers also can act as conventional file, application, and/or database servers. NOTE Windows NT Server carries the single-logon process one step further by authenticating user accounts across trusting domains. If the domain that is responsible for the user's account data is trusted by the other domains to which the domain with the user account is connected, the user automatically has an account in each of the other domains. A full discussion of trust relationships between domains is beyond the scope of this book. The Concepts and Planning Guide that accompanies Windows NT Server provides a complete explanation of domain topology. If you have more than one server in a Windows NT Server domain, every five minutes or so the domain controller replicates the user-account data on each of the servers in the domain. To minimize replication overhead, only changes to the user-account records are reflected in the servers' user-account tables. Replicating user-account data provides a backup in case the domain controller fails. If a domain controller failed and then was restored online, it would be automatically demoted to a domain server. This is done to prevent the failed domain controller's possibly out-of-date user account data from being used. The domain administrator can promote any server to domain controller status. Promoting a server to domain controller demotes the current domain controller to server status. #### The Topology and Protocols Used in This Chapter's Examples The examples in this chapter use Windows 95 as the peer-to-peer NOS, Windows NT Server 3.51 as the client-server NOS, and both Windows NT Workstation 3.51 and Windows 95 as client workstation environments. Windows NT Server 3.51 is a superset of Windows NT Workstation 3.51 that provides a number of additional features that aren't included in Windows NT's built-in peer-to-peer (workgroup) networking capability. One of the additional features offered by Windows NT Server is trust relationships between domains (as discussed earlier). Other added features, such as fixed-disk fault tolerance and directory replication, are discussed in a section later in this chapter. SQL Server for Windows NT 6.0, used in Chapter 20, "Creating Front Ends for Client-Server Databases," runs as a service of Windows NT Server. In order to understand many of the examples shown in this and the next chapter, you need to know the configuration of the computers and the topology of the network used to create the examples. Otherwise, you might not know why drives with letters such as G: and H: appear in the examples. Each of the computers uses generic NE-2000-compatible Ethernet cards connected by thin Ethernet (10base2) cabling. Following are the specifications and configurations of the disk drives of the server and workstation computers: The domain (Darkstar) controller and file server (GayDeceiver) is a Pentium-90 MHz PCI/ISA-bus PC with 32M of RAM and a 2G (2 gigabyte) PCI SCSI (Small Computer Systems Interface), 8-ms disk drive running Windows NT Server 3.51 and Windows 95 in a dual-boot configuration. The drive is configured as a 1.6G C: FAT drive, a Windows 95 DRVSPACE drive of 500M (I:), and a 300M NTFS partition (D:). A second 1G SCSI drive serves for temporary storage. The Windows NT file system (NTFS, which is accessible only by Windows NT Server), provides faster file access and additional security features. The V: drive is a simple Panasonic CD drive connected to a SoundBlaster sound card. The U: drive is a Sony CDU-33A double-speed CD-ROM drive connected to an IBM Audiovation mWave Sound System. A Panasonic IDE/ATPI quad-speed CD drive provides fast access to CDs when needed. There is also a Toshiba CD drive connected to the SCSI bus. The SCSI adapter is an Adaptec 2940 PCI interface adapter that uses Windows 95's protected-mode drivers when running under Windows 95. The file server also acts as a database server for Microsoft SQL Server for Windows NT (SQLNT), which is located on the NTFS D: drive. The remaining 250M partition was doubled using DRVSPACE to allow for efficient storage of many thousands of sample files. Darkstar supports NetBIOS Extended User Interface (NetBEUI), IPX/SPX, and TCP/IP protocols, both for Ethernet and for dialup connections. Connections to the Internet are made through a 28K BPS dialup PPP connection. The Internet node name is darkstar.mv.com. One client workstation (Pixel) is an 80486DX2/50 ISA-bus PC with 16M of RAM running Windows 95. A 2G IDE drive is divided into two partitions on this system. The first partition, C:, is about 1G and contains the operating system and system files. The remaining space (1G) then becomes the D: partition, which is used for temporary storage. Drive S: is a Mitsumi CD-ROM drive connected to a Mitsumi card, and drive Z: is a Panasonic IDE/ATPI quad-speed CD drive that provides an additional CD drive. Server shares (shared server directories) appear as drives H: and higher on Pixel. Pixel uses both NetBEUI and IPX/SPX protocols. Pixel accesses the Internet using Windows 95's TCP/IP protocol and dialup networking. Pixel also hosts a digital voice mail and fax system that is connected to a special telephone line. You can call in to this system and have it read any pending e-mail. In the future, maybe you'll be able to call in from a telephone and create outgoing e-mail! Another client workstation (Long) is an 80386DX-33 ISA-bus PC with 8M of RAM and an 850M IDE fixed disk drive (C:) that runs Windows 95. The Long workstation is used primarily for testing and developing Windows applications and as a FAX/e-mail server. If you send me a fax, Long gets it. The Server shares appear as drive D: and higher on Long. This workstation uses only the NetBEUI protocol. Windows NT Server 3.51 is used as the client-server NOS in this chapter because Windows NT Server 3.51 and SQL Server for Windows NT (NTSQLS) replace LAN Manager 2.2 and Microsoft SQL Server 4.2 for OS/2 in Microsoft's new enterprise networking strategy. With the release of Windows NT 3.51, the success of Windows NT is expected to hinge on the acceptance of Windows NT Server as an enterprise-wide NOS for both large and small organizations. Acceptance of NTSQLS also will influence the adoption of Windows NT Server, because the two products are designed to work best when they are combined. Oracle Corporation has announced the availability of a Windows NT implementation of its ORACLE 7 RDBMS. Oracle also has been experimenting with distributing software using the Internet. NOTE Oracle Corporation has been experimenting with several methods of software distribution, including low-cost CDs using shareware techniques and online distribution using the Internet. In late 1995 you could download a fully functional version of Oracle's product from the Internet and try it for free for 30 days. Whether Oracle continues to support these new policies is yet to be seen, but the techniques have garnered Oracle substantial press coverage. Check the www.oracle.com World Wide Web page for more information and pricing. Although the GayDeceiver workstation is configured to boot either Windows NT 3.51 or Windows 95, this chapter doesn't include examples of using Windows NT 3.51 as a network client, except for remote domain administration. Virtually all Windows 95 applications run quite effectively under Windows NT 3.51. The resources required to run Windows NT effectively (an 80486DX PC with at least 16M of RAM) and the lack of mainstream client-side applications that take advantage of Windows NT's 32-bit multithreaded, multitasking capabilities preclude Windows NT from replacing a substantial portion of the 30 million or so registered copies of Windows 3.1 and Windows 95 running on today's PCs. In late 1995, Microsoft released 32-bit versions of Excel and Word for Windows, which will help make Windows NT Workstation 3.51 more accepted than its predecessor. This book was written using the Windows 95 version of Word for Windows, which runs under both Windows NT and Windows 95. NOTE At the time this book was written, there were indications that Windows NT was becoming more popular in the business environment. When Microsoft introduces a version of Windows NT with the Windows 95 user interface, Windows NT might become a serious contender for the majority of the business (but not home) users of PCs. Windows NT Workstation is bound to become more popular; however, it will have difficulty competing with Windows 95. Windows NT Workstation will probably be desirable only in instances in which Windows NT's enhanced robustness and security are essential. Independent software vendors appear more optimistic than Microsoft about the future of Windows NT as a client OS. Performance of compilers and complex mega-apps can benefit greatly from 32-bit multithreaded operation. Frame Technology has announced that its FrameMaker 3.0 publishing application will be available for Windows NT. Micro Focus has introduced a COBOL compiler for Windows NT. AGE Logic supplies XoftWave/32 for Windows NT so that you can run UNIX applications in an X server environment on your PC. Welcom Software Technologies' Texim Project is a high-end project management application for Windows NT. AutoDesk, Inc., has released a version of AutoCAD for Windows NT. The performance improvement of these types of products under Windows NT is likely to induce power users to install dual-boot Windows NT on their Windows 3.1+ workstations. Of course, the release of Windows 95 will help bring new 32-bit applications to Windows NT Workstation, because Microsoft has stated that it wants all Windows 95 applications to also run under Windows NT. At the time this book was written, the combination of Windows NT Server 3.51 and NTSQLS had the lowest entry cost of any product combination that implements a full-featured, networked client-server computing environment. (Depending on the number of users, the cost of a Windows NT Server/NTSQLS installation is likely to be less than 25 percent of the cost of a comparable UNIX-based client-server database system.) Windows NT Server is much easier to install, administer, and maintain than any other currently available client-server NOS for enterprise-wide networks, such as Novell NetWare 4.x and Banyan VINES. NTSQLS is equally easy to install and includes server administrative tools and utilities that run under Windows on Windows NT, Windows 95, and WfWg (Windows for Workgroups) workstations. The capability to run Windows NT Server and NTSQLS on RISC-based computers using either the MIPS 4000/4400 or the Digital Alpha chipsets provides an alternative to using PCs based on Intel 80x86 MPUs (multiprocessor units). Substantial improvements in price-performance ratings of both Windows NT Server and NTSQLS are in store when the production volume of RISC-based computers speeds up in 1996 and beyond. NOTE Windows NT Workstation 3.51 and Windows NT Server 3.51 also offer scalability. Scalability means that you can add more microprocessor (MPU) chips to a Windows NT Server (or workstation) to achieve improved performance. Windows NT Workstation and Windows NT Server can divide processing chores between up to four 80x86 MPUs. However, increasing the number of MPUs doesn't always lead to improved server performance. Many server operations, such as file replication, import, and export, are I/O bound. Adding more memory (beyond 32M) to increase the size of the disk cache often is more effective in increasing server throughput than adding more MPU chips. Other options for improving I/O include dedicated caching HD controllers and high-speed fast-wide SCSI controllers and drives. You should also consider using mirroring and/or duplexing. Workstations that run high-performance graphics packages (such as photo editing) also show a considerable performance improvement when the standard video card is replaced with a high-performance 32- or 64-bit video card. #### Logging on to Servers and Joining Workgroups When you log on to a Windows NT Server network from a Windows NT workstation, you specify the domain you want to join in the From combo box of the Logon to Windows NT dialog box. If you're using a Windows for Workgroups 3.11 workstation or a Windows 95 workstation, you can join a workgroup and simultaneously log on to Windows NT Server when you run Windows for Workgroups by following these steps (for WfWg 3.11): Create an account for yourself in your Windows NT Server domain. You need to have an account with the same name and password in the Windows NT Server domain and the workgroup in order for simultaneous logon to work. Open the Microsoft Windows Network dialog box by double-clicking the Network icon in Control Panel's application group window. In the Workgroup text box, type the name of the workgroup you want to join, as shown in Figure 19.5. Figure 19.5. Entries in WfWg 3.11's Control Panel Network dialog box to log on to the Darkstar domain. Click the Startup button to display the Startup Settings dialog box, shown in Figure 19.6. Check the Log On at Startup and Log On to Windows NT or LAN Manager Domain check boxes. Figure 19.6. The Startup Settings dialog box for automatic logon to a Windows NT Server domain. Type your domain name in the Domain Name text box. If you need to change your password so that the password used by WfWg is the same as that for your Windows NT Server account, click the Set Password button and change your password. Click the OK button to close the Startup Settings dialog box, click the OK button in the Microsoft Windows Network dialog box to close it, and then close Control Panel. If you changed the workgroup name, the Network dialog box advises you that you need to reboot your computer in order for the change to become effective. (You don't need to reboot if you changed only the Domain Name entry in the Startup Settings dialog box.) For Windows 95, you should follow these steps: Create an account for yourself in your Windows NT Server domain. You need to have an account with the same name and password in the Windows NT Server domain and the workgroup in order for simultaneous logon to work. Open the Microsoft Windows network dialog box by double-clicking the Network icon in Control Panel's application group window. Click the Identification tab in the Network dialog box, shown in Figure 19.7. Type the name of the workgroup you want to join in the Workgroup edit box. Figure 19.7. Entries in Windows 95's Control Panel Network dialog box to log on to the Darkstar domain. Click the Access Control tab in the Network dialog box to display the Access Control settings dialog box. Choose the option you want to use. If you need to change your password so that the password used by Windows 95 is the same as that for your Windows NT Server account, open the Passwords dialog box from Control Panel and change your password, as shown in Figure 19.8. The Passwords dialog box lets you activate remote administration and support for user profiles. Figure 19.8. The Properties for Passwords dialog box in Windows 95. Click the OK button to close the Network dialog box, and then close Control Panel. If you changed the workgroup name, the Network dialog box advises you that you need to reboot your computer in order for the change to become effective. The next time you run Windows 95, the Welcome to Windows for Workgroups dialog box appears, as shown in Figure 19.9. When you enter your password and click the OK button, the Windows for Workgroup message box shown in Figure 19.10 indicates that you were successfully logged on to the domain name you chose. (\\DORA is the unified naming convention (UNC) name of the server that acts as the domain controller for the Darkstar domain.) You can skip the logon confirmation by clicking the Don't Display Message on Successful Logon check box in the Startup Settings dialog box. Figure 19.9. The initial logon dialog box that appears when you start Windows for Workgroups 3.11 as a Windows NT Server client. Figure 19.10. The message box that confirms successful logon to the domain. If the domain controller is down or you have a network connection problem, a message box such as that shown in Figure 19.11 appears to inform you that the Windows NT Server shares you specified in File Manager to reconnect at logon weren't reconnected. Using File Manager to connect to shared files and directories is discussed later in this chapter. (Click the Yes button to preserve the reconnect at logon status of shares.) After any other failure-to-connect messages, the message box shown in Figure 19.12 appears. When you click the OK button, you are logged on to the workgroup. Any workgroup shares you specified to reconnect at startup are available to your computer, but you can't access shares on Windows NT Server(s). Figure 19.11. The message box that indicates that a server share connection failed. Figure 19.12. The message box that indicates a failure of the domain controller or your network connection. #### Server Redundancy and Backup Systems Windows NT Server provides fault tolerance for the fixed disks of network servers by employing Redundant Array of Inexpensive Disks (RAID) methodology. The following five levels (strategies) for providing fault tolerance with RAID hardware are available: RAID level 1, disk mirroring, uses a disk mirror set to provide an exact duplicate of data on two fixed disk drives. Disk writes to one member of the mirror set are duplicated on the other member. If one disk of the mirror set fails, Windows NT Server automatically transfers disk operations to the remaining operable disk. The advantage of disk mirroring is that only two disk drives are required; other methods of providing fault tolerance require three or more disks. Only one mirror set disk drive can have a boot sector, so you need to boot from the Windows NT recovery disk that you created when you installed Windows NT Server if the disk with the boot sector fails. RAID level 2 writes blocks of data across multiple disks (a process called disk striping) and uses an error-correcting code to regenerate good data from the data blocks on a failed drive. RAID level 2 requires at least two data disks and usually more than one disk to store the error-correction data. RAID level 2 provides a faster read data rate than level 1, but it's no longer in common use because of its inefficient method of storing data. RAID level 3 is a disk-striping method similar to RAID level 2, but it offers better price-performance ratings because the size of the error-correcting code is smaller. (Only one disk drive is required to store the parity information for data on the other disk drives.) RAID level 3 often is used for applications such as client-server RDBMSs that use relatively few large files. RAID level 4 is the same as RAID level 3, except that the blocks of striped data are larger. RAID level 5 uses a technique called striping with parity. RAID level 5 uses the large-block striping method of RAID level 4 but also stripes the parity data across all disks. Logic in the software and RAID disk controller assures that the parity information for a data block and the data block itself never reside on the same disk drive. Read performance is better than with RAID level 1, but write performance is slower because of the time required to calculate and write the parity values. NOTE RAID level 0 (disk striping only) provides improved fixed-disk read performance by sequentially placing blocks of data on multiple disks. RAID level 0 isn't included in the preceding list because RAID level 0 disk striping by itself doesn't provide fault tolerance. Windows NT Server lets you choose either RAID level 1 or RAID level 5 redundancy to keep the network operating despite the failure of a single disk drive. Unless you have a particular reason for choosing RAID level 1, RAID level 5 is currently the favored method of providing disk drive fault tolerance. If more than one disk drive at a time fails, you're out of luck, because you can't reconstruct the missing data with either RAID level 1 or level 2 strategies. Low-cost fixed-disk drives ($200 per gigabyte and still falling) with an advertised MTBF (mean time between failures) of 800,000 to 1,000,000 hours were available at the time this book was written, so multiple-drive failure is unlikely unless the server experiences a power surge that your power-line conditioning system can't take in stride. WARNING No form of RAID is effective when drives are killed. Natural disasters, especially lightning, can easily destroy all the drives in a RAID system at one time. CAUTION If you believe advertised MTBF figures, the probability of two disk drives failing simultaneously because of mechanical or on-board electronic component malfunction is extremely small. On the other hand, the first disk drive installed in the Darkstar domain controller experienced an unexplained catastrophic failure within the first few days of operation. The replacement drive then failed less than 60 days after it was installed. MTTF (mean time to failure) is a more useful measure of the reliability of fixed disk drives, but manufacturers rarely report MTTF values. Fault-tolerance strategies are never a substitute for regular backups of server data. Windows NT Server doesn't expand on Windows NT 3.51's tape backup system. Windows NT supports a variety of SCSI and QIC tape drives, including drives that use the 4-mm DAT (digital audio tape) format. Many suppliers of backup tape drives that aren't supported by the drivers included with Windows NT Server provide their own drivers for Windows NT 3.51. Windows 95 supports QIC drives connected to floppy controllers and some limited QIC drives connected either to parallel or dedicated controllers. At the time this book was written, Windows 95 didn't support SCSI or DAT tape drives. Aftermarket backup programs for SCSI and DAT tape drives are available to Windows 95 users. NOTE Hardware products that have been tested and found to perform satisfactorily with Windows NT 3.51 and the hardware drivers that are included with the retail versions of Windows NT Server 3.51 and Windows NT Workstation 3.51 are listed in the Hardware Compatibility List that accompanies Windows NT. Periodic additions to the list of tested hardware products appear in updated versions of the list and are available for downloading from Library 1 of the WINNT forum on CompuServe. Microsoft also maintains a WWW server at www.microsoft.com, where there are links to a vast array of information about Microsoft, including the extensive Knowledge Base. Virtually any files that are available from Microsoft may be found on ftp.microsoft.com. #### Network Adapter Cards and Operating Protocols Windows 95, Windows NT Workstation, and Windows NT Server support a variety of network adapter cards (also called NICs, Network Interface Cards) and operating protocols. Both Windows NT 3.51 and Windows 95 use the Open Systems Interconnection (OSI) Reference Model, which divides the flow of data in a connection between an application running under a computer operating system and the network hardware into the seven layers shown in Figure 19.13. This layered configuration results in the various protocols used to communicate between networked computers as a stack. Each of the layers in the workstation's stack communicates with the same layer in the server's stack. Figure 19.13. OSI Reference Model protocol stacks for a workstation and a server. The OSI Reference Model has been adopted by the United Nations' International Standards Organization (ISO) and is accepted on a worldwide basis as the standard methodology for network software implementation. The following sections provide the details of Microsoft's implementation of the OSI Reference Model. ##### The Network Driver Interface Specification and Network Adapter Card Drivers The protocol stack (also called protocol, transport protocol, or protocol driver) for WfWg 3.11, Windows 95, Windows NT Workstation 3.51, and Windows NT Server 3.51 includes the transport and network layers. The application, presentation, and session layers are attached to the operating system kernel (Windows 95, Windows NT Workstation, and Windows NT Server) or the environment (WfWg 3.11). The data-link layer of each of the three products is based on Microsoft's Network Driver Interface Specification (NDIS) standard for Windows. When you install WfWg 3.11, Windows 95, Windows NT Workstation 3.51, or Windows NT Server 3.51, you choose the NDIS driver supplied by Microsoft for the adapter card in your computer. The process of connecting the driver to the data-link layer and the adapter card is called binding. NOTE Some network protocols include the transport, network, data link, and physical layer in a single monolithic protocol. The advantage of Microsoft's NDIS approach is that you can use more than one protocol with a single adapter card. In this case, the multiple protocols share the transport and network layers of the protocol stack. The computer first transmits data in the primary protocol and then in the other protocols (if multiple protocols are used). Windows automatically assigns a new number (LANA number) to the adapter card for each protocol in use. Novell's Open Datalink Interface (ODI) is similar in concept to NDIS and also allows multiple protocol stacks. ##### Network Protocol Stacks Included with Windows NT Server Windows NT 3.51 and Windows 95 include a number of protocol stacks: NetBEUI, TCP/IP, IPX/SPX, Novell IPX/ODI, DEC Pathworks, Banyan Vines, SunSelect PC-NFS protocol, and DLC. Windows NT Server also includes a protocol stack for the AppleTalk networking system built into all Macintosh computers. (Macintosh connectivity was an extra-cost option for LAN Manager 2.2.) The following list briefly describes the purpose and capabilities of each of the most commonly used protocols supplied with Windows NT Server: NetBEUI (NetBIOS Extended User Interface) is a protocol developed by IBM that has been used in both IBM and Microsoft products since the mid-1980s. (IBM LAN Server and Microsoft LAN Manager both derive from the original 3-Com NOS that Microsoft licensed for incorporation in OS/2.) NetBEUI is a very fast protocol within a single LAN, but it's not a routable protocol. WANs require routable protocols, which include a hierarchical addressing method to specify the destination of data packets. Therefore, NetBEUI is best suited for use on a single LAN. TCP/IP (Transmission Control Protocol/Internet Protocol) is a routable protocol that was developed by the ARPA (later DARPA, the U.S. Defense Advanced Research Projects Agency) for communication among government agencies and contractors (especially university research institutes) participating in defense-related research activities. The wide-area network created by ARPA was called the Internet. Admission to the Internet later was granted to corporations, to individuals able to afford a direct connection, and to Internet service providers who provided dial-up access to the Internet. At the time this book was written, about 50 percent of the Internet host sites were commercial. The Internet is now the ultimate in wide-area networks and links several million computers around the world. TCP/IP is discussed in two later sections. IPX/SPX (Internetwork Packet Exchange) is the Novell protocol for NetWare networks. Windows NT and Windows NT Server implement IPX through an NDIS-compliant data-link layer called NWLink, which supports the STREAMS interface. NWLink currently isn't a complete solution to accessing files on NetWare servers. You need to install and run NetWare workstation software on PCs that share files on NetWare servers. This two-vendor approach to a protocol stack has been the subject of much consternation among NetWare users. (Roughly 60 percent of the networked PCs in North America used NetWare in 1993, but the percentage of non-NetWare networks is increasing.) Services for Macintosh includes the ability to share files and printers between PCs and Macs. Windows NT Server can act as the sole file server for all Macs connected to the network. Windows NT Server's Services for Macintosh also lets you create an AppleTalk "internet" that connects two or more separate AppleTalk networks. Services for Macintosh supports AppleTalk Phase 2, which supports routing and network protocols other than the AppleTalk protocol. (The current version of Services for Macintosh doesn't support AppleTalk Phase 1.) DLC (IBM data-link control) protocol can be (but seldom is) used to connect Windows NT clients to IBM mainframe computers. DLC also lets you use printers that are connected directly to the network rather than connected to a network server or WfWg workstation. (The Hewlett-Packard LaserJet IIIsi printer, for example, supports DLC using the JetDirect interface card.) Microsoft's SNA Server for Windows NT, which costs about $400, is a more satisfactory approach to IBM mainframe connectivity. Windows 95 supports the Microsoft DLC protocol. Windows 95 includes five categories of network protocols arranged by manufacturers. Figure 19.14 shows the Select Network Protocol dialog box for Windows 95. Figure 19.14. Windows 95 network protocols. The five manufacturer protocols include Banyan, Digital Equipment (DEC), Microsoft, Novell, and SunSelect. The following list briefly describes the purpose and capabilities of each of the protocols supplied with Windows 95: Banyan Vines Protocol was developed by Banyan for their networks. It's not as common as the Microsoft and Novell protocols. DEC protocols are included so that Windows 95 can communicate directly with DEC VAX servers. There are four supported protocols under DEC: PATHWORKS V4.1 Ethernet, PATHWORKS 4.1 Token Ring, Pathworks V5.0A Ethernet, and Pathworks V5.0A Token Ring. Microsoft NetBEUI is a protocol developed by IBM that has been used in both IBM and Microsoft products since the mid-1980s. (IBM LAN Server and Microsoft LAN Manager both derive from the original 3-Com NOS that Microsoft licensed for incorporation in OS/2.) NetBEUI is a very fast protocol within a single LAN, but it's not a routable protocol. WANs require routable protocols, which include a hierarchical addressing method to specify the destination of data packets. Therefore, NetBEUI is best suited for use on a single LAN. Microsoft TCP/IP is a routable protocol that was developed by ARPA for communication among government agencies and contractors (especially university research institutes) participating in defense-related research activities. The wide-area network created by ARPA was called the Internet. Admission to the Internet later was granted to corporations, to individuals able to afford a direct connection, and to Internet service providers who provided dial-up access to the Internet. At the time this book was written, about 50 percent of the Internet host sites were commercial. The Internet is now the ultimate in wide-area networks and links several million computers around the world. TCP/IP is discussed in two later sections. Microsoft IPX/SPX is the Novell protocol for NetWare networks. Windows NT and Windows NT Server implement IPX through an NDIS-compliant data-link layer called NWLink, which supports the STREAMS interface. NWLink currently isn't a complete solution to accessing files on NetWare servers. You need to install and run NetWare workstation software on PCs that share files on NetWare servers. This two-vendor approach to a protocol stack has been the subject of much consternation among NetWare users. (Roughly 60 percent of the networked PCs in North America used NetWare in 1993; however, the percentage of non-NetWare networks is increasing.) Microsoft Network Monitor is a protocol used for network monitoring and is useful for debugging network problems. Microsoft DLC (IBM data-link control) protocol can be (but seldom is) used to connect Windows NT clients to IBM mainframe computers. DLC also lets you use printers that are connected directly to the network rather than connected to a network server or to a WfWg workstation. (The Hewlett-Packard LaserJet IIIsi printer, for example, supports DLC using the JetDirect interface card.) Microsoft's SNA Server for Windows NT, which costs about $400, is a more satisfactory approach to IBM mainframe connectivity. Windows 95 supports the Microsoft DLC protocol. Novell's IPX ODI protocol is also supported. This protocol lets a Windows 95 user access Novell networks using two protocols—Novell's IPX ODI or Microsoft's IPX/SPX protocol. SunSoft's SunSelect PC-NFS protocol is also supported, allowing you to connect to SunSoft servers. Currently, the SunSelect network isn't commonly used. Although Windows NT Server supports the TCP/IP protocol that is used primarily by UNIX applications, there is no provision in Windows NT Server for connecting to Network File System (NFS) servers that let UNIX and DOS/Windows applications share a common set of files. NFS was developed by Sun Microsystems, Inc., in 1983 for use with Sun UNIX workstations. Sun offers PC-NFS, an add-in application for Windows 3.1 and WfWg clients that provides NFS connectivity in Ethernet environments. ##### TCP/IP in Windows NT Server 3.51 and Windows NT Workstation 3.51 TCP/IP is rapidly attaining the status of a de facto protocol standard for wide-area communication between local-area networks. Most firms that have heterogeneous LANs (LANs that support a variety of workstation types or transport protocols) also use TCP/IP as their primary LAN transport protocol. Virtually all mainframes, minicomputers, RISC workstations, and PC operating systems support TCP/IP, at least over Ethernet cabling. Thus, if you're developing Visual C++ database applications for large organizations, it's likely that you'll need to deal with TCP/IP. NOTE Included with Windows NT Server is the Microsoft Windows NT Server TCP/IP manual. This document describes Windows NT's implementation of TCP/IP. TCP/IP is a connection-oriented protocol that is made up of two protocols—TCP and IP. The IP protocol establishes a connection between two devices on a network, based on 4-byte (32-bit) addresses; inclusion of the IP address makes TCP/IP a routable protocol. The IP address is represented by the decimal values of each of the four bytes of the address, separated by periods, as in 115.27.88.33, which corresponds to 0x731B5821 in Visual C++ hexadecimal notation. The IP address consists of the following two components: A system network ID that identifies groups of devices (hosts) that are located on the same network A system host ID that identifies a particular device on the network, such as a workstation or a server, with the specified network ID A second 4-byte value, called the subnet mask, specifies which bytes of the IP address are to be interpreted as the network ID and which are host ID values. You create a subnet mask by creating a 32-bit binary value that has bits that are set to 1 in positions corresponding to the network ID byte(s) and to 0 in positions representing the host ID byte(s). Thus, a subnet mask with a value of 255.255.0.0 (0xFFFF0000) applied to the IP address used in the preceding example specifies that the network ID is 115.27 and the host ID is 88.33. NOTE An address with a 2-byte network ID and a 2-byte host ID is called a class B network address. A 1-byte network ID and 3-byte host ID is a class A address. A 3-byte network ID and 1-byte host ID is a class C address. Using different address classes lets you determine how many individual networks can be addressed. As you assign more bytes to network addresses, the number of devices allowed on each network decreases. All computers connected on a single network must use the same network ID and subnet mask. After the connection is created between the two network devices specified by the IP address and subnet mask, TCP creates individual IP packets from the data to be transmitted. Each packet has a header that includes the following information: A port ID that identifies the application running on the transmitting device. A checksum that is used to verify that the packet was transmitted without error. If an error occurs, the packet is retransmitted. A sequence number that lets the receiving device reassemble the packets into a stream of received data that is identical to the original transmitted data. Other control information related to the type of data and the transmitting application. Windows NT Server provides the following 17 basic utility services that are associated with the TCP/IP network protocol. NOTE To obtain help on one of the TCP/IP utilities, enter the command with the help option (-?). For example, arp -? gives you help information about the options for the arp utility. WARNING Utilities such as ftp, ftpsvc, rexec, and telnet require the use of passwords. The password is sent to the host system in an unencrypted (plain-text) form. I strongly recommend that you make sure these passwords are unique and different from the passwords used on the local Windows NT network for users, domains, and workgroups. The arp utility is used to display and modify the IP-to-Ethernet of token-ring physical address translation tables that are used by the Address Resolution Protocol (ARP). You can choose to display the current entries (all entries or those based on a specific interface), delete an entry, or add an entry. The finger utility is a connectivity command that is used to display information about a user who is on a specific system that is running the finger service. The output of the finger utility varies depending on the remote systems responses. The ftp utility uses the file transfer protocols to let you send and receive files over TCP/IP networks with File Transfer Protocol (FTP) and Trivial File Transfer Protocol (TFTP). Both of these protocols use the Windows NT command line. The ftp utility can take its input either directly from the command line or from an ASCII text file. Anonymous FTP, one mode of which lets you use Anonymous as the user name and usually your e-mail address as the password, is the most common method of transferring text and binary files over the Internet. The hostname command is used to display the name of the current TCP/IP host. This command has no options. The ipconfig utility is used for diagnostics. It displays information about the configuration of the current machine. This utility is most useful on systems that are running Dynamic Host Configuration Protocol (DHCP) servers. The lpq utility is used to obtain the status of a specific printer queue on a specific server. An option lets you obtain detailed status information. The lpr utility lets you print a file to a host system that is running as an LPD server. The nbtstat command is used to display statistics about the protocol and the current TCP/IP connection. You use this command when you're using NetBIOS over TCP/IP. The ping utility can be used to verify the connections to one or more remote hosts. The connection is verified by having the host send one or more ECHO packets to the client. The ping utility returns information that can be used to estimate the performance of the connection to the host. The rcp command can be used to copy files between the Windows NT system and a remote system running rshd (remote shell server). You can also copy files between two other systems running rshd when you issue the rcp command from the Windows NT system. The rexec command lets a user run a command on a remote host that is running the rexecd service. This command will authenticate the user's name on the remote system (by using a password) before executing the command. The route utility is used to manage and modify the network routing tables. With the route utility you can print, add, delete, or change routing. The rsh command is used to run commands on hosts that are running the RSH (Remote Process Execution) service. This command is similar to the rexec command. The snmp (Simple Network Management Protocol) utility reports the current status of a server or workstation on a network. Using snmp, you can specify the communities and host(s) from which the server or workstation will accept requests for network status information and send an authentication trap (request for identification) when an unspecified community or host makes a request from the server or workstation. Communities are called user groups in a TCP/IP network environment. The telnet command provides character-based terminal emulation that lets you operate TCP/IP hosts that support Telnet. You can start Telnet from Control Panel's Services option. After Telnet services start, Windows NT's Terminal applet launches with the Telnet port open. Under Windows 95, you can start Telnet from either the Explorer or from a DOS session command prompt. The tftp command is used to transfer files to and from a remote computer that is running the TFTP. The tftp command is very similar to the ftp command; however, TFTP doesn't provide for user authentication. The tracert utility is used to determine the route that is taken to a specified destination. It does this by sending ECHO packets that have varying Time-To-Live values. Because each router is required to decrement the Time-To-Live value, the Time-To-Live value can be used to determine the number of routers in the ECHO packet's path. When Time-To-Live becomes zero, the ECHO packet should be returned to the sender. Not all routers actually return the packet. Those that don't won't be discovered by the tracert utility. NOTE Microsoft's implementation of TCP/IP does not, in itself, provide file-sharing services between PC clients and UNIX client-server network systems. TCP/IP originally was designed for communication and file transfer instead of sharing files in a multiuser environment. Suppliers of UNIX-based RDBMSs license connectivity products to let DOS/Windows, DOS/WfWg, and Windows NT act as RDBMS clients. You currently need an NFS server (described briefly in the preceding section) and an NFS add-on application to share other types of files, such as desktop database table files, with UNIX workstations. (Microsoft didn't adapt its LAN Manager/X product, developed in the late 1980s to share files between computers using the UNIX and OS/2 operating systems, to Windows NT or Windows NT Server.) NFS software licenses currently cost approximately $200 to $400 per client (although these prices might have changed). Windows NT Workstation and Windows NT Server also offer a variety of other command-line utilities, principally for testing network connections and interacting with UNIX systems that were described earlier. A full description is found in Chapter 11, "Utilities Reference," of the TCP/IP booklet that accompanies Windows NT Workstation and Windows NT Server. A complete technical description of TCP/IP, UNIX utilities, and sharing files between computers running UNIX, DOS/WfWg, and Windows NT is beyond the scope of this book. A variety of books are devoted to the subject of UNIX networking. If you're developing a Visual C++ database application that uses a UNIX-based RDBMS such as Sybase SQL Server or that needs to share database files with UNIX workstations, your investment in a good UNIX networking book will quickly be repaid. ##### NetBIOS Over TCP/IP and the Windows Sockets API TCP/IP for Windows is implemented with both NBT (NetBIOS over TCP/IP) and the Windows Sockets API. The two implementations share the same levels in the protocol stack. NBT provides naming services so that NetBIOS applications can locate NetBIOS workstations and servers on the TCP/IP network by a valid NetBIOS name rather than a numeric IP network ID. NetBIOS names are the computer names, such as Pixel, that you assign to PC servers and workstations; NetBIOS names derive from the original PC peer-to-peer networking application developed by IBM and PC-LAN, and they must comply with DOS filenaming conventions. You use the LMHOSTS (LAN Manager hosts) file to associate NetBIOS names with IP addresses. The format of the LMHOSTS file is identical to that used for the HOSTS file associated with implementations of TCP/IP for DOS, such as FTP Software's PC/TCP, which also includes NFS services. Here is a typical entry in the LMHOSTS file:
>     199.125.78.23     Darkstar
> When you specify a computer name or an IP address, the corresponding entry in LMHOSTS provides the required name resolution. Windows Sockets is modeled after the Berkeley Sockets included in the BSD (Berkeley Software Distribution) version 4.3 of UNIX developed by people at the University of California at Berkeley. In UNIX terminology, a socket is a bidirectional connector to an application. Two sockets, each identified by an address, participate in a two-way network conversation. If you intend to create a Visual C++ application that needs to connect directly to another application with TCP/IP, using the Windows Sockets API is the most straightforward approach. NetManage, Inc., publishes NEWT-SDK, a collection of DLLs that let you add TCP/IP networking capability to Windows applications. NEWT-SDK is compatible with the Windows Sockets API and provides APIs for FTP, SNMP, SMTP (Simple Mail Transmission Protocol), SLIP (Serial Link Interface Protocol), and PPP (Point to Point Protocol). Windows NT Server doesn't provide SMTP (Microsoft Mail provides e-mail service). SLIP is used for the RAS service to allow interoperability with other third-party remote access software. SLIP lets you redirect TCP/IP transmission from the network adapter card to a serial port, allowing remote dial-up connections to a network with a server that implements SLIP. NEWT-SDK includes API function prototype declarations for Visual C++. You need a fundamental understanding of TCP/IP, UNIX, and C programming in order to use the NEWT-SDK APIs effectively. NOTE Other than the support included with Windows NT 3.51 (RAS supports CSLIP/SLIP and PPP), at the time this book was written, no commercial products were available to add SLIP services to Windows NT Server. Thus, you're currently limited to using SLIP to access UNIX RDBMSs remotely. It's likely that one or more enterprising ISVs (independent software vendors) will provide add-in products to implement SLIP as Windows NT Server gains market share. Windows 95 includes built-in PPP support, and an add-in SLIP protocol handler is part of the Plus! Package. NetManage also publishes Chameleon, a set of stand-alone Windows TCP/IP applications. Chameleon lets you use FTP, TFTP, SNMP, SMTP, and SLIP services with Windows 3.1 and WfWg clients. Chameleon also includes Telnet with IBM 3270 terminal emulation and a newsreader application, NEWTNews, for the Internet. Chameleon's application group is shown in Figure 19.15. TCP/IP for Visual C++ is designed to simplify the incorporation of TCP/IP and the five basic services to Visual C++ applications with custom controls and source code examples. Figure 19.15. The application group for NetManage's Chameleon TCP/IP applications. For World Wide Web browsers, a number of very interesting products are available, including NetScape (shareware with a low registration price), which has truly outstanding performance. Also available is a product called Mosaic, which is freeware. Windows 95's Plus! Package includes Internet Explorer, which is based on Mosaic. #### Hubs, Bridges, Routers, and Gateways The following four types of hardware devices commonly are employed in LANs and WANs and to connect to mainframe computers: Hubs are used to connect groups of computers to LANs that use topologies that are more complex than Ethernet's simple inline connections. For example, you need a hub to connect one or more computers to a network that uses unshielded twisted pair (UTP, 10baseT) cabling or to token-ring networks. NOTE It's possible to connect two computers using twisted pair without using a hub and thereby create a very simple two-node network. If you need to add a third computer to the network, however, you must install a hub. Bridges provide connectivity between dissimilar LANs. You use a bridge, for example, to connect an Ethernet LAN to a token-ring LAN. Routers are used in WANs to direct network data packets to the appropriate transmission device. If you have a T1 switch and a satellite link that serve remote computers, the router connects the LAN to the switch and link hardware. Routers are similar to multiplexers that are used to combine multiple voice conversations and data transmission on a single telephone line. Smart routers maintain a list of addresses and handle the switching chores without the need for intervention by computers on the network. Gateways provide connectivity between PC LANs and mini- or mainframe computers. IBM provides a token-ring gateway for its AS/400 minicomputer and all of its current mainframe computers. Gateways often consist solely of software that you add to the mainframe's operating system or a specific application, such as an IBM DB2 server, and to the client application. In this case, the client connects to an IBM I/O controller. Information Builders, Inc.'s EDA/SQL combined with EDA/Link for Windows is an example of a gateway from Windows front-end applications to a DB2 back end running under MVS on IBM mainframes. NOTE Terminal-emulation cards, such as DCA's IRMA card, which let PCs run mainframe terminal (IBM 3270 or 5250) sessions in conjunction with terminal-emulation software, aren't LAN components. Terminal-emulation cards connect to a mainframe I/O controller by a coaxial cable; however, that connection isn't properly a LAN connection. ### Maintaining Database Security in a Network Environment This book has mentioned several times that Visual C++ database applications don't have the capability to manage database security features. You can't implement or alter the security features of Access databases, nor can you change passwords or alter password protection of Paradox 3+ table files. In a multiuser environment, however, you can control access to database files by individual users or groups of users through the security features of the network. The majority of Visual C++ applications can achieve results that are similar or equivalent to the security features built into Access if you implement a well-planned network security system. Even when you use Access, the first line of defense against unauthorized viewing or modification of database files is network security. The following sections describe how network security works in a Windows NT Server environment and how to design Visual C++ database applications to take maximum advantage of network security. If you're an Access developer, much of the terminology in the sections devoted to network security will be familiar to you. Access databases use the network security model. #### Network Authority, Permissions, and Accounts Network operations are divided into the following two basic categories: Administration of the network, which includes adding and deleting user accounts; assigning accounts to particular groups of users; granting users the ability to read from, write to, copy, or delete specific files or a collection of files in a specific directory; and backing up server files. The administrator's authority determines what administrative activities he or she can perform. Windows NT Server defines authority as a combination of rights and abilities that are inherent in a user's group. Firms with large client-server networks usually employ one or more full-time network administrators to manage the LAN. Use of network resources, which encompasses file transfer and file sharing, access to database servers on the network, printing on network printers, using network modems to send faxes or to communicate with remote computers, and the like. A user's permissions determine which network resources he or she can use and how the resources can be used. The basic element of network security in client-server networks is the user account. Administrators and users each must have a user account that lets them log on to the network. The user account record, at the minimum, includes fields to hold the user's logon ID and password and to indicate the group(s) to which the user belongs. Regular network users must belong to at least one group, most commonly called Users, but there is no limit to the number of groups to which users can be assigned. Most NOSs create a unique, encrypted system ID (SID) to identify the user. A system ID prevents confusion between users who might accidentally use the same logon ID. Duplicate logon IDs can easily be intercepted and prevented on a LAN. However, a user on a WAN in San Francisco might unknowingly use the same logon ID as a WAN user in Sydney, Australia. Maintaining user accounts is one of the principal duties of network administrators. ##### Security Limitations of Workgroup Networks There is little distinction between network administrators and users in workgroup environments. Workgroup networks are self-administered; any user can share files located in directories on his or her computer with other members of a workgroup. Workgroups don't maintain user accounts. Therefore, files in any directory that are shared by a user are, by default, "up for grabs" by anyone else who is connected to the network. The user sharing files can restrict other users from modifying the files by sharing the files in read-only mode and can require that workgroup members enter a password to gain access to files in the shared directory. The limited security offered by conventional workgroup networking environments has limited their acceptance by IS departments of large firms. Using the Access database security system with Visual C++ applications (the subject of the next section) can overcome the security limitations of WfWg 3.1+ and Windows 95. The peer-to-peer networking features of Windows NT 3.51 provide an increased level of security compared to that offered by WfWg 3.11 and Windows 95. Windows NT requires that you log on to Windows NT with a user ID and password, whereas logon IDs and passwords are optional for WfWg. If you have administrative authority, you can assign users of individual computers to groups and then grant group authority to share your directories. The normal practice is to create a user group with the same name as the workgroup. If you use the Windows NT file system (NTFS) instead of the DOS file allocation table (FAT) system, you can grant users permissions on a file-by-file basis. The FAT file system, required by dual-boot installations, restricts you to granting permissions to share entire directories. Using predefined groups and creating new groups, as well as granting directory and file permissions to members of groups, are subjects of later sections in this chapter. Windows NT overcomes many of the objections of MIS managers to the lack of security within self-administered networks, but peer-to-peer networking remains a threat to the centralized authority (and in many organizations, the perceived status) of IS departments. The likelihood of a large number of corporate PC clients running Windows NT instead of Windows 95 or WfWg 3.11 (at least in the economic climate that prevailed at the time this book was written) is quite small because of the expense of upgrading PCs to meet the resource requirements of Windows NT. ##### Supplementing Workgroup Security with Access Database Security Features One of the advantages of using Access databases with Visual C++ applications is that you can use the retail version of Access to implement database security with SYSTEM.MDW in addition to restricting access to the DATABASE.MDB file through network security. Access uses the SYSTEM.MDW file to store group names, user IDs, passwords, and SIDs. When you add a new user to an Access security group, you enter the user ID and a four-digit PIN (personal identification number). (The PIN distinguishes between users with the same user ID.) Access combines the user ID and PIN to create an encrypted binary SID (system ID) value that is used by Access .MDB files to identify each user who has permissions for files that exceed the scope of default permissions (also called implicit permissions) granted to the group(s) to which the user belongs. NOTE Access 2 uses SYSTEM.MDA, and Access 7 uses SYSTEM.MDW. Access 7 will use an Access 2 .MDA file, or you can convert the Access 2 .MDA file to an Access 7 .MDW file. Using an Access 2 .MDA file with Access 7 uses more memory than using an .MDW file. Using Access database security features means that at least one individual must be appointed as a database administrator (DBA) to manage the user accounts in the SYSTEM.MDW file that is shared by members of one or more workgroups. You can use a single SYSTEM.MDW file that is shared by all members of all workgroups, or multiple SYSTEM.MDW files, each of which is located in the directory that contains the .MDB file(s) that the workgroup members share. Workgroup members must have read-write access to SYSTEM.MDW so that users can change their password periodically to enhance database security. Thus, if you want to use network security to provide one group of users read-only permissions and to grant another group of users read-write permissions, you should use the single SYSTEM.MDW approach and place SYSTEM.MDW in a directory to which all members of all workgroups have read-write network permissions. Access lets you grant read-only or read-write permissions to groups and individual users for tables in the database; however, members of the User group, by default, have read-write permissions (read data and modify data) on all database tables. You need to explicitly remove write (modify data) permissions for the Users group and then assign write permissions to authorized users. SYSTEM.MDW is the default name for the security library database of Access databases. You can specify a name other than SYSTEM.MDW for the security database, but doing so requires that you use the Change Workgroups application supplied with Access or that you manually edit the SystemDB=d:\path\library.mdw entry in the [Options] section of the MSACCESS.INI file. This line specifies the security library that the retail version of Access attaches to the currently open database. Access database security is modeled on the security system of LAN Manager 2.2 and Windows NT Server, so describing network security before discussing Access database security methodology makes Access's labyrinthine security features a bit more comprehensible. #### Network Administrators, Operators, and Users Windows NT Server has an extraordinary number of predefined groups of administrators and users. Table 19.1 lists the predefined groups that are created when you install Windows NT Server, the groups predefined by Windows NT 3.51 workstations, and the groups of database users defined by Access. The rows in Table 19.1 are ordered by descending level of authority-to-administer and permission-to-use domain resources. The Domain Admins and Domain Users groups are global groups; the remainder of the groups are local to a specific server computer. An N/A entry indicates that the group isn't available in the particular environment. Table 19.1. The authority and permissions of predefined groups.
> Windows NT Server Domains | Windows NT Workstations | Access
> Domain Admins | Administrators | Admins
> Administrators | Administrators | Admins
> Backup Operators | Backup Operators | N/A
> Server Operators | N/A | N/A
> Account Operators | N/A | N/A
> Print Operators | N/A | N/A
> Replicators | N/A | N/A
> N/A | Power Users | N/A
> Everyone | Everyone | N/A
> Domain Users | Users | Users
> Users | Users | Users
> (Guests) | Guests | Guests
> The following list briefly describes the basic categories of predefined groups for Windows NT Server, Windows NT Workgroup, and Access: Administrators: A person with an administrator account on a domain controller is given domain administrator authority as a member of the Domain Admins group. The trust relationship between Windows NT Server domains also lets a domain administrator who has an account with the same authority in another domain administer that domain. This lets a domain administrator in North America administer a domain located in Europe or Asia. Members of the Domain Admins and Administrators groups have the rights and abilities to do anything within the domains and on the servers that are within the scope of their authority. When you install Windows NT Server, you're automatically granted domain administrator authority. Similarly, an administrator of a Windows NT workstation exercises full authority over that workstation. Members of the Access Admins group in a particular SYSTEM.MDW file have full permissions for all objects that were created with the specific SYSTEM.MDW file in use. (The emphasis is added because this is a very important point that is discussed at the end of this chapter.) Admins members can't revoke the permissions of the creator of an object in an Access database, nor is it possible to prevent a user from creating objects in an Access database. Operators: Windows NT Server administrators can delegate some of their responsibilities to members of the Backup, Server, Account, and Print Operators groups. The names assigned to Operators groups imply the scope of authority of members of these groups. There is no equivalent to Operators groups in Windows NT or Access. The Replicators group is used only in conjunction with file replication services. Users: The term users encompasses any group that is not an administrative or operative group. "Everyone" is a special entity that refers to all users, but not to Administrators or Operators. (Operators don't have user privileges.) Special entities also include SYSTEM, NETWORK, INTERACTIVE, and CREATOR OWNER. The CREATOR OWNER entity is equivalent to the Access Creator (object owner) entity. People who simply use the network to get their work done usually are made members of the Users group. Windows NT Workstation's Power Users group has limited administrative authority; this group is designed primarily for establishing and maintaining secure workgroups. Access requires that anyone who opens a secure Access database be a member of the Users group. (Being a member of the Admins group isn't sufficient to open a secure Access database. Members of the Admins group, however, are the only people who can directly modify the SYSTEM.MDW file.) Guests: Guests aren't permitted to do anything at a Windows NT Server computer, including log on to the server (thus the parentheses surrounding Windows NT Server Guests in Table 19.1). Guests are allowed to log on to Windows NT workstations, but they can't participate in any network activities. Access gives Guests read-only permissions for database tables. The Guest user of the Guests group (neither of which you can delete) is used for transitory access to a Windows NT workstation or to Access database applications. The best approach with secure Access databases is to assign a password to the mandatory Guest account and then forget the password. Chapter 3, "How Network Security Works," in the Concepts and Planning Guide for Windows NT Server provides a complete description of the rights and abilities of each predefined group and special entity of Windows NT Server and Windows NT. #### File Permissions Using Windows NT File System Partitions Windows NT Server and Windows NT Workstation directories that are located on fixed-disk partitions formatted as FAT (DOS) partitions can be shared on the network, but you can't control network access to individual files or subdirectories of a shared FAT directory. In order for you to control access to individual files, the files must be located in a directory of an NTFS partition. Only the most courageous early adopters of Windows NT Server are likely to run Windows NT Server itself, which must boot from the C: drive, in an NTFS partition. Most installations are likely to be Windows NT/DOS dual-boot types that use a FAT partition to hold both the DOS and Windows NT operating systems. You can gain the benefits of NTFS for file-sharing operations and NTSQLS databases by establishing one or more logical drives in extended partitions that you format with NTFS. This method was used to create the NTFS E: logical drive on the extended partition of the Darkstar server used in this chapter's examples. You might want to create a separate NTFS logical drive in an extended partition to install NTSQLS. NOTE After you've gained experience with Windows NT Server and are fully confident of its capabilities, you can reformat the FAT partition to NTFS without losing the data that the partition contains by running the CONVERT.EXE application. Make sure you back up the FAT partition before running CONVERT.EXE. You can't change an NTFS partition to a FAT (or HPFS) partition. Instead, you delete the partition, along with all the data on the partition, and then re-create the partition and format it as a FAT (or HPFS) partition. If Windows NT Workstation or Windows NT Server is located on the NTFS partition you want to reformat, you need to run the Windows NT setup application to delete the partition. After you've added the NTFS logical drive (volume), you create the directory structure for the files to be shared by the server. Files in directories and subdirectories on NTFS drives can be assigned one or more of the permissions listed in Table 19.2 for individual users or groups of users. Table 19.2. NTFS file and subdirectory permissions.
> Permission | Abbreviation
> Read | R
> Write | W
> Delete | D
> Execute | X
> Change permission | P
> Take ownership | O
> Table 19.3 lists the standard Windows NT permissions for shared NTFS directories. The Directory column lists the abbreviations of the permissions that apply to the directory itself, and the New Files column lists the abbreviations of the permissions for files that are added to the shared directory after directory-level permissions are granted. Permissions you assign to file and subdirectory shares apply to users who log on to the server itself, as well as to users of workstations. Only members of the Administrators and Operators groups are allowed to log on to the server with Windows NT Server's default security settings. Table 19.3. Standard permissions for shared directories and their files in NTFS partitions.
> Permissions | Directory | New Files | Description
> No access | None | None | The user can't obtain access to the directory or its subdirectories.
> List | RX | N/S | The user can list the files and subdirectories but not read the files.
> Read | RX | RX | The user can read and execute files in the directory (basic read-only access).
> Add | WX | N/S | The user can add and execute files but can't read or change existing files.
> Add and read | RWX | RX | The user can read and execute files in the directory but can't modify files.
> Change | RWXD | RWXD | The user can read, write, and delete files in the directory.
> Full control | All | All | In addition to having change permissions, the user can set permissions for and take ownership of any file in the directory.
> Table 19.4 lists the standard Windows NT permissions and the Access database file permissions applicable to Access Table and QueryDef objects that correspond to the Windows NT file permissions. Permissions that apply to Access forms, reports, macros, and modules aren't applicable to Visual C++ database applications, because they can't access these objects. Table 19.4. Standard permissions for shared files in NTFS partitions and Access database files.
> Permissions | Files | Description | Microsoft Access
> No access | None | The user can't obtain access to the file. | No permissions
> Read | RX | The user can read or execute the file. | Read definitions, read data
> Change | RWXD | The user can read, write, or delete the file. | Read definitions, read data, modify data
> Full control | All | The user can read, write, delete, set permissions for, or take ownership of the file. | Full permissions (includes modify definitions)
The Windows NT File Manager is similar to that of WfWg 3.11, except an additional toolbar button with a key icon lets you set file permissions for individual files on NTFS volumes. To assign permissions for a file or a group of files, select the file(s) in File Manager's window and then click the File Permissions button to display the File Permissions dialog box. Click the Add button to display the Add Users and Groups dialog box. Figure 19.16 shows the Add Users and Groups dialog box for file permissions. Double-click the names of the existing groups for which you want to assign permissions to add the name of the group to a semicolon-separated list in the Add Names text box. If you want to add an individual user to the list, select the group to which the user belongs and click the Show Users button to display a list of users in the group. Figure 19.16. The Add Users and Groups dialog box of Windows NT Server. A full description of Windows NT Workstation and Windows NT Server share security for both FAT and NTFS partitions is provided in Chapter 5, "Managing Network Files," of the Windows NT Server Concepts and Planning Guide. ### Fathoming the Access Security System The Access database security system has been called labyrinthine, Byzantine, and even Machiavellian. As noted earlier in this chapter, Access's security methodology is derived from a mixture of LAN Manager, SQL Server, and Windows NT security techniques. If you decide to implement Access security in conjunction with Visual C++ database applications, or your Visual C++ database applications share secure .MDB files with Access applications, you need to have a fundamental understanding of how Access implements security for Table and QueryDef objects. You don't need to worry about security issued for other Access objects, forms, reports, macros, and modules, because Visual C++ applications don't recognize these objects. WARNING Before you use any Access security features that are discussed in the following sections, make a backup copy of the SYSTEM.MDW file in the \ACCESS directory and back up any .MDB files that have permissions you plan to modify. If you haven't made any changes to the default values in the SYSTEM.MDW file that was installed when you set up Access, make a copy of the SYSTEM.MDW file on a disk and save it for future use as the base SYSTEM.MDW file for creating new applications. #### Assigning Access User Accounts and Securing Access Databases When you first launch Access, you're assigned a default user ID of Admin, a member of Access's Admins group, with an empty password. This combination of user ID and empty password prevents Access's Logon dialog box, shown in Figure 19.17, from appearing when you launch Access. If the Logon dialog box appears when you launch Access, you have the beginnings of a secure database system. (This statement assumes that unauthorized users don't know the valid user ID and password combinations contained in SYSTEM.MDW.) Figure 19.17. Access's Logon dialog box. To initiate database security with Access, you need to add a new user ID and assign the new user account membership in the Admins group. After you add the new member of the Admins group and take ownership of the objects in the database(s) you intend to secure, you can delete the default Admin user account (if other Access .MDB files don't depend on the presence of the Admin user). Follow these steps to secure Access so that only DBAs can launch Access: Launch Access and open any .MDB file (NorthWind.MDB is a good choice) so that the Security menu bar appears. (You can't enter Access's security subsystem without opening a database.) Choose Security | Users to display the Users dialog box. Click the Add button to display the New User/Group dialog box. Type the new Admins user ID in the Name text box and add a four-digit PIN (personal identification number) in the Personal ID Number text box, as shown in Figure 19.18. (Access user IDs aren't case-sensitive.) Figure 19.18. The Users and New User/Group dialog boxes of Access's security system. Click the OK button of the New User/Group dialog box to close it. Access automatically makes the new user a member of the Users group. Select Admins in the Available Groups list box and click the Add button to add the new user to the Admins group. The Users dialog box now appears, as shown in Figure 19.19. (This is the first critical step in the process. The new user must be a member of both the Admins and Users groups.) Click the Close button to complete the record for the new user's account and close the Users dialog box. Figure 19.19. The Users dialog box after you add a new Admins user. Choose Security | Change Password to display the Change Password dialog box, shown in Figure 19.20. You need to add a password for the Admin user so that the Logon dialog box appears when you next launch Access. (This is the second critical step.) Note that you are still logged on to Access as Admin. Tab past the Old Password text box (to indicate an empty password for the Admin user). Type a password for the Admin user in the New Password text box and type the password again for confirmation in the Verify text box. (Access passwords are case-sensitive.) Figure 19.20. Access's Change Password dialog box. Click the OK button to close the Change Password dialog box and exit Access. Relaunch Access. If you followed the instructions in step 7, the Logon dialog box will appear. Enter your new user ID in the Name text box and click the OK button. (You haven't yet assigned a password to the new user account.) Open a database file. Choose Security | Change Password and repeat steps 7 and 8. The password you choose for your new Admins account should contain at least eight characters and should have a combination of letters and numbers. Using a combination of upper- and lowercase letters provides even better password security. Relaunch Access and enter your new user ID and the new password. You can inspect the contents of the SYSTEM.MDW file at this point by following these steps: Use File Manager to create a copy of SYSTEM.MDW as SYSTEM.MDB. (You can't open SYSTEM.MDW because it's attached as a library database to the currently open database.) Choose View | Options to display the Options dialog box. Change the value of the Show System Objects property in the default General options category to Yes and click the OK button to close the Options dialog box. The system tables that begin with the prefix "MSys" now appear in the Table list box of the Database window. Double-click the MSysAccounts table to display its contents, as shown in Figure 19.21. Figure 19.21. The contents of the MSysAccounts table with a single new user added. Records in MSysAccounts with a value of –1 (TRUE) in the FGroup field are group accounts. The Engine and Creator accounts are entity accounts corresponding to Windows NT Server's SYSTEM and CREATOR OWNER entities, respectively. You can't delete the Engine, Creator, or guest account. Values in the Password and SID fields are encrypted for security purposes. WARNING You might be tempted at this point to delete the Admin account. The Access documentation recommends that you delete the Admin user at this point. Don't do it. The next section explains why you shouldn't delete the default Admin user now. #### Securing Existing Database Files At this point, Access is secure, and any new Access databases you create also will be secure. Henceforth, your new user ID is the owner of any new database objects you create. However, no Access database objects that you and others created with the Admin account (using the blank password) are secure. The reasons are as follows: The Admin user is the owner (the "creator" in Access) of all objects in every database you or others created using the Admin account, as well as the sample databases supplied with Access. No user, including the Admin user, has the authority to revoke the object owner's permissions. By default, the owner of an object has full permissions for the object. The SID (system ID) of the default Admin user is created by combining the user name and company name (if any) you entered when you installed Access and then encrypting the combination. SETUP.EXE imprints setup disk 1 with your user name and company name. (Both names are encrypted on the disk.) Anyone who gains possession of your Access setup disks can install a bootleg copy of Access that creates a SYSTEM.MDW file with the same SID that you (and possibly others) used to create database objects until you (and others) logged on with new user IDs and passwords. The user with the bootleg copy of Access has full permissions for every database object in every unsecure database. You do not delete the Admin user at this point because it's possible that something could be wrong with your new account in the Admins group. If this is the case, you wouldn't be able to secure the database with the process described in the following steps. (To solve this problem, relaunch Access and log on as the Admin user and make sure that the Admins group has full permissions for all objects in the database. Delete the newly added account and create another new user ID with membership in the Admins group.) To secure database objects that have a creation date that precedes the time when you secured Access, you need to take ownership of the database objects by importing the objects into a new database file. To assume ownership of objects in existing Access databases, follow these steps: Launch Access with your new user ID and password and choose File | New Database to open the New Database Wizard. Select Blank Database in the General tab and click OK. Type a name for the new database in the File Name text box and click the Create button to create the new database. Choose File | Get External Data | Import to display the Import dialog box. Search for the database in which you're going to take ownership of objects, and click the Import button. For this example, you will use the NorthWind.MDB database. Select one or more Tables, and any other object that you want to import, from the Objects dialog box, as shown in Figure 19.22, and then click the OK button to import the table into your new database. (Make sure that the default Definition and Data option button is selected before you click the Import button.) Figure 19.22. The Import Objects dialog box for Table objects in NorthWind.MDB. Access confirms that the tables (and other selected objects) have been imported by listing them in the NewDatabase window, as shown in Figure 19.23. Figure 19.23. Successful importation of an Access object. After you've imported all the objects into the new database, inspect the Table, QueryDef, and any other imported Access objects to make sure that the objects imported properly. Make a backup copy of the original database and then delete the original database and rename the new database to that of the original. You now have a secure database in which you are the undisputed owner of all the database objects. If Microsoft had made the take ownership (O) permission of Windows NT applicable to Access database objects, the transfer of title would be a much simpler process. #### Granting and Revoking Access Permissions for Groups and Users By default, Access grants full permissions on all Table and QueryDef objects to members of the Users group. Granting full permissions by default to the Users group has been the subject of many complaints from Access developers. It's unlikely that you want everyone who can open the database to have read-write access to all or even any of the tables in the database. This is especially true of databases that are the source of data for decision-support applications. (One of the Canons of Database Administration is this: I shall grant no one with a title other than Data Entry Operator or Data Entry Supervisor read-write privileges in my databases.) Because all except the Guest user of Access databases must be a member of the Users group, you need to revoke modify data privileges from the Users group and create a new group, DataEntry, that has both read data and modify data privileges. (Everyone with access to the database should be granted read definitions privileges.) ##### Revoking Permissions from the User Group To revoke modify definitions and modify data permissions from the Users group for objects in your databases, follow these steps: Open the database that has permissions you want to modify and choose Security | Permissions to open the Permissions dialog box. The first Table object in the database is the default object. Click the Groups option button in the List group to display groups instead of users in the Name combo box. Select Users from the Name combo box. Click the Modify Definitions and Modify Data check boxes to clear the check marks, as shown in Figure 19.24. Figure 19.24. Revoking modify definitions and modify data permissions from the Users group for a database object. Click the Assign button to make the revocation of modify definitions and modify data permissions permanent. Choose the remaining objects in the database and repeat steps 3 and 4 to revoke the write permissions for each object. When you've completed this tedious operation, click the Close button to return to Access's main window. Members of the Users group no longer have default (implicit) permissions to modify the design of tables or queries, or to update tables in this database. You can give specific members of the Users group modify data permission by listing users instead of groups, selecting the user from the combo box, and clicking the Modify Data check box. Implicit permissions of users inherited from group membership don't appear in the check boxes when you display individual user permissions. (This is a peculiarity of the Access security system.) ##### Creating a New Access Group and Assigning Group Permissions Follow these steps to create a new DataEntry user group and set up the correct permissions for the new group: Open one of the databases that you want to make available for updating by members of the DataEntry user group. Choose Security | Groups to open the Groups dialog box. Click the New button to open the New User/Group dialog box, shown in Figure 19.25. Type the name of the new group (DataEntry) in the Name text box and type a PIN for the group in the Personal ID Number text box. Figure 19.25. Creating a new Access group. Click the OK button to close the New User/Group dialog box. Click the OK button of the Groups dialog box to close it. Perform steps 2 through 6 of the preceding section, with the following exceptions: Select the DataEntry group in step 2 and remove only the check mark in the Modify Definitions check box in step 3 so that members of the DataEntry group can update tables in the database. ### Summary This chapter covered a great deal of territory, from an elementary description of PC networking systems to the intricacies of security management with Windows NT Server to creating Access databases that have both network and internal security. Although this chapter could have been divided into two chapters that separately discussed networking and Access security topics, the relationships described between network and Access security methodology are an aid to a better understanding of Access's security features. The next chapter delves into the issues you face when you create front ends for client-server RDBMSs instead of desktop databases. The Microsoft ODBC API and SQL Server 4.21 for Windows NT running under Windows NT Server are used for the sample applications in Chapter 20. Contact reference@earthweb.com with questions or comments. Copyright 1998 EarthWeb Inc., All rights reserved. PLEASE READ THE ACCEPTABLE USAGE STATEMENT. Copyright 1998 Macmillan Computer Publishing. All rights reserved. |