Layered Network Services

[Previous] [Next]

Windows 2000 includes network services that build on the APIs and components we've presented in this chapter. Describing the capabilities and detailed internal implementation of these services is outside the scope of this book, but this section provides a brief overview of remote access, Active Directory, Network Load Balancing, File Replication service (FRS), and Distributed File System (DFS). In addition, Windows 2000 supports several services that are based on extensions to the TCP/IP protocol. These include network address translation (NAT), Internet Protocol security (IPSec), and Quality of Service (QoS), and we conclude with a look at each.

Remote Access

Remote access, which is available with Windows 2000 Server, allows remote access clients to connect to remote access servers and access network resources such as files, printers, and network services as if the client were physically connected to the remote access server's network. Windows 2000 provides two types of remote access:

• Dial-up remote access is used by clients that connect to a remote access server via a telephone or other telecommunications infrastructure. The telecommunications medium is used to create a temporary physical or virtual connection between the client and the server.
• Virtual private network (VPN) remote access lets a VPN client establish a virtual point-to-point connection to the server over an IP network such as the Internet.

Remote access differs from remote control solutions because remote access acts as a proxy connection to a Windows 2000 network, whereas remote control software executes applications on a server, presenting a user interface to the client.

Active Directory

Active Directory is the Windows 2000 implementation of Lightweight Directory Access Protocol (LDAP) directory services. Active Directory is based on a database that stores objects representing resources defined by applications in a Windows 2000 network. For example, the structure and membership of a Windows 2000 domain, including the user account and password information, are stored in Active Directory.

Object classes and the attributes that define properties of objects are specified by a schema. The objects in the Active Directory schema are hierarchically arranged, much like the registry's logical organization, where container objects can store other objects, including other container objects. (See Chapter 8 for more information on container objects.)

Active Directory supports a number of APIs that clients can use to access objects within an Active Directory database:

• The LDAP C API is a C language API that uses the LDAP networking protocol. Applications written in C or C++ can use this API directly, and applications written in other languages can access the APIs through translation layers.
• Active Directory Service Interfaces (ADSI) is a COM interface to Active Directory that abstracts the details of LDAP programming. ADSI supports multiple languages, including Microsoft Visual Basic, C, and Microsoft Visual C++. ADSI can also be used by Microsoft Windows Script Host (WSH) applications.
• Messaging API (MAPI) is supported for compatibility with Microsoft Exchange client and Outlook Address Book client applications.
• Security Account Manager (SAM) APIs are built on top of Active Directory to provide an interface to logon authentication packages such as MSV1_0 (\Winnt\System32\Msv1_0.dll, which is used for legacy NT LAN Manager authentication) and Kerberos (\Winnt\System32\Kdcsvc.dll).
• Windows NT 4 networking APIs (Net APIs) are used by Windows NT 4 clients to gain access to Active Directory through SAM.

Active Directory is implemented as a database file that is named \Winnt\Ntds\Ntds.dit, and that is replicated across the domain controllers in a domain. The Active Directory directory service, which is a Win32 service that executes in the Local Security Authority Subsystem (Lsass) process, manages the database, using DLLs that implement the on-disk structure of the database as well as provide transaction-based updates to protect the integrity of the database. The Active Directory database store is based on a version of the Extensible Storage Engine (ESE) database that is used by Microsoft Exchange Server version 5.5 client/server messaging and groupware. Figure 13-21 shows the Active Directory architecture.

Figure 13-21 Active Directory architecture

Network Load Balancing

As we stated earlier in the chapter, Network Load Balancing, which is included with Windows 2000 Advanced Server, is based on NDIS intermediate-driver technology. Network Load Balancing allows for the creation of a cluster containing up to 32 computers, which are called cluster hosts in Network Load Balancing. The cluster maintains a single virtual IP address that is published for access by clients, and client requests go to all the computers in the cluster. However, only one cluster host responds to the request. The Network Load Balancing NDIS drivers effectively partition the client space among available cluster hosts in a distributed manner. This way, each host handles its portion of incoming client requests and every client request always gets handled by one and only one host. The cluster host that determines it should handle a client request allows the request to propagate up to the TCP/IP protocol driver and eventually a server application; the other cluster hosts don't. If a cluster host fails, the rest of the cluster realizes that the cluster host is no longer a candidate for processing requests and redistributes the incoming client requests to the remaining cluster hosts. No new client requests are sent to the downed cluster host. Another cluster host can be added to the cluster as a replacement, and it will then seamlessly start handling client requests.

