Using Server Isolation to Help Protect Key Management Service (KMS) Hosts

for

Windows Vista™ and Microsoft®
Windows Server® 2008

Microsoft Corporation

Published: June, 2008

Abstract

Some organizations use widely shared or
even publicly available networks. Securing access to Key Management Service
(KMS) hosts in such environments is needed. This white paper examines the use
of server isolation with IPsec and Microsoft® Active Directory® with directory
services to help secure access to KMS hosts. It provides step-by-step guidance
to deploy such a solution on computers that are running volume editions of
Microsoft Windows® Vista®, Windows Server® 2008, and Windows Server 2003.

Introduction

Volume Activation 2.0 (VA 2.0) is a set of
tools that help customers automate activation of computers that are running
volume editions of Microsoft Windows® Vista® and Windows Server® 2008. VA 2.0
provides two models of activation: Multiple Activation Key (MAK) and Key Management
Service (KMS). MAK activates computers directly with Microsoft® activation
servers. KMS enables customers to host a local service within their own network
without individual clients having to contact a Microsoft activation
clearinghouse. Only KMS, the primary activation model, is discussed in this
white paper.

KMS
Activation

KMS uses a client/server method that
enables you to configure one or more systems to act as activation servers,
called KMS hosts, on your network. KMS clients connect to this service to
activate. KMS, like many services, is designed to be lightweight. KMS hosts
automatically publish their presence using a Domain Name System (DNS) service
(SRV) resource record. KMS clients can find KMS hosts by querying DNS. The
activation process between the KMS client and the KMS host does not include any
authentication (proof of identity) or authorization (more secure access that
uses permissions and access control lists (ACLs)). This means that any Windows
Vista and Windows Server 2008 computer that connects to your network can be
activated by your KMS hosts.

Organizations can control which computers
are able to connect to their KMS hosts by using firewalls that block
connections from external networks, and by controlling physical access to the
corporate network. However, these security measures may be insufficient for
some organizations. Universities and research institutions, for example,
frequently have clients that connect over the Internet. Large organizations may
share a corporate network with partners and other business units. This can make
securing remote access to the corporate network a challenge.

Knowledge Prerequisites

This white paper provides prescriptive
guidance on how to use server isolation to help secure access to KMS hosts. Server
isolation enables organizations to restrict KMS activations to only those
computers that are authorized to use KMS on that network.

To understand and use the concepts and
procedures in this document, you should have an understanding of core networking,
IP security (IPsec) principles--in particular, Microsoft’s implementation of
IPsec, Active Directory concepts, Group Policy, and the creation and use of
group policy objects (GPOs) including the application of security templates.

Isolation Solutions

Isolation uses security settings to
restrict access to specific systems. Isolation embodies two solutions—server
isolation and domain isolation. Server isolation restricts access to a few
specific servers whereas domain isolation restricts access to all computers
that belong to a domain. This includes users’ client computers. Applications
such as KMS that run on isolated servers can remain lightweight by using server
isolation to enforce authentication, authorization, and communication security.
You can read more information about server and domain isolation at http://www.microsoft.com/sdisolation.

How Server Isolation Works

Server isolation creates a logically
isolated network around a specific set of servers, greatly reducing the
possibility of unauthorized access to sensitive data and services. Computers on
an isolated network are not physically separated from other computers. IPSec
and Group Policy settings are used to logically create an isolated environment.
Computers that use isolation can verify that an authenticated computer sent a
packet and that the packet was not modified in transit. These settings enable
trusted and untrusted hosts to be connected side-by-side on the same physical
network and IP address space, while keeping them logically isolated.

Server Isolation Components

The following components are part of the
configuration of server isolation for a KMS host.

Active Directory domain

Computers that you want to configure as
isolated servers must be members of an Active Directory domain. Computers can
connect to isolated servers through a wired LAN, wireless connection, or
remotely through a dial-up connection or a virtual private network (VPN). In a
multidomain environment, computers can access isolated servers that belong to a
different domain as long as the computer’s domain is trusted by the domain that
contains the isolated server, or an exemption is configured. Exemptions are explained
later in this section.

IPsec

IPsec is a suite of IP protocols that are
used to help secure communications between computers. IPsec blocks traffic from
untrusted computers, and helps to protect valid traffic from address spoofing,
data injection, session hijacking, replay attacks, and other types of data
tampering. IPsec is usually thought of as a tunneling protocol that provides
encrypted access between gateways for VPNs. Server isolation uses IPsec in
transport mode. This enables direct connections between computers without the
need to set up VPN tunnels.

