Assigning IPSec Policies


As a domain administrator, you can configure IPSec policies to meet the security requirements of a user, group, application, domain, site, or global enterprise from a domain controller. IPSec policy can also be implemented in a non-Windows 2000-based domain environment by using local IPSec policies.

Follow the steps shown in Figure 6.10 to assign IPSec policies during your deployment.

click to expand
Figure 6.10: Assigning IPSec Policies

Make sure that you test these IPSec policies before you actually assign them in your production environment. For more information about testing IPSec policies, see "Testing Your Policies in a Test Lab" later in this chapter.

First determine whether to use Active Directory to apply IPSec policy to clients. If you decide to do so, make sure that you understand how Group Policy inheritance affects the way in which the IPSec policies are applied and how IPSec policy precedence differs from standard Group Policy inheritance.

Understanding the New Default IP Security Policies Container Permissions

Domain-based IPSec policies are stored in the IP Security Policies container in the System container. By default in Windows Server 2003, Active Directory restricts Read permissions on the IP Security Policies container more than in Windows 2000. In Windows Server 2003, only members of the Group Policy Creator Owners and the Domain Computers groups have Read permissions on the IP Security Policies container. Only members of the Domain Admins group or those to whom rights have been delegated can configure domain-based IPSec policy.

If you perform a new installation of Windows Server 2003 and create a domain controller, the domain controller will have the following new default permissions on the IP Security Policies container:

  • Owner: Domain Admins

  • Group: Domain Admins

  • Allow domain computers: Read only

  • Allow Group Policy Creator Owners: Read only

  • Allow Domain Admins: Full Control

When you run the Adprep tool (available in the 1386 directory in the Windows Server 2003 product CD) to prepare Windows 2000 domains and forests for an upgrade to Windows Server 2003, it will change the permissions on the IP Security Policies container to these new settings, unless you have already changed the default permissions in Windows. When you create new objects in the IP Security Policies container, those objects inherit the permissions of that container. Upgrading from Windows 2000 will not modify the permissions on existing IPSec policy objects.

Due to the more restrictive permissions in Windows Server 2003, a member of the Domain Admins group must explicitly allow the assignment of an IPSec policy to child domains within a forest by enabling child domain computers to read the IP Security Policies container in the directory. For these computers to retrieve domain-based IPSec policy from Active Directory, the Local System account for each computer must have Read permissions on the IP Security Policies container. If computer accounts in child domains must read a parent domain-based IPSec policy, you must modify the permissions on the IP Security Policies container to allow this.

Make sure to carefully control Modify access to the IP Security Policies container. Do not assign specific permissions for individual IPSec policies. The IPSec policies are a collection of related directory objects, some of which can be shared between policies. Accordingly, you should control permissions on the IP Security Policies container itself.

An IPSec policy administrator typically has Write access to all IPSec policies. You can restrict who can create and modify GPOs so that only authorized individuals can assign a domain-based IPSec policy. Make sure to investigate these permissions and set them as needed for your environment.

Permissions on the IP Security Policies container and objects cannot be delegated using standard delegation tools, but instead require the use of ADSI Edit. ADSI Edit is a Windows Support Tool that uses the Active Directory Service Interfaces (ADSI) and that is provided on the Windows 2000 and Windows Server 2003 operating system CD. To install this tool, run the Suptools.msi file in the Support\Tools folder.

Understanding IPSec Policy Precedence

To know how to apply IPSec policy in a domain environment, you must understand IPSec policy precedence. Unlike most Group Policy settings, which are cumulative, only one IPSec policy can be assigned to a computer at a time. Therefore, if there are multiple IPSec policies assigned at different levels, the last one applied is the one that takes effect. IPSec policy uses the same precedence sequence as other Group Policy settings, which is from lowest to highest, as follows:

  • Local GPO. Each computer has one local GPO. For a computer that is not a member of a domain, this is the only place where IPSec policy can be assigned. Although you can assign an IPSec policy by editing the local GPO, you can also assign a local policy directly in the IP Security Policy Management snap-in, outside of the Group Policy context, or by using the Netsh IPSec context. When IPSec policy assignments are made outside of the GPO context, the GPO cannot display the local IPSec policy that is assigned.

  • Site. IPSec policies are not often assigned at the site level because all computers within a site must have the same security needs, which is unlikely. Furthermore, if the computer moves to another subnet — such as when a user travels to another location with a laptop that uses DHCP — different policies are applied, which results in different security behaviors.

  • Domain. Simple IPSec policies are often assigned at the domain level and then superseded by more specific IPSec policies, as required on various OUs.

  • OU. Specific IPSec policies are assigned to groups of computers. This is the last policy applied under normal conditions, and, therefore, the policy takes precedence. If an OU is nested within another OU, the IPSec policy assigned to the nested OU takes precedence.

