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.
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 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
.jpg)
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.
.jpg)
4. In the DomainName Properties
dialog box, click the Group Policy tab, and then click New.
.jpg)
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 DomainName Properties
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 ENTERPRISE DOMAIN CONTROLLERS
group. In the Permissions for ENTERPRISE DOMAIN CONTROLLERS
list, in the Apply Group Policy row, click to check Deny.
.jpg)
3. Click the WMI Filter tab.
Click This filter, and then click Browse / Manage. The Manage
WMI Filters dialog box displays.
4. Click Advanced to expand the Manage
WMI Filters 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’
.jpg)
6. Click Save, and then click OK
to close the Manage WMI Filters dialog box.
7. Click OK to close the GPOName
Properties dialog box. In the Security dialog box, click Yes
to confirm your changes.
8. Click Close to exit the DomainName
Properties 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 Group Policy Object Editor,
and then click Add. The Group Policy Wizard starts.
.jpg)
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.
.jpg)
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 Computer Configuration, Windows Settings,
Security Settings, and Windows Firewall with
Advanced Security. Right-click Connection Security Rules,
and then click New Rule. The New Connection Security Rule Wizard
starts.
.jpg)
2. Click Custom, and then click Next.
.jpg)
3. On the Endpoints page of the wizard, leave the default setting of Any
IP address in the Which computers are Endpoint
1? section. In the Which computers are Endpoint
2? section, click These IP addresses, and then click Add.
In the This IP address or subnet 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.
.jpg)
5. On the Requirements page of the New Connection Security Rule Wizard,
click Require authentication for inbound connections
and request authentication for outbound connections,
and then click Next.
.jpg)
6. On the Authentication Method page of the New Connection Security
Rule Wizard, click Computer (Kerberos V5), and then click Next.
.jpg)
7. On the Profile page of the New Connection Security Rule Wizard,
click to check Domain only, and then click Next.
.jpg)
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 All Programs, 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.
.jpg)
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 All Programs,
click Accessories, right-click Command Prompt, 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 Connection Security
Rules. 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.
.jpg)
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
.jpg)
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
http://www.microsoft.com/sdisolation
Microsoft Product Activation
http://go.microsoft.com/fwlink/?LinkID=74008
Microsoft Volume Activation 2.0 Technical
Guidance
http://go.microsoft.com/fwlink/?LinkID=75674