Exam 70-221 - Designing a Windows 2000 Network Infrastructure

Overview

Deployment cycle

Design

Where decisions are made. Requires knowledge of existing network infrastructure and organizational goals. You will need to choose which services to implement and how to combine them to increase performance and simplify management. Also designed at this stage is the management strategy, which specifies how the network will be managed on a day-to-day basis.

Implement

Takes place after the network design has been properly tested. The network is configured as specified in the design, and monitoring is setup to collect data on its performance.

Manage

Using the performance data you have collected bottlenecks are identified and removed to enable changes needed to maintain the network within design specifications.

Organizational goals to include in a design

Important building blocks

TCP/IP

This is an open, industry-standard, and routable protocol. It is required for many essential Windows 2000 network services such as DHCP, WINS, DNS, and Active Directory. TCP/IP should be used in heterogeneous environments and whenever Internet connectivity is called for as part of the design.

DNS

Domain Name Service - resolves fully qualified domain names (FQDN) to IP addresses. Allows network admins to assign “people-friendly” names to network resources. Windows 2000 Active Directory is based entirely on the hierarchical structure of the DNS namespace.

DHCP

Dynamic Host Configuration Protocol - used to dynamically assign Internet Protocol (IP) addresses to clients and reduce administrative overhead in managing and maintaining a TCP/IP-based network.

WINS

Windows Internet Name Service - a NetBIOS name service that resolves NetBIOS names to IP addresses in a Windows network. Required for Windows 3.11/95/98/NT4 clients that do not have the Active Directory client installed.