Note that this is the default order in which policies of different types are applied. This order can be overridden by using a number of options, including Enforced, Block Policy Inheritance, and Loopback processing. For more information about the results of these options, see "Designing a Group Policy Infrastructure" in Designing a Managed Environment of this kit.

Note

If you create a persistent policy, this policy adds to or overrides the local or Active Directory policy and remains in effect regardless of whether other policies are applied. For more information about persistent IPSec policy, see "Assigning IPSec Policies Locally" later in this chapter.

Selecting a Method for Assigning IPSec Policies

The next step is to decide how to distribute and assign IPSec policies. This might include storing and assigning IPSec policies from Active Directory as part of Group Policy, storing and assigning them from the local computer, or assigning them from a remote computer.

The primary method of building the IPSec policy is using the graphical user interface provided by the IP Security Policy Management snap-in. You can use the IP Security Policy Management snap-in to create, modify, and activate IPSec policies, and then assign them to an OU in Active Directory that contains the server using the Group Policy Object Editor snap-in. Use this for situations where larger numbers of computers need to be managed in a consistent fashion. A Group Policy-based management solution addresses this situation well.

If a computer is not a member of a Windows 2000 domain or a Windows Server 2003 domain, it cannot retrieve IPSec policy from Active Directory. The IPSec policy configuration for a server can be distributed two ways that do not use Active Directory:

  • As a Netsh IPSec script that is included as a startup script for the computer.

  • As an IPSec file that can be imported from another computer by using the IP Security Policy Management snap-in or Netsh if the computer is running Windows Server 2003. Use this method when computers need to secure their communications, but there are few enough of them that applying policies to OUs is inconvenient. After the policy is imported, you can use the IP Security Policy Management snap-in to assign the policy to the computer.

If you use either of these two methods, make sure you use strict version and change control processes to ensure that the policy file cannot be altered after it was created. If the policy is accessed by using Lightweight Directory Access Protocol (LDAP), the IPSec policy configuration data can be authenticated and encrypted.

Using explicit credentials for remote management and monitoring of IPSec is not supported. Instead, the IP Security Policy Management and IP Security Monitor snap-ins use the credentials that are provided during the desktop logon process to authenticate to a remote computer.

Assigning Domain-based, OU-Level, and Local IPSec Policies

IPSec policies can be applied to local computers, domains, sites, organizational units, or any Group Policy object in Active Directory. The following sections describe deployment considerations for domain-based, OU-level, and local IPSec policies.

Assigning Domain-based IPSec Policy

After you determine where you want to protect data and create IPSec policies for each of those areas, you must determine which IPSec policy to assign to GPOs.

A GPO defines access, configuration, and usage settings for accounts and resources. When an IPSec policy is assigned to a GPO, the IPSec policy is propagated to any computer accounts that are affected by the GPO.

