|< Day Day Up >|| |
Chapter 8 described how to configure IPSec on individual computers. This is sufficient for testing IPSec in your lab environment, but it is impossible to manually configure every computer in a large enterprise. Fortunately, IPSec can be deployed by using Active Directory Group Policy objects (GPOs), much like most other security settings. Alternatively, you can configure IPSec by using batch files and three different IPSec command-line utilities. This provides you with the flexibility to use IPSec on computers that do not participate in a domain or on computers that are members of domains that you do not manage.
Chapter 8 also described how to configure IPSec to use certificates for authentication. While that aspect of configuring certificates-based authentication is simple, actually deploying Windows Server 2003 Certificate Services for IPSec is much more complex. This lesson will list important factors to consider when deploying certificates for IPSec authentication. Additionally, this lesson provides an exercise that guides you through the process of configuring Certificate Services and actually establishing an IPSec session authenticated by certificates to prepare you for deploying such an environment in the real world.
After this lesson, you will be able to
Describe the various methods for deploying IPSec policies to multiple computers.
List the steps necessary to deploy IPSec policies by using Active Directory.
List the tools used for configuring IPSec at the command line and describe the circumstances in which you use each.
Configure Certificate Services to issue certificates that can be used to authenticate IPSec peers.
Estimated lesson time: 55 minutes
If your organization has an Active Directory domain, you should almost always use Active Directory to deploy IPSec. The primary tool for building IPSec policies is 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 a domain, site, or organizational unit (OU) in Active Directory by using the Group Policy Object Editor snap-in.
To tightly control IPSec policy management, you can dedicate one computer to configure local IPSec policy and then use the IP Security Policy Management Export Policies and Import Policies menu commands to back up and restore IPSec policy. After you create an IPSec policy, use a version control system to track changes to the policy during the development, testing, and deployment phases.
If you decide to deploy IPSec policies by using GPOs, you must understand how IPSec policies differ from other types of security settings. Most settings in a security template can be combined by importing them into a single GPO. If multiple GPOs with overlapping settings are assigned to a single computer, the computer will automatically resolve any conflicting settings. Because multiple security templates and sets of Group Policy settings can be applied to a single computer, role-based security templates work perfectly when a computer serves multiple roles.
|Security Alert|| |
IPSec policies can be protected just like any other object. Local IPSec policies are stored in the registry under HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\ Windows\IPSec\. Active Directory–based IPSec policies are stored in CN=IP Security, CN=System,DC=domainname,DC=topleveldomain. However, you must keep in mind that local administrators will have Read access to an assigned IPSec policy after it is cached in the local registry. Accordingly, there is no effective way to provide highly restricted Read access to an Active Directory–based IPSec policy.
Only one IPSec policy can be applied to any single computer. If multiple GPOs assign multiple IP security policies to a computer, only the GPO with the highest precedence will be applied. IPSec policy uses the same precedence sequence as other Group Policy settings, which is from lowest to highest: Local GPO, site, domain, OU.
For example, if you create a security policy for Web servers that uses certificates for authentication, and you create another policy for internal servers that uses Kerberos, you cannot assign both policies to a single computer by using multiple GPOs. Instead, one policy will override the other policies. If you attempt to assign an IPSec policy to the local computer and a policy has been assigned to the computer by using a GPO at the domain level, the IP Security Policy Management snap-in will alert you with the message “Policy is assigned, but it is being overridden by Active Directory–assigned policy,” as shown in Figure 9.1.
Figure 9.1: Local IPSec policy overridden by a domain policy
|See Also|| |
As with other GPO settings, you can use Resultant Set of Policy (RSoP) to determine which IPSec policy is effective. For more information about GPOs and RSoP, refer to Chapter 3.
As a result, you should create as few different IPSec policies as possible. Fortunately, you can use IP filters to create complex IP security policies that contain different settings for different computer roles. For example, if your organization requires internal file servers to use Kerberos IPSec authentication and external mail servers to use certificate-based IPSec authentication, you can create a single IPSec policy with rules that negotiate Kerberos authentication for requests from internal clients and certificates authentication for requests from external clients. Alternatively, you could separate the file server and mail server roles onto separate physical computers: apply an IPSec policy requiring Kerberos authentication to the file server, and apply a different IPSec policy requiring certificates-based authentication to the mail server.
Neither of these two solutions is perfect. Separating the roles onto physically separate computers requires additional server hardware and systems administration effort. Using IP filters to create rules that apply different filter actions based on the source IP address does not accommodate the possibility that users can access the file server from an external IP address or attempt to communicate with the mail server from an internal IP address. You could theoretically create IP filters based on the port numbers used by file sharing and messaging protocols, but client computers would only be able to connect to the server as either a file server or a mail server—not as both.
|Off the Record|| |
There’s one way to use multiple security policies on a single computer: by using virtual machines. I use virtual machines extensively to run multiple instances of different operating systems on a single computer simultaneously. Enterprises often use virtual machines in servers to avoid conflicts between server applications, such as the limitation of having a single IPSec policy applied to a computer. I use Microsoft Virtual PC 2004. You can find information about this software at http://www.microsoft.com/virtualpc/.
When designing IPSec policies for your organization, follow one guideline before all others: keep it simple. Although you might want to provide different levels of security for different computers, use as few policies as possible to minimize the complexity of your system. A simpler system is less likely to produce problems and is also easier to troubleshoot if it does. You can further simplify the process of deploying IPSec by using the built-in policies: Client, Request Security, and Require Security. These policies have been configured to provide the maximum level of compatibility possible without significantly sacrificing security.
There is a significant limitation to using IPSec to protect communications within a domain: you should not use IPSec and Kerberos authentication between domain members and domain controllers. Establishing an IPSec connection requires sending a request to a domain controller, but if that request requires an IPSec connection to be established, you will never be able to complete the Internet Key Exchange (IKE) negotiation. In addition, no other authenticated connections can be made using other protocols, and no other IPSec policy settings can be applied to that domain member through Group Policy. For these reasons, Microsoft does not support using IPSec for communications between domain members and domain controllers.
There are additional limitations when using IPSec to protect traffic to a cluster. Many clustering and load-balancing services use the same IP address for all nodes in a cluster, which creates incompatibilities with IPSec. Windows Server 2003 IPSec has proprietary extensions that allow it to work with the Windows Server 2003 Network Load Balancing service and Windows Cluster Service. However, support for these extensions does not exist in the current Microsoft Windows 2000 and Windows XP IPSec client implementations, so you will experience some loss of connectivity when you add or remove Windows 2000 cluster nodes.
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. However, as Chapter 8 described, you can use the Netsh, Ipseccmd.exe, and Ipsecpol.exe command-line tools to create IPSec scripts. You can then include these scripts as startup scripts for each computer on your network. You can use Ipsecpol.exe only on computers running Windows 2000, Ipseccmd.exe only on computers running Windows XP, and the Netsh commands for IPSec only on computers running Windows Server 2003.
Although having three separate scripting tools for the three operating systems makes managing a typical network challenging, the three tools are similar in functionality. Although the exact parameters vary, each tool provides separate static and dynamic configuration modes and the ability to display existing IPSec configuration information. For each tool, the dynamic configuration mode changes the currently running IPSec settings, although static configuration mode changes the persistent configuration. In other words, dynamic configuration changes are lost after you restart your computer, but static configuration changes will remain.
Avoid scripting IPSec policies at all costs. I would make a different recommendation if Microsoft provided a single command-line interface that worked for all Windows operating systems, but, for now, it’s just not worth the trouble.
Every organization I’ve worked with has to support several versions of Windows. So, if you want to script IPSec policies for your entire organization, you’ll need to either create separate scripts for Windows Server 2003, Windows XP, and Windows 2000, or create a single complex script that contains commands for each of the scripting tools.
I’m glad Microsoft integrated IPSec functionality into Netsh, but I wish Microsoft would provide a single scripting interface for all supported Windows platforms. Scripting IPSec would be much more practical if the Netsh IPSec extensions were available for previous versions of Windows (perhaps in a feature pack), or if Windows Server 2003 were backwards-compatible with IPSecCmd and IPSecPol. Help, Microsoft!
In the meantime, if you must use IPSec scripting with Active Directory, you’ll have to create separate GPOs for each version of Windows and use Windows Management Instrumentation (WMI) filtering to deploy separate logon scripts to different platforms. Or you could create a single script that incorporates each of the three different IPSec scripting tools. That script would look something like this:
Netsh IPSec static add … Netsh IPSec static add … Netsh IPSec static add … IPSecCmd … IPSecPol …
Sure, several of the commands won’t work on any given version of Windows, but Windows will simply show an error that you can ignore. Besides being sloppy, the biggest drawback to this approach is that it’s error prone. You have to know three separate scripting tools, and every time you make a change to IPSec policy, you need to update the commands for each of the tools.
To script the creation of IPSec policy on computers running Windows Server 2003, use the Netsh IPSec commands. There are two ways to do this: use the Netsh ipsec static add command to add IP filters, rules, and IPSec policies, or use the Netsh ipsec static importpolicy command to import a saved IPSec policy.
Windows 2000 and Windows XP also include Netsh; however, they lack the IPSec extensions.
The simplest way to populate a list of IP security policies on a computer using a script is, ironically, to use a graphical tool. First, create the policies using the IP Security Policy Management snap-in. Then export the policies to a file. Finally, create a script that imports the policies on the destination Windows Server 2003–based computers by using the Netsh command-line tool. In this way, you can centrally manage the IPSec policies in your organization by exporting policies used by all computers to a central file server. Then distribute startup scripts that import the IP security policies, and assign one of the policies. Exercise 2 at the end of this lesson takes you through the process of exporting an IPSec policy and then importing it by using Netsh.
You can also create IPSec policies directly from the command line, without ever relying on graphical tools. The Netsh ipsec static add filteraction command can be used to create new filter actions. The Netsh ipsec static add filter and Netsh ipsec static add filterlist commands are used to create IP filters and IP filter lists. The Netsh ipsec static add policy command creates new policies, which can be immediately assigned. Finally, use the Netsh ipsec static add rule command to add rules to a policy by specifying IP filter lists and filter actions.
The Netsh command has a very complicated set of parameters. For a detailed list of parameters, run any of the commands without any parameters. For example, to view the syntax for adding a rule by using Netsh, open a command prompt and run Netsh ipsec static add rule.
The following Netsh script creates a new policy. The first line creates and assigns a policy named TestPolicy. Assigning the policy automatically un-assigns any other IPSec policies. The second line adds a filter action named DropPacket with the Block action. The third line adds a rule named NoICMP to the new TestFilter IPSec policy. The NoICMP rule is created by using the built-in IP filter list All ICMP Traffic and the newly created rule named Drop Packet.
netsh ipsec static add policy name=TestPolicy assign=yes activatedefaultrule=no netsh ipsec static add filteraction name=DropPacket action=block netsh ipsec static add rule name=NoICMP policy=TestPolicy filterlist="All ICMP Traffic" filteraction=DropPacket
I used the command netsh ipsec static add policy to create the batch file to configure and assign IPSec policy for the troubleshooting lab in Chapter 8. To script the creation of local or Active Directory–based IPSec policy on computers running Windows XP, you can use Ipseccmd.exe, a Windows Support Tool that is included in the Support Tools folder of the Windows XP operating system disc. To install IPSecCmd, you must perform a complete installation of the Support Tools. A normal installation does not install the IPSecCmd tool.
The syntax for IPSecCmd is complex. Creating scripts by using IPSecCmd is challenging even for people experienced with scripting, and the resulting scripts are difficult to maintain. Whenever you create a script, you need to plan for someone else to maintain that script in the event that you leave the organization. Because of IPSecCmd’s confusing syntax, administrators who take over the maintenance of your script will certainly have a difficult time updating the scripts. For these reasons, you should avoid using IPSecCmd except when absolutely necessary.
IPSecCmd uses a syntax similar to that of IPSecPol but very different from that of Netsh. While Netsh uses separate commands to create IP filters, rules, filter actions, and policies, IPSecCmd can create each of these components of an IPSec policy with a single command. For example, to create and assign a local policy named TestPolicy, with a rule named SecureTraffic, using a mirrored filter for any traffic to the local computer and a preshared key as the authentication method, run the following command:
ipseccmd -f 0+* -a p:"localauth" -w reg -p TestPolicy -r "SecureTraffic" -x
For detailed information about using IPSecCmd, open a command prompt and run Ipseccmd -? | more.
To script the creation of local or Active Directory–based IPSec policy on computers running Windows 2000, you can use Ipsecpol.exe, a command-line tool that is provided with the Windows 2000 Server Resource Kit. Ipsecpol.exe is not a full-featured command-line or scripting tool (for example, you cannot use Ipsecpol.exe to delete or rename filter lists or filter actions), nor is it supported under any Microsoft standard support program or service.
IPSecPol, thankfully, uses syntax that is very similar to that of IPSecCmd because IPSecCmd evolved from IPSecPol. In fact, most of the time you only need to change the name of the command when deploying a script to computers running both Windows 2000 and Windows XP. For example, to create and assign a local policy named TestPolicy, with a rule named SecureTraffic, using a mirrored filter for any traffic to the local computer and a preshared key as the authentication method, run the following command:
ipsecpol -f 0+* -a p:"localauth" -w reg -p TestPolicy -r "SecureTraffic" -x
One notable difference between IPSecCmd and IPSecPol is that IPSecPol cannot be used to display information about the computer’s current IPSec configuration. You can download IPSecPol from the Microsoft Web site at http://www.microsoft.com /windows2000/techinfo/reskit/tools/existing/ipsecpol-o.asp.
|Exam Tip|| |
You should know that you must use IPSecCmd for Windows XP, IPSecPol for Windows 2000, and Netsh for Windows Server 2003. It is much more important for you to be familiar with the syntax of Netsh than with the tools used with previous versions of Windows.
Although Kerberos is the simplest way to authenticate IPSec peers, certificates provide greater flexibility for authenticating non-Windows IPSec peers and other computers that are not members of an Active Directory domain. In Windows 2000 and Windows Server 2003, you can use Certificate Services to automatically manage computer certificates for IPSec authentication. IPSec also supports the use of a variety of non-Microsoft X.509 public key infrastructure (PKI) systems. Windows Server 2003 IKE has basic compatibility with several certificate systems, including those offered by Microsoft, Entrust, VeriSign, and Netscape. If you are using a non-Microsoft PKI system, the PKI system must be able to issue certificates to computers and store their certificates in the Windows Cryptographic Application Programming Interface (CryptoAPI) computer certificate store.
|See Also|| |
Chapter 7 covered Certificate Services in detail, so this chapter describes only the aspects of Certificate Services that relate directly to deploying certificates for IPSec.
IPSec’s use of certificate authentication is compatible with many different PKI architectures, and IKE places relatively few requirements on the contents of a certificate. Typically, computers that have a common trusted root, or whose certificates can chain through a cross-certification trust relationship, can successfully use certificate- based authentication for IPSec. To use certificates for IPSec authentication, you define an ordered list of acceptable root certification authority (CA) names in the authentication method.
Certificates obtained from Certificate Services with the advanced option set for Enable strong private key protection do not work for IKE authentication because a personal identification number (PIN) cannot be entered to access the private key during IKE negotiation.
If IKE authentication fails, you cannot retry the authentication using a different method. For this reason, before you apply an IPSec policy that can use certificates for authentication, make sure that all target computers have the correct root CA certificates and valid computer certificates. Additionally, to ensure that certificate authentication works as intended, test your PKI infrastructure with various IPSec policy configurations before deployment.
In Windows Server 2003, you can enable IPSec certificate-to-account mapping, as shown in Figure 9.2. This causes IPSec to look up the peer’s computer account in the Active Directory forest during certificate authentication. IPSec allows access from the peer only if the peer has a valid computer account and the account has the Access This Computer From The Network user right. This improves security because it eliminates the possibility that a computer with a valid certificate issued by your CA, but that is not a domain member, can establish an IPSec connection to a server. However, certificate- to-account mapping can only be used when all IPSec connections will come from computers in the same forest.
Figure 9.2: Configuring certificate-to-account mapping
If you use certificate authentication to establish trust between IPSec peers, you can configure Windows Server 2003 to exclude CA names from certificate requests. Excluding the CA name prevents a malicious user from learning sensitive information about the trust relationships of a computer, such as the name of the company that owns the computer and the domain membership of the computer (if an internal PKI is being used). Although excluding the CA name from certificate requests enhances security, computers with multiple certificates from different roots might require the CA root names to select the correct certificate. Also, some non-Microsoft IKE implementations might not respond to a certificate request that does not include a CA name. For these reasons, excluding the CA name from certificate requests might cause IKE certificate authentication to fail in certain cases.
In this practice, you will deploy IPSec by using two methods: using an Active Directory GPO and importing a policy from the command line.
In this exercise, you will configure Certificate Services to enroll IPSec certificates, enroll Computer1 and Computer2, and then deploy an IPSec policy requiring certificates authentication by using an Active Directory–based GPO.
First, install Certificate Services if it is not yet installed:
Log on to the cohowinery.com domain on Computer1 using the Administrator account.
Open Add Or Remove Programs in Control Panel.
Click Add/Remove Windows Components.
On the Windows Components page of the Windows Components Wizard, select the Certificate Services check box. When prompted, click Yes.
In the CA Type page, click Enterprise Root CA, and then click Next.
In the Common Name For This CA box, type computer1. Click Next.
On the Certificate Database Settings page, accept the defaults by clicking Next. If prompted to stop IIS, click Yes.
If prompted, click Yes to enable Active Server Pages.
After Certificate Services is installed, click Finish. Close all open windows.
Next, issue the built-in IPSec certificate template:
Click Start, point to Administrative Tools, and then click Certification Authority.
Expand Computer1. Right-click Certificate Templates, click New, and then click Certificate Template To Issue.
The Enable Certificate Templates dialog box appears.
Click IPSec, and then click OK.
Next, enroll Computer1 and Computer2 by using the IPSec security template. Repeat the following process on both Computer1 and Computer2:
Open a blank Microsoft Management Console (MMC) console, and then add the Certificates snap-in. When prompted to select the account, select Computer Account, and then select Local Computer.
Expand Certificates. Right-click Personal, click All Tasks, and then click Request New Certificate.
The Certificate Request Wizard appears.
Click Next. On the Certificate Types page, click IPSec.
Click Next twice, and then click Finish.
Next, configure an IPSec policy in the Default Domain Policy GPO that uses certificates for authentication:
Open a blank MMC console, and then add the Group Policy Object Editor snap- in. When prompted to select the GPO, click Browse and select the Default Domain Policy, click OK, and then click Finish.
Expand Default Domain Policy, Computer Configuration, Windows Settings, and Security Settings, and then click IP Security Policies On Active Directory.
Right-click IP Security Policies On Active Directory, and then click Create IP Security Policy.
The IP Security Policy Wizard appears.
Click Next. On the IP Security Policy Name page, type Certificate Authentication, and then click Next.
On the Requests For Secure Communication page, leave Activate The Default Response Rule selected, and then click Next.
On the Default Response Rule Authentication Method page, click Use A Certificate From This Certification Authority.
Click Browse. If prompted, click Yes. Select Computer1’s certificate, and then click OK.
Select Enable Certificate To Account Mapping. Click Next.
The Certification Authentication Properties dialog box appears.
The Security Rule Wizard appears.
Click Next three times.
On the IP Filter List page, click All IP Traffic. Click Next.
On the Filter Action page, click Request Security (Optional). Click Next.
On the Authentication Method page, click Use A Certificate From This Certification Authority.
Click Browse. If prompted, click Yes. Select Computer1’s certificate, and then click OK.
Select Enable Certificate To Account Mapping. Click Next.
You should select Enable Certificate To Account Mapping here because all of the computers that will be authenticating have valid computer accounts in the same forest.
On the Certificate Authentication Properties page, click OK.
In the Group Policy Object Editor snap-in, right-click Certificate Authentication, and then click Assign.
At this point, you have done everything you need to do to allow Computer1 and Computer2 to communicate by using IPSec authenticated by certificates. To make the new IPSec policy take effect immediately, run the command Gpupdate /force on both Computer1 and Computer2. Then verify that Computer1 and Computer2 can successfully establish a connection:
On Computer1, start Windows Explorer. On the Tools menu, click Map Network Drive. In the Folder box, type \\computer2\c$, and then click Finish. If prompted, provide Administrator credentials for Computer2. Browse the files on Computer2 to generate network traffic.
The purpose of this step is simply to communicate with Computer2.
Open a blank MMC console, and then add the IP Security Monitor snap-in. When prompted to select the computer or domain, select Local Computer, and then click Finish.
Expand Computer1, and then expand Main Mode. Click Security Associations.
In the right-pane, double-click the Security Association (SA) created between Computer1 and Computer2.
The Properties dialog box appears. The authentication type is listed as Certificate (RSA Signature), as shown in Figure 9.3. This verifies that IPSec authentication with certificates succeeded.
Figure 9.3: Security association authenticated with certificates
To prepare the computers for future exercises, return to the IP Security Policies On Active Directory snap-in, right-click Certificate Authentication, and then click Un- Assign.
In this exercise, you will export a security policy from the IP Security Policy Management snap-in. You will then import it by using Netsh to demonstrate how to import security policies by using startup scripts.
Log on to the cohowinery.com domain on Computer1 using the Administrator account.
Open a blank MMC console, and then add the IP Security Policy Management snap- in. When prompted to select the computer or domain, select Local Computer.
In the left pane, right-click IP Security Policies On Local Computer, click All Tasks, and then click Export Policies.
In the Save As dialog box, specify C:\ipsec-policies.ipsec
In the right pane, right-click Server (Request Security), and then click Delete. When prompted, click Yes.
Deleting this policy allows you to demonstrate that the policies were successfully re-imported later.
Leave the MMC console open, and open a command prompt.
At the command prompt, run the following command:
netsh ipsec static importpolicy C:\ipsec-policies.ipsec
Switch back to the MMC console, right-click IP Security Policies On Local Computer, and then click Refresh.
The Server (Request Security) policy will reappear, demonstrating that the policies were successfully exported and then reimported. In a production environment, you would probably locate the exported file on a centralized file server and perform the input from a startup script.
The following questions are intended to reinforce key information presented in this lesson. If you are unable to answer a question, review the lesson materials and try the question again. You can find answers to the questions in the “Questions and Answers” section at the end of this chapter.
Which of the following options ensures that certificates are accepted from only valid computer accounts in the same forest?
Enable Certificate To Account Mapping
Exclude The CA From The Certificate Request
Use Session Key Perfect Forward Secrecy
Use Master Key Perfect Forward Secrecy
Which of the following operating systems could you configure by using the IPSecPol command-line tool?
Windows Server 2003
The simplest way to deploy IPSec is to configure IPSec policies by using the Group Policy Object Editor and distribute the GPOs by using Active Directory.
You can configure IPSec policies on individual computers by using command-line tools. These local policies will be overridden by domain IPSec policies if any exist, however.
For Windows Server 2003, use Netsh to create IPSec policies from the command line. Use IPSecCmd for computers running Windows XP, and IPSecPol for computers running Windows 2000.
If all IPSec peers are not in a trusted Active Directory domain, you can use certificates to authenticate computers. Windows Server 2003 includes Certificate Services, which can be used to issue certificates for IPSec.
|< Day Day Up >|| |