MS Proxy Server 2.0 (KB# Q164084)

This is a combination firewall/proxy server product that provides security by allowing organizations to control the exchange of data between the Internet and their private network. Can also be used to improve the performance of Internet access through its content caching features. It is extremely scalable and suitable for enterprise type deployment within an organization.

NAT

Network Address Translation – a protocol found in Routing and Remote Access Services (RRAS) in Windows 2000. Used to provide Internet connectivity in simple network environments where all machines are on a single subnet. Provides some security.

IP Routing

Windows 2000 RRAS supports both static and dynamic routing protocols. Connections over non-persistent links are supported through demand-dial routing.

Remote Access

Used to allow remote users access to a private network. Can include dial-up connections over the regular telephone system and also Virtual Private Network (VPN) connections over the Internet.

RADIUS

Remote Authentication Dial-In User Service - provides authorization, authentication, and accounting services for distributed dial-up networks. Used in conjunction with RRAS and IAS (Internet Authentication Service).

TCP/IP

IP addressing and subnetting: (KB# Q186341 & RFCs: 950, 1518, 1519, 1812, & 1878)

Public addressing schemes

All hosts connected to the public Internet require a globally unique IP address. Any network connected to the Internet must have a minimum of one public IP address for connectivity. Used when the organization has a large number of hosts requiring direct Internet access and there is a sufficient pool of registered addresses to work from. Public addressing schemes are expensive and limit network growth as once all available addresses have been exhausted, no new devices can be added to the network unless more IP addresses are purchased.

Private addressing schemes: (RFC 1918)

Used when most hosts do not require direct Internet access and/or when there are insufficient public addresses available. Special ranges of addresses are used for private addressing which are not routable on the public Internet (see table below). This is the most inexpensive route to go and it provides nearly unlimited network growth.

A NAT device must be installed to pass traffic from the private network to the public network and vice versa. The NAT device must have one valid public IP address and one private IP address assigned to it. (KB# Q243078)

Subnet limitations

Analyze the network bandwidth to ensure it meets design considerations. If the current subnets are congested with traffic consider increasing the number of subnets.

In an IP-routed network you must consider the number of hosts in each subnet as well as the number of subnets. When the network is IP-switched you need to design for the number of WAN connections only.

Always allow for future growth when designing subnetting schemes.

Subnets and Active Directory

In Windows 2000, domain controllers in the same subnet are automatically made part of the same site. When you move domain controllers between sites you are actually moving them between subnets. When designing your replication topology, you must consider how your subnets will affect Active Directory replication.

Classless Interdomain Routing (CIDR): (RFC 1519)

CIDR was created several years ago to help prevent the Internet from running out of IP addresses. The "Class" system of allocating IP addresses was very wasteful; organizations demonstrating a need for more that 254 host addresses were assigned a Class B address block of 65533 host addresses. Even more wasteful were companies and organizations that were allocated Class A address blocks, containing over 16 Million host addresses! Only a small percentage of the allocated Class A and B address space has ever been assigned to a host computer on the Internet.

It was determined that IP addresses could be conserved if the original class system was eliminated. By allocating only the amount of address space that was actually needed, the address space crisis could be avoided for many years. This was first proposed in 1992 as a standard called “Supernetting.”

Under supernetting, the classed subnet masks are extended (or made classless), so that a network address and subnet mask could, for example, specify multiple Class C subnets with one address. For example, if 1000 addresses are required, supernetting four Class C networks together will provide the necessary solution.

When supernetting an address range, treat all the classes of the addresses being combined into a subnet as Class A. Then use whatever method is preferable to determine the appropriate subnet mask.

Other design considerations

Automatic Private IP Addressing (APIPA) is used for TCP/IP address configuration for hosts on a single subnet without a DHCP server. Allocated from 169.254.x.x/16 as specified by IANA. (KB# Q220874 & Q255836)

Some IP traffic such as streamed multimedia is considered “time-sensitive” and requires that bandwidth is reserved for it. The Quality of Service (QoS - bandwidth management) mechanisms built into Windows 2000 allow administrators to prioritize network traffic. (KB# Q233203 & Q233039)

Performance and availability considerations

• Authentication, logon and encryption traffic are delay and latency sensitive. It may be necessary to place necessary services on both sides of a link exhibiting latency to prevent a disruption in service.

• Increasing the TCP/IP Receive Windows Size through a registry modification may help alleviate problems with network delay. (KB# Q199947)

• If packet loss is high, check your network for router congestion.

• Combine IP ranges by supernetting. Proper use of supernetting reduces routing issues.

• Use variable length subnetting to divide IP ranges. The subnet mask is adjusted in a hierarchical fashion to accommodate a varying number of hosts in each subnet. Keep the number of routers in the hierarchy to a minimum. Routers that support RIP for IP v2, BGP, and OSPF will support variable length subnetting.

• Route cost metrics should be set equally when there is no cost difference between them.

• Higher cost metrics should be assigned to demand-dial links that are backups to less expensive persistent links.

• Place redundant links and routers between locations where high availability is needed. This improves bandwidth performance as well as availability.

Security considerations

Packet filtering

Data and connection security is provided through TCP/IP packet-level filtering (KB# Q259605). TCP/IP filtering allows you to block inbound traffic to any address that does not appear on your exceptions list, limit traffic to dedicated servers, and filter at the application layer. IP packets can be filtered by their protocol type (except for IPSec, ICMP, IGMP, TCP and UDP) and TCP/UDP port number.

IPSec Overview (KB# Q231585, Q252735, Q253169, & RFC 2401)

IPSec itself is a protocol, not a service. It consists of two separate protocols: Authentication Headers (AH) and Encapsulated Security Payload (ESP). AH provides authentication, integrity and anti-replay. It does not encrypt data, but is used when a secure connection is needed but the data itself is not sensitive. ESP provides the aforementioned plus confidentiality (data encryption). It is used to protect sensitive or proprietary information, but is associated with greater system overhead for encrypting and decrypting data.

IPSec can be implemented in a Windows 2000 domain using Active Directory or on a Windows 2000 machine using its Local Security settings. It is not available for Windows 95/98 or Windows NT.

Supported IPSec authentication methods are Kerberos v5 Public Key Certificate Authorities, Microsoft Certificate Server, and Pre-shared Key. (KB# Q240262)

The IPSec Policy Agent is a Windows 2000 service that runs within the LSASS.EXE process and shows up in the Services snap-in in MMC. It is loaded at system start-up and retrieves an IPSec policy from either Active Directory or the local registry. After the IPSec Policy has been obtained, it will be applied to *all* IP traffic sent or received by that system (default behavior - IPSec policy can be modified to allow "soft associations" KB# Q234580).

Before two computers can communicate they must negotiate a Security Association (SA). The SA defines the details of how the computers will use IPSec: which keys, key lifetimes, which encryption and authentication protocols will be used for example.

IPSec Encryption Algorithms

• 3DES, 128-bit – Provides strongest security but affects performance due to overhead associated with longer key length.

• DES, 56-bit – Provides performance improvement over 3DES and can be used when a shorter key length is allowed.

• DES, 40-bit – Provides greatest performance but the least security. Use mainly when some security is required, but performance is the primary consideration.

IPSec Authentication Protocols

• MD5, 128 bit – (message digest 5). Less secure than SHA. Requires less CPU overhead and increases performance.

• SHA, 160 bit – (secure hash algorithm). Provides stronger security but affects performance. Use for U.S. government contracts that require the FIPS (Federal Information Processing Standard). (KB# Q237849)

Diffie-Hellman Groups

• Group One – Low, 768 bits.

• Group Two – Medium, 1024 bits.

IPSec Key Exchange

• Preshared Keys – Uses a secret key that has been previously agreed upon by two users. They must be manually configured and are used on non-Windows 2000 standalone systems and systems that are not running Kerberos v5.

• Public Key Certificates – Computers not running Kerberos v5 use them for authentication. It is preferable to use preshared keys when large numbers of systems are involved.

• Kerberos v5 – Default in Windows 2000. Used for authentication with any clients in a trusted domain running this protocol.

NetBIOS over TCP/IP (KB# Q179442)

Computers in specialized roles, such as proxy servers or firewall bastion servers, should not have NetBIOS over TCP/IP installed. Windows 2000 allows administrators to disable this feature.

DNS

Planning a namespace

In Active Directory, the namespace is based on DNS. You will need to plan your namespace if you choose to use multiple domains.

There are two types of namespace: Internal (used by Active Directory) and External (registered with Network Solutions for access from the Internet). When implementing AD, you can choose to use the same or different internal and external namespaces.

Using the same internal and external namespaces has the following two advantages: uses the same logon names both internally and externally (e.g. jdoe@brainbuzz.com could serve as both the logon and e-mail ID) and uses the same tree name (e.g. brainbuzz.com for example is consistent on both the internal network and public Internet).

Using the same internal and external namespaces results in a more complex proxy configuration and administrators must be careful not to publish internal resources externally. There is duplication of effort in managing resources (e.g., duplicate zone records). As well, users get a different view of internal and external resources even though the namespace is the same.

Using separate namespaces makes it easier to distinguish between internal and external resources, as there is no overlap or duplication of effort. This makes things easier to manage and proxy configuration much simpler. Disadvantages of using separate namespaces are that multiple names must be registered with an Internet DNS and logon names are different from e-mail IDs.

MS recommends that you register any domain name you plan to use with AD even if it will only be for internal use. This is to prevent internal clients from being unable to distinguish between the internal name and a name that has been publicly registered by someone else.

Design and interoperability considerations

• Number of DNS clients per location? The number of clients determines how many DNS servers must be installed per location.

• How many locations in your organization? Typically at least one DNS server will be installed per location.

• Are there any pre-Windows 2000 DNS servers currently in use? Newer features in Windows 2000 DNS may not work with older Windows and UNIX DNS servers.

• Is Active Directory in use or planned in the future? Active Directory integrated zones are only available in Windows 2000 DNS servers (they reduce management overhead by using AD replication to copy the zone databases to all domain controllers).

Use only RFC compliant (ANSI) characters with NT4 and older BIND DNS servers; they do not support Unicode. (KB# Q255913, Q250488, Q241973, Q241980, Q151416 & RFC 2181)

In native mode WINS is not necessary. In mixed-mode DNS requests should be forwarded to WINS for NetBIOS name resolution. BIND servers see WINS and WINS-R record types as invalid. If mixing Windows and BIND, specify that WINS records do not replicate to BIND DNS servers. (KB# Q173161 & Q164176)

For WINS resolution, use a delegated domain as a placeholder for WINS names. When there is a private and public DNS namespace, the WINS sub domain should reside in the private portion. Organizations using the same private and public namespace should place their WINS sub domain under the root of the organization.

Working with zones

Traditional/standard (KB# Q227844)

The primary zone is the only type that has a read/write copy of the database (single master model). Only one primary zone is allowed, but there is no limit to the number of secondary zones (read only). If the server hosting the primary zone fails an administrator must intervene immediately to prevent disruption to network services. Traditional zones are completely compatible with BIND-based (UNIX) DNS servers.

Active Directory Integrated (KB# Q198473)

Required for secure DDNS. All domain controllers hold a read/write copy of the zone database file (multi-master replication). Since all DNS servers behave as primaries, the failure of a single server will not affect DNS updates (improves availability). Treated as primary zones by BIND-based DNS servers. Data from AD integrated zones can be replicated to other AD integrated zones or traditional secondary zones.

Reverse lookup zones can be AD integrated, standard primary or standard secondary. The rules listed above apply to reverse lookup zones as well.

Exposing resources to the Internet

DNS queries from within your organization can either be forwarded to that organization’s ISP or to the Internet’s root DNS servers.
Incoming queries from the Internet can be resolved on an organization’s behalf by their ISP (recommended only if resource names aren’t changed often) or by a DNS server maintained by the organization in a screened subnet (use when resource names change frequently).

Place the primary zone inside the organization’s firewall and place the secondary zone (read-only database) inside the screened subnet to prevent unauthorized changes to the DNS database. Do not place an AD integrated zone in the screened subnet as it could jeopardize the security of your AD information.

The public DNS server should contain only those records necessary to do its job. Placing a complete zone database on the machine could expose private information for servers inside the corporate firewall and will also degrade the machine’s performance. (KB# Q193837)

Performance and availability considerations

With AD-based DNS servers, simply add more DNS servers as needed to handle traffic. With traditional DNS zones, add secondary zones or delegated domains to increase performance. Delegated domains contain a subset of the domain namespace. (KB# Q164054)

Incremental zone transfers (IXFR) place less of a burden on the network than full zone transfers (AXFR) – use them whenever possible. Fast zone transfers compress replication data, but are not supported by older versions of BIND. Schedule replication to take place during off-peak hours when possible, to avoid network congestion.

A caching DNS server simply resolves requests and caches data from resolved requests until its TTL expires. They can be used to reduce traffic across low-speed WAN links where resource information changes infrequently and insufficient bandwidth for zone replication traffic. (KB# Q167234)

Network Load Balancing redundant DNS zones spread a traffic load across multiple servers. Use when the amount of time it takes to resolve queries has become unacceptable, when DNS traffic exceeds the capacity of a WAN link at a remote location, or when the connection between the two DNS servers supports the extra replication traffic. (KB# Q240997 & Q248654)

Use MS Cluster Service to increase availability (local servers only: remote servers cannot be clustered). Clustered servers should share a cluster drive so that both nodes have access to the most recent zone database file. Failed servers can be restored more quickly from a cluster drive, as there is no need to resynchronize. (KB# Q259267)

Security considerations

Secured updates are only available with AD integrated zones. Use them to prevent impersonation of servers when using DDNS. Permissions can be assigned to a group, computer or user account. W2K clients can directly update DNS records but this should only be done if

1. It does not create a security risk

2. The client station has a static IP address, and

3. It does not create unacceptable management overhead in terms of managing permissions.

Having a DHCP server perform DNS updates is more secure, reduces the headache of managing permissions, and should be used with non-Windows 2000 clients (as they cannot automatically update the DNS).

Encrypt replication data using VPN and IPSec for additional security. Using AD integrated zones provides further protection, as they will not replicate to other AD zones that are not registered with Active Directory.

Firewalls should be configured to permit only DNS queries from the Internet and zone replication traffic only from the private network.

DHCP (RFCs 951, 2131 & 2132)

Design considerations

Is the network switched, routed, or a combination of both? Consider the location of broadcast domains and the placement of DHCP Relay Agents to forward lease requests through routers that do not accommodate BOOTP/DHCP forwarding. (KB# Q120932 & RFC 1542)

When using a single DHCP server, place it on the subnet with the highest population of clients – the other subnets will use relay agents or BOOTP/DHCP forwarding on their routers. Use multiple DHCP servers for a geographically dispersed network, low speed WAN links, or dial-up users.

To what extent have non-Microsoft hosts been deployed through the organization? They may cause problems by not recognizing MS-specific vendor options like default router metric base, which provides a base cost for default gateways to the client. Diskless workstations (BOOTP clients) are becoming increasingly popular but are not properly supported by NT4’s DHCP server. BOOTP clients should be placed in the same broadcast domain as a W2K DHCP server that has been updated to support RFC 951-compliant devices. (KB# Q174765)

Performance and availability considerations (KB# Q199160)

Increase DHCP lease length when network traffic is a concern. The longer the lease, the lower the traffic.

When working with a small pool of IP addresses, decrease lease length to make greatest use of your addresses. This has the side effect of increasing network traffic. Windows 2000 clients can be configured to give up their lease at shutdown.

Using distributed scopes with multiple servers in remote locations increases availability in the event of a server failure. Allocate between 50 – 80 percent of an IP address scope to a server on the local subnet and the remainder to a remote server. When the server on the local segment goes down, the remote server can continue allocating addresses.

Implement vendor classes (KB# Q240247 & Q266675, RFC 2132) when there is a need to provide similar DHCP options to like groups of clients. User classes are used when specific groups of users have different DHCP configuration options than other groups within the company.

Windows Clustering increases availability by providing automatic failover if the primary node goes down and failback when the downed server comes back online. Clustering is only available to locally placed machines with a persistent high-speed link. (MS whitepaper)

Network Load Balancing is not an option with DHCP.

Security considerations

Placing a DHCP server outside of your firewall or inside a screened subnet poses a security risk since a valid IP address could be allocated to an unauthorized client (allowing access to network resources). Minimize the security risk by extending lease times (this reduces the chance of an IP address being captured), using the smallest possible address range to meet your needs, and manually reserving/mapping addresses to the MAC addresses of specific clients.

WINS (RFCs 1001 & 1002)

Design considerations

Is the network switched, routed, or a combination of both? Consider the location of broadcast domains and the placement of WINS proxy agent to forward broadcast traffic across routers. (KB# Q121004 & Q164765)

The advent of DDNS in Windows 2000 has obviated the need for WINS, except in networks that are running pre-W2K domain controllers. WINS should be installed when there is a need to provide NetBIOS name resolution services while reducing the amount of related NetBIOS broadcast traffic.

Non-WINS clients are supported by installing WINS proxy agent (recommended), static WINS entries (next best), or LMHOSTS entries (most work). To avoid changing hundreds (or thousands) of LMHOSTS files whenever a resource is added or removed, use the #INCLUDE statement to reference a centrally managed LMHOSTS file.

Performance and availability considerations

Replication across WAN links should be scheduled in off-peak hours. The frequency of replication can also be controlled.

The best replication convergence times are provided by a hub and spoke model. Aim for persistent high-speed connections between replication partners whenever possible. Push- or pull-only relationships should be avoided (except for slow WAN links) when planning for WINS replication.

For remote servers use push/pull WINS replication. Local servers can be clustered for high availability. (KB# Q226796)

Security considerations

When a WINS server is placed outside a firewall or inside a screened subnet, use pull only replication from its partner. This replication traffic should be encrypted using VPN tunnels or IPSec. (KB# Q179442)

MS Proxy Server 2.0 (KB# Q164084, FAQ & RFC 1918)

Design and interoperability considerations

A special install wizard has been released to upgrade a Proxy 2 installation so that it is compatible with Windows 2000. Please see the release notes.

If there is a need to reduce private network traffic within an organization then consider implementing Proxy 2 with its Web object caching. Its firewall capabilities can also be used to create screened subnets inside a private network to secure data.

A proxy server at the edge of the private network isolates it from the public network and secures confidential data. It can also reduce traffic on the outbound connection by caching frequently requested Web objects.

An organization with insufficient public IP addresses can assign one valid public IP to the proxy server and have it service thousands of clients which are using private, non-routable addresses instead (acting as a proxy on their behalf).

Internet Explorer 5.0 is all that is required for HTTP and FTP traffic. Install the WSP client for any Windows-based Internet application that uses wsock32.dll or NWLink (32-bit only – see FAQ). For UNIX and Macintosh clients, SOCKS4 compatible applications are supported (SOCKS4 supports TCP but not UDP).

Performance and availability considerations

When configuring demand-dial connections be sure to specify the data rate and the persistence of the connection, especially if there is a charge for keeping the connection alive. With digital subscriber line (DSL), it is possible to install DSL and use it with a demand-dial interface for creating a VPN tunnel.

Active content caching makes the most commonly requested objects available in the cache automatically. It will go out and retrieve objects on its own during low traffic periods if needed. Active caching conserves hard drive space but is more CPU intensive. With passive caching, objects are retrieved when requested by a client and stored in the cache until their TTL expires. Passive caching uses less CPU time but more hard drive space than Active caching. (KB# Q164085)

Multiple servers can be configured as a proxy array for fault-tolerance. If an array member goes down, the remaining servers pick up the slack. As the Web content cache is spread amongst the array, the cache is lost only on the machine that fails. All servers in the proxy array must share the same array name and belong to the same AD domain and site.

Setting up multiple proxy servers for Network Load Balancing provides all three machines with a single IP address used by clients making requests. When one of the proxy servers fails, the others will share the work between them.

You can use round robin DNS resolution to provide fault-tolerance for proxy servers as well. This provides something of a “poor man’s load balancing”.

Proxy servers can be “chained” so that requests are forwarded from one proxy server or proxy array to another.

It is best to setup a machine with multiple interfaces if the resources of the proxy server permit (centralized administration). If resources are an issue, establish multiple proxy servers (decentralized administration).

Security considerations

When your proxy server belongs to an Active Directory domain you can assign access permissions to users and/or groups. In a heterogeneous environment install Services for UNIX, CSNW, and/or Services for Macintosh to provide access for non-Windows clients.

Proxy can also be installed on a stand-alone computer and access granted (or denied) through its local users and groups. The guest account would only be enabled when it is desirable to have anonymous access to resources.

When designing hierarchical screened subnets, the broadest security belongs at the top of the hierarchy and becomes stronger as you move lower. (e.g. Management has lax security where as the Research division has very strong security). (KB# Q191146)

Packet and domain filtering provides the ability to completely restrict traffic by protocol, IP address, domain, user, group, and computer.

Web publishing allows for placement of a single Web server behind a firewall. This increases security, since the proxy server fetches requested pages on behalf of the client and returns them (acting as a Web server). This hides the identity of the real Web server and protects it from attack.

NAT (KB# Q234815, Q229965 & RFC 1631)

Design considerations

NAT is only appropriate for non-routed network environments where all users have the same access privileges but where private addressing for all computers is required.

A DHCP server is not required, as NAT will automatically assign IP addresses to machines capable of acting as a DHCP client. NAT should not be installed on a machine that is running DHCP, as they both use the same port (or a machine configured for DDNS). (KB# Q250603)

The following protocols are not supported by NAT: IPX/SPX (NWLink), SNMP, LDAP, Kerberos v5 (DCs cannot replicated AD information through NAT), RPC, and IPSec (header encryption not supported). (KB# Q261203)

Choose NAT when you want to exchange traffic between two dissimilar network segments (e.g. Ethernet and ISDN), but the expense and complexity of MS Proxy 2 is not desired. NAT can also be used to create screened subnets but lacks the flexibility of MS Proxy 2.

A DNS proxy is included in NAT to forward name resolution queries to a DNS server belonging to the organization or one belonging to its ISP.

Performance and availability considerations

Dedicate system to running NAT. This enhances both performance and availability as there are no other applications running that consume needed resources or can destabilize the system.

Use multiple Internet connections whenever possible for redundancy. This prevents a resource from being unavailable in the event of a one connection failing and enhances performance by spreading traffic across multiple connections. Also choose persistent connections whenever possible, as demand-dial connections take time to establish (lower performance) and can reduce availability (busy signals).

Security considerations

VPN (PPTP) connections can be used whenever remote users need access to resources on a private network or whenever remote resources need to be secured on a user-level basis. Both outbound and inbound connections are supported. (KB# Q255784)

Use RRAS IP filters on both the Internet and/or private network interfaces to grant or block access by IP address and/or protocol. (KB# Q256644)

By default, all computers behind NAT are inaccessible from the Internet. If access to the private network is given to a single IP address, you must define its port mappings within RRAS. This is not necessary when using multiple addresses reserved in an address pool, since all IP ports are open unless specifically filtered in RRAS.

Routing

Protocols

IGMP is used when existing routers are multicast capable, the IGMP clients are directly connected to the same subnet, and multicast traffic needs to pass to and from the public Internet (NetMeeting and Windows Media Player are two apps that can use multicast).

RRAS has two modes of support for IGMP: Proxy Mode, which simply forwards multicast traffic to a multicast capable router/server; and Router Mode, which can listen for and update the multicast-forwarding table. Router mode cannot propagate group listening information to other multicast capable routers, however.

RIP is used when it is desirable to reduce the management overhead caused by maintaining static routes. It should be used if frequent changes to routing information occur, demand-dial interfaces are used, the existing routers use RIP, or there are no more than 14 hops between routers. (KB# Q164363)

Choose RIP version 2 if your network includes variable length subnet masks, CIDR, multicast routing table updates, or password authentication between routers.

Choose OSPF when dynamic routing is necessary, existing routers are OSPF compliant, there are over 50 subnets, or there are redundant paths between your subnets (link state). OSPF design can be subdivided into three hierarchical levels:

1. OSPF Autonomous System – a collection of networks that share a common administrative authority. Autonomous Systems (AS) are subdivided into OSPF areas.

2. OSPF Area – a group of routers that connect to contiguous network segments and are all connected by area border routers (ABR) into a backbone area.

3. OSPF Network – consists of individual segments that are connected by OSPF routers.

Design considerations

For router placement, consider the following questions

• Do you need to logically segment the network (create subnets) to isolate traffic?

• Are dissimilar network topologies (ATM, ISDN, Token Ring, and Ethernet) being connected?

• Does the organization require the creation of screened subnets (packet filtering) to secure confidential data?

• Are connections persistent (higher availability and data rate) or demand-dial (you will have to set persistence for these), which will invariably add to its operating cost?

Routers placed at the edge of a network (between the Internet and the private network) can provide firewall type security when packet filtering is enabled.

Static routing is an option when it is desirable to reduce overhead (generated by dynamic routing protocols such as RIP and OSPF) or to increase security (by preventing transmission of routing tables). It should be avoided when it generates unacceptable management overhead because of the number of resources or the frequency of changes. Routes for demand-dial interfaces must be manually added as neither RIP nor OSPF support them. (KB# Q178993 & Q235492)

Auto-static routing is a combination of static routes and RIP for IP. It allows an administrator to specify a schedule when a demand-dial connection is established and static route entries are automatically updated. It reduces the management overhead associated with static routes, but it can cause availability problems if auto-static updates are not performed frequently enough. Auto-static routing does not support OSPF. (KB# Q241545)

Performance and availability considerations

To obtain the best performance use a dedicated computer as a router. If a router is performing more than one role, its performance will be degraded and possibly its stability as well (lowered availability).

Persistent connections enhance availability and eliminate connection times associated with demand-dial interfaces. Connections should be redundant, maintaining high availability in the event a connection fails.

Multiple routers should be installed to provide fault-tolerance in the event of equipment failure.

Security considerations

In your network design, RIP for IP or OSPF passwords can be implemented to authenticate routers only if a clear-text password exchange is acceptable and all routers use the same protocols.

IPSec Machine Certificates provide a greater degree of security. It should only be used when all routers support IPSec (servers running IPSec can only communicate with other servers running IPSec), and there is a Certificate Authority that can issue machine-based certificates. IPSec provides authentication and protection against spoofing when using the Authentication Header (ESP) protocol, but does not encrypt the data itself (choose ESP protocol for that).

VPN (Virtual Private Network) can be used if there is a need to secure routers (which support VPN). Choose PPTP with NT4 routers and L2TP with Windows 2000 routers. Third party routers may be compatible with PPTP and L2TP: check their specifications when planning to use VPN for security.

MS Point-to-Point Encryption (MPPE) is used by Point-to-Point Tunneling Protocol (PPTP) to secure confidential data. This method is not as secure as IPSec and only provides user-level authentication. It is also used in lieu of certificate-based authentication.

IPSec tunnels can be used to protect confidential data. Tunnel mode is used strictly for point-to-point communication whereas transport mode can communicate with more than one computer at a time. When used with L2TP, machine-based authentication is possible using certificates.

Remote Users

Design considerations

VPNs

A Virtual Private Network (VPN) is an extension of the physical network. Rather than restricting the network to local cabling, VPN uses the Internet as a segment backbone. VPNs are used by organizations that have a need for members to access private network resources via the Public Internet. Windows 2000 has two main encryption protocols that are used with a VPN:

• MPPE (Microsoft Point-to-Point Encryption) is used with PPTP (Point-to-Point Tunneling Protocol). PPTP was developed by Microsoft and others. It has not been widely adopted by most of the Internet community. MPPE uses 40-bit, 56-bit, and 128-bit (North America only) encryption.

• IPSec (IP Security Protocol) - an open protocol suite that relies on L2TP (Layer 2 Tunneling Protocol) for encrypting user names, passwords, and data. IPSec is used to negotiate the secure connection utilizing DES (Data Encryption Standard/ 56-bit), and 3DES (Triple DES). IPSec is currently supported by Windows 2000 only.

There are two VPN connection types: compulsory and voluntary. Compulsory tunnels are initiated by the RAS server, do not require client support for tunneling, and require user-based client authentication (RADIUS is optional). Voluntary connections are initiated by the dial-up user and require support on the client end for the tunneling protocols, but the connections do not need intermediate RAS server support for tunneling.

Dial-up Access

Used when the security risk from allowing access the private network via a VPN tunnel from the public Internet is unacceptable. RRAS support the MS RAS protocol (NetBIOS only) and PPP, but not SLIP.

PPP supports the following protocols

• TCP/IP

• IPX/SPX (NWLink)

• NetBEUI

• Appletalk

PPP also support the following WAN technologies

• PSTN (Public Switched Telephone Network)

• ISDN (Integrated Services Digital Network)

• X.25 and X.25 PAD

PPP supports the following security protocols

• CHAP (Challenge Handshake Authentication Protocol)– is one step above PAP in that it does not use clear-text passwords.

• EAP (Extensible Authentication Protocol)– allows the client and the server to negotiate the protocol that will be used, in much the same way that networking protocols are determined. Possible choices include one-time passwords, username/password combinations, or access tokens (used to encrypt L2TP).

• MS-CHAP (Microsoft Challenge Handshake Authentication Protocol) requires the client to be using a Microsoft operating system (version 2), or a small handful of other compatible operating systems (version 1).

• PAP (Password Authentication Protocol) uses a plain-text password authentication method and should only be used if the clients you support cannot handle encryption.

• SPAP (Shiva Password Authentication Protocol)– is also one step above PAP. It is there for backward-compatibility and is not favored for new installations

RRAS integrates with the following W2K network services (reduces management overhead)

• RADIUS – allows centralized administration of remote access policies, distributed client authentication in a heterogeneous network, and authentication/accounting logging from multiple remote access servers.

• DHCP – IP addresses can be allocated to remote access clients.

• DNS – remote access clients can register their dynamic IP addresses with the DNS server.

• Active Directory – remote access policies can be administered through AD in a W2K native-mode network.

Client/server dial-up designs should specify

• Which users will be granted remote access,

• Remote access policy restrictions by user or group, and

• How many adapters, phone lines, modems, and ports are needed to support client connections.

Demand-dial routing designs should specify

• What accounts will be used by the RRAS servers when performing authentication,

• Remote access security policy restrictions,

• Routing capabilities of RRAS servers,

• Demand-dial interfaces used by RRAS servers in each location, and

• How many adapters, phone lines, modems, ports are needed to support connections to remote locations.

Dial-up solutions in non-routed environments

• What is the aggregate throughput required by the remote access clients? Make sure the LAN interface in the remote access server can handle the traffic.

• What is the security model in place for remote access users? W2K native-mode domain policies have greater flexibility over mixed-mode policies.

• How many concurrent dial-up sessions must be supported? If PPP Multilink or BAP are being used it may be necessary to provide more than one connection point per client.

• What will the TCP/IP configuration of the clients be (fixed IP address, allocated by RAS server, or allocated by DHCP server)?

Dial-up solutions in routed environments

Implementing dial-up solutions should be considered when

• Access from the public Internet (VPNs) is considered an unacceptable security risk to the private network

• Access from the public Internet (VPNs) outweighs the costs associated with providing dial-up access.

• Security policies require use of additional technologies such as Caller ID or callback.

• An Internet connection does not provide a consistent enough sustained data throughput rate due to router congestion during peak traffic periods.

• Client requirements necessitate additional connections to accommodate bandwidth requirements (Multilink or BAP).

Choose VPN as part of a network design when

• Access to the private network via the Internet is an acceptable security risk.

• The variability of Internet bandwidth is not a concern.

• The organization’s Internet connection supports the projected aggregate bandwidth of the maximum number of concurrent remote access client connections.

Performance and availability considerations

Position the RAS server on the subnet with the most client-accessible resources in a switched, non-routed LAN to minimize the amount of unicast traffic flowing across all segments and to minimize cross-subnet traffic in routed networks with multiple routers.

Position the RAS server in a single segment, non-switched LAN when clients are only allowed access to resources on the RAS server.

Do not try to combine a VPN server using L2TP tunnels and IPSec with a NAT server. The NAT server will be unable to read the encrypted IP headers.

Use Internet Connection Manager to connect remote dial-up users to your network. Assign each remote-access client a backup phone number in the event of server failure. Connection Manager can also be used to reduce management overhead when distributing updated access numbers to remote clients.

High availability designs must include more than one VPN server. Multiple VPN servers can have their traffic distributed via round robin DNS entries (this uses less resources than Windows Clustering).

Network Load Balancing can make up to 32 W2K VPN servers appear to the client as a single server. It is more resource consumptive but provides immediate failover.

Security considerations

Restricting access on a private network

The following client access restrictions can be placed upon remote users:

• Access is confined to RAS server only (set by server, not by user).

• Static routes are defined only to specific subnets where access is granted (can be set by user or server policy).

• Access is permitted to all resources on the routed network (this can only be set by server, not by user).

Place an RAS server in a screened subnet when

• Security policies specify that all client access must take place through a firewall or filter (this creates a “screened subnet”),

• The majority of resources accessed by remote clients exist in the screened subnet,

• Clients VPN tunnels to connect to the private network, and/or

• The RAS server contains data that is made available to the public Internet.

Place a VPN server outside the firewall when

• Confidential data is protected behind the firewall and the only access through the firewall is strictly limited to the VPN server,

• Allowing access to the complete range of VPN IP address through the firewall poses an unacceptable security risk, and/or

• It will not compromise the integrity of the network design’s security to expose the VPN server directly to the Internet.

RADIUS (RFC 2138 & 2139)

Overview

Internet Authentication Service (IAS) is Microsoft’s implementation of the Remote Authentication Dial-in User Service (RADIUS). RADIUS and IAS together perform centralized connection authentication, authorization, and accounting for dial-up and virtual private network (VPN) remote access and for router-to-router connections. Used in conjunction with RRAS , they enable single- or multiple-vendor network remote access.

Design considerations

Place RADIUS clients as near as possible to remote users creating a local point-of-presence (POP - reduce/eliminate dial-up costs), reducing administrative overhead by delegating administration to local network admins in the same region, and reducing the risk of confidential data being exposed.

RADIUS servers should be placed as close as possible to the server that provides remote user account authentication. This localizes traffic, keeping it within the same private network and helps prevent unauthorized access to the user account database.

It is possible to outsource dial-up support for remote-access users to an ISP with RADIUS. Local users access the organization’s RADIUS server (which performs authentications) through the RADIUS client installed within the ISP’s network.

Dial-up remote access connections are used when organizational security policy dictates additional security measures such as callback, caller ID, or when private network access through the Internet is prohibited. This method entails maintaining a significant number of phone lines, modems, and other expensive hardware.

VPN connections can be included in a network design when the organization’s Internet pipe has enough bandwidth to support the VPN traffic, security policies allow the private network to be accessed via the Internet, and remote-access policy allows for the outsourcing of modems, phone lines, and multi-port communication Adaptors.

Remote access client protocols

• Appletalk – used for Apple-based servers, Apple-based file and print resources, and running applications based on the Appletalk protocol.

• IPX/SPX – used for Netware-based servers, Netware-based file and print resources, and running applications based on the IPX/SPX protocol.

• TCP/IP – used for administering W2K-based servers, accessing Web-based applications and FTP servers, and running applications based on TCP/IP.

Performance considerations

Capacity planning/hardware scaling for an IAS server

Performance Guidelines for a Single IAS Server 

When selecting the data rate and persistence always attempt to specify a persistent connection that exceeds the required data rate.

When using MPPE encryption, 40-bit provides less security than 128-bit; however it is less CPU intensive because of the shorter key length. If security is paramount, use 128-bit encryption and allocate the necessary resources to accommodate the reduction in server performance.

The RADIUS server must have a high-speed, persistent connection to the global catalog server. If CPU performance is not an issue, installing IAS on the global catalog server may increase authentication performance.

RADIUS authentication/accounting performance can be improved by adding additional RADIUS servers as needed, upgrading existing servers, and reducing the level of accounting detail logged.

To design for RADIUS client availability install redundant RADIUS clients and give remote users phone number for the primary and backups, install sufficient phone lines and modems to handle the user load, and register your redundant RADIUS clients with the RADIUS servers to guarantee proper authentication/accounting.

To design for RADIUS client availability for VPN connections use Network Load Balancing to provide immediate failover or round robin DNS to distribute the load across multiple RADIUS servers.

Security considerations (KB# Q246118)

Authentication can take place from any domain that is accessible to Windows 2000. This includes Windows NT 4.0 domains, Windows 2000 mixed-mode domains, Windows 2000 native-mode domains, as well as any domains that are accessible through trust relationships (e.g. Kerberos 5 authentication realms). RADIUS only supports a single default domain, but users can specify a different authentication realm (domain) if necessary.

Both the RADIUS client and server use remote-access policies in conjunction with a user account’s dial-up properties to grant authorization. While a user is connected, RRAS matches the connection to settings of the user account and remote-access policy profile.  As long as they match the connection stays alive (e.g. profile settings allow one hour maximum connection time. When a user goes over an hour, the policy no longer matches and the user is disconnected).

MS recommends specifying connections between the RADIUS client and the server that encrypts all data and authenticates using VPN or IPSec. RADIUS secrets (KB# Q168667 & RFC 2139) should be used between mutually authenticating RADIUS servers. The RADIUS secrets should be at least 16 characters long and include a mixture of uppercase and lowercase letters and punctuation.

Authentication protocols

• PAP (Password Authentication Protocol) uses unencrypted (clear text) authentication. Only use when no other authentication protocol is supported.

• SPAP (Shiva Password Authentication Protocol) provides encrypted authentication for Shiva LAN Rover clients.

• CHAP (Challenge Handshake Authentication Protocol) provides encrypted authentication for multiple operating systems (including Mac and UNIX).

• MS-CHAP (Microsoft Challenge Handshake Authentication Protocol) provides encrypted authentication for Windows 95/98/NT4

• MS-CHAPv2 (Version 2) provides encrypted authentication for Windows 2000.

Managing Network Services

Manual testing

Schedule regular audits of network services security and performance. Manually test Network Load Balancing (e.g. for Web servers use a tool like WebCAT), failover response of clustered servers (switch one off under controlled circumstances and see what happens), stop and restart services as needed, etc.

Monitoring

Throughout your testing and the regular operation of the network services, analyze how service uptime, performance, and interaction with other services are affected. The Performance Console, Performance Logs and Alerts, Snap-in and regular monitoring of server logs (can be automated through scripting) will help greatly.

Keeping an eye on things

Management processes must be put in place to readily monitor the current status of the network services, analyze data that is collected, and identify trends to verify that the operation of the services falls within the parameters of the network design. A system for responding to changes (MS recommends SMS) should also be implemented to bring network services back into design specifications.

Data collection tools and strategies

Data should be collected from multiple points within your network services infrastructure. This information is usually funneled to a central management point by one of two methods:

• In-band data collection – status data traverses the same network that provides services. The traffic from collecting this data can impact the network if large amounts are collected, and the data lost in the event of a network services failure. Should be used when the network has redundant paths (fault tolerance).

• Out-of-band data collection – status data is gathered via separate physical/logical network connections. Failure of network services/components being monitored does not affect data collection. Use when the network being monitored is not fault-tolerant.

With centralized data collection, data is collected and analyzed at a central location (usually a host running specialized management tools). This method generates increased traffic and can affect network performance. In the event of a network failure, status data may be lost.

A distributed data collection strategy entails accumulating data on multiple nodes within the network infrastructure where it is processed before being forwarded on to a management node. This reduces the burden of the management node and allows localized responses to failures. Use when design planning calls for independent operation of locations.

Event notification is provided by specialized software (Performance Alerts, SNMP) that monitors a service and generates an event when a pre-defined threshold has been exceeded. These software monitors not only generate events in the form of event log entries, they can also notify administrators of problems via e-mail/pager and even restart failed services and/or servers if necessary.

Useful tools

Utility	Function
NBTSTAT	Displays protocol stats and current TCP/IP connections using NetBIOS over TCP/IP.
NETDIAG	Performs a series of tests that help to isolate network connectivity problems. Can also diagnose state of network client. Found in \support\tools folder on W2K CD.
NETSTAT	Displays TCP/IP protocol statistics and current connections.
Network Monitor	Packet sniffer. Monitors all network traffic sent to and from the computer it is running on. SMS version can capture all data.
NSLOOKUP	Used for troubleshooting DNS problems (host name resolution failure).
PATHPING	Combination of PING and TRACERT. Helps to pinpoint where packet loss is occurring.
PING	Used to troubleshoot IP connectivity.
TRACERT	Used to trace the path taken from the host to the destination router.

Event logs

Event type	Function
Error	Indicates problems (failure of services) that may lead to a loss of functionality.
Information	Entry made upon the successful operation of an application/driver/service.
Warning	Events that may indicate future problems (e.g. low virtual memory).
Success Audit	Indicates that a successful access to an audited resource has taken place.
Failure Audit	Indicates that an unsuccessful attempt to access an audited resource has taken place.

Performance console

System Monitor, found in the Performance Console (perfmon), can be used to collect real-time data and logs. Be aware that running System Monitor on the system being monitored can affect the integrity of the status data.

Performance Logs and Alerts is used to log events over a period of time (creating reports and establishing performance baselines) and for event notification. Choose the appropriate counters for the service you are monitoring (DNS, DHCP, AD, etc.) and establish a management process for analyzing the results. This will help you to determine whether your network services are within design specifications.

SNMP (RFC 1157)

Support for Simple Network Management Protocol (SNMP) services may play a large part in your network design. Many of the hubs, routers, and switches in your existing network infrastructure may already be managed by SNMP. It can be used to remotely configure devices/services (using NMS), monitor network performance, and detect faults (when alarms are triggered the events are generated).

SNMP Agents are the software and hardware that support SNMP. They all have a defined Management Information Base (MIB – RFC 1213) – a configuration database from which they read and write data. Status info can be collected interactively from an SNMP manager or as an SNMP trap (an event generated by the SNMP manager).

Windows Management Instrumentation (WMI)

You can acquire data on the status of services on local and remote systems through WMI. It provides a central integration point for accessing status data from multiple sources within a computer. Use it when scripted/programmed access is needed for performance counters and events, but direct intervention with the services is not desired. It is started by default on W2K systems but must be manually started on Windows 95/98 systems.

Using scripts and programs for data collection/analysis

Many administrators run scripts or batch files to read accumulated performance data (application logs, event logs, and performance logs) and generate event notifications when certain pre-programmed thresholds are exceeded. MS recommends using Windows Scripting Host in combination with popular languages such as VBScript and JScript to monitor and network services.

Data collected in the form of log files, event logs, and so on can be imported into Microsoft Excel to provide visual representations in the form of spreadsheets, imported into Microsoft Access or SQL Server databases for analysis, or analyzed using a custom program or third-party solution.

Custom programmed applications can be created to manage network services as well. They can take the form of stand-alone executables, ActiveX dlls, MMC snap-ins, and COM components. These programs can automate data collection and analysis, maintenance, and event notification as needed.

Reactive and proactive response strategies

Reactive responses occur after an event notification and should only be used in a design if there is fault-tolerance built into the network services (e.g. clustering) and some downtime can be tolerated. Reactive responses are usually triggered by events such as a help-desk call, e-mail notifications, performance-counter related events, and warnings from management and monitoring systems.

Proactive responses happen before the problem really becomes a problem and are based on implementing management processes that to future resource usage limits and failures. Proactive responses are reliant on the collection and analysis of status information on performance, services, network traffic load, data from manual testing, etc. Include proactive responses in your design strategy when downtime must be minimized and prior warning of resource issues/limitations and performance related failures is essential.

Combining Network Services

Advantages

Combining services (e.g. DHCP and WINS services on the same server cluster) can reduce the number of computers needed which results in cost savings and reduced management overhead. When services are combined properly performance, availability, and security can also be improved. Services should be combined when:

• The organization’s goal is to reduce the number of computers,

• Existing computer hardware resources will support the combined services, and/or

• Combining services enhances performance, availability, and security.

Disadvantages

The most common obstacle to combining services on a single computer is hardware resources. The trick is to recognize which services use which resources and combine them properly so that all resources on the machine are fully utilized (e.g., combining a CPU intensive service with a RAM intensive services).

Hardware Resources

 

Service	RAM	CPU	Network	Disk
DHCP	Low	High	Low	High
DHCP Relay Agent	Low	Med	Med	None
DNS	High	Med	Low	High
IAS	High	Med	Low	None
IPSec	Low	High	Low	None
MS Proxy 2	High	High	High	High
NAT	High	High	High	None
Remote Access Server	High	High	High	None
RRAS Router	High	Med	High	None
VPN	Low	High	Low	None
WINS	Low	Low	Med	High
WINS Proxy	Low	Low	Low	None

Also, the presence of certain applications running on a system may preclude combining certain services because of resource issues or other conflicts (e.g. NAT and DHCP cannot be combined on the same server).

With DDNS, the DHCP service performs frequent DNS updates. If the services are on separate machines, network traffic is generated whenever updates are performed. If there is a large volume of updates, consider combining the services on the same machine to reduce network traffic.

The layout of physical networks may also prevent the combination of services. Services may be combined when the clients that access them are in the same geographic location as the system providing the services. If the routers and network segments between the clients and the systems running combined services can support the extra traffic load then it is acceptable to have some geographic separation.

Combining with clustering services

DHCP and WINS are cluster-aware services and automatically store critical data on cluster-based drives. These services will automatically failover when the primary system in the cluster goes down. Always make sure that cluster-aware services are set up for automatic failover.

When working with services that are not cluster-aware, make sure that both servers have been configured for automatic failover and that critical data is stored on a shared cluster drive.

Security considerations

Services that define screened subnets (Proxy Server 2.0 and RRAS) should be isolated. When these computers connect to the public Internet, only those services required to create the screened subnet should be combined.

Services running inside screened subnets should only be combined when all users accessing the system require the same network resources at the same security level.

Combining services running inside a private network is usually best. These systems are at low risk as security systems and are in place on other systems dedicated to the task.