An Extranet Deployment Walkthrough and Best Practices Guide for Secure Business-to-Business Collaboration

Article
12/09/2009

This document describes how to construct an extranet in a prototype environment to examine how you can configure the Windows 2000 Server family to provide a secure extranet for business-to-business (B2B) collaboration through the Internet. Collaboration will be demonstrated by providing a set of internal and external users with read, write, create, and delete access to a common set of files by using both NTFS file system shares and shared Web folders.

Summary

Business-to-business collaboration and resource sharing allows a company and its partners to work more effectively towards reaching business goals. A connection to the Internet facilitates the flexibility and convenience of accessing data at any time or place. Unfortunately, the ability to share and obtain information presents significant risks. The services that are made available through Internet connections can be misused, which makes it necessary to employ network security strategies.

Most organizations have relationships with customers, vendors, allied companies, suppliers, consultants, regulators, and other people who work with the organization. Many of these partners, as they are often called, greatly benefit from direct access to your company’s data and applications. However, providing direct access to partners without the proper planning and safeguards increases the risk of divulging sensitive information to competitors or exposing the corporate computer infrastructure so that it can be compromised by malicious users. Because of this, a well-defined security policy that is implemented by using robust security technologies is required so that only authorized partners can gain access to the corporate computer infrastructure. The organization will then want to limit access to the minimum level that the business relationship requires.

The network and security infrastructure that allows partners to gain access to your corporate network is often called an "extranet." Extranet security planning begins with a written security policy. The policy that you write must satisfy both security and business requirements, where business requirements are defined by the extranets purpose and workflow model. There are four generic purposes for creating an extranet. Each purpose works best for a specific type of business relationship:

Information publishing: Subscription services and repair manuals
Distribution channel: Order entry and tracking, as well as customer service
Supply chain: Inventory control and corporate portal
Collaboration: Joint manufacturing or research, as well as access to medical records

For each purpose, you can build an extranet by using three different components However, some of the components models are not equally useful for all purposes. The basic extranet components, including examples with both strengths and suggested business programs, are listed in this section so that you can familiarize yourself with the options that are beyond the scope of this document.

Table 1 Web-Based Components

Programs	Strengths
Content publishing with Microsoft Internet Information Services (IIS)	Personalized data searching and browsing
	Subscription services and repair manuals
Application sharing with IIS	Single interface to diverse services
	Corporate purchasing and service portals
Reverse proxy with Microsoft Internet Security and Acceleration Server (ISA Server)	Thin client model
	Web interface to non-Web enabled applications
Collaboration with both Microsoft SharePoint Portal Services (SPS) and Microsoft SharePoint Team Services (STS)	Project portals
	Knowledge management

Table 2 File-Based Components

Programs	Strengths
Shared database with Microsoft SQL Server	Relational integrity and structured queries
	Medical records and customer service
Shared files with the NTFS file system, Common Internet File System (CIFS), or	Different applications
Web Distributed Authoring and Versioning (WebDAV)	File location identifies relationships
	Branch offices
	Joint research and development
Collaboration with SPS or STS	File sharing and versioning
	Coauthor or edit document
	Knowledge management

Table 3 Message-Based Components

Programs	Strengths
E-mail messages with Microsoft Exchange Server	Mail impersonation for outsourcers
	Secure e-mail transfers
	Coauthor or edit document
	Global reach and no server management
Electronic Data Interchange (EDI) and	Business-to-business (B2B) transactions
Extensible Markup Language-based (XML-based) forms with	B2B workflow
Microsoft BizTalk Server	Communicate to different systems
	Distribution channels
	Supply chains

Note The Windows 2000 operating systems provide suitable application and security technology for all of the previously-mentioned uses.

You must determine the extranets purpose and component models before you can finalize the security policy. Before you attempt to create an appropriate security policy and translate it into a successful extranet security plan, you should know the scope of the resources that must be protected. Although an extranet typically has of a fixed number of shared servers, the full extent of the extranet includes all of the connected corporate networks, regardless of whether they are directly or indirectly connected to the networks.

A thorough discussion of security policy and risk analysis is outside of the scope of this document. Instead, the goal of this document is to suggest methods that you can use to help you choose and configure Windows 2000 Server security technologies to deploy a secure extranet that enables collaboration between business partners in a joint design and manufacturing project. Extranets typically employ the same technologies that employees use to gain remote access to the intranet, such as virtual private networks (VPNs) or secure dial-up connections that are provided by the Routing and Remote Access service.

Although the goals of your security policy should be essentially the same for both internal (employee) and external (partner) users, there are significant differences that you must consider when you translate policy into both security strategies and deployment practices. Typically, corporate employees can work in the office or remotely and partners can only use the extranet (or do business by either phone or mail).

Although an extranet portal might be convenient for your employees, your extranet is typically a mission-critical necessity for both partners and internal business units that work with them. Therefore, partners and business units are very sensitive to the timeliness of the extranet service. Business functions often depend on the data that is exchanged, so delays can be very costly. The extranet needs to be reliable, and the partners and business units need to be able to contact someone who can quickly fix the issues when they arise. Because of this, an effective extranet security policy needs to emphasize reliability, scalability, flexibility, and supportability, in addition to controlling authorized access to resources. Staffing is particularly critical, along with thorough pilot testing, policy and procedure development, and interorganizational communication. Staffing is one of the fundamental considerations in the extranet architecture that is recommended in this document. Skilled network administrators and security officers are difficult to hire, expensive to train, and a challenge to retain. It is more cost effective and leads to more consistent and effective security practices if you leverage the administrative skills and security procedures that are already developed for your corporate intranet when you create a policy to manage the extranet. Therefore, it is recommended that you design and deploy extranets by using the same types of Windows 2000 Server infrastructure components (for example, domain controllers, certificate servers, and DNS servers) that make private intranets.

Security-relevant servers must be authoritative only for shared resources that are on the extranet. Extranet resources must never be used to manage accounts or namespaces that are used on private intranets. The easiest way to ensure this is to deploy a dedicated forest for all of the extranet servers and services. This approach allows administrators to apply the same skills and training to manage security for both intranet and extranet resources.

Although intranet and extranet administration skills should overlap, proper security planning requires isolation between private and shared physical resources. The most well understood and proven strategy to do this is to place all of the equipment that is used for sharing resources through the extranet in a separate network, known as a perimeter network (also known as DMZ, demilitarized zone, and screened subnet). The perimeter network and all of the servers that are in the perimeter network are logically located on the boundary between your organization and the outside world.

Figure 1 Perimeter Network Conceptual Network Diagram

Figure 1 Perimeter Network Conceptual Network Diagram

Your corporate internet firewall has an additional network adapter that directs traffic to the perimeter network that is typically based on the types of network traffic (and possibly the partner IP addresses) that are authorized to gain access to that area of the network.

You must ensure that perimeter network servers have no access (or controlled access), to corporate resources. When you do this, malicious users cannot use the perimeter network servers to easily gain access to other computers that are in your intranet if a security breach does occur on those servers. Both the perimeter network and all of internal network components need to be physically secured against access by anyone other than the administrators. This ensures that no one, not even one of your employees, can weaken security by rearranging cabling or by inappropriately using locally logged in accounts.

Physically separate the perimeter network from other computers and networking equipment, because the perimeter networks critical role in the security of your network demands separate policies and procedures. The smallest changes that are made improperly can create a breach in security that malicious users can exploit. Therefore, apply additional physical security measures so that it is impossible for unqualified staff to change the perimeter network.

In some situations, Windows 2000 Server network security technologies depend on other Windows 2000 security technologies. However, you can leverage these dependencies and policy-based management to simplify extranet security administration. For example, the virtual private network (VPN) Layer Two Tunneling Protocol (L2TP) uses the Internet Protocol security (IPSec) protocol to provide security from the remote client to the VPN server. The safest method that you can use to allow both internal and external users to establish L2TP tunnels to the perimeter network is to configure IPSec security negotiation so that it requires certificates to authorize the connection. When you do this, users need to gain access to at least one certificate server that is trusted on the perimeter network and configured to issue the necessary certificates for IPSec. You can address this requirement by installing a Windows 2000 enterprise certificate server in each forest that contains the computers that must communicate by using IPSec.

Scenario Background

In our scenario, Tailspin Toys manufactures, distributes, and sells childrens toys throughout the world. The major engineering and manufacturing sites are located in Los Angeles, Mexico City, and Hong Kong. Major distribution centers are in Los Angeles and Hong Kong. Other distribution centers are located in England and France. The corporate headquarters and information technology (IT) organization are in Los Angeles.

The toy business has become fiercely competitive. A new product line that is planned for December must be kept secret until merchandise is shipped to stores. Despite strong confidentiality requirements for new designs and marketing campaigns, Tailspin Toys product groups need to collaborate with business partners and external consultants. They need to share design proposals, manufacturing specifications, and marketing plans that contain sensitive, confidential, and proprietary information. The Tailspin Toys company can store this information on secure servers and allow the creator of a document to publish it to everyone or to limit access to only those employees who need to see the documentation. Employee access to information varies, based on their team memberships or project responsibilities. The challenge is about how to extend this simple collaboration scheme to the employees of business partners and to the external consultants. Secure Multipurpose Internet Mail Extensions (S/MIME) e-mail could provide a secure method to exchange the material. However, there are many documents, and the documents frequently change; e-mail is not a reliable change-control mechanism.

Tailspin Toys needs to extend secure file sharing beyond the corporate boundary. However, this file sharing must be done in a way that does not compromise the security of either the corporate network or the data. File sharing must also be cost effective and must allow resource owners to determine who can gain access to their information.

After considering their business requirements, the Tailspin Toys IT organization has decided to deploy an extranet to collaborate with its partners. They will do this by using file share components. The prototype will be limited to a single project, and the Tailspin Toys IT administrators will perform all of the user and system administration. In production, this extranet can be extended to support multiple projects with multiple partners, because it is typically not cost effective to maintain a separate extranet for every project and business relationship. Additionally, components will be added as needed by using the same procedure.

The primary collaboration facility for the extranet will be implemented as a perimeter network local area network (LAN). This is a proven and well-understood technique that you can use for asset isolation (isolating semipublic resources that you can share with external partners from private resources that are on the corporate network). Although the perimeter network LAN topology does complicate access to some resources for Tailspin Toys employees, there are two fundamental reasons for why you would want to isolate the collaboration servers in a perimeter network:

Isolating the collaboration servers in a perimeter network restricts external users to a single network segment with a small number of servers that you can manage and monitor, instead of allowing the external users to gain access to the full corporate network.
The isolation that is provided by a correctly designed perimeter network prevents servers that are on the extranet from being used as entry points for external users to gain unauthorized access to resources that are in the corporate network.

Having decided on the perimeter network approach for asset isolation and the file share building block, Tailspin Toys still needs to determine the best network security techniques for collaboration with its partners. You can deploy Web servers that are directly connected to the Internet and protect them by using HTTPS (secure HTTP that uses Secure Sockets Layer/Transport Layer Security, or SSL/TLS); access to file servers is provided indirectly through a Web interface. If partners need direct access to the file servers, or if they need to share applications that do not support a Web interface, you can provide them with direct, secure access over the Internet by using VPN technology. In this scenario, external user access is possible only through a tunnel (such as through Point-to-Point Tunneling Protocol, PPTP, or through Layer 2 Tunneling Protocol/IPSec, or L2TP/IPSec). The following list describes the three primary network security technologies, as well as their strengths and weaknesses.

Table 4 Network Security Strengths and Weaknesses

	HTTPS	VPN (tunnels)	IPSec
Pro	Easy to deploy Firewall acceptance across platforms	Supports any program Network authentication Controlled IP visibility Robust Connectivity	Encryption at the network layer is transparent to applications End-to-end security
Con	Limited to only programs that are aware of SSL No network	Complex administration Public key infrastructure (PKI) trust management	Difficult to manage the correct IPSec policies and filter rules between companies PKI and trust issues Network Address Translation (NAT) issues
Best for	Publishing Portals Corporate purchasing	Branch offices Joint research and development (R&D) Supply chain	Enterprise intranets

Tailspin Toys uses the VPN approach for the following reasons:

VPN tunnels allow you to require authentication when users connect to the perimeter network. Additionally, VPN tunnels allow standard operating system-based authentication and access control that is enforced when users connect to either shared file servers or Web servers.
VPN tunnels are transparent to the programs. Therefore, VPN supports any type of program protocol and any combination of client or server software. You do not need to modify programs like you would if the company decided to use Secure Sockets Layer/Transport Layer Security (SSL/TLS). This is important because Tailspin Toys anticipates that they will need to add extranet support for additional programs, such as streaming media and video conferencing.
VPN connections prevent the shared file and Web servers from being visible on the Internet. Although you have to properly secure and manage perimeter network servers, the VPN gateways provide an extra layer of security that improves their resistance to external attack. Perimeter network servers are not directly exposed to attacks by malicious users and denial of service attacks. Also, you can safely use routable IP addresses on the perimeter network servers because the perimeter network servers cannot be accessed from the Internet, except through authenticated VPN tunnels. Also, perimeter network servers cannot be probed to disclose their configurations by scanning over the Internet. Routable IP addresses avoid many of the well known conflicts that can occur between NAT with private addresses and security protocols (for example, Kerberos and IPSec) that use cryptographic checksums or encryption to protect network traffic.
You can deploy domain controllers and Domain Name System (DNS) servers directly on the perimeter network. The Tailspin Toys network must be properly secured and managed, just like the file and Web servers; however, the VPN servers provide a single entry point that simplifies securing these servers against external attack. VPN server filters and encrypted tunnels help to prevent these servers and all of their network traffic from being exposed to the Internet.

The VPN approach allows Tailspin to safely deploy a complete Windows 2000 forest infrastructure on the extranet. By making both the file and Web servers members of a Windows domain, Tailspin Toys can apply all of the Windows 2000 authentication and authorization mechanisms to protect shared resources. By deploying a separate forest, you can manage access for all external users and local administrators who have accounts that are localized to the extranet and can gain access to Tailspin Toys resources. Trusts that are one way from the perimeter network domain to corporate account domains allow Tailspin Toys employees to gain access to shared resources by using their corporate user accounts. Trusts must be used with caution because each trust requires connectivity to all of the domain controllers that are in the trusted domain from all of the perimeter network computers whose resources will be accessed. This allows the organization that hosts the extranet perimeter network to exercise explicit control over which users can gain access to extranet resources. It also allows the host to delegate administration of external user accounts to partners without exposing the organizations internal employee account management infrastructure. Although this approach requires external users and local administrators to maintain a separate extranet user account and password, these credentials cannot be used to gain unauthorized access to the corporate network of that users employer if any of the users extranet account is compromised.