IPsec is deployed as a local policy or a
domain-based Group Policy. Part of the new Group Policy options introduced in
Windows Vista is a Microsoft Management Control (MMC) snap-in for Windows® Firewall
with Advanced Security. Server isolation is defined by using connection
security rules that are a part of the Windows Firewall with Advanced Security
configuration settings.

Group
Policies

Connection security rules for the Windows
Firewall are distributed by using Group Policy. To deploy server isolation, you
configure Group Policy settings to require that all incoming connection
requests to the KMS host and subsequent data be authenticated and protected by
using IPsec-based authentication. Group Policy then distributes these policies
to groups of computers that you specify.

Exemptions

Server isolation requires that all
computers belong to the same or a trusted Active Directory domain. However,
many organizations have computers that are not joined to a trusted Active
Directory domain, such as computers that are used in lab environments or as
public kiosks. By default, these computers are blocked by server isolation and
cannot use the organization’s KMS hosts. Organizations can enable these
computers to use a KMS host by defining exemptions to their server isolation
policy.

Exemptions are specific IP addresses or
subnets, or both, that are exempted from the IPsec authentication requirement.
Computers that use these addresses can connect to KMS hosts even if they are
not members of the Active Directory domain.

Note: Using
server isolation exemptions opens the possibility of non-authorized computers
using these IP addresses to obtain access to KMS hosts. Organizations should
carefully consider the security implications before granting an exemption to an
IP address or subnet. If an exemption is configured, organizations can use
additional security measures like Virtual LAN segmentation or 802.1X
authentication.

Exemptions are defined by connection
security rules. Windows Server 2003, Window XP, and earlier Windows operating
systems do not support connection security rules in Windows Firewall with
Advanced Security, and cannot initiate connections to KMS hosts protected by
server isolation. This should not be an issue, however, because these operating
systems do not support activation by using KMS. If you must allow specific
systems that are running earlier operating systems to connect to KMS hosts, the
IP addresses for these systems should also be included as exemptions to the
server isolation policy.

An
Example KMS Host Isolation

In a simplified server isolation
deployment, you configure and activate a Windows Firewall policy by using a
connection security rule that specifies that all network traffic to the KMS hosts
must be authenticated by using IPsec. Computer domain credentials are used to
authenticate the incoming connections by using the Kerberos V5 authentication
protocol.

Because all KMS activation requests are
initiated from KMS clients, this policy requires authentication only for
communications initiated from the KMS clients to the KMS hosts. The KMS hosts
are still able to initiate communications to other servers on the network. This
includes domain controllers and DNS servers.

After the connection security rule is
created, you then activate the IPsec policy for the appropriate Active
Directory containers, such as sites, domains, and organizational units, by
using Group Policy. The member computers in the Active Directory containers to
which the Group Policy settings apply automatically download the Group Policy
settings.

After the domain member computers have
downloaded and applied the Group Policy settings, they have both the correct
IPsec policy for server isolation and the domain credentials needed to
communicate more securely with isolated KMS hosts. Computers that are not
domain members and that do not have domain credentials or the correct IPsec
settings cannot initiate communications with the KMS hosts without an
exemption. This scenario is shown in Figure 1.

Figure 1. Communication process with
server isolation

How to Implement Server Isolation for KMS Hosts

This section contains the procedures needed
to configure server isolation on a KMS host. To implement server isolation on
your KMS hosts you must create a Group Policy object (GPO). You then create
connection security rules that apply to your KMS hosts and to all KMS clients.
This GPO must then be downloaded and enforced on all Active Directory domains
that have KMS clients.

Note: These
steps are for KMS hosts running Windows Vista and Windows Server 2008.
Additional steps are needed for KMS hosts running Windows Server 2003. These
steps are listed in Appendix 1 in this document.

Before You Begin

To complete the procedures in this section,
you must have the IP addresses of the KMS hosts and a user account that is
assigned the rights to create and link GPOs to every Active Directory domain
that has KMS clients.

Note: KMS
hosts should have static IP address and should not use DHCP or any other form
of dynamic IP attribution.

How
to Create a Group Policy Object that Enforces Server Isolation

