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.
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 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 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 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:
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 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.
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 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:
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.
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):
For Windows 95, you should follow these steps:
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.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.
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:
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.
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 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.
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:
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:
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 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 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:
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.
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.
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.
The following four types of hardware devices commonly are employed in LANs and WANs and to connect to mainframe computers:
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.
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.
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 operations are divided into the following two basic categories:
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.
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.
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.
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.
| 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:
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.
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.
| 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.
| 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.
| 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.
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.
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:
Figure 19.19. The Users dialog box after you add a new Admins user.
You can inspect the contents of the SYSTEM.MDW file at this point by following these steps:
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.
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:
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:
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.
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.)
To revoke modify definitions and modify data permissions from the Users group for objects in your databases, follow these steps:
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.)
Follow these steps to create a new DataEntry user group and set up the correct permissions for the new group:
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.