Network Load Balancing isn't a general-purpose clustering solution because the server application that clients communicate with must have certain characteristics: the first is that it must be TCP/IP-based, and the second is that it must be able to handle client requests on any system in a Network Load Balancing cluster. This second requirement typically means that an application that must have access to shared state in order to service client requests must manage the shared state itself—Network Load Balancing doesn't include services for automatically distributing shared state across cluster hosts. Applications that are ideally suited for Network Load Balancing include a Web server that serves static content, Windows Media Server, and Terminal Services. Figure 13-22 shows an example of a Network Load Balancing operation.

Figure 13-22 Network Load Balancing operation

File Replication Service

File Replication service (FRS) is included with Windows 200 Server. Its primary purpose is to replicate the contents of a domain controller's \SYSVOL directory, which is where Windows 2000 domain controllers store logon scripts and group policies. (Group policies permit administrators to define usage and security policies for the computers that belong to a domain.) In addition, FRS can be used to replicate Distributed File System (DFS) shares between systems. FRS allows for distributed multimaster replication, which enables any server to perform replication activity. When a replicated directory or file is changed, the changes are propagated to the other domain controllers.

The fundamental concept in FRS is a replica set, which consists of two or more systems that replicate between themselves the contents of a directory tree according to an administratively defined schedule and topology. Only directories on NTFS volumes can be replicated because FRS relies on the NTFS change journal to detect changes to files in directories in a replica set. Because FRS is based on multimaster replication, it can theoretically support hundreds or even thousands of systems as part of a replica set, and the computers of a replica set can be connected with arbitrary network topologies (such as ring, star, or mesh). Computers can also be members of multiple replica sets.

FRS is implemented as a Win32 service (\Winnt\System32\Ntfrs.exe) that uses authenticated RPC with encryption to communicate between instances of itself running on different computers. In addition, because Active Directory contains its own replication capabilities, FRS uses Active Directory APIs to retrieve FRS configuration information from a domain's Active Directory.

Distributed File System (DFS)

Distributed File System (DFS) is a service that layers on top of the Workstation service to connect together file shares into a single namespace. The file shares can reside on the same or on different computers, and DFS provides client access to the resources in a location-transparent manner. The root of a DFS namespace must be a file share defined on a Windows 2000 server.

In addition to delivering a unified network-resource namespace, DFS provides other benefits through DFS replica sets, which are based on FRS replica sets. An administrator can create DFS replica sets from two or more shares so that FRS copies data between the shares of a replica set to keep their contents synchronized. DFS provides a limited form of load balancing by randomly selecting a member of a replica set to fulfill a client request for data on the replica set. In addition, DFS achieves high availability by routing requests to the working member or members of a replica set when a member becomes unavailable.

The components that make up the DFS architecture are shown in Figure 13-23. The server-side implementation of DFS consists of a Win32 service (\Winnt\System32\Dfssvc.exe) and a device driver (\Winnt\System32\Drivers\Dfs.sys). The DFS service is responsible for exporting DFS topology management interfaces and maintaining the DFS topology in either the registry (on non-Active Directory systems) or Active Directory. The DFS driver performs topology lookups when it receives a client request so that it can direct the client to the system where the file it is requesting resides.

Figure 13-23 DFS components

On the client side, the implementation of DFS relies on support from the MUP driver and the NetWare and CIFS redirector. When a client issues a file I/O request that specifies a file in the DFS namespace, the MUP driver on the client communicates with a DFS server by using the appropriate redirector.

TCP/IP Extensions

Other Windows 2000 networking services extend basic networking features of the TCP/IP protocol driver by relying on add-on drivers that integrate with the TCP/IP protocol driver using private interfaces. These include network address translation (NAT), Internet Protocol security (IPSec), and Quality of Service (QoS).

Network Address Translation

Network address translation (NAT) is a routing service that allows multiple local IP addresses to map to a single IP address. Without NAT, each computer of a LAN must be assigned a public IP address to communicate across the Internet. NAT allows one computer of the LAN to be assigned an IP address and the other computers to be connected to the Internet through that computer. NAT translates between LAN addresses and the public IP address as necessary, routing packets from the Internet to the appropriate LAN computer.