The GPO in this procedure is created on a
domain controller. However, you can create it remotely from a Windows computer
that has the Administration Tools Pack (adminpak.msi) installed.

To create a group policy object

1.Log on to a domain controller by using an
account that has the rights to create Group Policy objects.

2.Start Active Directory Users and
Computers.

3.Right-click the name of the domain to which
the KMS hosts belong (in this example, that is contoso.net), and then click Properties.

4.In the DomainName Properties
dialog box, click the Group Policy tab, and then click New.

5.Type a name for the new GPO, such as KMS
Isolation Policy, and then click OK.

How
to Edit the Policy

This procedure sets the appropriate
permissions and Windows Management Instrumentation (WMI) filters to enforce
server isolation. These settings should only be applied to Windows Vista and
Windows Server 2008 computers. Additionally, it should never be applied to an
Active Directory domain controller.

To edit a group policy object

1.In the DomainNameProperties
dialog box, click the new GPO created in the previous procedure, and then click
Properties.

2.Click the Security tab. In the Group
or user names list, click the ENTERPRISEDOMAINCONTROLLERS
group. In the PermissionsforENTERPRISEDOMAINCONTROLLERS
list, in the ApplyGroupPolicy row, click to check Deny.

4.Click Advanced to expand the ManageWMIFilters dialog box, and then click New.

5.Type a name and a short description for the
new filter. Click to position a cursor in the Queries box and type the
following query:Root\CimV2; Select * from
Win32_OperatingSystem where Version >=‘6’

6.Click Save, and then click OK
to close the ManageWMIFilters dialog box.

7.Click OK to close the GPONameProperties dialog box. In the Security dialog box, click Yes
to confirm your changes.

8.Click Close to exit the DomainNameProperties dialog box.

How to Configure Connection Security Rules and Enforce Server
Isolation

After you create the GPO you must configure
the appropriate connection security rules. Because this is a new GPO option
introduced in Windows Vista, the GPO must be edited from a computer that is
running Windows Vista or Windows Server 2008.

To configure connection security rules

1.Log on to a domain-joined computer that is running Windows Vista or
Windows Server 2008 using an account that has the rights needed to manage GPOs.

2.Click Start, click All Programs, click Accessories,
and then click Run. The Run application starts.

4.On the File menu, click Add/Remove Snap-in. In the Available
snap-ins list, click GroupPolicyObjectEditor,
and then click Add. The Group Policy Wizard starts.

5.Click Browse to open the list of available Group Policy
objects, click the server isolation GPO (in this example, that is KMS Isolation
Policy), and then click OK.

6.Click Finish to close the Group Policy Wizard, and then click
OK to close the Add or Remove Snap-ins window.

To enforce server isolation

1.On the left navigation pane of the MMC, expand the new isolation
policy GPO node. Expand ComputerConfiguration, WindowsSettings,
SecuritySettings, and WindowsFirewallwithAdvancedSecurity. Right-click ConnectionSecurityRules,
and then click NewRule. The New Connection Security Rule Wizard
starts.

2.Click Custom, and then click Next.

3.On the Endpoints page of the wizard, leave the default setting of AnyIPaddress in the WhichcomputersareEndpoint1? section. In the WhichcomputersareEndpoint
2? section, click TheseIPaddresses, and then click Add.
In the ThisIPaddressorsubnet box, type
the IP address of a KMS host, and then click OK.

4.Repeat the previous step, adding the IP addresses of all KMS hosts
in the organization, and then click Next.

5.On the Requirements page of the New Connection Security Rule Wizard,
click Requireauthenticationforinboundconnectionsandrequestauthenticationforoutboundconnections,
and then click Next.

6.On the Authentication Method page of the New Connection Security
Rule Wizard, click Computer (Kerberos V5), and then click Next.

7.On the Profile page of the New Connection Security Rule Wizard,
click to check Domain only, and then click Next.

8.On the Name page of the New Connection Security Rule Wizard, type a
name and a short description for the rule, and then click Finish.

9.Exit the MMC.

How
to Define Exemptions

You can define additional connection
security rules to exempt specific IP addresses and subnets from the server
isolation policy. The KMS hosts will not require IPsec authentication for
network traffic coming from the exempted IP addresses or subnets. This enables
specified computers that are not domain-joined and that are running Windows
Vista or Windows Server 2008 to use these KMS hosts for activation.