To simplify initial deployment and address security considerations, the Tailspin Toys collaboration extranet perimeter network is built in two phases. The emphasis of the prototype phase is to determine the software and operational requirements that are needed to deploy extranets that are running Windows 2000 that securely support collaboration in the company over the Internet. By making a prototype for the extranet in a safe environment where it is not exposed to attack, you can complete all of the installation and basic configuration steps without risk that any temporary vulnerabilities or mistakes that can occur when you apply security policies can be exploited. In the preproduction phase, you can perform a thorough lock down of all servers to establish a security baseline that is appropriate to use for controlled, simulated production with live Internet access. This allows you to test the configuration and operational security measures in a live environment while continuing to limit exposure of real data if a compromise occurs. After you fully understand the issues that can occur when you manage a secure extranet, you can transition the extranet to a production environment where real collaboration occurs. By initially limiting the number of projects and partners, you can evaluate the extranet to determine the advanced security techniques that are necessary to collaborate on multiple projects that have multiple partners by using a common extranet infrastructure.

Prototype Phase

In this example of the prototype phase, there are two perimeter networks in an isolated environment. You create two completely separate extranet perimeter network LANs. Each perimeter network is a separate forest that contains a single Windows domain. The Tailspin Toys Windows NT Server 4.0 domains are TSTEX (Tailspin collaboration partner extranet) and PTREX (partner extranet); these domains have no affiliation or trust between each other or with any other Windows NT Server 4.0 domain. The TSTEX domain is eventually the simulated production extranet perimeter network that is exposed to external partners. PTREX is used to model external partners to facilitate initial creation for both the server and client ends of the VPNs and to work through all of the deployment and security issues.

During the prototype phase, connectivity between the perimeter networks is through an Ethernet hub that emulates the Internet. Each perimeter network includes three servers that have the following roles:

VPN: Dual-homed VPN server for the perimeter network and (emulated) root DNS server for the Internet
Domain controller: Domain controller and certification authority (CA) for the perimeter network and authoritative DNS server for the forest
Resource servers: NTFS file server and Web server

Additional servers are required for availability and performance of resources and services in production.

In the prototype phase, each perimeter network has two DNS servers. The DNS server that is on the domain controller is authoritative for the local DNS domain, tstex.tailspin.tld or ptrex.tailspin.tld. The DNS server on the VPN computer is a root DNS server that emulates the DNS name server hierarchy during prototyping when access to the Internet is not available.

In the prototype phase, a single CA is installed on a dual-purpose server. This is not recommended for a production PKI implementation.

The external network adapters for the two VPN servers are connected to an Ethernet hub that is used to emulate the Internet. Neither perimeter network is connected to the corporate network. The only external access to the servers that are connected to the internal network adapters of the VPN servers is through those VPN servers. The external network adapters for the VPN servers are configured with public IP addresses. The internal IP addressing scheme uses nonroutable IP subnets: 10.0.1.0 for TSTEX, and 10.0.2.0 for PTREX. You can delegate the DNS subdomains that are under tailspin.tld by using local DNS root servers to emulate the real Internet domain name hierarchy.

You should configure and verify that the following VPN connections are functional before you configure any additional servers:

PPTP client-to-router connection
PPTP router-to-router connection
L2TP/IPSec router-to-router connection
L2TP/IPSec client-to-router connection

All tunnels are initiated from PTREX to TSTEX.

Figure 2 Network Diagram of the Tailspin Toys Extranet Prototype

Simulated Production Phase

In the simulated production phase, a security baseline is established so that an administrator can configure both TSTEX and PTREX for simulated production mode and so that TSTEX and PTREX can be connected to the Internet. All servers are locked down, based on the Tailspin Toy security policy. There is no live access by external users; both external partner and employee access is simulated by using VPN connections between the two extranet perimeter networks that you created in the prototype phase.

After securing the servers according to the Tailspin Toys security policy, some DNS modifications are required before you can connect the perimeter networks to the Internet. The local root DNS servers must be reconfigured as DNS forwarders, and the DNS subdomains that are managed by the perimeter network DNS servers must be delegated under a live DNS server for Tailspin Toys. After you do this, you can use the Internet DNS server hierarchy to resolve perimeter network DNS names. After you finish both the security and DNS configuration changes, you can connect the external network adapters for the two VPN gateways to screening routers that have direct Internet access.

After you complete both the server lockdown and DNS changes, and then ensure that any screening routers (in front of your VPN servers) pass the necessary IP traffic to support PPTP and L2TP/IPSec tunnels, you can securely gain access to TST-SRV by using VPN tunnels over the Internet. Initiating tunnels from PTREX to TSTEX should demonstrate the behavior that will be experienced by partner employees in a production environment. Internal employees should also be required to perform network authentication when they connect to resources that are on the perimeter network. The easiest way to accomplish this is to establish an internal VPN server that supports client-to-router connections from the corporate intranet to the perimeter network. This walkthrough does not describe this type of server, but the server's configuration would be similar to the VPN servers that are discussed. Another option would be to require employees to tunnel to the same Internet-facing VPN servers that partners use. However, corporate security policies commonly prevent direct client VPN tunnels to arbitrary endpoints on the Internet. When this occurs, you need to employ a technique that is not addressed in this document. First create a client-to-router tunnel from the users desktop to a designated corporate VPN gateway on the Internet, and then create a second tunnel (inside of the first tunnel) to TST-VPN by using PPTP.

Before you proceed with this section, you should change all of the perimeter network addresses to routable IP addresses. Routable IP addresses avoid many of the well-known conflicts between using NAT (with private addresses) and security protocols (such as Kerberos and IPSec) that use cryptographic checksums or encryption to protect network traffic. It is best to perform testing on the same configuration that will be used in production. Addresses can continue to be statically defined; Dynamic Host Control Protocol (DHCP) is not required for the perimeter network. It is also recommend that you place a firewall between the VPN server and the remainder of the perimeter network to further limit the access of authenticated users.

Deployment Considerations

The two extranet perimeter networks, TSTEX and PTREX, are designed to be:

Self-contained, so they can be deployed without any dependencies on corporate or Internet services.
Isolated to prevent any security risk to corporate resources during design and prototyping.

The domain controller for each of the TSTEX and PTREX domains is the root Windows domain in a new forest. All servers are members of that domain. All administrator and user accounts are members of that Windows domain, except for local computer accounts.

Each perimeter network has its own DNS domain: tstex.tailspin.tld or ptrex.tailspin.tld. The DNS service that is running on the domain controller will be configured as a standard DNS server that is authoritative for that perimeter networks DNS namespace and maintains its zone file. In the prototype phase, the DNS service that is on the VPN computer will be a root DNS server. Each root DNS server will emulate the Internets DNS name server hierarchy down to tailspin.tld by being configured with successively subordinate domains for tld and tailspin under period (.). Also, each root server will have delegations under the tailspin domain, for both TSTEX and PTREX, which point to the respective extranet DNS servers.

The extranets internal DNS server (which is also a domain controller) needs to respond only to external queries that are received through VPN tunnels; the extranet's internal DNS server does not have to be exposed directly to the Internet. You can include the prototype design in your production environment by using the same Windows and DNS domain names, and by changing the root DNS servers to forwarders for client connections to the Internet.

Configure static IP addresses for all of the servers to avoid the increased complexity and potential for attack that DHCP could introduce. For the prototype phase, use internal 10.x.x.x addresses because routing into the interior extranet LANs is not supported at this phase; the only way to connect to the interior extranet LANs is through a VPN tunnel. You should use routable IP addresses for the perimeter network servers in both the simulated production and production phases.

Before You Begin

This detailed example describes the steps that you must use to configure a common extranet infrastructure that allows secure intercompany collaboration. The IP, subnet, network addresses, subnet masks, names of routing interfaces, filter values, and domain names are specific to this example. Although your network configuration may be different than the network configuration that is described here, you can still apply these concepts to your network environment. The following list describes the requirements for this example:

Familiarity with Windows 2000, DNS, and VPN.
Windows 2000 Server Service Pack 1 (SP1) on all of the servers.
For this example, a minimum of six servers.
The suggested minimum hardware configuration of a 300 megahertz (MHz) Pentium II CPU, 256 megabytes (MB) of RAM, and an 8-gigabyte (GB) hard disk.
A hub to connect the extranet perimeter networks during the prototype phase.
The infrastructure to support Internet connectivity (such as screening routers or direct Internet connections) is required in the simulated production phase.
A minimum of two external IP addresses are required for the VPN gateway external network adapters.

Extranet Perimeter Network: Prototype Phase

The prototype phase is crucial for administrators who do not have experience deploying VPNs or perimeter networks that need to be secured for Internet use. You can safely emulate Internet connectivity without exposing the networks to Internet traffic or attacks. When you do this, you can stage a self-sufficient extranet perimeter network and leave the servers in their default security configurations. You can then progressively secure the servers to establish the level of security that is required for production before going live on the Internet. This phased approach is invaluable for determining an understanding of, and confidence in, both the operation and security of perimeter networks. The Tailspin Toys IT administrator builds the perimeter network prototype by completing the following procedures:

Windows 2000 installation and configuration.
Configure static IP addresses
Promote the domain controller
Join the servers to the domain
Emulate the DNS hierarchy and Internet connectivity
Create groups, user accounts, and shared folders
Configure the Routing and Remote Access service on the VPN servers
Test perimeter network isolation and tunnel connections
Install Certificate Services to support L2TP/IPSec

Almost all of this installation and configuration work is required for a production perimeter network. The only aspects of the installation and configuration that are unique to prototyping are the use of a hub to emulate Internet connectivity and local root servers to emulate the Internets DNS hierarchy.

Windows 2000 Installation and Configuration

The administrators first task in the process of creating an extranet perimeter network is the installation of Windows 2000 Server on all of the computers. Two completely separate extranet perimeter networks are created and each consists of three servers in each perimeter network.

Install one network adapter in each of the four domain controllers or file servers.
Install two network adapters in the two VPN servers.
Connect the external network adapter of each VPN server to a common hub.
It is recommended that you install a clean installation of Windows 2000 Server on all of the computers. Install only the specific services that are required for each server role (VPN server, domain controller, or file server), rather than installing all of the default Windows 2000 Server services.

VPN Servers

VPN servers are named with the following sample names:

Tailspin Toys VPN server computer name: TST-VPN
Partner VPN server computer name: PTR-VPN

On each VPN server, install Windows 2000 Server and enable only the following services and components:

Accessories and Utilities: Accessories and Communication
Management and Monitoring: Network Monitor (Netmon)
Network Services: DNS
Script Debugger

Finish the setup procedure:

Use the Typical Network Configuration option.
Create a strong password for the local Administrator account.
Make the server a member of the workgroup that is named "Workgroup."
Quit the Configure Your Server Wizard.
Open the DNS Microsoft Management Console (MMC), and then click Configure DNS Server to start the wizard.
Make a root DNS server. To do this, click This is the first DNS server on network, and then click No, do not create a forward lookup zone.
Install the Windows 2000 Server service packs.

Domain Controllers

Domain controllers are named with the following sample names:

Tailspin Toys domain controller computer name: TST-DC
Partner domain controller computer name: PTR-DC

Install Windows 2000 Server on each domain controller and choose only the following additional services during setup:

Accessories and Utilities: Accessories and Communication
Management and Monitoring: Network Monitor (Netmon)
Script Debugger

Note You can also enable these services after you install Windows 2000 by using the Add/Remove Windows Components Wizard that you can start in the Add or Remove Programs in Control Panel.

Finish the setup procedure:

Use the Typical Network Configuration option.
Create a strong password for the local Administrator account.
Make the server a member of the workgroup that is named "Workgroup."
Quit the Configure Your Server Wizard.
Install Windows 2000 Server Service Packs.

File Server

File servers are named with the following sample names:

Tailspin Toys file server computer name: TST-SRV
Partner file server computer name: PTR-SRV

For each file and Web server, choose only the following additional services during setup:

Accessories and Utilities: Accessories and Communication
Management and Monitoring: Netmon (SNMP optional)
Internet Information Services (IIS): Common Files, Internet Information Services Snap-In, World Wide Web server
Script Debugger

Note You can also enable these services after you install Windows 2000 by using the Add/Remove Windows Components Wizard that you can start in the Add/Remove Programs tool in Control Panel.

Finish the setup procedure:

Use the typical network configuration.
Create a strong password for the local Administrator account.
Make the server a member of the workgroup that is named "Workgroup".
Cancel the Configure Your Server Wizard.
Install Windows 2000 Server service packs.

Configure Static IP Addresses

VPN servers must use static IP addresses for some demand dial configurations. Generally, you should configure the domain controllers and DNS servers that are on each LAN with static IP addresses or reserved DHCP assigned addresses. If you do not do this, DHCP address lease updates could result in servers obtaining a new address that is not fully replicated or expired from relevant caches. This situation could cause a servers name to be incorrectly resolved until the latest information is replicated. In this scenario, all computers, including file servers, are configured with static IP addresses. The Local Area Connection icons are renamed with the IP subnet address for the connections so that it is easier for the administrator to distinguish between the interface connection.

There are a total of six servers, and some of the servers have multiple network interfaces. The following table summarizes the static IP addresses.

Table 5 Static IP Addresses

Company name	Computer name	IP address	Subnet mask	Default gateway	Preferred DNS server	Alternate DNS server	Network interface name
Tailspin	TST-VPN	see below	255.255.255.0	none	10.0.1.1	10.0.1.2	Internet
Tailspin		10.0.1.1	255.255.255.0	none	10.0.1.2		10.0.1.x
Tailspin	TST-DC	10.0.1.2	255.255.255.0	10.0.1.1	10.0.1.2	10.0.1.1	10.0.1.x
Tailspin	TST-SRV	10.0.1.3	255.255.255.0	10.0.1.1	10.0.1.2	10.0.1.1	10.0.1.x
Partner	PTR-VPN	see below	255.255.255.0	none	10.0.2.1	10.0.2.2	Internet
Partner		10.0.2.1	255.255.255.0	none	10.0.2.2		10.0.2.x
Partner	PTR-DC	10.0.2.2	255.255.255.0	10.0.2.1	10.0.2.2	10.0.2.1	10.0.2.x
Partner	PTR-SRV	10.0.2.3	255.255.255.0	10.0.2.1	10.0.2.2	10.0.2.1	10.0.2.x

The VPN server IP addresses are provided by the company.

Use the information that is in Table 5 to configure the static IP addresses for each server:

In the Network Connections folder. right-click Local Area Connection, and then click Rename.
Type the IP subnet address for the network to which the interface is connected.
In the Network Connections folder, right-click the network interface that you renamed in the previous step, and then click Properties.
Click Internet Protocol, and then click Properties.
On the General tab, click Use the following IP address, and then type the appropriate data from the previous table in the following boxes:
- IP address
- Subnet mask
- Preferred DNS server
- Alternate DNS server

Note Leave the Default gateway box blank when you configure VPN servers because their network adapters connect to a network that contains a single subnet.

Promote the Domain Controller

After you install Windows 2000 Server, promote a server to a domain controller so that you can use the domain controller in each perimeter network, and then add Active Directory and DNS. The following table summarizes the domain controller configuration.

Table 6 Domain Controller Configuration

Computer name	Full DNS domain name	Domain name	IP address	Subnet mask	Default gateway
TST-DC	tstex.tailspin.tld	TSTEX	10.0.1.2	255.255.255.0	10.0.1.1
PTR-DC	ptrex.tailspin.tld	PTREX	10.0.2.2	255.255.255.0	10.0.2.1

Use the information in Table 6 to install Active Directory:

Click Start, click Run, type dcpromo, and then press ENTER.
In the Active Directory Installation Wizard, specify the following information:
1. In the Domain Controller Type box, click Domain controller for a new domain.
2. In the Create Tree or Child Domain box, click Create a new domain tree.
3. In the Create or Join a Forest box, click Create a new forest of domain trees.
4. In the New Domain Name box, type the full DNS domain name.
5. In the NetBIOS Domain Name box, accept the default NetBIOS domain name.
6. In the Database and Log Locations box, accept the default settings.
7. In the Shared System Volume box, accept the default setting.
When you receive the following warning message, either confirm your DNS configuration or install and configure a DNS server on this computer, and then click OK:

The wizard cannot contact the DNS server that handles the name tstex.tailspin.tld to determine if it supports dynamic updates.
Specify the following information, and then finish the wizard:
1. In the Configure DNS box, click Yes, install and configure DNS on this computer.
2. In the Permissions box, click Permissions compatible only with Windows 2000 servers.
3. In the Directory Services Restore Mode Administrator Password box, type the password.
Restart the domain controller when you are prompted to do so, and then log on as a domain administrator.
Change the domain from mixed mode to native mode. When you do this, you can use domain local groups and static routes on user objects. To do this:
1. Click Start, click Run, type mmc, and then press ENTER.
2. On the File menu, click Add/Remove Snap-in.
3. Click Add.
4. Click Active Directory Domains and Trusts, and then click Add.
5. Click Finish, click Close, and then click OK.
6. Right-click the domain controller node, and then click Properties.
7. Click the General tab, click Change Mode, and then click Yes.

Note After you change the domain from Mixed mode to Native mode, you cannot change Active Directory back to mixed mode because you cannot run Windows NT Server 4.0 domain controllers in a native mode domain.

Join the Servers to the Domain

After you create the two domains, join both the VPN and file servers to the TSTEX and PTREX domains. Use the information in the following table to do this.

Table 7 Domain Membership of Computers

Domain name	Computer name	Member of
Tailspin	TST-VPN	tstex.tailspin.tld
Tailspin	TST-SRV	tstex.tailspin.tld
Partner	PTR-VPN	ptrex.tailspin.tld
Partner	PTR-SRV	ptrex.tailspin.tld

Complete the following task on each of the VPN and file servers:

Right-click My Computer, and then click Properties.
Click the Network Identification tab, and then click Properties.
Click the Domain in the Member Of box, type the domain name to which you want to join the server, and then click OK.
When you are prompted to provide a user name and a user password to join the computer to the domain, type the administrator credentials, and then click OK.
Restart the computer when you are prompted to do so.
Log on as a local administrator, add the domain administrator account to the built-in Administrators group, log off of the computer, and then log back on as the domain administrator.

Emulate the DNS Hierarchy and Internet Connectivity

When you installed Windows 2000 Server on the VPN servers, you also installed DNS and configured the servers as root DNS servers. After you do this, configure the root DNS servers to emulate the full DNS hierarchy. This approach simplifies the DNS reconfiguration that is required to switch to production mode and Internet connectivity.

Add Delegations to Root DNS (VPN) Servers

To create subdomains and delegations on the root DNS servers, use the following steps on each VPN server:

Open the DNS MMC Snap-in:
1. Click Start, click Run, type mmc in the Open box, and then press ENTER.
2. On the File menu, click Add/Remove Snap-in.
3. Click Add.
4. Click DNS, and then click Add.
5. Click Finish, click Close, and then click OK.
Click Forward Lookup Zones, and then right-click the period (.) entry.
Click New Domain, and then type tld for the name of the new domain.
Right-click the new tld entry, and then repeat step 3 to create a new domain entry for tailspin under the tld domain.
Right-click the tailspin entry.

Click New Delegation, click Next, and then use the following table to create delegation entries for the local DNS subdomain.

Table 8 Delegation Entry

Domain name	Computer name	DNS subdomain	Delegated domain	Server name	IP address
Tailspin	TST-VPN	local	TSTEX	TST-DC	10.0.1.2
Tailspin		remote	PTREX	PTR-DC	10.0.2.2
Partner	PTR-VPN	local	PTREX	PTR-DC	10.0.2.2
Partner		remote	TSTEX	TST-DC	10.0.1.2

To create delegation entries for the local DNS subdomain:

In the Delegated Domain box, type a domain name, and then click Next.
Click Add, type the server name and IP address, and then click OK.
Click Next, and then click Finish.

Repeat Step a through Step c to create a delegation for the remote DNS subdomain.

Test DNS Configuration

After you configure the hierarchy and delegations, use both of the following steps to test the DNS configuration by pinging the servers on both the local and remote perimeter network:

From each server, ping the other two servers on the same perimeter network by using their DNS name.
From each server on one perimeter network, verify that the server can ping all of the servers that are in the other perimeter network by using their DNS name.

Create Groups, User Accounts, and Shared Folders

After you create the user accounts, the user accounts are added to the groups. After the user accounts are added to the groups, the groups are applied to the access lists for the shared folders so that the users can gain access to the shared folders.

Create Groups and User Accounts

This section describes how to create groups, user accounts, and folders on the file servers. You will use these groups, user accounts, and folders later in this document so that you can test both access and permissions to shared folders.

On the domain controller for TSTEX (TST-DC) only, create several groups and user accounts:

Open the Active Directory Users and Computers MMC Snap-in.
1. Click Start, click Run, type mmc in the Open box, and then press ENTER.
2. On the File menu, click Add/Remove Snap-in.
3. Click Add.
4. Click Active Directory Domains and Trusts, and then click Add.
5. Click Finish, click Close, and then click OK.
In the Users folder:
1. Create an TST ALL global group that you can use to control access to file shares.
2. Create the following domain local groups that you can use to control access to file shares:
  
  TST Authors
  
  TST Users
  
  TST Reviewers
  
  TST Publishers
3. Create the following domain user accounts:
  
  user1
  
  TSTuser1
  
  TSTuser2
  
  tstAuth
  
  tstRev
  
  tstPub
For the TSTuser1, TSTuser2, tstAuth, tstRev, and tstPub accounts, use the following steps on each of the accounts:
1. Right-click the account, and then click Properties.
2. Click the Dial-in tab.
3. In the Remote Access Permission (Dial-in or VPN) box, click Allow access, and then click OK.
Make TST Users, TST Authors, TST Reviewers, and TST Publishers members of the TST ALL group.
Make TSTuser1 and TSTuser2 members of the TST Users group.
Make tstAuth a member of the TST Authors group.
Make tstRev a member of the TST Reviewers group.
Make tstPub a member of the TST Publishers group.

On the domain controller for PTREX (PTR-DC) only, create several user accounts:

Open the Active Directory Users and Computers MMC snap-in.
1. Click Start, click Run, type mmc in the Open box, and then press ENTER.
2. On the File menu, click Add/Remove Snap-in.
3. Click Add.
4. Click Active Directory Users and Computers, and then click Add.
5. Click Finish, click Close, and then click OK.
Right-click the Users folder, click New User, and then create the following domain user accounts:
- PTRuser1
- PTRuser2

Create a Shared Folder

To create a shared folder and restrict access to the specified groups:

On TST-SRV only, use Windows Explorer to create a subfolder, TST, in the root of drive C.
To enable file sharing on the server, right-click TST, and then click Properties.
Click the Sharing tab, click Permissions.
Click Add, and then type tstex\administrators, and then grant full control to the built-in Administrators group. To do this click Full Control.
Click the Everyone group, and then click Remove.
Click Add, type tstex\tst all, and then click OK.
Grant the TST ALL group Change and Read permissions. To do this, click both Change and Read, and then click OK.
On the Security tab, add the built-in Administrators group, grant the Administrators group Full Control by clicking Full Control, and then delete the Everyone group.
Add the TST ALL group, and then grant the TST ALL group Modify permissions by clicking Modify.
On TST-SRV computer, open Windows Explorer, and then click the TST folder.
On the File menu, point to New, and then click Folder. Name the new folder Draft Specs.
On the File menu, point to New, and then click Folder. Name the new folder Final Specs.
On the File menu, point to New, and then click Folder. Name the new folder Published Specs.

Test User Account Access Permissions

Log on to the TST-SRV computer with a different user account, and then test the permissions on the TST folder by accessing the share:

Log on to the TST-VPN computer as user1. Use the My Network Places Wizard or the net use command to try and gain access to the TST share on the TST-SRV computer. Access is denied because user1 is not a member of the TST ALL group.
Log on to the TST-VPN computer as TSTuser1. Use the My Network Places Wizard or the net use command to try and gain access to the TST share on the TST-SRV computer. Access is granted because user1 is a member of the TST ALL group.

Configure the Routing and Remote Access Service on VPN Servers

The Routing and Remote Access service provides both remote access and demand-dial routing connections over virtual private networks (VPNs) by using either PPTP or L2TP/IPSec. Remote access is based on client-to-router tunnels, which involves authentication of the dial-up user and authentication between the two computers. Router-to-router demand-dial tunnels involve only authentication of the two computers; no user-level authentication is involved. You can use router-to-router tunnels between VPN servers that are at the edge of the perimeter network to simplify extranet connectivity that is over the Internet and between the host and partner network infrastructures. Client-to-router tunnels provide the easiest method for connectivity for roaming users. Client-to-router tunnels also force partner users to authenticate to the perimeter network before they can gain access to perimeter network computer resources.

Note Before you configure the Routing and Remote Access service to use Windows authentication and domain credentials, make sure that the computer is joined to the domain and that you are logged on as a domain administrator.

Install the Routing and Remote Access Service

After you join the VPN servers to the domain, you can configure routing on each of the VPN servers. Use the following table as a reference when you use the steps in this section to configure routing on the VPN servers.

Table 9 VPN Server Routing

Domain	Computer name	Local area connection	Modem pool IP addresses
Tailspin	TST-VPN	Internet	10.0.1.20 through 10.0.1.30
Partner	PTR-VPN	Internet	10.0.2.20 through 10.0.2.30

To configure routing on each of the VPN servers:

Click Start, click Programs, point to Administrative Tools, and then click Routing and Remote Access to open the Routing and Remote Access MMC Snap-in.
On the Action menu, click Add Server.
In the Add Server dialog box, click OK to accept the default server (This computer).
On the Action menu, click Configure and Enable Routing and Remote Access.
Do the following in each dialog box in the wizard:
1. In the Common Configurations box, click Virtual private network (VPN) server.
2. In the Remote Client Protocols box, click Yes, all of the available protocols are on this list.
3. In the Internet Connection box, click the external local area connection.
4. In the IP Address Assignment box, click From a specified range of addresses.
5. In the Address Range Assignment box, type the static address pool that you want from Table 9.
6. In the Managing Multiple Remote Access Servers box, click No, I don’t want to set up this server to use RADIUS now.
  
  Note When you complete the wizard, you can ignore the DHCP error message. To support the relaying of DHCP messages from remote clients, you must configure the properties of the DHCP Relay Agent with the IP address of your DHCP server.

Create Dial-In Credentials for the Demand-Dial Interface

You must now create domain user accounts to use as the dial-in credentials for the demand-dial interfaces that you will create on the VPN servers in the following section. This manual step is required because the Demand-Dial Interface Wizard cannot create domain accounts, only local accounts. Dial-in credentials are a user account that an answering router uses to authenticate a calling router whenever a demand-dial interface connection is established between them. The user name on the account must exactly match the interface name that you supply when you create the demand-dial interface.

On the TST-DC server, open the Active Directory Users and Computers MMC:
1. Click Start, click Run, type mmc, and then press ENTER.
2. On the File menu, click Add/Remove Snap-in.
3. Click Add.
4. Click Active Directory Users and Computers, and then click Add.
5. Click Finish, click Close, and then click OK.
Right-click the Users folder, and then click New User. Create a user account named DD_PTREX_PPTP.
Right-click the DD_PTREX_PPTP user account, and then click Properties.
Click the Dial In tab, and then, in the Remote Access Permissions box, click Allow Access.

With a VPN tunnel that is initiated one way (which is true for TSTEX because TSTEX does not initiate calls), dial-in credentials are not necessary for the calling VPN router. However, you cannot leave the dial-out credentials blank when you create a demand-dial interface. Because the dial-out credentials that are on a calling router correspond to the dial-in credentials that are on the answering router, a user account is created in the PTREX domain. The new user account simulates dial-in credentials to simplify administrative bookkeeping, but you should not configure it to allow dial-in access.

Create and then disable a new user account on the PTR-DC server, and then open the Active Directory Users and Computers MMC Snap-in:
1. Click Start, click Run, type mmc, and then press ENTER.
2. On the File menu, click Add/Remove Snap-in.
3. Click Add.
4. Click Active Directory Users and Computers, and then click Add.
5. Click Finish, click Close, and then click OK.
In the Users folder, create a DD_TSTEX_PPTP user account.
Right-click the new DD_TSTEX_PPTP user account, and then click Properties.
Click the Dial In tab, and then click Deny Access in the Remote Access Permissions.
Click the General tab, verify that the DD_TSTEX_PPTP account is disabled, and then click OK to disable the account.

