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

for

 

Windows Vista™ and Microsoft® Windows Server® 2008

Microsoft Corporation

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.

Table of Contents

Introduction
    KMS Activation
    Knowledge Prerequisites
Isolation Solutions
    How Server Isolation Works
    Server Isolation Components
        Active Directory domain
        IPsec
        Group Policies
        Exemptions
An Example KMS Host Isolation
How to Implement Server Isolation for KMS Hosts
    Before You Begin
    How to Create a Group Policy Object that Enforces Server Isolation
    How to Edit the Policy
    How to Configure Connection Security Rules and Enforce Server Isolation
    How to Define Exemptions
Test the Solution
    Verify the GPO is Applied
    Verify Server Isolation
    Verify Connectivity from the KMS Host
Additional Scenarios
    Multiple Active Directory Forests
    Protocol and Port Filtering
    Network Address Translation (NAT)
Conclusion
Related Links and Resources

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.

Note: The step-by-step guidance provided in this white paper refers to KMS hosts running Windows Vista or Windows Server 2008. Additional configuration steps are required if your organization has KMS hosts running Windows Server 2003 Service Pack 1 (SP1). These steps are explained in Appendix 1 of this white paper.

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 https://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.

3.    Click the WMIFilter tab. Click Thisfilter, and then click Browse / Manage. The ManageWMIFilters dialog box displays.

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.

3.    In the Open box, type mmc.exe, and then click OK. Microsoft Management Console 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.

2.    In the Open box, type mmc.exe, and then click OK. Microsoft Management Console 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.

2.    Type mmc.exe at the command prompt and then press Enter. Microsoft Management Console starts.

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.

Protocol and Port Filtering

By default, server isolation uses IPsec Encapsulating Security Payload (ESP) protocol without encryption to protect network packets sent to the KMS hosts, and Internet Key Exchange (IKE) protocol to authenticate remote hosts. ESP uses IP protocol 50, and IKE uses UDP ports 500 and 4500. All internal routers and firewalls must enable these protocols to pass for communication to the KMS hosts to succeed.

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.

Related Links and Resources

Microsoft TechNet Web Site for Server and Domain Isolation

https://www.microsoft.com/sdisolation

Microsoft Product Activation

https://go.microsoft.com/fwlink/?LinkID=74008

Microsoft Volume Activation 2.0 Technical Guidance

https://go.microsoft.com/fwlink/?LinkID=75674