Ten Tips for Designing, Building and Deploying Server and Domain Isolation

  • Article

By Fernando Cima, Senior Security Consultant, Microsoft Security Center of Excellence

See other Security Tip of the Month columns

Server and Domain Isolation (SDI) is a great solution for protecting your systems and your information against network attacks. SDI uses Internet Protocol Security (IPsec) for host authentication and network traffic integrity (and optionally encryption), ensuring that untrusted computers plugged into your corporate network -- maliciously or not -- cannot introduce worms or make targeted attacks to your servers, desktops, and notebooks.

Even better is that your organization has probably already bought the solution, which comes as part of every Windows operating system since Windows 2000, so deploying SDI is just a matter of configuring the appropriate IPsec and Group Policies. But before you do this, here are some tips collected from successful SDI implementations worldwide.

Recent government regulations have emerged that focus on data protection and privacy. This legislation has a strong impact on organizational PC asset decommissioning policies. Some of the more important U.S. regulations include the following:

  1. Know Your Network
    During SDI planning you will need to have an accurate list of all your Domain Controllers, WINS servers, and DNS servers, as well as internal subnets and other network information. Not only that, but you’ll need to have this information up to date because any changes will need to be reflected in the IPsec policies.

    If you don’t have this information ready, you’ll need to start your solution planning by first getting to know your network. Identify your network infrastructure servers and map your network topology. List the systems that do not support IPsec or that are not joined to a Active Directory domain. There are scripts to help this task in the Server and Domain Isolation Using IPsec and Group Policies guide, and inventory solutions in Microsoft Systems Management Server 2003 may also be of great help.

  2. Ensure That FRS Replication Is Working and Group Policies Are Being Applied
    SDI uses Active Directory Group Policies to distribute the IPsec policies to your systems. Although this is great because it allows “zero-touch” configuration and management, it also means that Group Policies must be working correctly in order to support SDI - and in many cases they aren’t.

    Many (of the few) SDI deployment problems are traced to Group Policies silently failing to be applied. We’ve seen at least one organization where Group Policies actually had never worked at all for most of its systems. SDI simply magnified the problem; instead of simply not receiving a desktop configuration, the client computer cannot talk to the network.

    Group Policy failures are usually traced to broken File Replication Service (FRS) replication and DNS misconfiguration. Sonar is a great tool for monitoring and troubleshooting the FRS. DCDiag and NetDiag can be used to diagnose DNS misconfiguration. EventCombMT can be used to search for Event ID 1001 from the Windows Security Configuration Editor Client Engine (SceCli -- “Security policy cannot be propagated”) and to identify these systems prior to SDI deployment.

    Security-minded organizations will probably see this as more of a feature than a problem. By not applying Group Policies correctly, systems may not be receiving the appropriate security hardening and patch management configuration. Blocking these systems from effectively joining the network protects will ensure that only compliant systems are able to connect to your more valuable assets.

  3. No, You Don’t Need a PKI
    IPsec authentication can use either Kerberos credentials or Digital Certificates with the same level of support. This means that, unless you need to authenticate non-AD joined machines or interoperate with non-Windows systems, Kerberos (read: Active Directory) completely satisfies the needs of SDI and no Public Key Infrastructure is needed.

  4. Use IPsec Simple Policy Hotfix (if you can)
    Windows Vista and Windows Server codenamed “Longhorn” introduce many new IPsec features, and one of them, called IPsec Simple Policy, has been backported to Windows XP SP2 and Windows Server 2003 SP1. By using this fix your organization does not need to maintain a list of the IP addresses for Domain Controllers, WINS, DNS, and DHCP Servers (see tip #1) as exemptions in the IPsec policy, which greatly simplifies operations.

    The IPsec Simple Policy fix is especially valuable in organizations with a large number of domain controllers in branch offices. The caveat here is no Windows 2000 support -- which can be another great reason for upgrading these systems to Windows XP or Windows Vista.

  5. Avoid Exempting Specific Ports and Protocols (but do exempt ICMP)
    IPsec policies allow rules to exempt certain ports and protocols from using IPsec, or even blocking such ports. This is a powerful tool, but creating rules for specific ports may create policies that are mismatched (the policy in one host exempts the protocol from IPsec, while the policy in the other requires it), making policy management difficult and creating network problems that are hard to troubleshoot. Server and Domain Isolation is a great solution to authenticate hosts, but it is not a port firewall (for that, see tip #10).

    An exception to this advice is Internet Control Message Protocol (ICMP). ICMP is the main tool for diagnosing network problems, and the universal best practice is to keep ICMP exempt from IPsec to help troubleshooting. Although this practice involves an additional (if minimum) security exposure, because untrusted machines will be able to “ping” your systems, this risk is far outweighed by the benefits in operations.

  6. Encrypt Only When Necessary
    IPsec is mostly associated with VPN and network encryption, so one of the usual reactions to SDI is, “Are we going to tunnel everything? Will all traffic be encrypted?”

    Apart from the fact that SDI uses IPsec in transport mode rather than in tunnel mode, using SDI does not mean that you need to encrypt your traffic. Actually most of the traffic will not be encrypted: by default SDI uses IPsec with no encryption (integrity only, or ESP-NULL), which enables network intrusion detection systems to continue monitoring and identifying suspicious traffic, and represents minimal overhead for the systems.

    IPsec encryption remains a powerful tool for protecting servers with high business impact information, especially if your application does not have built-in encryption capabilities, and should be used where needed. It is a very useful resource for meeting security regulations that require encryption of sensitive data while on the network. But the key words should be, “where needed.”

  7. ISA Server Is Your Friend
    In many Server and Domain Isolation deployments it may be the case that a high-value server (say, a mainframe or UNIX box) may not support IPsec, but still the organization wants to protect or even encrypt this traffic. For these situations, Microsoft Internet Security and Acceleration (ISA) Server can act as an “IPsec proxy,” authenticating and encrypting the traffic from hosts, and proxying it to the server(s).

    Figure 1

    Figure 1. ISA Server as an “IPsec Proxy”

    In this configuration a dual-homed ISA Server is used, one network interface in the corporate network, and the other in a private network connected to the non-IPsec server. The ISA Server is joined to the Active Directory domain and receives the regular IPsec policies, requiring IPsec authentication for all inbound connections in the corporate network. On the other side, ISA Server uses Server Publishing to publish the services from the non-IPsec server, so requests coming from the client machines to the internal interface of the ISA Server are transparently proxied to the server.

    A single ISA Server can support multiple non-IPsec servers in this configuration. It is a simple but effective solution for extending the Server and Domain Isolation solution to hosts that cannot natively support SDI.

  8. Verify Internal Router ACLs
    Many organizations use router access control lists (ACLs) to filter network traffic between internal subnets, only allowing certain ports and protocols. If your organization has this practice, ensure that IP protocol 50 (ESP) and UDP ports 500 and 4500 (IKE) are permitted across your entire network.

  9. Create an Exemption for Home Networks
    After deploying Server and Domain Isolation, some people may discover that their corporate notebooks are not reachable anymore by other systems when plugged into their home networks. This will happen if these home networks are in the same IP address range used by the corporate network, which will trigger the SDI IPsec rules and block any incoming, unauthenticated traffic.

    A best practice in these cases is to assign a specific IP address space to be used by home networks, and exempt these subnets from IPsec protection. For instance, your organization can exempt 192.168.0.0/23 (which corresponds to the 192.168.0.x and 192.168.1.x subnets, the ones typically used by home networks), and tell employees that they should use this address space at home.

  10. Windows Firewall and SDI: Better Together
    To an untrained eye, Windows Firewall and IPsec policies may look like competing features. After all, both can be used to block unwanted inbound traffic. But, in fact, each technology adds value to the other -- so much, actually, that it could be said that no SDI deployment is complete without Windows Firewall and vice versa.

    Windows Firewall complements SDI by protecting mobile hosts from network attacks when outside the corporate network, where SDI rules usually do not apply. Windows Firewall is also an effective barrier against broadcast and multicast traffic, which by default are exempt by IPsec.

    On the other hand, SDI makes Windows Firewall deployment much easier. When deploying Windows Firewall a lot of the effort is usually put into identifying and managing the exceptions -- ports and hosts from where the firewall allows inbound traffic -- which can be a daunting task for large organizations. Fortunately, Windows Firewall comes with authenticated bypass, a feature that allows traffic authenticated by IPsec to traverse the firewall, because it comes from trusted hosts.

    The synergy between IPsec and Windows Firewall has increased in Windows Vista, where Firewall and IPsec settings are integrated, making it much easier to configure and reducing the risk of conflict between the two protection mechanisms. IPsec and Windows Firewall will use a single management UI and share the same set of rules and filters. Check this Cable Guy column for more information about the new Windows Firewall in Windows Vista and Windows Server “Longhorn”.

Epilogue (or, the last tip)

We’ve talked about how Server and Domain Isolation can protect your assets today against network attacks. But beyond these immediate benefits, deploying SDI now helps you prepare your network for the future: IPv6 and NAP. IPv6 uses IPsec for network authentication and encryption (IPsec was actually “backported” from IPv6 to IPv4), and SDI is the preferred isolation method for the Microsoft Network Access Protection technology coming in Windows Server “Longhorn.” Check the guidance available at https://www.microsoft.com/sdisolation, use these tips, and good luck with your deployment!