Create the PPTP Demand-Dial Interfaces

Because you designed the TSTEX perimeter network to host shared resources for collaboration with external partners, you do not need to establish connections to partners. However, TST-VPN must service tunnels from both client computers and partner VPN routers. Therefore, you should configure the VPN routers that are on both perimeter networks with demand-dial interfaces for PPTP and L2TP that are not persistent and not initiated one way, from PTR-VPN to TST-VPN. Tunnels that are not persistent can improve performance for multiple partners who are at different sites because the connections are disconnected to conserve VPN server resources when no one is using them. Tunnels that are initiated one way help to prevent employees from using the TSTEX perimeter network as an Internet backdoor that bypasses corporate proxy servers.

To create the PPTP demand-dial interfaces:

Click Start, click Programs, point to Administrative Tools, and then click Routing and Remote Access to open the Routing and Remote Access MMC Snap-in.
In the console tree, click to expand Routing and Remote Access, and then click to expand server_name-VPN (where server_name is the name of your server).
Right-click Routing Interfaces, and then click New Demand-dial Interface.
In the dialog box that is displayed on the TST-VPN computer (the answering router), provide the following information:
1. In the Interface Name box, type DD_PTREX_PPTP. The name of an interface should identify the other end of the tunnel, as well as the type of tunnel if you support both PPTP and L2TP. Note that this is the name of the account that you created for dial-in credentials in the previous section.
2. In the Connection Type box, click Connect using virtual private networking (VPN).
3. In the VPN Type box, click Point-to-Point Tunneling Protocol (PPTP).
4. In the Destination Address box, do not type anything because this is tunnel is initiated one way.
5. In the Protocols and Security box, accept the default option for Route IP Packets. Do not click Add a user account so remote router can dial in because this option creates only local computer accounts and you want to use the domain account that you created earlier.
6. In the Dial Out Credentials box, type the dial-in credentials that you created earlier. Note that you must type something in this box, even for an answering router with connections that are initiated one way. You do not need to type a valid user account in the Dial Out Credentials box. Use the dial-in credentials that you created above:
7. In the User Name box, type DD_TSTEX_PPTP.
8. In the Domain box, type PTREX.
On the PTR-VPN computer (the calling router), provide the following information:
1. In the Interface Name box, type DD_TSTEX_PPTP.
2. In the Connection Type box, click Connect using virtual private networking (VPN).
3. In the VPN Type box, click Point-to-Point Tunneling Protocol (PPTP).
4. In the Destination Address box, type the IP address for the external network adapter on TST-VPN. You must use static IP addresses on VPN server network adapters because they statically route to each other. Because of this, use the IP address to avoid DNS lookup.
5. In the Protocols and Security box, accept the default options to route IP packets. Do not click Add a user account so remote router can dial in because this option creates only local computer accounts and you want to use the domain account that you created earlier.
6. In the Dial Out Credentials box, type the credentials that you created earlier. Note that the credentials must be for a valid account that matches the dial-in credentials for the answering router. Type the following:
  
  In the User Name box, type DD_PTREX_PPTP.
  
  In the Domain box, type TSTEX.

Add a Static Route for the Demand-Dial Interface

After you install and configure the routing service, static routes are added to reach network IDs in the perimeter network to control where traffic goes.

Add static routes so that traffic to the perimeter network is forwarded by using the appropriate demand-dial interface. For each route, configure the interface, destination subnet, destination subnet mask, and metric. The Interface box displays the network interface that is used when the packets are forwarded to the network ID, DD_PTREX_PPTP. The Metric box displays the cost of a route. If multiple routes exist to a given destination network ID, the metric is used to determine the route to take. The route with the lowest metric is the preferred route.

Table 10 Static Routes

Domain	Computer name	Interface name	Destination subnet	Destination subnet mask	The Use This Route option
Tailspin	TST-VPN	DD_TSTEX_PPTP	10.0.2.0	255.255.255.0	Clear box
Partner	PTR-VPN	DD_PTREX_PPTP	10.0.1.0	255.255.255.0	Click box

To add a static route for the demand-dial interface:

Click Start, click Programs, point to Administrative Tools, and then click Routing and Remote Access to open the Routing and Remote Access MMC Snap-in.
In the console tree, click to expand Routing and Remote Access, click to expand server_name-VPN (where server_name is the name of your server), click to expand IP Routing, and then click to expand Static Routes.
Right-click Static Routes, and then click New Static Route.
For each VPN server, supply the following information:
1. In the Interface box, click the interface name.
2. In the Destination box, type the destination subnet.
3. In the Network Mask box, type 255.255.255.0.
4. In the Metric box, accept the default value of 1.
5. Either click to clear or click to select the Use this route to initiate demand-dial connections check box, depending on Table 10.

Test Perimeter Network Isolation and Tunnel Connections

Use the procedures in the following sections to confirm that the network is secure and users have the correct level of access.

Test Packet Filters

Verify that the default packet filters that you created by using the Demand-Dial Interface Wizard are working. To do this, ping the external network adapter IP address on TST-VPN from the PTR-VPN computer. When you do this, you receive a host unreachable error message because the default filters do not allow Internet Control Message Protocol (ICMP) traffic.

Test the Router-To-Router Tunnel

Verify that you can manually connect the router-to-router tunnel:

On the PTR-VPN computer, click Start, click All Programs, point to Administrative Tools, and then click Routing and Remote Access to open the Routing and Remote Access MMC Snap-in.
In the console tree, click to expand Routing and Remote Access, click to expand PTR-VPN, and then click to expand Routing Interfaces.
Right-click the DD_TSTEX_PPTP interface.
Click Connect. Note that the ConnectionState column changes from disconnected to connected in 10 to 20 seconds.
From all three of the servers that are on the PTREX computer, verify that you can ping all three of the servers that are on the TSTEX computer by using their full DNS names.

Verify that you can automatically establish the tunnel on demand:

On the PTR-VPN computer, manually disconnect the tunnel. To do this, right-click the DD_TSTEX_PPTP interface, and then click Disconnect.
On the PTR-SRV computer, ping tst-srv.tstex.tailspin.tld. The ping command will not work the first time that you use it, but it will work the second time that you use it. If all attempts to ping tst-srv.tstex.tailspin.tld time out, use the ping command again with the -t switch to ensure that the ping command continues to work until the demand-dial link is established. Perform this step from at least one server in each perimeter network.
On the PTR-VPN computer, click refresh in the Routing and Remote Access MMC Snap-in. The status of the DD_TSTEX_PPTP interface changes to connected.

After you use the previous steps, verify connectivity. Perform the following steps to edit the packet filters for both the TST-VPN and PTR-VPN computers to allow ICMP traffic so that you can ping directly from one VPN server to the external network adapter for the other VPN server. To ping from the PTR-VPN computer to the TST-VPN computer, add the following filters:

Click Start, click Programs, point to Administrative Tools, and then click Routing and Remote Access to open the Routing and Remote Access MMC Snap-in.
In the console tree, click to expand Routing and Remote Access, click to expand server_name-VPN (where server_name is the name of your server), click to expand IP Routing, and then click to expand General.
Right-click Local Area Connection for the external network adapter, and then click Properties. Note that Local Area Connection is displayed as enabled in the Filters column.
In the Properties dialog box on the PTR-VPN computer:
1. Click Allow Echo Request, and then click Echo Reply in.
2. Click Output Filters, and then click Add.
3. In the Protocol box, click ICMP.
4. In the Type box, type 8.
5. In the Code box, type 0, and then click OK.
6. Click Input Filters, and then click Add.
7. In the Protocol box, click ICMP.
8. In the Type box, type 0.
9. In the Code box, type 0, and then click OK.
Click OK to accept the filter changes, and then close the Properties dialog box.
In the Properties dialog box on the TST-VPN computer:
1. Click Echo Request in, and then click Echo Reply out.
2. Click Output Filters, and then click Add.
3. In the Protocol box, click ICMP.
4. In the Type box, type 0.
5. In the Code box, type 0, and then click OK.
6. Click Input Filters, and then click Add.
7. In the Protocol box, click ICMP.
8. In the Type box, type 8.
9. In the Code box, type 0, and then click OK.
Click OK to accept the filter changes, and then close the Properties dialog box.

Note Remove the ICMP filters in a production environment.

Create a Client-To-Router Tunnel

Create a client tunnel connection and use it to connect to the TST-VPN computer. This procedure will establish a client-to-router tunnel that is inside of a router-to-router tunnel. To create a client-to-router tunnel:

On the PTR-SRV computer, in the Network and Dial-up Connections dialog box, right-click Make New Connection, click New Connection, and then provide the following information in the wizard:
1. In the Network Connection Type box, click Connect to a private network through the Internet.
2. In the Public Network box, click Do not dial the initial connection.
3. In the Destination Address box, type the IP address for the external network adapter for the TST-VPN computer.
4. In the Connection Availability box, click For all users.
5. In the Completing the Network Connection Wizard box, type a name for the connection.
On the PTR-SRV computer, finish configuring the new connection, right-click the connection, and then click Properties.
Click the Options tab, verify that all three of the Dialing options are selected, and then click OK.

Test a Client-To-Router Tunnel

On the PTR-SRV computer, test the client-to-router connection:

Connect to the TSTEX perimeter network by using the new connection, and then supply credentials for user1. This procedure does not work because remote access is not permitted for the account.
Repeat step 1 with the TSTuser1 user. This attempt to connect works. If the connection does not work, re-create the connection.

On the TST-VPN computer, verify the remote access client connection:

Click Start, click Programs, point to Administrative Tools, and then click Routing and Remote Access to open the Routing and Remote Access MMC Snap-in.
In the console tree, click to expand Routing and Remote Access, click to expand TST-VPN, and then click to expand Remote Access Clients. If the connection works, the console tree changes to display Remote Access Clients (1) and there is an entry in the details pane for TSTEX/TSTuser1. If the connection does not work, verify that you have completed the procedures that are described earlier in this document.

Install Certificate Services to Support L2TP/IPSec

A PPTP tunnel connection involves a single authentication operation that, by default, is based on the users password. To connect by using an L2TP/IPSec tunnel, you have to use two authentication operations, one of which requires certificates. The easiest method that you can use to issue certificates for L2TP/IPSec is to install Windows 2000 Certificate Services. Windows 2000 includes an integrated public key infrastructure (PKI) that you can use to enable the secure exchange of information across the Internet, extranets, and intranets. In addition to allowing certificate-based IPSec authentication, you can also use certificates to authenticate each user who is involved in an electronic transaction, and allow domain users to log on to a domain by using the additional security that is provided by using smart cards. Windows 2000 Certificate Services is an integral component of Windows 2000 that you can use to deploy enterprise certification authorities (CAs). You can use CAs to both issue and revoke certificates. The certificates are integrated with Active Directory, which simplifies the process of locating CA services and enrolling for certificates by using templates. Active Directory also publishes certificates and certificate revocation lists (CRLs).

This section describes all of the installation and configuration steps that you can use to create both the PKI that is necessary to issue certificates for IPSec and the L2TP/IPSec demand-dial interfaces that can use those certificates. To use L2TP/IPSec tunnels to the perimeter network, the Tailspin Toys administrator must complete the following tasks to correctly install Certificate Services and configure the perimeter network to support L2TP/IPSEC. Note that most of the steps that are related to configuring the LT2P/IPSec demand-dial interfaces are similar to the steps that you use for PPTP.

Install Certificate Services on the TSTEX domain controller.
Install automatic computer certificate enrollment.
Install and enable Router (Offline request) certificate support.
Enable the router certificate template on the CA.
Install Certificate Services Web Enrollment support on the TST-SRV file and Web server.
Enable delegation on the Web server for Web enrollment.
Create L2TP/IPSec tunnel interfaces.
Create domain user accounts for the demand-dial interfaces.
Create L2TP/IPSec demand-dial interfaces.
Add static routes for the demand-dial interface.
Install certificates for L2TP/IPSec.
Request, export, and then import a computer certificate for PTR-VPN.
Request, export, and then import user certificates for both DD_PTREX_L2TP and DD_PTREX_PPTP.
Test the L2TP tunnel.

Install Certificate Services on the TSTEX Domain Controller

Because one-way initiated, demand-dial tunnels require a single CA to issue certificates, it is sufficient for you to install an enterprise root CA on the domain controller for TSTEX. Note that you may need a Windows 2000 Server CD-ROM to complete the Certificate Services installation procedure. To install an enterprise root CA on the domain controller for TSTEX:

On TST-DC, click Start, point to Programs, point to Administrative Tools, and then click Configure Your Server.
Click Advanced, click Optional Components, and then start the Windows Components Wizard.
Click Certificate Services, and then, when you are prompted to continue, click Yes.
Click Details, click both the Certificate Services CA and Certificate Services Web Enrollment Support check boxes, and then click OK.
Click Next to accept the default CA, the Enterprise root CA.
Click Next, and then type the following information in the CA Identifying Information box:
1. In the CA Name box, type Tailspin CA.
2. In the Organization box, type Tailspin Toys.
3. Leave the Organizational unit box blank.
4. In the City box, type Los Angeles.
5. In the State or province box, type CA.
6. In the Country/Region box, type US.
7. Leave the E-mail box blank.
8. Leave the CA Description box blank.
9. In the Valid for box, accept the default value.
Click Next to accept the default data storage locations, and then click Next to finish the wizard.

Install Automatic Computer Certificate Enrollment

The only certificate that is issued through auto-enrollment that will be used for L2TP/IPSec is the certificate that you installed on TST-VPN. To issue this certificate, you must make an automatic certificate request. To do this on TST-DC:

Open the Active Directory Users and Computers MMC:
1. Click Start, click Run, type mmc in the Open box, and then press ENTER.
2. On the File menu, click Add/Remove Snap-in.
3. Click Add.
4. Click Active Directory Users and Computers, and then click Add.
5. Click Finish, click Close, and then click OK.
Right-click the domain name for which you installed the enterprise CA, and then click Properties.
Click the Group Policy tab, click Default Domain Policy, and then click Edit. Note that this step opens the Group Policy MMC Snap-in.
Click to expand Computer Configuration, click to expand Windows Settings, click to expand Security Settings, and then click to expand Public Key Policies.
Right-click Automatic Certificate Request Settings, and then click New.
Click Automatic Certificate Request, and then provide the following information in the wizard:
1. In the Certificate templates box, click Computer.
2. In the Certificate authority box, click the enterprise CA that you just installed.
Finish the wizard, and then click OK to close the Group Policy MMC Snap-in.