NAT components on Windows 2000 consist of a NAT device driver that interfaces with the TCP/IP stack as well as editors that an administrator uses to define address translations. NAT can be installed as a protocol with the Routing And Remote Access MMC snap-in or by configuring Internet connection sharing using the Network And Dial-Up Connections tool (though NAT is much more configurable when installed using the Routing And Remote Access MMC snap-in).

Internet Protocol Security

Internet Protocol security (IPSec), which is integrated with the Windows 2000 TCP/IP stack, provides protection for IP data against snooping and manipulation and defends against IP-based attacks. Both goals are met through cryptography-based protection services, security protocols, and dynamic key management. IPSec-based communication includes these properties:

• Authentication verifies the origin and integrity of an IP message.
• Integrity protects IP data from being modified in transit without being detected.
• Confidentiality uses encryption to ensure that only valid recipients of a message can decipher the contents of the message.
• Antireplay ensures that each packet is unique and can't be reused. This property prevents a snooper from replying to captured messages to establish a session or gain unauthorized access to data.

IPSec on Windows 2000 relies on group policies that are stored in Active Directory for configuration, and it uses Active Directory's Kerberos version 5 authentication to authenticate computers that participate in IPSec message exchange. IPSec uses private/public keys pairs based on the Windows 2000 CryptoAPI certificate services for encrypting and decrypting IPSec message data and passwords as part of its authentication process. (See the section "Encrypting File System Security" in Chapter 12 for more information on CryptoAPI.)

IPSec's implementation consists of an IPSec device driver (\Winnt\System32\Drivers\Ipsec.sys) that integrates with the TCP/IP protocol driver. In user space, a policy agent obtains IPSec configuration information from Active Directory and passes IPSec filtering information (IP address filters for which IPSec communications should be used) to the IPSec driver and security settings to an Internet Key Exchange (IKE) module. The IKE module waits for security association requests from the IPSec driver and negotiates the requests, passing the results back to the IPSec driver for use during authentication and encryption.

Quality of Service

If no special measures are taken, IP traffic is delivered over a network on a first-come-first-serve basis. Applications have no control over the priority of their messages and can experience bursty network behavior, where they occasionally obtain high throughput and low latencies but otherwise receive poor network performance. Although this level of service is acceptable in most situations, an increasing number of network applications demand more consistent service levels, or Quality of Service (QoS) guarantees. Video conferencing, media streaming, and enterprise resource planning (ERP) are examples of applications that require good network performance. QoS allows an application to specify minimum bandwidth and maximum latencies, which can be satisfied only if every networking software and hardware component between a sender and receiver supports QoS standards such as IEEE 802.1p, an industry standard that specifies the format of QoS packets and how OSI layer 2 devices (switches and network adapters) respond to them.

Windows 2000 QoS support is based on a handful of Microsoft-defined Winsock APIs that allow an application to request QoS for traffic over their Winsock sockets. For example, an application uses WSCInstallQOSTemplate to install a QoS template that specifies desired bandwidth and latency. (Only applications with administrative privileges can use QoS.) A second API, the traffic control (TC) API, lets an administrative application more precisely control the traffic flow over networks attached to the computer.

The heart of the Windows 2000 QoS implementation is the Resource Reservation Setup Protocol (RSVP) Win32 service (\Winnt\System32\Rsvp.exe), as shown in Figure 13-24. The RSVP Winsock service provider (\Winnt\System32\Rsvp.dll) communicates application QoS requests via RPC to the RSVP service. The RSVP service in turn uses the TC API to control traffic flow. The TC API, which is implemented in \Winnt\System32\Traffic.dll, sends I/O control commands to the Generic Packet Classifier (GPC) driver (\Winnt\System32\Drivers\Msgpc.sys). The GPC driver communicates closely with the QoS packet scheduler NDIS intermediate driver (\Winnt\System32\Drivers\Psched.sys) to control the flow of packets to the network from the computer so that the QoS levels promised to particular applications can be met and to ensure that appropriate QoS headers can be placed on packets for which QoS is desired.

Figure 13-24 QoS architecture