Active Directory Replication Over Firewalls
This article is based on an article in the Microsoft TechNet Library and is presented here to enable those outsides of Microsoft who are interested and knowledgeable on this topic to improve it.
More recent guidance regarding Active Directory replication in Windows Server 2008 is in the article Active Directory Domain Services in the Perimeter Network (Windows Server 2008).
More recent guidance about Microsoft support boundaries for using Active Directory with Network Address Translation is at http://support.microsoft.com/default.aspx?scid=kb;EN-US;978772.
More recent information about network port requirements for Windows Server System is at http://support.microsoft.com/kb/832017
Introduction
Firewalls present two difficulties when deploying a distributed Active Directory (AD) directory service architecture:
- Initially promoting a server to a domain controller.
- Replicating traffic between domain controllers.
Active Directory relies on remote procedure call (RPC) for replication between domain controllers. (Simple Mail Transfer Protocol [SMTP] can be used in certain situations—schema, configuration, and global catalog replication, but not domain naming context—limiting its usefulness.) Getting replication to function properly in environments where a directory forest is distributed among internal, perimeter networks and external (that is, Internet-facing) networks can be challenging. There are three possible approaches:
- Open the firewall wide to permit RPC's native dynamic behavior.
- Limit RPC's use of TCP ports and open the firewall just a little bit.
- Encapsulate domain controller (DC-to-DC) traffic inside the IP Security Protocol (IPSec) and open the firewall for that.
Each approach has its pros and cons. In general, there are more cons than pros at the top of the list, and more pros than cons at the bottom. So although this document describes how to do all three, most of its focus is on the IPSec approach because of its benefits over the other two.
Full Dynamic RPC
| Pros | Cons |
| No special server configuration | Turns the firewall into "Swiss cheese" |
| Random incoming high-port connections | |
| Insecure firewall configuration |
Although configuring your environment to work this way is certainly possible, there are plenty of reasons not to do it—most importantly—it results in an insecure network. It does, however, require the least amount of configuration work.
To enable replication over dynamic RPC, configure your firewall to permit the following:
| Service | Port/protocol |
| RPC endpoint mapper | 135/tcp, 135/udp |
| Network basic input/output system (NetBIOS) name service | 137/tcp, 137/udp |
| NetBIOS datagram service | 138/udp |
| NetBIOS session service | 139/tcp |
| RPC dynamic assignment | Win 2k/2003:1024-65535/tcp
Win 2008+:49152-65535/tcp |
| Server message block (SMB) over IP (Microsoft-DS) | 445/tcp, 445/udp |
| Lightweight Directory Access Protocol (LDAP) | 389/tcp |
| LDAP ping | 389/udp |
| LDAP over SSL | 636/tcp |
| Global catalog LDAP | 3268/tcp |
| Global catalog LDAP over SSL | 3269/tcp |
| Kerberos | 88/tcp, 88/udp |
| Domain Name Service (DNS) | 53/tcp1, 53/udp |
| 1 | TCP is used for zone transfers and whenever answers to questions exceed 512 bytes. |
For a reference of Windows port requirements, see:
832017 Service overview and network port requirements for the Windows Server system (http://support.microsoft.com/default.aspx?scid=kb;EN-US;832017)
It is that "RPC dynamic assignment" rule that makes this scenario insecure. Sometimes referred to as "TCP high ports," the rule needs to permit inbound traffic on any port above 1024 in 2000-2003 and ports above 49152 in 2008 and newer. If your firewall permits this, there is very little reason even to have a firewall.
If you do not want to permit DNS or WINS, you can use HOSTS (for DNS) and LMHOSTS (for WINS) files for name resolution. These files are stored in %SystemRoot%\system32\drivers\etc. Look inside the files for information on how to use them.
How RPC Works
An RPC service configures itself in the registry with a universally unique identifier (UUID) (similar to a globally unique identifier [GUID]). UUIDs are well-known identifiers, unique for each service and common across all platforms. When an RPC service starts and it does not ask for a specific port from the runtime, it obtains a free high port and registers that port with the UUID. The port assignment is static for the lifetime of the service.
When a client wants to communicate with a particular RPC service, it cannot determine in advance which port the service is running on most of the time. Some RPC interfaces document a known endpoint (port) they use. This is not done for any of the RPC interfaces used by AD.
So it establishes a connection to the server's portmapper service (on 135) and requests the service it wants by using the service's UUID. The portmapper returns the corresponding port number to the client and closes the connection. Finally, the client makes a new connection to the server by using the port number it received from the portmapper.
Because it is impossible to know in advance which port an RPC service will use, the firewall must permit all high ports through.
Limited RPC
| Pros | Cons |
| More secure than dynamic RPC—only one open high port | Registry modification to all servers |
| Attackers may use open port once they identified it |
This scenario gives you more security, but it does require making registry modifications to all your domain controllers. Registry modifications can be scripted with tools like REG.EXE, which helps eliminate configuration errors.
You must decide upon fixed port numbers for AD replication and SYSVOL file replication service (FRS or DFSR). The Internet Assigned Numbers Authority (IANA) has set aside the range 49152 through 65535 for use by private and dynamic assignments.
Using the registry editor, navigate to this registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\
Add a new DWORD value called TCP/IP Port (include the space). Set the value's data to the port number that you want to use (remember to change the displayed base to decimal before you enter the data). Install the hotfix available in MSKB 2827870 if you implement this registry setting on Windows Server 2008 R2 domain controllers.
For File Replication Service, navigate to this registry key:
- HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTFRS\Parameters\
Add a new DWORD value called RPC TCP/IP Port Assignment (include the spaces). Set the value's data to the port number that you want to use (remember to change the displayed base to decimal before you enter the data).
The Distributed File Services Replication Service includes the Dfsrdiag.exe command-line tool. Dfsrdiag.exe can set the server RPC port that is used for administration and replication. To use Dfsrdiag.exe to set the server RPC port, follow this example:
dfsrdiag StaticRPC /port: nnnnn /Member: Branch01.sales.contoso.com
In this example, nnnnn represents a single, static RPC port that DFSR will use for replication. Branch01.sales.contoso.com represents the DNS or NetBIOS name of the target member computer. If no member is specified, Dfsrdiag.exe uses the local computer.
Do this on all your Active Directory servers. In Windows 2000 and 2003, you need to restart the server so the "NTDS" setting is picked up. In Windows 2008 and newer it's sufficient to restart "Active Directory Domain Services". This will also restart NTFRS used for SYSVOL. You still need to manually restart the "DFS Replication" service.
Now configure your firewall to permit the following:
| Service | Port/protocol |
| RPC endpoint mapper | 135/tcp, 135/udp |
| NetBIOS name service | 137/tcp, 137/udp |
| NetBIOS datagram service | 138/udp |
| NetBIOS session service | 139/tcp |
| RPC static port for AD replication | <AD-fixed-port>/TCP |
| RPC static port for FRS or | <FRS-fixed-port>/TCP |
| RPC static port for DFS Replication | <DFSR-fixed-port>/TCP |
| SMB over IP (Microsoft-DS) | 445/tcp, 445/udp |
| LDAP | 389/tcp |
| LDAP ping | 389/udp |
| LDAP over SSL | 636/tcp |
| Global catalog LDAP | 3268/tcp |
| Global catalog LDAP over SSL | 3269/tcp |
| Kerberos | 88/tcp, 88/udp |
| DNS | 53/tcp, 53/udp |
Replace <AD-fixed-port>, <FRS-fixed-port> and <DFSR-fixed-port>/TCP with the port numbers that you used in the registry values.
As before, if you do not want to permit DNS or WINS, you can use HOSTS (for DNS) and LMHOSTS (for WINS) files for name resolution. These files are stored in %SystemRoot%\system32\drivers\etc. Look inside the files for information on how to use them.
You still need the endpoint mapper because clients will not know that you fixed the ports. The endpoint mapper always returns your fixed ports when clients request the port numbers associated with AD's and FRS's RPC UUIDs.
You should pick a port for AD and FRS RPC services that is clear of the standard port allocation by the TCP/IP stack and that is not a commonly used port. For Windows 2008 and newer, choose a range below 49152 and create a list containing ports and the service they are assigned to (AD server port, FRS port, DFS-R port, app service X port, …). Your network security folks may already have such a list, so ask them to put you on it for the ports you need. For example, the ports they give you are 34223, 34224 and 34225 (in hex 85AF, 85B0 and 85B1). Create a reg file from this text then:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters]
"TCP/IP Port"=dword:000085AF
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTFRS\Parameters]
"RPC TCP/IP Port Assignment"=dword:000085B0
And use: "dfsrdiag StaticRPC /port:34225 /Member: Branch01.sales.contoso.com Top of page
RPC UUID filtering firewalls
| Pros | Cons |
| More secure than dynamic RPC—only one open high port | Client request timing can cause sporadic errors |
| Only interfaces allowed by the Firewall admin traverse the firewall |
A new class of firewalls is available where administrators can specify the RPC interfaces that are allowed across the network. The firewall would monitor the RPC endpoint mapper requests and responses. When a request is successful and the interface is permitted, it would create a table entry of known RPC servers and allow the RPC session and bind requests that are supposed to happen in a split second.
When the partner now connects to the port, the firewall allows it based on the previous endpoint mapper request.
You still need to open a few of the well-known ports:
| Service | Port/protocol |
| RPC endpoint mapper | 135/tcp, 135/udp |
| NetBIOS name service | 137/tcp, 137/udp |
| NetBIOS datagram service | 138/udp |
| NetBIOS session service | 139/tcp |
| SMB over IP (Microsoft-DS) | 445/tcp, 445/udp |
| LDAP | 389/tcp |
| LDAP ping | 389/udp |
| LDAP over SSL | 636/tcp |
| Global catalog LDAP | 3268/tcp |
| Global catalog LDAP over SSL | 3269/tcp |
| Kerberos | 88/tcp, 88/udp |
| DNS | 53/tcp, 53/udp |
The list of RPC interfaces used by Active Directory:
| Name | UUID | Common Name |
| MS NT Directory DRS Interface | e3514235-4b06-11d1-ab04-00c04fc2dcd2 | AD Replication |
| MS NT Directory NSP Interface | f5cc5a18-4264-101a-8c59-08002b2f8426 | Outlook Address book, optional |
| LSA RPC | 12345778-1234-abcd-ef00-0123456789ab | Local Security Authority |
| Netlogon | 12345678-1234-abcd-ef00-01234567cffb | Remote Logon |
| SAM RPC | 12345778-1234-abcd-ef00-0123456789ac | Security Accounts Manager |
| NTDS Backup Interface | ecec0d70-a603-11d0-96b1-00a0c91ece30 | AD Backup, optional |
| NTDS Restore Interface | 16e0cf3a-a604-11d0-96b1-00a0c91ece30 | AD Restore, optional |
| File Replication Service | f5cc59b4-4264-101a-8c59-08002b2f8426 | FRS Replication |
| File Replication API | d049b186-814f-11d1-9a3c-00c04fc9b232 | FRS Administration |
| DFS Replication Service | 897e2e5f-93f3-4376-9c9c-fd2277495c27 | DFS-R Interface |
You can combine this approach with "Limited RPC". With this combination, you can change the server port on a regular basis for added obscurity without the need to reconfigure the firewalls.
Encapsulating Inside IPSec
| Pros | Cons |
| Provides the best firewall security | IPSec policy configuration on all servers |
| Individualized policies, if required | Your Firewall Admin team may not very fond of tunnels |
| Good reason to start deploying a public key infrastructure (PKI), if desired |
IPSec provides a way to easily encapsulate and carry RPC traffic over a firewall. Besides simplifying the transport of RPC, IPSec also increases security between the DCs because of IPSec's mutual authentication feature: by using either Kerberos or machine certificates, the DCs will "know" whom they are communicating with before any actual information exchange occurs.
This document shows you how to create an appropriate IPSec policy by using the Microsoft Management Console (MMC) interface. You can script policy creation with IPSECPOL.EXE, a tool available in the Windows 2000 Resource Kit. Be sure to thoroughly read and understand the IPSECPOL.EXE documentation before you try to use it—unlike the GUI, the command-line tool has very little consistency checking built in.
There is one decision that you must make before you begin—whether to use certificates for IPSec authentication or built-in Kerberos for Windows 2000. Kerberos authentication requires that both computers already be in the same domain, so if you prefer Kerberos, then you must use something other than IPSec for the domain controller promotion (DCPROMO) phase (because the target server is not yet a member of the domain). Point-to-Point Tunneling Protocol (PPTP) tunnels work well for this and are documented here. If instead, you want to use certificates for authentication, you must obtain a certificate for each DC that will participate in IPSec replication. Please see http://www.microsoft.com/windows2000/library/ for documents that describe how to build a Windows 2000 certificate authority and how to configure your domain for automatic enrollment of machine certificates.
For IPSec replication and IPSec or PPTP promotion, configure your firewall to permit the following:
| Service | Port/protocol |
| DNS | 53/tcp, 53/udp |
| PPTP establishment (if using PPTP) | 1723/tcp |
| GRE, generic routing encapsulation (if using PPTP) | IP protocol 47 |
| Kerberos | 88/tcp, 88/udp |
| IKE, Internet Key Exchange | 500/udp |
| IPSec ESP, encapsulated security payload | IP protocol 50 |
| IPSec AH, authenticated header | IP protocol 51 |
| 1 | If you decide to use certificates for IPSec authentication instead of Kerberos, you can configure the servers to carry Kerberos traffic inside IPSec. This will be covered in more detail later. Regardless of authentication mode, Kerberos between domain controllers is still required. |
Note that IPSec will not work through network address translation (NAT) devices. Because IPSec uses IP addresses when computing packet checksums, IPSec packets whose source addresses were altered by NAT are discarded when they arrive at the destination. As of Windows XP and Windows 2003, NAT-T is supported. Refer to KB885348 for an important note on usage.
Domain Controller Promotion with PPTP Tunnels
If you choose to use PPTP tunnels for the promotion phase, you must configure Routing and Remote Access (RRAS) in the internal network. RRAS can run either on an internal domain controller or on a separate server. For simplicity, it is best that the RRAS server exists in the same subnet as the root domain controller—then no static route maintenance is necessary.
To configure RRAS:
Select Start | Programs | Administrative Tools | Routing and Remote Access.
Right-click your server in the left-hand pane, and then click Configure and Enable Routing and Remote Access. The RRAS setup wizard starts.
Click Manually configured server.
Figure 1: Routing and Remote Access Wizard
Finish the wizard and start the service when it prompts you.
The MMC should now look like this, after clicking on the + next to the server name.
Figure 2: RRAS after Configuring and Enabling
After RRAS is configured and enabled, make the following changes:
Right-click the server, and then click Properties. Click the IP tab. Click Static address pool. Type an IP address range in the same subnet as your internal domain controller. Only a few—perhaps 9—addresses are necessary. Close all dialog boxes.
Figure 3: Server Properties, IP Address Assignment
Right-click Ports (in the left pane of the MMC), and then click Properties. Configure Direct parallel so that neither remote access nor demand dial connections are permitted; if you have any modems on the server (as in the example below), configure them likewise. Configure Demand dial (L2TP) so that there are zero ports and neither remote access nor demand dial connections are permitted. You do not need to make any changes to Demand dial (PPTP) unless you need more than five ports. Close all dialog boxes.
Figure 4: Ports Properties
RRAS is now ready to accept inbound PPTP connections for domain controller promotion.
Before promoting a perimeter network or external server to a domain controller, establish a PPTP tunnel to the internal RRAS server. Open the Properties page of My Network Places and click Make New Connection. In the wizard:
- Click Connect to a private network through the Internet.
- Do not dial any initial connection.
- Type the IP address of the internal RRAS server as the destination.
- Set the connection availability to For all users.
- Do not share the connection.
- Name the connection whatever you wish.
The connection then opens. Before connecting, click the Properties button. Click the Options tab, and then click Include Windows logon domain. Close the dialog box.
Now log onto the RRAS server by using enterprise administrator credentials (the administrator of the root domain). After the server completes the connection, you may start DCPROMO. DCPROMO requires a reboot at the end of the process; this will also disconnect the PPTP tunnel. Because you no longer need the tunnel, you may delete the connection .
Domain Controller Promotion with IPSec and Machine Certificates
You may want to consider this approach if any of these apply:
- You do not want to use PPTP for promotion.
- You prefer not to permit Kerberos through your firewall.
- You are looking for a reason to begin deploying a PKI.
You must install certificates on your domain controllers so that they can perform IPSec authentication. All the certificates require signatures from the same certificate authority. Windows 2000 includes a Request for Comments (RFC-compatible) certificate authority (CA) that works very well in this case. With group policies, you can configure your domain to automatically enroll member computers with machine certificates. While IPSec will work with certificates from any CA, auto-enrollment requires a Windows 2000 CA. If you already have a PKI, the Windows 2000 CA can be configured as a subordinate by issuing CA. Please see the documentation, including the walkthroughs mentioned earlier, for more details.
If you decide to go this route, then you also have the option of including Kerberos traffic inside IPSec. Normally, certain kinds of traffic are exempt from IPSec transport mode processing:
- Broadcast—cannot be classified by IPSec filters because the sender does not know all the receivers.
- Multicast—same as broadcast.
- Resource reservation protocol (RSVP), IP protocol 46—must be exempt so that quality of service marking occurs; however, IPSec packets can be carried inside RSVP packets.
- Internet key exchange (IKE)—IPSec uses IKE to establish security parameters and perform the key exchange. IKE negotiations are already encrypted as necessary.
- Kerberos—the native Windows 2000 authentication protocol and also used by IPSec for machine authentication. Kerberos itself is already secure.
Even though an IPSec filter may specify that all traffic from one computer to another should be encapsulated, the previous kinds of traffic are exempt from IPSec processing.
Windows 2000 Service Pack 1 introduced a registry key that alters this behavior somewhat. Using the registry editor, navigate to:
HKEY_LOCAL_MACHINE
SYSTEM\
CurrentControlSet\
Services\
IPSEC\
Add a new double-word (DWORD) value called NoDefaultExempt and set the value to 1. The following values are allowed:
0: default exemptions apply
1: Kerberos and RSVP are included in IPSec processing
Including Kerberos inside IPSec is fine after a machine is promoted to a domain controller (and thus is a member of the domain). But for a machine not yet a member of a domain the one that you want to promote to a domain controller you cannot establish IPSec by using Kerberos. You must use some other form of authentication, which is the reason for using machine certificates.
Here is some text that you can import into the registry. It will set the NoDefaultExempt value to 1. Copy it to the clipboard, paste it into a blank Notepad screen, save the file with a .REG extension, and then double-click that file in Windows Explorer.
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\IPSEC]
"NoDefaultExempt"=dword:00000001
Understand this before you proceed. If you decide to follow this approach, you also must follow all the steps in the next section, "Configuring IPSec transport mode for DC-to-DC communication," before you run DCPROMO. Here is the order:
- If you want to include Kerberos in IPSec processing, add the previous registry key.
- Install a certificate authority.
- Obtain machine certificates for all existing domain controllers and for all candidate domain controllers.
- Perform the steps in the section "Configuring IPSec transport mode for DC-to-DC communication."
- Run DCPROMO on candidate domain controllers.
- All done—leave everything in place; ongoing replication occurs over the existing IPSec configuration.
Comparison of the Two Methods of Promotion
Here are the differences between the two methods presented earlier.
PPTP tunnels
- Easy and fast.
- Requires the firewall to permit Kerberos.
- Requires the firewall to permit PPTP.
- Separates the promotion and replication functions—configure PPTP for promotion, and then configure IPSec for ongoing replication.
IPSec with machine certificates
- Provides good reason for deploying a PKI.
- Allows Kerberos to be included in IPSec processing.
- Fewer protocols through the firewall—no PPTP, possibly no Kerberos.
- Single step for promotion and ongoing replication.
Although neither method is preferred over the other, using IPSec with machine certificates is probably the more "forward looking" approach, especially because most organizations plan to deploy PKIs of some kind.
Configuring IPSec Transport Mode for DC-to-DC Communication
Now it is time to configure policies on all domain controllers to use IPSec transport mode to communicate with each other. With this configuration, you must permit only IPSec and related protocols over the firewall, which is much simpler and more supportable. Note that you are not creating IPSec tunnels. Instead, you are using IPSec transport mode—end-to-end IPSec—to secure the communications sessions between the servers.
On every domain controller, you must create an IPSec policy for replication, along with a corresponding IP filter list and filter action. Select Start | Programs | Administrative Tools | Local Security Policy.
Figure 5: Local Security Settings
Next, click IP Security Policies on Local Machine (in the left-hand pane of the MMC). This displays the default policies, where you will add a new one for replication. First, however, you must create the filter list and action.
The filter list indicates which IP addresses, ports, and protocols trigger the application of IPSec. You want to secure all the traffic between the domain controllers only, not any traffic between a domain controller and some other machine. Right-click in the MMC's right-hand pane and click Manage IP filter lists and filter actions. You will be on the Manage IP Filter Lists tab. A filter list is simply a list of filters; you will create a filter for each server that this one replicates with. That is, only one filter list is required and the list contains filters for all domain controllers.
Figure 6: IP Filter Lists and Filter Actions, Filter Lists Tab
Click the Add button to create a new filter list. Name the filter list DC replication. Click the Add button to create a new filter; follow these steps to complete the wizard:
- Select My IP address as the source address.
- Select A specific IP address as the destination address, and then type the IP address of the other server.
- Select Any as the protocol type. This configures the filter so that all traffic between the two computers will be carried inside IPSec2.
Figure 7: Domain Controller Replication Filter List
Add additional filters for the remaining domain controllers. When finished, close the dialog box.
Next, you want to define a filter action. Click the Manage filter actions tab, and then click the Add button to create a new action. In the wizard:
- Name the action DC replication.
- Click Negotiate security.
- Click Do not communicate with computers that do not support IPSec.
- Click High (Encapsulated Secure Payload).
- Select the Edit properties check box (you will need to make changes later).
- Click the Finish button.
In the Properties dialog box, clear the check box next to Accept unsecured communication, but always respond using IPSec. You do not want the server to respond at all to unsecured communication. Of course, this applies only to those machines that are part of the corresponding IP filter list; you will link the filter list and the filter action with a policy in just a moment. Close all dialog boxes.
Figure 8: Domain Controller Replication Filter Action
Now you are ready to create the IPSec policy. Right-click in the MMC's right-hand pane and click Create IP security policy. In the wizard:
- Name the policy Domain controller replication.
- Clear Activate the default response rule.
- Ensure that the Edit properties check box is selected and close the wizard.
The policy exists but contains no rules.
Figure 9: Domain Controller Replication IPSec Policy
You create a rule by associating the filter list and filter action that you created earlier. Click the Add button to define a new rule. In the wizard:
Select This rule does not specify a tunnel.
Select Local area network (LAN) for the network type.
Choose an authentication method
- Select Windows 2000 default (Kerberos V5 protocol) if you used PPTP tunnels for DCPROMO, or
- Select Use a certificate from this Certificate Authority (CA) if you are using certificates. Then click Browse and select the certificate authority that issued the machine certificate installed on the computer.
You will see a list of IP filter lists. Select the filter list that you created earlier, DC replication, from the list.
You will see a list of filter actions. Select the filter action that you created earlier, DC replication, from the list.
Do not edit the properties. Finish the wizard.
Your policy will now look like this (the authentication column will indicate "Certificate" if you selected that method).
Figure 10: Completed Domain Controller Replication Policy
Finally, you need to turn on—that is, assign—the policy.
- Right-click the Domain controller replication policy.
- Click Assign.
Figure 11: Domain Controller Policy Is Assigned
IPSec processing happens immediately. There is no need to reboot the server.
Every domain controller requires a similar IPSec policy. Regardless of whether the controller is in the internal network, the perimeter network, or the external network, you must configure its IPSec policy so that all communications with all other domain controllers are through IPSec. Not only does this allow the knowledge consistency checker to build a replication topology that ignores the firewall, it also secures all IPSec replication between every server.
Testing the IPSec policy. Be sure to test the policies that you have created. After you have created and assigned a policy on at least two machines, you can use the IPSECMON.EXE utility to observe when the machines establish the IPSec security association:
- Open a command window.
- Issue the command ipsecmon. A graphical utility starts, listing current security associations and how much authenticated and/or encrypted traffic has passed through the server. (Unless the DCs have started to exchange information, there probably will not be any system administrators right now.)
- Click the Options button and change the refresh rate to one second.
- Go back to the command prompt and ping another domain controller that also has an IPSec policy. Use the -t flag to ping continuously until stopped (ping -t ip-address ).
- Look for several "Negotiating IP security" responses—the machines are exchanging cryptographic keys and building their security associations. Finally, you will see normal replies. It may take 10 to 12 seconds to establish the security associations in both directions.
- Press CTRL +C to stop.
Further Lockdown of DCs in a Perimeter Network
Networks supporting electronic commerce and extranet connections may require a domain controller in the perimeter network. Although at first this might appear to create security issues, IPSec can help here, too. It is possible to create fine-grained packet filters by using the permit/block features of IPSec rules. Please see the document, "Using IPSec to Lock Down a Server," at http://www.microsoft.com/technet/itsolutions/network/security/ipsecld.mspx. You can combine the approach there with the information here to create an IPSec policy that permits only secure DC-to-DC communication and blocks all other traffic from reaching the DC in the perimeter network.
Is This a Legitimate Use of IPSec?
Although probably not envisioned by IPSec's designers, the protocol has become an excellent method for encapsulating complex traffic so that it can be safely transported between networks. The Windows 2000 IPSec policy engine can be used to create very fine-grained rules that specify traffic that is permitted, blocked, or secured between hosts. In the scenario here, we are using it to secure all traffic between known hosts—specific domain controllers—while permitting other traffic to and from those hosts.
For More Information
For more information about Windows 2000 IPSec, and other security features of Windows 2000, please begin your adventure at http://www.microsoft.com/technet/security/default.mspx.
| 1 | This document doesn't discuss using preshared keys. Preshared key authentication is included in Windows 2000 only for compatibility with other IPSec implementations and to conform to the IPSec RFCs. In no cases do we encourage the use of preshared keys in a production environment because of the inherent security risks associated with shared-secret style authentication. |
| 2 | That is, all traffic except that which is exempted from IPSec processing, as discussed earlier. |
Other Languages
This article is also available in the following languages: