SQL Server Magazine

When you think of network-management tools, products such as HP's OpenView or IBM's NetView usually come to mind. These products monitor and maintain configuration information for network devices such as hubs, switches, and routers. Network-management tools usually rely on Simple Network Management Protocol (SNMP) agents, running on these managed devices to provide information to the management console or server. However, few of these tools provide visibility above the Open Systems Interconnection (OSI) network layer of services; instead, they must rely on the individual vendors of those services to provide for management. Windows NT 5.0 steps in to fill this network-management role.

NT 5.0 provides many enhanced and new network services to support and improve the functionality of your Microsoft and non-Microsoft distributed infrastructure. Enhanced services include Dynamic Host Configuration Protocol (DHCP), Windows Internet Naming Service (WINS), and Domain Name System (DNS). New to NT 5.0 are the IP Security (IPSec) standards for authentication, integrity, and encryption of network-layer traffic, and Quality of Service (QoS) support within the network stack and Active Directory (AD). You can think of network-management capabilities in NT 5.0 as network services management rather than as traditional network management. The primary difference between traditional network management and the network services management in NT 5.0 is that NT 5.0's network services tools don't provide the robust enterprise-level monitoring, alerting, and reporting of network devices that a true network-management tool does. However, NT 5.0's tools provide a primary interface for configuration, management, and some monitoring of the network services NT 5.0 provides. In this article, I'll guide you through some of the new and enhanced network services in NT 5.0, and I'll give you a glimpse of the tools you'll use to manage those services.

What's New for Network Management in NT 5.0
Microsoft built many new and advanced networking features into NT 5.0 Server and Workstation. Two of these features are QoS support and the IPSec protocol. (To learn more about QoS, see Tao Zhou, "Build a Better Network with QoS," page 127. To learn more about IPSec, see Tao Zhou, "Internet Protocol Security in NT 5.0," August 1998.)

QoS. QoS is a way of guaranteeing available bandwidth on a per-connection basis and is most frequently associated with multimedia applications or applications that require predictable near- realtime delivery. QoS encompasses a set of industry-standard protocols and requires the participation of your NT 5.0 server and intermediate network devices such as switches or routers. NT 5.0's Admission Control Service (ACS) is Microsoft's part of the QoS equation. The ACS resides on an NT 5.0 server but must be available on each subnet for which you want to provide QoS. If you have five subnets, you'll need either one ACS server for each subnet or one ACS server with five NICs—one NIC to connect to each subnet. But, as I mentioned, the ACS server is only part of the equation. To fully implement QoS, you also need applications that can request a minimum amount of bandwidth. If your network uses routers and switches, those devices must be able to allocate the necessary bandwidth or prioritize traffic within their queues for a given request. Your network devices must also support the Resource Reservation Protocol (RSVP)—an Internet Engineering Task Force (IETF) standard for maintaining a QoS path through your network from a client to a server. You can think of RSVP as its name implies—a reservation for bandwidth at each network device between client and server. The ACS server is the first stop in this reservation process. A server application that requires guaranteed bandwidth contacts the ACS server and communicates its needs. The ACS server sends the bandwidth request through the network to client applications that want to communicate with the server. A client sends its reservation to the server, and communication begins.

ACS offers the ability to differentiate bandwidth allocation based on a specific user, whether you define the criteria for allocation within AD or for outside parties requiring use of your network. Using the ACS management snap-in for the Microsoft Management Console (MMC), you can define bandwidth requirements for the subnet to which your server is connected, and you can define policy for the server based on user accounts, as Screen 1 shows.

IPSec. Support for IPSec is another key network service NT 5.0 provides. IPSec lets you specify authentication and encryption of network communications between a set of defined network devices to ensure privacy. Because IPSec works at the network layer, it doesn't require special modifications to your applications.

To implement IPSec in NT 5.0, you first must define a set of IP security policies. You do so through NT 5.0's IPSec MMC snap-in. These policies define different IPSec profiles you can create to enforce different security requirements. An IPSec policy contains several setting options. The first option is the creation of IP filter lists. These lists let you define groups of machines or subnets and specify which IP protocols and ports will be subject to IPSec. For example, you can create a filter list that specifies the use of IP security between all machines on subnet 192.168.100.0 and all machines on subnet 192.168.101.0 when they are communicating over TCP from any TCP port to TCP port 25 (Simple Mail Transfer Protocol—SMTP—mail). After you create a filter list, you define a negotiation policy. The negotiation policy lets you define how two communicating computers talk to each other. For example, you can specify algorithms that apply varying levels of data integrity and confidentiality. In addition to negotiation policy, you can specify which protocols to use for authentication of the IPSec connection, whether to use an IP tunnel for a given IPSec policy, and what types of connections to apply the policy to (e.g., dial-up or LAN). Screen 2 shows a security policy I set up that requires the use of IPSec for all traffic going to TCP port 25 between two subnets on my network.

After you define an IPSec policy, you can manage it centrally if you install AD within your NT infrastructure. Specifically, the Group Policy feature in AD includes support for security policies. You can include your predefined IPSec policy within a Group Policy Object (GPO) that you create. Because you can apply GPOs at the site, at the Organizational Unit (OU), or at the domain level, you can deliver IPSec policy based on a computer's or user's placement within AD. For example, if you want to apply your IPSec policy to a user in the Engineering OU, you can include that policy in the GPO for the Engineering OU. Doing so guarantees that all traffic to and from that user is subject to your IPSec policy, regardless of the workstation used.

   Prev. page   [1] 2 3     next page