Keep these factors in mind when selecting GPOs for IPSec policy assignment:

  • IPSec policies can be assigned to the GPO of a site, domain, or OU. However, only a single local or domain-based IPSec policy can be assigned to a specific computer.

  • Like Group Policy settings, the assignment precedence for IPSec policies, from lowest to highest, is local, site, domain, and OU. In addition, persistent IPSec policy has the highest precedence of all, even though it is stored on the local computer.

  • Unlike Group Policy settings, IPSec policies from different OUs are never merged.

  • The highest level of the Active Directory hierarchy is typically used to broadly assign IPSec policies, to reduce the amount of configuration and administration required.

  • For domain-based IPSec policy, limit the number of rules to 10 or less, even though Windows Server 2003 supports over 1500 rules per policy.

  • Create and apply an IPSec policy at the domain level to provide a baseline of IPSec protection. For example, the default domain policy GPO can often be used to assign IPSec policy for all clients in a domain.

  • A new IPSec policy can be tested as a local policy on a server or a client first before it is uploaded into the domain. Be sure to adequately test the impact of new IPSec policies before assigning them in the domain.

  • When configuring the Negotiate security filter action, select the Allow unsecured communication with non-IPSec aware computers check box during the rollout phase, so that communication will not be blocked after a computer starts using IPSec policy. After verifying that all computers have IPSec policy and are working correctly, clear this check box to require only IPSec-secured communications.

  • Use the Export Policies and Import Policies commands in the IP Security Policy Management console to back up and restore all of the IPSec policy objects in the IP Security Policies container in Active Directory. The Export Policies command exports all IPSec policy objects from the policy store into one .ipsec file. The Import Policies command imports all IPSec policy objects in the .ipsec file into the destination policy store. Note that importing IPSec policy into Active Directory will overwrite existing IPSec policy objects.

Caution

When importing or editing IPsec policy in Active Directory, do not close the IP Security Policy Management snap-in (or exit the Netsh environment, if you are using the netsh ipsec static importpolicy command) before all IPSec policy data has been written to Active Directory. If the IP Security Policy Management snap-in or Netsh Ipsec cannot finish writing all of the policy data into Active Directory, IPSec policy corruption might result.

If you detect IPSec policy corruption, you can try to reimport the IPSec policy file. In some cases, you must use either LDP.exe or ADSIedit.exe to delete the IPSec policy objects. (LDP.exe is a Support Tool that was included in the Support Tools folder of the Windows 2000 operating system CD, and is included in the Support Tools folder of the Windows XP and Windows Server 2003 operating system CDs). The IPSec policy objects must be deleted so that a new IPSec policy import operation can be successfully completed. If you are managing IPSec policy remotely over slow links, transfer the IPSec policies in .ipsec export files by using a file copy technique first. Then use Remote Desktop Connection to connect to the remote server and perform the import operation quickly.

Assigning OU-Level IPSec Policies

After assigning a domain-based IPSec policy as a baseline for IPSec protection, you can assign other IPSec policies to specific OUs to provide tighter IPSec filtering in sensitive areas of your network. By default, the IPSec policies assigned to a GPO at the OU level override the baseline policy for the domain.

For example, you can organize the computer accounts in the domain to keep domain clients in one OU and IPSec-protected servers in another OU, so that client policy will not affect servers.

Note

Assigning an IPSec policy to a GPO (such as an OU) records a pointer to the IPSec policy inside the GPO. Thus Group Policy only detects changes in IPSec policy assignments, not changes made within an IPSec policy after it is assigned to a GPO. The IPSec service detects changes in the related IPSec policy. You can specify the frequency of this detection process, known as the IPSec polling interval, by setting a value on the General tab of the properties of a policy by using the IP Security Policy Management snap-in.

It is recommended that you test your new IPSec policies as a local policy on a server or a client first before assigning them into the domain.

Assigning IPSec Policies Locally

Each computer running Windows Server 2003 has one local GPO, which is also known as the local computer policy. When this local GPO is used, Group Policy settings can be stored on individual computers regardless of whether they are members of an Active Directory domain. The local GPO can be overridden by GPOs assigned to sites, domains, or OUs in an Active Directory environment that have higher precedence. On a network without an Active Directory domain (that is, a domain that does not have a domain controller running Windows 2000 or Windows Server 2003), the local GPO settings determine IPSec behavior because they are not overridden by other GPOs.

Local policy assignment is a way to enable IPSec for computers that are not members of a domain.