To obtain a certificate immediately for TST-VPN, either restart the computer or type the following command at a command prompt:

secedit /refreshpolicy machine_policy

Install and Enable Router (Offline Request) Certificate Support

The default IPSec policy that is associated with L2TP/IPSec tunnels requires that both computers use a certificate that is issued from the same CA. Therefore, the enterprise CA for the TSTEX perimeter network must issue a certificate for the calling VPN router, PTR-VPN. Auto-enrollment works only in a domain. Because if this, you must manually issue and install this certificate. You must use a special template, the Router (Offline request) template, for this process.

Enable the Router Certificate Template on the CA

You must enable the Router (Offline request) template because the CA is not configured to issue this template, by default:

On the TST-DC domain controller, open Certificate Services.
Right-click Policy Settings, point to New, click Certificate to issue, click Router (Offline request) certificate, and then click OK.

Install Certificate Services Web Enrollment Support on the TST-SRV File and Web Server

You can only request the Router (Offline request) certificate by using the Web Enrollment form. Because of this, Certificate Services Web Enrollment support is installed on the TST-SRV Microsoft Internet Information Services (IIS) server. To install Certificate Services Web Enrollment support on the TST-SRV file and Web server:

Click Start, point to Programs, point to Administrative Tools, and then click Configure Your Server.
Click Advanced, click Optional Components, and then start the Windows Components Wizard.
Click Certificate Services, and then click Yes when you are prompted to continue.
Click Details, verify that Certificate Services CA is not selected, verify that Certificate Services Web Enrollment Support is selected, and then click OK.
Click Next, and then use the following steps in the Certificate Services Client Configuration dialog box:
1. In the Computer name box, click Browse, and then click the enterprise CA server that you want to service Web enrollment requests.
2. In the CA box, accept the default; this box is automatically populated with the name of the CA.
When you receive a message about how the computer must be enabled for delegation and Kerberos, click OK.
When you are prompted to stop IIS, click OK, and then finish the wizard.

Enable Delegation on the Web Server for Web Enrollment

If you request certificates through the Web pages that you installed on the TST-SRV computer, the request does not work and you receive a policy error message until you enable the Web server for delegation. Use the following steps to delegate the file and Web server for Web enrollment on the TST-DC domain controller:

Open the Active Directory Users and Computers MMC Snap-in:
1. Click Start, click Run, type mmc in the Open box, and then press ENTER.
2. On the File menu, click Add/Remove Snap-in.
3. Click Add.
4. Click Active Directory Users and Computers, and then click Add.
5. Click Finish, click Close, and then click OK.
Click Computers, and then right-click the entry for TST-SRV.
Click Properties.
Click the General tab, and then click the Trust computer for delegation check box.
When you receive a warning message about the computer being trusted for delegation, click OK, and then click OK.

Create L2TP/IPSec Tunnel Interfaces

The procedure that you can use to creating an L2TP/IPSec tunnel interface is similar to the procedure that you can use to create a PPTP interface. The difference between these two procedures is in how the public key certificates are used. Two authentication procedures are used to connect an L2TP/IPSec tunnel:

The two computers perform mutual authentication while they establish an IPSec security association.

-and-
A second authentication is performed at the point-to-point protocol (PPP) layer by using demand-dial interface credentials (for a router-to-router tunnel) or user credentials (for a client-to-router tunnel).

In general, IPSec can use certificates, Kerberos, or secrets that are already shared. However, IPSec authentication requires certificates when you use the Demand-Dial Interface Wizard to configure an L2TP/IPSec tunnel. (PPP authentication can use either passwords or certificates.) The prototype perimeter network uses passwords for the default demand-dial interface credentials.

Create Domain User Accounts for the Demand-Dial Interfaces

You must manually create domain user accounts for the demand-dial interfaces, because you cannot create domain accounts when you use the Demand-Dial Interface Wizard; you can create only local accounts when you use the Demand-Dial Interface Wizard. Dial-in credentials are a user account that is used for authentication when the user connects to a demand-dial interface on an answering router. The user name must be the same as the name for the interface that you supplied when you created the demand-dial interface. Dial-in credentials determine dial-out credentials for the interface on the calling router. To create domain user accounts for the demand-dial interfaces on the TST-DC server:

Open the Active Directory Users and Computers MMC:
1. Click Start, click Run, type mmc in the Open box, and then press ENTER.
2. On the File menu, click Add/Remove Snap-in.
3. Click Add.
4. Click Active Directory Users and Computers, and then click Add.
5. Click Finish, click Close, and then click OK.
Right-click the Users folder, and then click New User.
Create a user account named DD_PTREX_L2TP.
In the Properties dialog box, click the Dial In tab in the Remote Access Permissions box, and then click Allow Access.

With one-way initiated VPN tunnels, you do not need dial-in credentials for the calling VPN router; however, you cannot leave the dial-out credentials blank when you create a demand-dial interface. Because of this, you must also create a user account in the PTREX domain:

On the PTR-DC server, open the Active Directory Users and Computers MMC:
1. Click Start, click Run, type mmc, and then press ENTER.
2. On the File menu, click Add/Remove Snap-in.
3. Click Add.
4. Click Active Directory Users and Computers, and then click Add.
5. Click Finish, click Close, and then click OK.
Right-click the Users folder, and then click New User.
Create a user account named DD_TSTEX_L2TP.
Click the Dial In tab in the Remote Access Permissions box in the Properties dialog box, and then click Deny Access.
Click the General tab, click the Account is disabled check box, and then click OK to disable the account.

Create L2TP/IPSec Demand-Dial Interfaces

On the TST-VPN computer (the answering router), provide the following information in the Demand Dial Interface Wizard:

In the Interface Name box, type DD_PTREX_L2TP. The name of an interface should identify the computer that is at the other end of the tunnel and specify that the tunnel is L2TP.
In the Connection Type box, click Connect using virtual private networking (VPN).
In the VPN Type box, click Layer Two Tunneling Protocol (L2TP).
Leave the Destination Address box blank for a tunnel that is initiated one way.
In the Protocols and Security box, accept the default option for Route IP Packets. Do not click the Add a user account so remote router can dial in check box because it creates only local computer accounts and you want to use the domain account that you created earlier.
In the Dial Out Credentials box, use the credentials that you previously created:
1. In the User Name box, type DD_TSTEX_L2TP.
2. In the Domain box, type PTREX.
  
  Note You cannot leave the Dial Out Credentials box blank, even for an answering router with connections that are initiated one way. You do not, however, have to use a valid user account.

On PTR-VPN computer (the calling router), provide the following information:

In the Interface Name box, type DD_TSTEX_L2TP.
In the Connection Type box, click Connect using virtual private networking (VPN).
In the VPN Type box, click Layer Two Tunneling Protocol (L2TP).
In the Destination Address box, type the IP address for the external network adapter for the TST-VPN computer. Because VPN server network adapters must use static IP addresses (they have static routes to each other), use the IP address for the network adapters to avoid DNS lookup.
In the Protocols and Security box, accept the default option, Route IP Packets. Do not click the Add a user account so remote router can dial in check box because it creates only local computer accounts and you want to use the domain account that you created previously.
In the Dial Out Credentials box, provide a valid account that is the same as the dial-in credentials for the answering router. Use the credentials that you created previously:
1. In the User Name box, type DD_PTREX_L2TP.
2. In the Domain box, type TSTEX.

Add Static Routes for the Demand-Dial Interface

After you install and configure the Windows 2000 routing service, static routes are added to reach network IDs that are in the perimeter network to control where traffic goes. You add static routes so that traffic to the perimeter network is forwarded by using the appropriate demand-dial interface. For each route, configure the interface, destination, network mask, and metric. The Interface box displays the network interface that is used by the routing service when forwarding packets to the network ID; the interface name that you previously created is used. The Metric box displays the cost of a route. If multiple routes exist to a given destination network ID, the metric is used to determine which route is to be taken. The route with the lowest metric is the preferred route.

Use the following table to add static routes for the demand-dial interface.

Table 11 Static Routes for the Demand-Dial Interface

Domain name	NetBIOS name	Interface name	Destination network	Destination subnet mask	The Use This Route option
Tailspin	TST-VPN	DD_PTREX_L2TP	10.0.2.0	255.255.255.0	Clear box
Partner	PTR-VPN	DD_TSTEX_L2TP	10.0.1.0	255.255.255.0	Click box

To add static routes for the demand-dial interface:

Click Start, click Programs, point to Administrative Tools, and then click Routing and Remote Access to open the Routing and Remote Access MMC Snap-in.
Click to expand Routing and Remote Access, click to expand server_name-VPN (where server_name* *is the name of your server), click to expand IP Routing, and then click to expand Static Routes.
Right click Static Routes, and then click New Static Route.
On each of the VPN servers, provide the following information in the New Static Route Wizard:
1. In the Interface box, click the interface name.
2. In the Destination box, type the destination network address.
3. In the Network Mask box, type 255.255.255.0.
4. In the Metric box, accept default value of 1.
5. In the Use this route to initiate demand-dial connections box, either click to select or click to clear the check box, depending on Table 11.

You cannot have two static routes that have same Destination and Metric values, and that are both configured with the Use this route to initiate demand-dial connections option. The most efficient method that you can use to avoid tunnel connection errors is to select this option for only one demand-dial interface static route at one time, either PPTP or L2TP. Therefore, on the PTR-VPN computer, click Properties for the DD_TSTEX_PPTP static route, and then click to clear the Use this route to initiate demand-dial connections check box.

Install Certificates for L2TP/IPSec

When an L2TP/IPSec tunnel is connected, the VPN routers perform mutual authentication at the IPSec layer by using certificates. The default IPSec policy requires that these certificates are issued from the same CA. Note that these certificates were created when you used the Demand-Dial Interface Wizard to configure an L2TP/IPSec tunnel. The calling and answering router certificates must include client and server authentication, respectively, in their extended key usage (EKU) attributes.

Because this sample is an example of a tunnel that initiated one way, both certificates are issued from the enterprise CA that is on the answering perimeter network (TSTEX). This allows the perimeter network host to control who can connect to it, and it simplifies Certificate Revocation List (CRL) checking. The answering VPN router (TST-VPN) can use its computer certificate that was obtained earlier through auto enrollment. You must manually issue and install a computer certificate for the calling VPN router (PTR-VPN).

Map Certificates to User Accounts

Certificates must be issued for the dial-in user accounts that you previously created, DD_PTREX_PPTP and DD_PTREX_L2TP. You must then map these certificates to the user accounts. You can use the Router (Offline request) template to request these certificates. You must use the following procedures on the issuing computer and on the user certificates:

Request and install Router (Offline request) certificates by using the Web enrollment form on the TST-SRV computer that is in the TSTEX domain.
Export the computer certificate to a .pfx file.
Import the computer certificate to the PTR-VPN computer.
Export the user certificates to .cer files.
Import the user certificates to the TST-DC computer.
Map the user certificates to the DD_PTREX_PPTP and DD_PTREX_L2TP user accounts.
Test the L2TP/IPSec tunnel operation.

Request and Install Router (Offline Request) Certificates

For each user account on the TST-SRV computer, start Internet Explorer, and then navigate to the https://hcp-srv/CertSrv Web page. To request a certificate for the DD_PTREX_L2TP user account:

On the Welcome page, click Request a certificate, and then click Next.
Click Advanced request, and then click Next.
Click Submit a certificate request to this CA using a form, and then click Next.
Provide the following information in the Advanced Certificate Request form:
1. In the Certificate Template box, click Router (Offline request).
2. In the Name box, type the user account name that is used by the calling router.
3. In the Key Options box, click Mark keys as exportable and Use local machine store, and then click Submit.
On the Certificate Issued page, click Install this certificate.

Repeat these steps to request a certificate for the DD_PTREX_PPTP user account.

Export the Computer Certificate

To export the computer certificate:

On the TST-SRV computer, open the Certificates (Local Computer) MMC Snap-in:
1. Click Start, click Run, type mmc in the Open box, and then press ENTER.
2. On the File menu, click Add/Remove Snap-in.
3. Click Add.
4. Click Certificates, and then click Add.
5. Click Finish, click Close, and then click OK.
Click to expand Personal; and then click Certificates.
In the Details pane, right-click the certificate that you just installed for DD_PTREX_L2TP.
On the Action menu, point to All Tasks, and then click Export.
Provide the following information in the Certificate Export Wizard:
1. Click Yes, export the private key. Note that this option is available only if the private key is able to be exported and if you have access to the private key.
2. Click the file format that you want to use to store the exported certificate. Click Personal Information Exchange - PKCS #12 (.PFX), click Include all certificates in the certification path if possible, click Delete the private key if the export is successful (do not click Enable strong protection), and then click Next.
3. Type the password that is required to protect the private key, and then click Next.
4. In the File to Export box, type the full path name for the file, c:\tst\ptr-vpn_key, and then click Finish.

Use Windows Explorer to remove the TST All group from the security permissions for ptr-vpn_key.pfx, and then add TSTuser2 with default permissions. In the lab environment, import the certificate from the Partner perimeter network with the Tailspin Toys administrator managing both perimeter networks. In a production environment, the domain administrator for the partner perimeter network is provided with both the password for the TSTuser2 account and the password for the .pfx file.

Import the Computer Certificate

On the PTR-VPN computer, use the domain administrator account to establish a PPTP tunnel to the TST-VPN computer. Access the TST folder by using credentials for TSTuser2, and then copy ptr-vpn_key.pfx to the local hard disk. To import the computer certificate:

Open the Certificates (Local Computer) MMC Snap-in:
1. Click Start, click Run, type mmc in the Open box, and then press ENTER.
2. On the File menu, click Add/Remove Snap-in.
3. Click Add.
4. Click Certificates, and then click Add.
5. Click Finish, click Close, and then click OK.
Click to expand Personal, and then click Certificates.
Right-click Certificates, click All Tasks, and then click Import.
Provide the following information in the Certificate Import Wizard:
1. In the File to Import box, type the full path to the ptr-vpn_key.pfx file, and then click Next.
2. Type the password that is used to encrypt the private key, do not mark the private key as exportable, and then click Next.
3. Click Automatically select the certificate store based on the type of certificate, click Next, and then click Finish.