To define exemptions

1.Log on to a domain-joined computer that is running Windows Vista or
Windows Server 2008 using an account that has the rights needed to manage GPOs.
Click Start, click AllPrograms, click Accessories,
and then click Run. The Run application starts.

3.On the File menu, click Add/Remove Snap-in. In the Available
snap-ins list, click Group Policy Object Editor, and then click Add.
The Group Policy Wizard starts.

4.Click Browse to open the list of available Group Policy
objects, click the server isolation GPO, and then click OK.

5.Click Finish to close the Group Policy Wizard, and then click
OK to close the Add or Remove Snap-ins window.

Test the Solution

You can confirm that the server isolation
policy is configured correctly by trying to connect to the KMS host from domain
and non-domain computers that are running Windows Vista and Windows Server
2008. Domain computers should be able to transparently connect to the KMS host.
However, traffic from computers that do not belong to a trusted domain should
be blocked unless there is an exemption defined.

Verify
the GPO is Applied

Perform the following procedure to verify
that the GPO is downloaded and applied to computers that are running Windows
Vista or Windows Server 2008:

Note: After
you create the GPO, allow time for it to propagate to the domain computers. You
can force propagation by rebooting the system or by running the gpupdate /force
command.

To verify the GPO is applied

1.From a domain-joined Windows Vista computer, open an elevated
command prompt. To do this click Start, click AllPrograms,
click Accessories, right-click CommandPrompt, and then
click Run as administrator.

3.On the File menu, click Add/Remove Snap-in. In the
list of available snap-ins, click Windows Firewall with Advanced Security,
and then click Add.

4.Confirm that the local computer is selected, and then click Finish.

5.Click OK to close the Add or Remove Snap-ins window.

6.In the left navigation pane of the console window, expand the Windows
Firewall with Advanced Security node, and then click ConnectionSecurityRules. The rules that are defined in the host and their current status
are displayed in the details pane. Verify that the rule specified by the GPO is
enabled on the host.

Verify Server Isolation

You can confirm that the server isolation
policy is working correctly by running the Ping command from a domain-joined
Windows Vista computer. This command should run successfully as follows:

C:\Users>ping KMSHOST

Pinging KMSHOST.contoso.net [192.168.0.30] with
32 bytes of data:

Reply from 192.168.0.30: bytes=32 time=12ms
TTL=128

Reply from 192.168.0.30: bytes=32 time=12ms
TTL=128

Reply from 192.168.0.30: bytes=32 time=12ms
TTL=128

Reply from 192.168.0.30: bytes=32 time=12ms
TTL=128

Note:
Because of increased security settings, there is a small delay when the two
computers communicate for the first time. This may cause the first packets to
be lost.

Running the following command from a
non-domain computer should result in failure as follows:

C:\Users>ping KMSHOST

Pinging KMSHOST.contoso.net [192.168.0.30] with
32 bytes of data:

Request timed out.

Request timed out.

Request timed out.

Request timed out.

Verify Connectivity from the KMS Host

The KMS host should be able to initiate a
connection to any other host in the network, regardless of its Active Directory
domain status. This is verified by checking if the KMS host can connect
normally to domain controllers and other servers on the network.

Additional Scenarios

Organizations should take the following
issues into consideration when they implement server isolation with IPsec to
protect their KMS hosts.

Multiple Active Directory Forests

Some organizations may have KMS client
computers that are located in multiple Active Directory forests in their
network, and may also have KMS hosts located in a separate forest from KMS
clients. This scenario is supported by server isolation, which can span and
validate computer credentials across forest boundaries.

Figure 2. Trust relationship between
forests

As shown in Figure 2, an Active Directory
forest that has KMS clients must trust the forest that contains the KMS host.
For more information about trust relationships, go to this Microsoft Web site.

Network Address Translation (NAT)

Earlier implementations of IPsec were
incompatible with NAT implementations. However, Windows Vista implements a
newer standard called IPsec NAT Traversal (NAT-T). NAT devices that support
this new standard should work with IPsec and server isolation.

Conclusion

The KMS service uses anonymous connections
to activate KMS clients. This means that the service, by default, is open to
any computer that has network connectivity to the KMS hosts. However, you can
implement server isolation with IPsec to enforce authentication of KMS clients.
This enables organizations to place their KMS hosts on open or shared networks
and still protect KMS hosts from unauthorized access.