You can also create and assign persistent IPSec policy, which secures a computer even if a local IPSec policy or an Active Directory-based IPSec policy cannot be applied. This policy adds to or overrides the local or Active Directory policy, and remains in effect regardless of whether other policies are applied or not. Persistent IPSec policies enhance security by providing a secure transition from computer startup to IPsec policy enforcement. Persistent policy also provides backup security in the event of an IPSec policy corruption, or if errors occur during the application of local or domain-based IPSec policy. To configure persistent policies, you must use the netsh ipsec static set store location=persistent command.

When designing persistent IPSec policy, it is important to consider the potential impact of persistent policy on remote management. If local or domain-based IPSec policy is not applied and the persistent IPSec policy is the only policy that is applied, attempts to remotely diagnose an issue might be blocked by the persistent IPSec policy. To allow for remote management in case troubleshooting is required, it is recommended that you create appropriate permit filters when configuring persistent IPSec policy.

To enable remote management, add the following exemption by using the Netsh IPSec context command:

 netsh ipsec dynamic set config bootexemptions tcp:0:3389:inbound UDP:0:68:inbound 

This command specifies two things: that the destination port 3389 for inbound TCP connections is permitted, thereby enabling clients to use Remote Desktop Connection or Remote Assistance; and that destination port 68 for inbound UDP connections is permitted, thereby preserving DHCP functionality.

If an error occurs when persistent IPSec policy is applied, the IPSec driver will block all traffic except for that which matches any specific permit filters that you configure (by using the netsh ipsec dynamic set config bootexemptions command), and DHCP.

For more information about assigning local IPSec policies, see "Creating, modifying, and assigning IPSec policies" in Help and Support Center for Windows Server 2003.

Understanding IPSec Protection During Computer Startup

Windows Server 2003 IPSec provides several options for protection during computer startup. To provide maximum protection against attacks during computer startup, it is highly recommended that you configure and assign a persistent IPSec policy. If you do not configure a persistent policy, the IPSec driver cannot enforce IPSec policy until domain-based or local IPSec policy is retrieved and applied.

Understanding IPSec Driver Startup Modes

To understand how IPSec policies are processed and applied, it is important to understand the modes in which the IPSec driver operates. The IPSec driver can perform in any of three following computer startup modes:

  • Permit. In this mode, the IPSec driver permits all inbound and outbound traffic. After persistent, local, or domain-based IPSec policy is applied, the IPSec driver no longer operates in this mode.

  • Block. In this mode, the IPSec driver blocks all inbound and outbound traffic until persistent policy is applied, except for traffic that matches any specific permit filters that you configure (by using the netsh ipsec dynamic set config bootexemptions command), and DHCP traffic.

  • Stateful. In this mode, the IPSec driver permits all outbound traffic initiated by the computer during startup. Inbound traffic that is sent in response to the outbound traffic is permitted, specific to the peer IP address, protocol, and source and destination ports. The IPSec driver also permits inbound traffic that matches any specific filters that you configure (by using the netsh ipsec dynamic set config bootexemptions command), and DHCP traffic. All other inbound unicast, broadcast, and multicast packets are dropped. The stateful inbound permit filters are discarded after the IPSec service starts and sets persistent IPSec policy.

If a persistent, local, or domain-based IPSec policy has been assigned to a computer, the IPSec Policy Agent sets the stateful mode for the IPSec driver by default. You can change the default startup mode for the IPSec driver by using the Netsh IPSec context or by modifying the registry.

To change the default startup mode of the IPSec driver by using the Netsh IPSec context, use the following command:

 netsh ipsec dynamic set config bootmode value={stateful | block | permit} 

  • To change the default startup mode of the IPSec driver by modifying the registry

    1. Under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\IPSEC, add a new DWORD entry named OperationMode

    2. Assign this new registry entry any value from 0, 1, or 3 where:

      • A value of 0 specifies that the IPSec driver operate in Permit mode, to allow all inbound and outbound traffic.

      • A value of 1 specifies that the IPSec driver operate in Block mode, except to allow traffic that matches any specific permit filters that you configure by using Netsh, and DHCP traffic.

      • A value of 2 is reserved.

      • A value of 3 specifies that the IPSec driver operate in Stateful mode and permits inbound traffic that matches any specific filters that you configure (by using the netsh ipsec dynamic set config bootexemptions command), and DHCP traffic.

    3. Restart the computer.