Export the User Certificates

Export the user certificates:

On the TST-SRV computer, open the Certificates (Local Computer) MMC Snap-in:
1. Click Start, click Run, type mmc in the Open box, and then press ENTER.
2. On the File menu, click Add/Remove Snap-in.
3. Click Add.
4. Click Certificates, and then click Add.
5. Click Finish, click Close, and then click OK.
Click to expand Personal, and then click Certificates.
In the Details pane, right-click the certificate that you just installed for DD_PTREX_L2TP.
On the Action menu, point to All Tasks, and then click Export. The Certificate Export Wizard starts.
Click No, do not export the private key (note that this option is available only if the private key is marked as exportable and you have access to the private key), and then click Next.
Click DER encoded binary X.509 (.CER), and then click Next.
In the File name box, type the full path to the c:\tst\dd_ptrex_l2tp file, and then click Next.
Click Next to finish the wizard.

Repeat all of these steps to export a certificate for the DD_PTREX_PPTP user account.

Import the User Certificates

On the TST-DC domain controller, the administrator accesses the TST directory on TST-SRV, where the exported certificates were placed. To import the user certificates:

Open the Certificates (Local Computer) MMC snap-in, click to expand Personal, and then click Certificates.
Right-click Certificates, click All Tasks, and then click Import. The Certificate Import Wizard starts.
In the File to Import box: type the full path name for the DD_PTREX_L2TP certificate in the File name box, and then click Next.
Click Automatically select the certificate store based on the type of certificate, click Next, and then click Finish.

Repeat all of these steps to import a certificate for the DD_PTREX_PPTP user account.

Map the User Certificates

To map the user certificates:

Open the Active Directory Users and Computers MMC Snap-in.
On the View menu, click Advanced Features.
In the console tree, click Users.
In the details pane, right-click the DD_PTREX_L2TP user account, and then click Name Mappings.
Click the X.509 Certificates tab, and then click Add.
In the Add Certificate dialog box, click the appropriate certificate file, click Open, and then click OK.

Repeat all of these steps to map the certificate for the DD_PTREX_PPTP user account.

Test the L2TP/IPSec Tunnel Operation

On PTR-VPN, verify that you can manually connect the DD_TSTEX_L2TP interface. This will verify that IPSec is working correctly with the Router (Offline request) certificate. The tunnel layer authentication will use the dial-out credentials password.

Note Occasionally, you may need to restart the VPN server after you install the computer certificate so that the computer can successfully authenticate.

To verify that you can manually connect the router-to-router tunnel:

On PTR-VPN, open the Routing and Remote Access MMC Snap-in.
Click to expand Routing and Remote Access, click to expand PTR-VPN, and then click Routing Interfaces.
Right-click DD_TSTEX_L2TP.
Click Connect. The ConnectionState entry changes from "disconnected" to "connected" in 10 to 20 seconds.
From all three servers on PTREX, verify that you can ping all three servers on TSTEX by using their full DNS names.

Verify that the tunnel will be established automatically on demand. On PTR-VPN manually disconnect the tunnel:

Right-click DD_TSTEX_L2TP, and then click Disconnect.
From PTR-SRV, try to ping tst-srv.tstex.tailspin.tld. The ping command may not work on the first attempt, but it will work on the second attempt. If all attempts time out, use the ping command again. Use the -t switch to ensure that the ping command continues until the demand-dial link is established. Perform this step from at least one server in each perimeter network.
On PTR-VPN, in the Routing and Remote Access MMC Snap-in, right-click PTR_VPN, and then click Refresh. The status of the DD_TSTEX_L2TP interface changes to "connected."

If the tests are unsuccessful, verify connectivity. Edit the packet filters on TST-VPN and PTR-VPN to allow ICMP traffic so that you can ping directly from one VPN server to the external network adapter of the other. To ping from PTR-VPN to TST-VPN add the following filters:

Open the Routing and Remote Access MMC Snap-in.
Click to expand Routing and Remote Access, click to expand server_name-VPN (where server_name-VPN is the name of the VPN server), click to expand IP Routing, and then click to expand General.
Right-click the local area connection for the external network adapter (the local area connection is displayed as "enabled" in the Filters column), and then click Properties.

On PTR-VPN allow Echo Request out and Echo Reply in:

Click Output Filters, and then click Add.
In the Protocol box, click ICMP.
In the Type box, type 8.
In the Code box, type 0, and then click OK.
Click Input Filters, and then click Add.
In the Protocol box, click ICMP.
In the Type box, type 0.
In the Code box, type 0, and then click OK.
Click OK to accept the filter changes, and then close the Properties dialog box.

On TST-VPN, allow Echo Request in and Echo Reply out:

Click Output Filters, and then click Add.
In the Protocol box, click ICMP.
In the Type box, type 0.
In the Code box, type 0, and then click OK.
Click Input Filters, and then click Add.
In the Protocol box, click ICMP.
In the Type box, type 8.
In the Code box, type 0, click OK, and then click OK.

Note Remove these ICMP filters in a production environment.

Prototype Extranet Perimeter Network- Best Practices

This section provides some best practices for a prototype extranet perimeter network.

When you deploy a secure extranet perimeter network, you have to stage multiple servers, install different software combinations, and configure a number of security-related parameters. Keep a detailed log book of every software installation and configuration step. The log book will help you troubleshoot any issues in production and document the configuration if you have to reconfigure the systems.
Invest the time to work out the final DNS and Windows domain names. Security is improved and DNS configuration is easier if you create local root DNS servers with delegations for both of the perimeter network DNS servers. You do not need to expose either internal DNS server to the Internet. The DNS server that is on the answering perimeter network does not have to be contacted until after a VPN tunnel is established and all of the traffic between the internal DNS servers is protected inside of the tunnel. You can leverage your investment in Windows and DNS domain names and roll the prototype extranet perimeter network into production mode if you change the root DNS servers to forwarders when you connect them to the Internet.
An extranet looks like a local area network (LAN), but you should not manage it like one. The connectivity and security issues are far more complex for an extranet than they are for a LAN. During the prototype stage, develop a detailed network diagram and keep it up to date. A detailed network diagram is invaluable for communicating with the IT organization when you need to order Internet connections, subnet address space, DNS delegations, router protocol, and packet filter configurations.
Before you configure a server that is running Routing and Remote Access to use Windows authentication and domain credentials, make sure that the computer is joined to the domain and that you are logged on as a domain administrator. If the computer is not joined to the domain and you are not logged on as a domain administrator, the server will not be added to the RAS and IAS Servers group in Active Directory. Also, tunnels to that router will not work and you will receive authentication server did not respond in a timely fashion error message. If you configure the server that is running Routing and Remote Access without complying with these conditions, manually add the computer account for this server to the RAS and IAS Servers group in the domain of which this server is a member. A domain administrator can do this by using the Active Directory Users and Computers MMC Snap-in or by using the netsh ras add registeredserver command at a command prompt.
PPTP tunnels are much easier to configure than L2TP/IPSec; however, the PPTP protocol is not as secure as L2TP/IPSec. It is very possible that PPTP passwords may not be changed frequently because changing the passwords requires a coordinated effort between administrators who are in two different companies. Because of this, you should use L2TP/IPSec for production.
After you fist configure VPN servers to use demand-dial interfaces for L2TP/IPSec tunnels, the interfaces may not connect and you may receive an error occurred during connection of the interface. The L2TP connection attempt failed because the security negotiation timed out error message. To resolve this behavior, always restart the VPN servers after you configure L2TP/IPSec interfaces.
Note that the default requirements for certificates that you use with L2TP/IPSec are the opposite of the PKI for SSL requirements. For SSL mutual authentication, the client and server can be issued certificates from different organizational CAs. It is necessary for them to import only each others root CA certificate. The default IPSec policy that is created by the server that is running the Routing and Remote Access Demand-Dial Interface Wizard requires that both VPN routers are issued certificates from the same CA.
If you install or reinstall DNS on the VPN server after you join it to the domain, the VPN server requires a workaround to force the Configure DNS Server Wizard to give you the First DNS server on network option, which allows you to create a root DNS server. You must temporarily remove any static IP addresses for DNS servers from the properties for the two Local Area Connections on the VPN server. Also, a zone file for the perimeter networks DNS subdomain (TSTEX or PTREX) is automatically created at the same level as the period (.) zone file. You must delete this perimeter network zone file entry.
Avoid using the calling router as a client to test tunnels. You can, however, use the calling router to manually connect or disconnect demand-dial interfaces. Use another computer in the domain to test ping, client-to-router connections, and file share access through tunnels. If you perform these tests from the VPN server, you may have unexpected results because of the VPN server's dual network adapters, routing tables, and packet filters.
You must configure the IIS server for delegation if you want to install Certificate Services Web Enrollment Support on the IIS server. When you configure the IIS server for delegation, some security-related concerns are introduced if the server is compromised. However, the risk that is introduced when you configure the IIS server for delegation may be preferable to the risk that is introduced when you install IIS on the domain controller, which is what is required if you directly install Web enrollment support on the enterprise CA.

Extranet Perimeter Network-Simulated Production

Now that you have successfully configured and tested the prototype, integrate security measures so that you can configure TSTEX and PTREX for a simulated production mode. The Tailspin Toys administrator locks down all of the servers, based on the company security policy and the IIS security checklist, to create a baseline security parameter for the perimeter network. External users and external partners are not involved in this phase, and all access to the perimeter network is simulated by using VPN connections between the two perimeter networks.

After you lock down all of the servers, both perimeter networks are connected to the Internet. The external network adapters for the two VPN servers may be connected to direct Internet taps. You should reconfigure the local root DNS servers as DNS forwarders. You must delegate the DNS subdomains that are managed by the perimeter network DNS servers under a live DNS server for Tailspin Toys. Now you can use the Internet DNS server hierarchy to resolve perimeter network DNS names.

Notes

If a direct Internet connection is not available in your lab environment, coordinate Internet connectivity through your IT administrator or modify the walkthrough to complete only the lockdown steps.

It is likely that a production extranet perimeter network will require routable IP addresses. Therefore, you should change all perimeter network IP addresses to routable addresses before you proceed with this phase to ensure that testing is performed on the same configuration that you will deploy in production. IP addresses can continue to be statically defined; DHCP is not required for the perimeter network. This avoids conflicts between network address translation (NAT) and security protocols, such as Kerberos and IPSec.

Because there is no trust relationship between the perimeter network and the internal network, any employee who needs access to the file server needs a local TSTEX account. This is the Internet VPN access to the TSTEX perimeter network that is available in the Tailspin Toys lab environment at the end of this phase of the walkthrough.

Figure 3 Simulated Production Extranet Perimeter Network Internet Access

This section primarily details with the security configuration that is required to lock down all of the servers before you expose them to the risks that are inherent in a production environment. This section also addresses both the network and DNS configuration changes that are required to transition from the simulated Internet environment to live Internet use.

The following steps are the primary steps that the Tailspin Toys administrator must complete to deploy a simulated production extranet perimeter network:

Secure all of the servers for Internet use.

Note If you are not familiar with this procedure, consider working with outside consultants.
Use Group Policy to manage security configuration.
Configure VPN tunnels for Extensible Authentication Protocol (EAP) authentication.
Connect the perimeter network to the Internet.
Switch from an emulated to a live DNS hierarchy.
Create a secure collaborative workspace on the file server.
Test workspace access over VPN tunnels.
Create a secure Web folder interface.

Important The security lock down techniques and procedures that are described in this section are extensive and necessary; however, this list does not include all of the steps that you can perform. Microsoft does not guarantee that these steps are sufficient to protect a perimeter network against all possible types of attack or compromise. It is very important that you build all production perimeter networks by using rigorous physical security and a comprehensive security policy.

Secure All of the Servers for Internet Use

Locking down a Windows domain-based perimeter network for live Internet access is a complicated process. It is not enough to make sure that the firewall (the VPN server and border router) are configured correctly. You also need to protect the domain controllers and DNS servers, as well as the Web and file servers. There are a number of configuration procedures that you can use to lock down servers before you connect a perimeter network to the Internet. Use the basic lockdown procedures in this section to secure the servers that are in the Tailspin Toys and Partner perimeter networks.

Use the procedures in this section on all of the servers, unless otherwise specified. As a precaution, you should create an emergency repair disk (ERD) for each computer, including the registry state, before you start the lockdown process. The backup procedure includes a wizard to help you create an ERD. You can use the emergency repair process to restore core system files.

The ERD allows you to make only basic system repairs, such as to the system files, boot sector, and startup environment. The ERD does not back up data, programs, or the registry, and it is not a replacement for system backups. To create an ERD, view the "How to Create an Emergency Repair Disk in Windows 2000" Microsoft Knowledge Base article at https://support.microsoft.com/?id=231777

To secure the servers in both perimeter networks:

Restrict default NTFS permissions.
Remove unnecessary access to files.
Secure local user accounts.
Restrict access from the network.
Enforce robust authentication.
Secure the registry.
Disable unnecessary network services.
Apply more restrictive security settings to help protect the computer against attacks that use the TCP/IP protocol.
Disable unnecessary default services.
Time service synchronization.
Configure strong auditing.
Protect perimeter network servers with IP packet filters.
Apply the IIS checklist to lock down Web servers for Internet access.
Install all patches or updates.

Restrict Default NTFS Permissions

For each hard disk on every computer, modify the DACL in the root folder:

Open Windows Explorer, and then right-click the hard disk.
Click Properties, and then click the Security tab.
Add the local Administrators group, and then give the Administrators group Full Control permissions.
Modify permissions for the Everyone group to apply to Domain Users instead, and then click Advanced.
Click Everyone, and then click View/Edit.
Click Change, and then, in the domain scope that is displayed in the Look in box, click Authenticated Users.
Click OK, click OK, click OK, and then click OK to close all of the dialog boxes and accept the changes.

Open Windows Explorer, right-click the icon for each of the following folders

Documents and Settings
Program Files
WINNT

and then use the following procedure on each folder to modify DACLs that do not inherit permissions form the root:

Click Properties, and then click the Security tab.
Modify permissions for Users to apply to Authenticated Users instead, and then click Advanced.
Click Users, and then click Edit on the View menu.
Click Change, and then click Authenticated Users in domain scope.
Click OK, and then click OK.
Remove the accounts for Power Users and Everyone by clicking Remove.
Click OK, and then click OK to close all of the dialog boxes and accept the changes.

Modify DACLs on Winnt\Repair and Winnt\System32\config to restrict access to the computers local security account manager (SAM) database:

In Windows Explorer, right-click the icon for the folder.
Click Properties, and then click the Security tab.
Modify permissions for Users to apply to Authenticated Users, and then click Advanced.
Click Users, and then, on the View menu, click Edit.
Click Change, and then click Domain Users in domain scope.
Click OK, and then click OK.
Remove accounts for Power Users and Everyone by clicking Remove.
Click OK, and then click OK to close all of the dialog boxes and accept the changes.

Remove Unnecessary Access to Files

Disable auto-generation of 8.3 names for backward compatibility with16-bit applications. In a secure environment, you should avoid using 16-bit applications. Set the following registry key:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\FileSystem\NtfsDisable8dot3NameCreation = reg_dword: 1

Remove default administrative network file shares:

For each hard drive on all computers, remove the default share (C$, D$, and so on).
Open Windows Explorer, and then right-click the icon for the hard drive.
Click Sharing, click Do not share this folder, and then click OK.
For the system volume, remove the default administrative share (Admin$), and then right-click the %Windir% folder.
Click Sharing, click Do not share this folder, and then click OK.
Set this registry key so that default shares will not be re-created:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\ LanmanServer\Parameters\AutoShareServer = reg_dword: 0

Caution Incorrectly editing the registry may severely damage your system. Before making changes to the registry, you should back up any valued data on the computer.

Secure Local User Accounts

Use the following steps to help make compromise more difficult for a malicious user:

In the Local Users MMC Snap-in rename the Administrator account. Create a fictitious Administrator account (an unprivileged local account named Administrator) that has no rights and is disabled. Make sure both accounts have strong passwords.

Note On domain controllers, do not rename the Administrator account. Copy it to create a working administrator account, and then remove all privileges and group memberships from the original account. This avoids the administrator account relative ID (RID).
Limit the membership of the local Administrators group.
Make sure that the Guest account is disabled and give it a strong password. For more information about strong passwords, see https://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/serverhelp/D406B824-857C-4C2A-8DE2-9B7ECBFA6E51.mspx.
Disable the TsInternetUser account and give it a strong password. This account is automatically created, both locally and on the domain, when the operating system is installed. Disable the account instead of deleting it; otherwise, any later system upgrades will recreate the account if it does not exist.
Disable the IUSR_computer account on the Web server and give it a strong password.

Restrict Access from the Network

Restrict unnecessary network access to the domain and servers:

If not already created in the prototype phase, create a top-level group (TST ALL) that can be used to control network access to the VPN, file, and Web servers. The user accounts created for the demand-dial interface dial-in credentials and all users who need to access the TST file share, should be made members of groups that roll up this group. Also add a domain administrative account to this group.
Disable network access for both the local Administrator and Administrators accounts. Force these accounts to require interactive access. You can also do this by using Group Policy:
1. Click Start, point to Programs, point to Administration Tools, click Local Security Policy, click Local Policies, and then click User Rights Assignment.
2. Right-click Access this computer from network.
3. Click Administrators, and then click OK.

Enforce Robust Authentication

By default, the "enforce robust authentication" options are not enabled. Do not use the TweakUI tool (the Autologon tool that is included in the Windows 2000 Resource Kit) or modify the registry to enable automatic logon. Robust authentication is enforced by the following procedures:

Configure all IIS virtual folders to require authentication. This includes disabling the Anonymous account.
Enforce strong passwords. The recommended minimum length is between 9 and 11 characters. It is also recommended that punctuation or other nonalphabetic characters are contained in the first seven characters of the password. This makes the password more difficult to guess because of the way that Windows 2000 creates the hash of the password. You can also do this through Group Policy.
Enable an account lockout threshold that will cause an account to be locked out after a defined number of logon attempts that do not work. You can also do this through Group Policy.
Enforce NTLMv2 response. Windows 2000 clients use NTLMv2 authentication and NTLMv2 session security if the server supports it. Domain controllers accept LM, NTLM, and NTLMv2 authentication. On all of the servers, set the following registry key:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\ LSA\LMCompatibilityLevel = reg_dword: 3

Secure the Registry

Secure the registry configurations on the servers to prevent unwanted access or modification to the registry:

Restrict anonymous access to the registry to prevent users who are not authenticated from enumerating shares and local or domain users. Set the following registry key:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\ Control\LSA\RestrictAnonymous = reg_dword: 1
Restrict remote network access to the registry.
Create the following registry key and set the registry key's DACL to grant access only to domain administrators:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\ Control\SecurePipeServers\Winreg
Change the file association for the .reg file extension to a file extension for a text editor, such as Notepad.exe. This prevents a malicious Web site from inserting new registry keys into your registry while you are browsing the Web.

Disable Unnecessary Network Services

By default, many network services are enabled that are not required in a secured perimeter network. To disable the unnecessary network services:

Disable NetBIOS over TCP/IP. This helps to prevent the computer from listening on port 139 and divulging your perimeter networks security-relevant configuration by responding to NBSTAT queries. For every physical network adapter on all servers:
1. In Network and Dial-up Connections, right-click Local Area Connection, and then click Properties.
2. Click Internet Protocol (TCP/IP), and then click Properties.
3. Click Advanced, and then click the WINS tab.
4. Click Disable NetBIOS over TCP/IP, and then click to clear the Enable LMHOSTS lookup check box.
5. Click OK, click Yes, click OK, and then click OK.
Set the following registry key:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\ NetBT\Parameters\NoNameReleaseOnDemand = reg_dword: 1

Note After you follow these steps, you need to use full DNS host names instead of short NetBIOS names for all programs. You can use the nbstat -a (-a) command to determine what the administrator account is if they the administrator is currently logged on and NetBIOS over TCP/IP is enabled.
On only the VPN routers, unbind file and print sharing from all physical and demand-dial network interfaces:
1. Right-click Local Area Connection or right-click the demand-dial interface.
2. Click Properties.
3. Click to clear File and Printer Sharing for Microsoft Networks.

Distributed COM (DCOM) is enabled by default. If you do not specifically need it, disable it. You should disable DCOM for all of the servers on both of the perimeter networks:

Click Start, click Run, type cmd in the Open box, and then press ENTER.
Type Dcomcnfg.exe at a command prompt, and then press ENTER.
Click Default Properties.
Click to clear Enable Distributed COM for this computer, and then click OK.

Apply More Restrictive Security Settings for TCP/IP

Apply more restrictive security settings to help protect the computer against attacks that use the TCP/IP protocol. To do this, set or create the following registry keys under the HKEY_LOCAL_MACHINE\System\CurrentControlSet\ Services\Tcpip\Parameters registry key:

EnableICMPRedirect = reg_dword: 0
EnableSecurityFilters = reg_dword: 1
SynAttackProtect = reg_dword: 1
EnableDeadGWDetect = reg_dword: 0
EnablePMTUDiscovery = reg_dword: 0
KeepAliveTime = reg_dword: 300000
DisableIPSourceRouting = reg_dword: 1
TcpMaxConnectResponseRetransmissions = reg_dword: 2
TcpMaxDataRetransmissions = reg_dword: 3

Set or create the following registry keys under the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\AFD\Parameters registry key:

DynamicBacklogGrowthDelta = reg_dword: 10
EnableDynamicBacklog = reg_dword: 1
MinimumDynamicBacklog = reg_dword: 20
MaximumDynamicBacklog = reg_dword: 20000

Disable Unnecessary Default Services

When you first installed Windows 2000 Server, you selected only the minimum number of components, based on the servers role in the perimeter network. Do not install Simple TCP/IP services as one of your network services. Do not install FTP unless you absolutely need it.

Despite the minimal components that you installed during the Windows 2000 setup procedure, each server is still running unnecessary default services. To improve both security and reliability, disable all unnecessary services that are installed on all of the servers:

Right-click My Computer, and then click Manage.
Click Services and Applications, and then click Services.
For each of the following services, right-click the entry in the details pane, click Properties, and then, for the Startup Type on the General tab, click Disabled:
- Alerter
- ClipBook
- Computer Browser
- Distributed File System
- Distributed Link Tracking Client
- Distributed Ling Tracking Server
- Distributed Transaction Coordinator
- Fax Service
- Internet Connection Sharing
- Intersite Messaging (this service must be running on all domain controllers if you are using multiple sites)
- Messenger
- NetMeeting Remote Desktop Sharing
- Network DDE
- Network DDE DSDM
- Remote Access Auto Connection Manager
- Task Scheduler
- Telnet
- Terminal Services
- Utility Manager
On the VPN servers, disable the following services:
- File Replication
- Print Spooler
On the file servers and the domain controllers, also disable the following two services:
- Remote Registry Service: You can set this back to Manual and start the service if you need to use Netdiags.exe.
  
  Note You cannot disable the Remote Registry service on the VPN servers because the Routing and Remote Access MMC Snap-in uses it to access configuration parameters that are stored in the registry.
- Telephony
  
  Note You cannot disable the Telephony service on the VPN servers because the Routing and Remote Access service uses part of the Telephony API (TAPI) subsystem to manage WAN miniports for PPTP and L2TP. Also, you cannot disable client servers that use Remote Access Connection Manager.

Time Service Synchronization

You must enable auditing both for accountability and to detect potential misuse of privilege and attacks. At a minimum, audit at least log on and log off, user and group management, restart and shutdown, and security policy changes. Other events that should be audited are folder access, file and object access, and system events. You can also enable auditing through Group Policy.

Protect Perimeter Network Servers with IP Packet Filters

The Demand Dial Interface Wizard automatically adds packet filters to the VPN servers when you create the PPTP and L2TP/IPSec interfaces. Filters for both types of tunnels are created on the external network adapter to prevent any other type of IP traffic from entering or leaving the server. You can improve security by editing these filters and changing the appropriate IP addresses from "any" to the IP address of the external network adapter. To protect perimeter network servers with IP packet filters:

On the VPN servers, open the Routing and Remote Access MMC snap-in, click to expand Routing and Remote Access, click to expand server-name-VPN, click to expand IP Routing, and then click to expand General.
Right-click the local area connection for the external network adapter (named Internet), and then click Properties.
Click Input Filters and do the following for every filter in the list:
1. Click Edit.
2. Click to select Destination network.
3. In the IP address box, type the IP address of external network adapter.
4. In the Subnet mask box, type 255.255.255.255.
5. Click OK, and then click OK
Click Output Filters and use the following steps for every filter that is in the list:
1. Click Edit.
2. Click Source network.
3. In the IP Address box, type the IP address of external network adapter.
4. In the Subnet mask box, type 255.255.255.255.
5. Click OK, and then click OK to accept filter changes and close the Properties dialog box.

You can delete one filter on the answering TST-VPN server because this is a demand-dial PPTP interface that is initiated as one way. This filter is necessary only to allow dial-out requests. If you delete the filter, you can help prevent malicious users from using simulated PPTP requests (originating from port 1723) to probe any port that is on the answering server. Open Input Filters (described in the step 3 in this section) and remove the filter that is described in the following table.

Table 13 PPTP Filter

Source address	Source mask	Destination address	Destination mask	Protocol	Source port	Destination Port
Any	Any	external network adapter IP address	255.255.255.255	TCP	1723	Any

Apply the IIS Checklist to Lock Down Web Servers for Internet Access

Review the configuration that is specified in the IIS security checklist that is available on the Microsoft Security Advisor Web site at https://www.microsoft.com/technet/security/prodtech/default.mspx. You can configure many of the Windows 2000 Server system settings through the security template (HisecWeb.inf) that is available in the Microsoft Knowledge Base at https://support.microsoft.com/default.aspx?scid=kb;en-us;316347&sd=tech. The IIS Lockdown tool (IISLock) provides recommendations and best practices that you can use to optimize secure Web servers. Note that the settings provide more security than the functionality; therefore, it is important that you understand how the changes will affect your environment.

IISLock is available at https://www.microsoft.com/technet/security/tools/locktool.mspx.

Install All Patches or Updates

To install all patches or updates, go to the Microsoft Update Web site at https://update.microsoft.com/microsoftupdate/. You should install all relevant patches on each server to ensure that each computer is up-to-date and secure.

Use Group Policy to Apply Security Templates (Optional)

You can create and apply security policies to simplify and centralize the process of configuring and managing network security. Because each type of server (VPN, domain controller, file and Web server) may have specific security requirements, the Tailspin Toys administrator can create organizational units for each type of server. The administrator can then create a customized security template for each type of server and install the resulting Group Policy to the organizational unit. These tasks would be completed only on the servers that are in the TSTEX domain.

Create Computer Organizational Units in Active Directory for Each Type of Server

To create computer organizational units in Active Directory for each type of server:

In Active Directory Users and Computers MMC Snap-in, right click the TSTEX domain.
Click New, and then click Organizational Unit.
Type VPN Servers, and then click OK.
Repeat steps 1 through 4 to create an organizational unit called File Servers.

Note You do not need to create an organizational unit for the domain controller, because a domain controllers organizational unit exists by default.
Click the Computer organizational unit.
Right-click the TST-VPN server, and then click Move.
Click the VPN Servers organizational unit, and then click OK.
Repeat steps 5 through 7 with TST-SRV to move the Computer object into the File Servers organizational unit.

Create a Customized Security Template for Each Type of Server

Each type of server needs a different security configuration. Although the differences will most likely be minor, automated management works best if you create a distinct template for each type of server. Open both the Securews.inf and Securedc.inf templates to create customized security policies for servers and domain controllers, respectively, and then make the changes that match your perimeter network security policy.

You should restrict who can log on from the network, for example, because the VPN servers are directly exposed to the Internet. View the Restrict Access from Network section for more information. Set the Access this computer from the network option for a group that contains only users or groups who need to create VPN tunnels to the perimeter network by using the Internet. Specifically, remove the default permissions of Administrators for network access. Another example is restricting interactive access. Only administrators and server operators should be able to interactively log on to VPN servers and domain controllers. Set the Log on locally option accordingly:

