Domain Isolation Policy Design Example
Updated: October 11, 2012
Applies To: Windows Server 2012
This design example continues to use the fictitious company Woodgrove Bank, and builds on the example described in the Firewall Policy Design Example section. See that example for an explanation of the basic corporate network infrastructure at Woodgrove Bank with diagrams.
In addition to the basic protection provided by the firewall rules in the previous design example, the administrators of the network want to implement domain isolation to provide another layer of security to their networked computers. They want to create firewall and connection security rules that use authentication to reduce the risk of communicating with untrusted and potentially hostile computers.
The following illustration shows the traffic protection needed for this design example.
All computers on the Woodgrove Bank corporate network that are Active Directory domain members must authenticate inbound network traffic as coming from another computer that is a member of the domain. Unless otherwise specified in this section, Woodgrove Bank's computers reject all unsolicited inbound network traffic that is not authenticated. If the basic firewall design is also implemented, even authenticated inbound network traffic is dropped unless it matches an inbound firewall rule.
The servers hosting the WGPartner programs must be able to receive unsolicited inbound traffic from computers owned by its partners, which are not members of Woodgrove Bank's domain.
Client computers can initiate non-authenticated outbound communications with computers that are not members of the domain, such as browsing external Web sites. Unsolicited inbound traffic from non-domain members is blocked.
Computers in the encryption zone require that all network traffic inbound and outbound must be encrypted, in addition to the authentication already required by the isolated domain.
Other traffic notes:
All of the design requirements described in the Firewall Policy Design Example section are still enforced.
Woodgrove Bank uses Active Directory groups and GPOs to deploy the domain isolation settings and rules to the computers on its network.
Setting up groups as described here ensures that you do not have to know what operating system a computer is running before assigning it to a group. As in the firewall policy design, a combination of WMI filters and security group filters are used to ensure that members of the group receive the GPO appropriate for the version of Windows running on that computer. For some groups, you might have four or even five GPOs.
The following groups were created by using the Active Directory Users and Computers MMC snap-in, all computers that run Windows were added to the correct groups, and then the appropriate GPO are applied to the group. To include a computer in the isolated domain or any one of its subordinate zones, simply add the computer's account in the appropriate group.
CG_DOMISO_ISOLATEDDOMAIN. The members of this group participate in the isolated domain. After an initial pilot period, followed by a slowly increasing group membership, the membership of this group was eventually replaced with the entry Domain Computers to ensure that all computers in the domain participate by default. The WMI filters ensure that the GPO does not apply to domain controllers. GPOs with connection security rules to enforce domain isolation behavior are linked to the domain container and applied to the computers in this group. Filters ensure that each computer receives the correct GPO for its operating system type. The rules in the domain isolation GPO require Kerberos v5 authentication for inbound network connections, and request (but not require) it for all outbound connections.
CG_DOMISO_NO_IPSEC. This group is denied read or apply permissions on any of the domain isolation GPOs. Any computer that cannot participate in domain isolation, such as a DHCP server running UNIX, is added to this group.
CG_DOMISO_BOUNDARY. This group contains the computer accounts for all the computers that are part of the boundary group able to receive unsolicited inbound traffic from untrusted computers. Members of the group receive a GPO that configures connection security rules to request (but not require) both inbound and outbound authentication.
CG_DOMISO_ENCRYPTION. This group contains the computer accounts for all the computers that require all inbound and outbound traffic to be both authenticated and encrypted. Members of the group receive a GPO that configures connection security and firewall rules to require both authentication and encryption on all inbound and outbound traffic.
If you are designing GPOs for only Windows 8, Windows 7, Windows Vista, Windows Server 2012, Windows Server 2008, and Windows Server 2008 R2, you can design your GPOs in nested groups. For example, you can make the boundary group a member of the isolated domain group, so that it receives the firewall and basic isolated domain settings through that nested membership, with only the changes supplied by the boundary zone GPO. However, computers that are running older versions of Windows can only support a single IPsec policy being active at a time. The policies for each GPO must be complete (and to a great extent redundant with each other), because you cannot layer them as you can in the newer versions of Windows. For simplicity, this guide describes the techniques used to create the independent, non-layered policies. We recommend that you create and periodically run a script that compares the memberships of the groups that must be mutually exclusive and reports any computers that are incorrectly assigned to more than one group.