Caution

Do not edit the registry unless you have no alternative. The registry editor bypasses standard safeguards, allowing settings that can damage your system, or even require you to reinstall Windows. If you must edit the registry, back it up first and see the Registry Reference on the Windows Server 2003 Deployment Kit companion CD or at http://www.microsoft.com/reskit.

Using IPSec in Safe Mode with Networking

When a computer is started in Safe Mode with Networking (for example, if you are performing Directory Service Restore Mode operations), the IPSec service does not start. As a result, no persistent, local, or domain-based IPSec policy can be applied, and IKE cannot negotiate security for network traffic. However, if an IPSec policy has been assigned to a computer, IPSec still can provide some level of filtering protection. If the IPSec service startup type is set to Automatic, the IPSec driver remains in computer startup mode (which is Stateful mode, by default). When the IPSec driver operates in this mode, you can configure specific permit filters to allow inbound traffic over specific protocols and ports.

If you must change the IPSec driver mode to Permit to allow all inbound connections, you must either set the OperationMode registry key to a value of 0 or change the IPSec service startup type to Manual or Disabled, and then restart the computer in Safe Mode with Networking again. Note that in this case, you cannot use the netsh ipsec dynamic set config bootmode value= command to change the IPSec driver startup type, because Netsh IPSec requires the IPSec service to be running.

Caution

Do not edit the registry unless you have no alternative. The registry editor bypasses standard safeguards, allowing settings that can damage your system, or even require you to reinstall Windows. If you must edit the registry, back it up first and see the Registry Reference on the Windows Server 2003 Deployment Kit companion CD or at http://www.microsoft.com/reskit.

Using Netsh Scripts to Assign IPSec Policies

In Windows Server 2003, the Netsh IPSec tool provides a scriptable command-line method of building an IPSec policy. This is useful in cases such as when a computer is not a domain member or is running an older version of Windows. Netsh IPSec can create a persistent policy or a local policy, both of which are stored in the local computer registry, or it can create a policy that is stored in Active Directory.

The IPSec context of the Netsh tool can also dynamically insert new IPSec rules into the runtime system. This "dynamic mode" IPSec policy is part of the run-time state and is not stored; therefore, it is lost when the IPSec service is stopped either administratively or during a restart.

The IPSec internal infrastructure components were significantly modified for Windows Server 2003 such that the Netdiag.exe, IPSecpol.exe, and IPSeccmd.exe tools from earlier Windows releases cannot run properly. You do not need to import policies created by these tools during an upgrade - policies in place before an upgrade to Windows Server 2003 continue to function after the upgrade has been completed. In all cases, the user or process that sets the IPSec policy must be running as a local or domain administrator.

For more information about importing IPSec policies, see "Creating, modifying, and assigning IPSec policies" in Help and Support Center for Windows Server 2003.

Windows 2000, Windows XP, and Windows Server 2003 do not have published programmatic APIs in the Microsoft Windows Platform Software Development Kit for IPSec policy. Command-line scripting using the Netsh IPSec tool is the only method of managing policy in an automated fashion.

Coordinating IPSec Client and Server Policies in a Domain

Both clients and servers need IPSec policy before secure communications can be enabled. Because the initial application of IPSec policy and policy changes can briefly interrupt connectivity, make sure to schedule these tasks during low use periods as much as possible. When policies are changed, the IPSec system might be forced to delete existing IPSec SAs, so that new SAs can be negotiated according to the new IPSec policy. This can cause a temporary loss of communication.

Remember that domain IPSec policy will override local IPSec policy. If a local administrator has secured a server with local IPSec policy, applying a domain policy might make the server less secure or break its secure communication. If persistent policy was used, the domain policy cannot override it, but can enhance that baseline security.




Microsoft Corporation Microsoft Windows Server 2003 Deployment Kit(c) Deploying Network Services 2003
Microsoft Corporation Microsoft Windows Server 2003 Deployment Kit(c) Deploying Network Services 2003
ISBN: N/A
EAN: N/A
Year: 2004
Pages: 146

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net