Open the Security Templates MMC snap-in, and then click to expand the default Templates folder.
Right-click securews, click Save As, and then type SecureVPN.inf.
Right-click this new template, make the changes that are common to VPN servers, file servers, and Web servers, and then save the template.
Right-click SecureVPN.inf, and then save the file as SecureSRV.inf.
Make the unique changes that are required for each of the two new templates, based on internal security policies and procedures.
Save each template.
Right-click securedc, click Save As, and then type SecureDC.inf.
Right-click this new template, make the changes that you want for the domain controller (based on internal security policies and procedures), and then save the template.

Set Group Policy for Each Computer Organizational Unit

Add Group Policy to each of the three computer organizational units, VPN servers, file servers, and domain controllers by using the appropriate template:

In the Active Directory Users and Computers MMC, locate the organizational unit where you want to install the policy:
1. Right-click the organizational unit, and then click Properties.
2. On the Group Policy tab, click New, and then type a descriptive name for the new policy.
3. Click the new policy, and then click Edit.
4. In Windows Settings, right-click Security Policies, and then click Import Policy.
5. Click the correct policy for the organizational unit, and then click Clear the database before importing.
6. Click Open, close Group Policy, and then click Close.
Repeat these steps for each organizational unit.

Note The domain controller organizational unit has a default policy, so make sure that the new policy is first in the list. To do this, click the Up button on the Group Policy tab.

Configure VPN Tunnels for EAP Authentication

After you establish the IPSec security association for an L2TP/IPSec tunnel, a second authentication is performed at the PPP layer. The demand-dial interface on the calling VPN router must authenticate to the answering router by presenting the appropriate dial-in credentials. This defaults to password-based authentication. The administrator can force certificate-based authentication for PPP by enabling Extensible Authentication Protocol (EAP) on both interfaces and by selecting a certificate for the calling interface to use. With EAP-TLS, the calling router sends a user certificate that is validated by the answering router.

You may decided that the PPTP tunnels should be configured to require EAP and to use certificates for user authentication. The PPTP encryption key is derived from the secret that you used during authentication, which is either the password or the key from the certificate. You can fundamentally improve PPTP protection if you require certificates. You can also apply certificates to L2TP/IPSec tunnels, but this procedure is not as critical because the IPSec layer authentication uses certificates. When you enable EAP and clear all password options on the answering router, you can prevent the use of passwords, or you can allow both certificates and passwords and you can individually configure the calling router interfaces. If you allow passwords, use only the Microsoft CHAP version 2 (MS-CHAP v2) authentication protocol.

Configure the Calling Interface to Require EAP

To configure the calling interface to require EAP:

In the PTREX domain, on PTR-VPN, open the Routing and Remote Access MMC Snap-in.
Click to expand Routing and Remote Access, click to expand PTR-VPN, and then click Routing Interfaces.
Right-click the DD_TSTEX_PPTP demand-dial interface, and then click Properties.
On the Security tab, click Advanced (custom settings), and then click Settings.
In the Advanced Security Settings dialog box, click Use Extensible Authentication Protocol (EAP), and then make sure that Smart Card or other Certificate (encryption enabled) is selected in the box.
Click Properties, and then click Validate Server Certificate, click Connect only if the server name ends with, click OK, click OK, and then click OK.
In the details pane, right click DD_PTREX_PPTP, and then click Set credentials.
In User Name For Certificate, click the DD_PTREX_L2TP user certificate for this interface, and then click OK.

Note You imported the root CA certificate in a .pfx file, along with the Router (Offline request) certificate, and you installed in the Trusted Root store on PTR-VPN.

Configure the Answering Router to Accept EAP

To configure the answering router to accept EAP:

On TST-VPN, open the Routing and Remote Access MMC Snap-in.
Double-click Routing and Remote Access, and then double-click TST-VPN.
In the console tree, double-click Remote Access Policies.
In the details pane, right-click Allow Access if Dial-in Permission is Enabled, and then click Properties.
Click Edit Profile, and then, on the Authentication tab, click Extensible Authentication Protocol, click Smart Card or other Certificate, and then click Configure.
Click the computer certificate that was issued to TST-VPN by auto enrollment, and then click OK.

This will be the default certificate if you have not issued or imported any other certificates into the local computer store.
Click the Microsoft Encrypted Authentication version 2 (MS-CHAP v2) and Microsoft Encrypted Authentication (MS-CHAP) check box, click OK, click No, and then select Grant remote access permission.

Note The default policy is used to avoid the additional complexity of creating a new policy. For production, it is recommended that you create a new policy.

Connect Extranet Perimeter Networks to the Internet

This section describes how to connect extranet perimeter networks to the Internet.

Screening Router Configuration

After you complete the previous tasks, you should establish a security baseline. Assuming that Internet access will be provided through routers, you can set packet filters that will allow only the traffic that needs to flow between your VPN routers. Almost all of the traffic that flows to and from the domain controllers and file servers occurs inside of the VPN tunnels, so the traffic is invisible to the routers. This means that the routers can impose fairly restrictive filters. Make sure that the routers pass all of the outbound and inbound traffic that is required for DNS, PPTP, L2TP, Internet Key Exchange (IKE), and IPSec to only the required destinations. Also, enable at least ICMP (echo, echo reply) during debugging.

Default Gateway Configuration

If you are using a network router, set the default gateway on the external network adapter of the VPN routers to the address of the network router. To do this:

Right-click the local area connection for the external network adapter in the Network and Dial-up Connections folder, and then click Properties.
Click Internet Protocol (TCP/IP), and then click Properties.
Click the General tab, and then type the network routers IP address in the Default gateway box.

Verify Internet Connectivity

To verify Internet activity:

If you are using a network router, manually establish a PPTP tunnel from PTR-VPN to TST-VPN. If this succeeds, use Netmon to verify that the network router is passing PPTP traffic in both directions, and then repeat this process for L2TP.
On PTR-VPN, verify that you can manually connect the DD_TSTEX_PPTP interface. This will verify that IPSec is working correctly with the Router (Offline request) certificate. The tunnel layer authentication will use the dial-out credentials password.
Verify that you can manually connect the router-to-router tunnel:
1. On PTR-VPN, open the Routing and Remote Access MMC Snap-in.
2. Click to expand Routing and Remote Access, click to expand PTR-VPN, and then click Routing Interfaces.
3. Right-click DD_TSTEX_PPTP.
4. Click Connect. The ConnectionState column entry changes from "disconnected" to "connected" in 10 to 20 seconds.
From all three servers on PTREX, verify that you can ping all three servers on TSTEX by their full DNS names.
Verify that the tunnel will be automatically established on demand:
1. On PTR-VPN, manually disconnect the tunnel. To do this, right-click DD_TSTEX_PPTP, and then click Disconnect.
2. From PTR-SRV, try to ping hcp-srv.tstex.tailspin.tld. The ping command does not work the first time that you use it but should work the second time that you use the command. If all attempts to use the ping command time out, use the ping command again, but use the -t option to ensure that ping command continues until the demand dial link is established. Perform this step from at least one server in each perimeter network.
3. On PTR-VPN, click refresh.

Change Root DNS Server to Forwarder

To change the root DNS server to a forwarder, use the following steps on each of the VPN servers:

Open the DNS MMC for all addresses except for the internal network adapters IP address.
Close the dialog box to accept changes.
In the Forward Lookup Zones box, delete the period (.) zone entry.
Stop the DNS service.
Copy the Systemroot\System32\DNS\Samples\Cache.dns file to the Systemroot\System32\DNS working DNS folder.
Restart DNS, and then verify that Root Hints are populated.

Add DNS Filters on VPN Servers

To allow name resolution and registration on each of the VPN servers:

Open the Routing and Remote Access MMC.
Double-click Routing and Remote Access, double-click the VPN server, double-click IP Routing, and then click General.
Right-click the local area connection for the external network adapter, and then click Properties
Click Input Filters, click Add, click Destination Network, type the address for the external network adapter in IP Address, and then type 255.255.255.255 in Subnet Mask.
Click UDP in the Protocol box, type 53 in the Source Port box, type 0 in the Destination Port box, click OK, and then click OK to accept filter changes and close the dialog box.

Verify that you can manually connect the router-to-router tunnel:

On PTR-VPN, open the Routing and Remote Access MMC.
Double-click Routing and Remote Access, double-click PTR-VPN, and then click Routing Interfaces.
Right-click DD_TSTEX_PPTP, and then click Connect.

When you click Connect, the connection state changes from "disconnected" to "connected" in 10 to 20 seconds.
From all three servers on PTREX, verify that you can ping all three servers on TSTEX by their full DNS names.

Verify that the tunnel will be automatically established on demand:

On PTR-VPN, manually disconnect the tunnel. To do this, right-click DD_TSTEX_PPTP, and then click Disconnect.
From PTR-SRV, try to ping hcp-srv.tailspin.tld.

If all of the attempts to use the ping command time out, try to use the ping command again with the -t option to ensure that ping continues until the demand dial link is established. Perform this step from at least one server in each perimeter network.
On PTR-VPN, click refresh on the Routing and Remote Access MMC.

The status of the DD_TSTEX_PPTP interface changes to "connected."

If the ping command does not work, use the nslookup command to verify that your local DNS subdomain is properly delegated and your local DNS servers name and IP address are properly registered on your corporate DNS server. For example, use the nslookup hcp-dc.tstex.tailspin.tld command for TST-DC. This command isolates the perimeter network and allows the perimeter network administrator maximum control over who is allowed access. It also guarantees that Kerberos authentication will work because the user and server accounts are in the same forest. However, this introduces extra management overhead for the Tailspin Toys administrator, who must create and manage these accounts. For more information about how this overhead could be offloaded by using administrative delegation at the organizational unit level, see the Active Directory information in Help. The lack of trust also has an impact on the user authentication experience. Users (Tailspin Toys or partner employees) log onto their corporate network by using their corporate credentials. They are prompted for additional credentials when they try to gain access to perimeter network resources. In production, this will not be acceptable to internal employees. Trust from the perimeter network to user account domains provides single sign-on, but most likely only NTLM will succeed. Refer to Active Directory documentation for more information about how to create trusts that are one way from the perimeter network to internal corporate account domains. It is important that you carefully think about the benefits and risks of such trusts and the connectivity that they require.

Before you move the perimeter network into production, you should complete further testing with actual files and business partners. The benefits of piloting the perimeter network to internal and external users include uncovering any security weaknesses and resolve issues that arise from user feedback. It is not possible to identify all of the security decisions that a company might make based on its unique criteria in this walkthrough. Additionally, infrastructure decisions depend on the business requirements of the companies that are involved, including planning on scalability and reliability.

Making a pilot or beta available also provides the ability for the IT administrator to understand and explore if the trusts between the perimeter network and the corporate network are appropriate. Doing this will also help you determine if the trusts between the perimeter network and partner networks are appropriate. Domain trust dramatically affects user account management, resource DACL management, user authentication, and credential management. You need to find the balance between the demands for granular access control, simplified administration, and risk management. However, Microsoft recommends that you avoid this type of trust.

References

The following references were used to help create this paper. Please view them for more information:

Microsoft Internet Information Server 4.0 Security Checklist https://www.microsoft.com/technet/security/prodtech/default.mspx
Chapter 17, Deployment Planning Guide: Determining Windows 2000 Network Security Deployment Planning Guide: Determining Windows 2000 Network Security https://www.microsoft.com/technet/prodtechnol/ windows2000serv/reskit/deploy/home.mspx

An Extranet Deployment Walkthrough and Best Practices Guide for Secure Business-to-Business Collaboration

On This Page

Summary

Scenario Background

Prototype Phase

Simulated Production Phase

Deployment Considerations

Before You Begin

Extranet Perimeter Network: Prototype Phase

Windows 2000 Installation and Configuration

VPN Servers

Domain Controllers

File Server

Configure Static IP Addresses

Promote the Domain Controller

Join the Servers to the Domain

Emulate the DNS Hierarchy and Internet Connectivity

Add Delegations to Root DNS (VPN) Servers

Test DNS Configuration

Create Groups, User Accounts, and Shared Folders

Create Groups and User Accounts

Create a Shared Folder

Test User Account Access Permissions

Configure the Routing and Remote Access Service on VPN Servers

Install the Routing and Remote Access Service

Create Dial-In Credentials for the Demand-Dial Interface

Create the PPTP Demand-Dial Interfaces

Add a Static Route for the Demand-Dial Interface

Test Perimeter Network Isolation and Tunnel Connections

Test Packet Filters

Test the Router-To-Router Tunnel

Create a Client-To-Router Tunnel

Test a Client-To-Router Tunnel

Install Certificate Services to Support L2TP/IPSec

Install Certificate Services on the TSTEX Domain Controller

Install Automatic Computer Certificate Enrollment

Install and Enable Router (Offline Request) Certificate Support

Enable the Router Certificate Template on the CA

Install Certificate Services Web Enrollment Support on the TST-SRV File and Web Server

Enable Delegation on the Web Server for Web Enrollment

Create L2TP/IPSec Tunnel Interfaces

Create Domain User Accounts for the Demand-Dial Interfaces

Create L2TP/IPSec Demand-Dial Interfaces

Add Static Routes for the Demand-Dial Interface

Install Certificates for L2TP/IPSec

Map Certificates to User Accounts

Request and Install Router (Offline Request) Certificates

Export the Computer Certificate

Import the Computer Certificate

Export the User Certificates

Import the User Certificates

Map the User Certificates

Test the L2TP/IPSec Tunnel Operation

Prototype Extranet Perimeter Network- Best Practices

Extranet Perimeter Network-Simulated Production

Secure All of the Servers for Internet Use

Restrict Default NTFS Permissions

Remove Unnecessary Access to Files

Secure Local User Accounts

Restrict Access from the Network

Enforce Robust Authentication

Secure the Registry

Disable Unnecessary Network Services

Apply More Restrictive Security Settings for TCP/IP

Disable Unnecessary Default Services

Time Service Synchronization

Protect Perimeter Network Servers with IP Packet Filters

Apply the IIS Checklist to Lock Down Web Servers for Internet Access

Install All Patches or Updates

Use Group Policy to Apply Security Templates (Optional)

Create Computer Organizational Units in Active Directory for Each Type of Server

Create a Customized Security Template for Each Type of Server

Set Group Policy for Each Computer Organizational Unit

Configure VPN Tunnels for EAP Authentication

Configure the Calling Interface to Require EAP

Configure the Answering Router to Accept EAP

Connect Extranet Perimeter Networks to the Internet

Screening Router Configuration

Default Gateway Configuration

Verify Internet Connectivity