| The following are the standard features of the Windows Server 2003 IPSec implementation: IPSec in Windows Server 2003 is policy based. Thus, it cannot be configured without an IPSec policy being in place. The IPSec policy allows an administrator to more easily apply settings to groups of objects, such as computers or users. IPSec on Windows Server 2003 can use Kerberos v5, a digital certificate, or a shared secret (string) for user authentication. IPSec mutually authenticates computers prior to any data being exchanged. IPSec establishes a security association (SA) between the two host computers involved in the data transfer. An SA is the collection of a policy and keys, which define the rules for security settings. IPSec encrypts data using Data Encryption Standard (DES) or Triple DES (3DES). IPSec uses the MD5 or SHA1 algorithm for data hashing. IPSec is invisible to users. IPSec operates at the network level of the Open System Interface (OSI) model; therefore, users and applications do not directly interact with the protocol. After an IPSec tunnel has been created, users can connect to applications and services as if they were on the local network and not on the other side of a public network.
The IPSec Authentication Header (AH) provides three services as part of the IPSec protocol. First (as its name might suggest), AH authenticates the entire packet. Second, it ensures data integrity. Third, it prevents any replaying of the packet by a third party who might be trying to penetrate the IPSec tunnel. One service AH doesn't provide is payload encryption. AH protects your data from modification, but an attacker who is snooping the network would still be able to read the data. To prevent the modification of the data, AH uses two hashing algorithms to "sign" the packet for integrity: The Message Digest 5 (MD5) algorithm applies the hashing function to the data in four passes. The Secure Hash Algorithm 1 (SHA-1) is closely modeled after MD5. SHA-1 uses 79 32-bit constants during the computation of the hash value, which results in a 160-bit key. Because SHA-1 has a longer key length, it is considered more secure than MD5.
Encapsulating Security Protocol (ESP) provides confidentiality in addition to authentication, integrity, and anti-replay. This portion of the IPSec protocol encrypts the data contents of the packet. The format of the ESP varies, depending on the type and mode of encryption being utilized. ESP can be used alone or in combination with AH. Policies allow you to quickly and easily configure IPSec based on the settings required within your organization. Windows Server 2003 comes with the following three preconfigured IPSec policies that may or may not meet your needs: Client (Respond Only) This policy requires IPSec-provided security only when another computer requests it. This policy allows the computer to attempt unsecured communications first and switch to IPSec-secured communications if requested. This policy contains the default response rule, which creates dynamic IPSec filters for inbound and outbound traffic. The filters are based on the requested protocol and the port traffic for the communication that is being secured. This policy, which can be used on workstations and servers alike, provides the minimum amount of IPSec security. Server (Request Security) This policy requests security from the other computer and allows unsecured communication with computers that are not IPSec-aware. The computer accepts inbound unsecured traffic, but always attempts to secure further communications by requesting IPSec security from the sending computer. If the other computer is not IPSec-enabled, the entire communication is allowed to be unsecured. This policy, which can be used on workstations and servers alike, provides a medium level of IPSec security. If desired, you can opt to use this policy on a workstation computer as well. Secure Server (Require Security) This policy is implemented on computers that require highly secure communications. These computers include servers transmitting sensitive data. The filters in this policy require all outbound communication to be secured, allowing only the initial inbound communication request to be unsecured. This policy has a rule to require security for all IP traffic, a rule to permit ICMP traffic, and the default response rule to respond to requests for security from other computers. This policy, typically used only on servers, provides the highest level of IPSec security on a network. This policy can also be used on workstation computers if you want. Computers that are not IPSec-enabled cannot establish any communications with computers using this policy. This policy can also be used on a workstation if desired.
Filter actions define the type of security and methods by which security is established. The default methods are Permit, Block, and Negotiate Security. The Permit option passes the traffic without the requirement for security. This action is appropriate if you never want to secure traffic to which a rule applies. The Block action silently blocks all traffic from computers specified in the IP filter list. The Negotiate Security action specifies that the computer is to use a list of security methods to negotiate the appropriate security for the communication. The IP Security Monitor snap-in is divided into three major areas: the Active Policy node, the Main Mode node, and the Quick Mode node. Table 12 explains each of the information items shown in the Active Policy node of the IP Security Monitor snap-in. The Active Policy is the IPSec policy that is currently in effect on the computer. Table 12. Active Policy Node ItemsItem | Description |
|---|
Policy Name | Specifies the name of the active IPSec policy. | Description | Describes the active IPSec policy. | Policy Last Modified | Provides the date and the time that the active IPSec policy was modified. | Policy Store | Provides the storage location for the active IPSec policy. For a local policy, it reads Local Store, and for a domain policy, it reads Domain Store. | Policy Path | Applies only to domain policies and provides the LDAP path to the active IPSec policy. | Organizational Unit | Applies only to domain policies and lists the organizational unit to which the group policy object (GPO) is applied. | Group Policy Object Name | Applies only to domain policies and lists the GPO to which the active IPSec policy is applied. |
Table 13 explains each of the information items shown in the Statistics folder in the Main Mode node of the IP Security Monitor snap-in. The Main Mode SA, also known as the ISAKMP SA, is used to protect the IPSec security negotiations. Table 13. Main Mode (Internet Key Exchange) StatisticsStatistic | Description |
|---|
Active Acquire | Specifies a request by the IPSec policy to have IKE perform a task. This number includes all outstanding and queued requests and is typically 1. Under heavy loading, this number increases. | Active Receive | Displays the number of IKE messages that have been received and are queued for processing. | Acquire Failures | Displays the number of times that an acquire has failed. | Receive Failures | Displays the number of times that errors have occurred in receiving IKE messages. | Send Failures | Displays the number of times that errors have occurred in sending IKE messages. | Acquire Heap Size | Displays the number of entries in the acquire heap, which stores active acquires. This number increases with heavy loading and decreases as the heap is cleared. | Receive Heap Size | Displays the number of entries in the IKE receive buffers for incoming IKE messages. | Authentication Failures | Displays the total number of identity authentication failures that have occurred during Main Mode negotiation. This is a very useful indicator to determine whether the authentication methods do not match between two computers attempting communications. | Negotiation Failures | Displays the total number of negotiation failures that occurred during Main Mode or Quick Mode negotiation. This is a useful statistic to determine whether security and/or authentication methods do not match between two computers attempting communications. | Invalid Cookies Received | Specifies a value contained in a received IKE message that is used by IKE to find the state of an active Main Mode. If a cookie in a received IKE message cannot be matched with an active Main Mode, it is invalid. | Total Acquire | Displays the total number of requests submitted by IKE to the IPSec driver to establish an SA for securing traffic. | Total Get SPI | Displays the total number of requests submitted by IKE to the IPSec driver to obtain a unique Security Parameters Index (SPI). | Key Additions | Displays the number of outbound Quick Mode SAs added by IKE to the IPSec driver. | Key Updates | Displays the number of inbound Quick Mode SAs added by IKE to the IPSec driver. | Get SPI Failures | Displays the number of requests submitted by IKE to the IPSec driver to obtain a unique SPI that have failed. | Key Addition Failures | Displays the number of outbound Quick Mode SA addition requests submitted by IKE to the IPSec driver that have failed. | Key Update Failures | Displays the number of inbound Quick Mode SA addition requests submitted by IKE to the IPSec driver that have failed. | ISADB List Size | Displays the number of Main Mode state entries, including negotiated Main Modes, Main Modes in progress, and Main Modes that have failed and have not yet been deleted. | Connection List Size | Displays the number of Quick Mode state entries. This number indicates the load placed on the computer. | IKE Main Mode | Displays the total number of successful SAs created during Main Mode negotiations. | IKE Quick Mode | Displays the total number of successful SAs created during Quick Mode negotiations. There are typically multiple Quick Mode SAs created for each Main Mode SA; thus, this value may not necessarily match that of the Main Mode. | Soft Associations | Displays the total number of negotiations that resulted in the use of unsecured traffic (also known as soft SAs). Typically this is an indication of SAs formed with computers that do not support IPSec or were not able to negotiate successful IPSec connections. This can be an indication of mismatched security and authentication settings. | Invalid Packets Received | Displays the number of received IKE messages that were invalid. Most commonly, invalid IKE messages are a result of retransmitted IKE messages or unmatched shared keys between the communicating computers. |
Table 14 explains each of the information items shown in the Statistics folder in the Quick Mode node of the IP Security Monitor snap-in. The Quick Mode SAs, also known as the IPSec SAs, are those security associations that have been created to protect the data sent between computers communicating securely using IPSec. Table 14. Quick Mode (IPSec) StatisticsStatistic | Description |
|---|
Active Security Associations | Displays the number of active IPSec SAs. | Offloaded Security Associations | Displays the number of active IPSec SAs that have been offloaded to hardware. | Pending Key Operations | Displays the number of IPSec key operations that are in progress. | Key Additions | Displays the total number of successful IPSec SA negotiations. | Key Deletions | Displays the number of key deletions for IPSec SAs. | Re-Keys | Displays the number of rekey operations for IPSec SAs. | Active Tunnels | Displays the number of active IPSec tunnels. | Bad SPI Packets | Displays the total number of packets for which the SPI was incorrect. SPIs are used to match inbound packets with SAs. If the SPI is incorrect, the inbound SA may have expired. If rekeying intervals are set very short, this number is likely to increase rapidly. Under normal conditions, a bad SPI packet does not mean that IPSec is failing because SAs expire normally. | Packets Not Decrypted | Displays the total number of packets that were not decrypted successfully. This may indicate that a packet has arrived for which the SA has previously expired. When the SA expires, the session key used to decrypt packets is removed. By itself, this does not indicate that IPSec is failing. | Packets Not Authenticated | Displays the total number of packets for which data could not be verified, meaning that the integrity hash verification failed. Most commonly this is a result of an expired SA. | Packets with Replay Detection | Displays the total number of packets that contained a valid Sequence Number field. | Confidential Bytes Sent | Displays the total number of bytes sent using the ESP protocol. | Confidential Bytes Received | Displays the total number of bytes received using the ESP protocol. | Authenticated Bytes Sent | Displays the total number of bytes sent using the AH protocol. | Authenticated Bytes Received | Displays the total number of bytes received using the AH protocol. | Transport Bytes Sent | Displays the total number of bytes sent using IPSec transport mode. | Transport Bytes Received | Displays the total number of bytes received using IPSec transport mode. | Bytes Sent in Tunnels | Displays the total number of bytes sent using IPSec tunnel mode. | Bytes Received in Tunnels | Displays the total number of bytes received using IPSec tunnel mode. | Offloaded Bytes Sent | Displays the total number of bytes sent using hardware offload. | Offloaded Bytes Received | Displays the total number of bytes received using hardware offload. |
Configuring the IP Security Monitor hasn't changed much since Windows 2000, except that the IP Security Monitor is now an MMC snap-in. You can open the IP Security Monitor properties for any server listed in the IP Security Monitor node by right-clicking it and selecting Properties from the context menu. You have the option to change the refresh interval for the display of the IP Security Monitor statistics and to decide whether you want to enable DNS name resolution, which comes into play when you're examining the SAs that are formed. If you have problems with IPSec, you should first verify that any routers or firewalls that traffic may be passing through are configured to support IPSec traffic. You need to allow the following traffic: Some other basic problems and troubleshooting tips for them are outlined here: You are not able to establish any communications with a computer In this case, you should first verify that basic network connectivity exists between the computers in question by using the ping command. You should also ensure that all required network services, such as DHCP and DNS, are operating properly for both computers. You are not able to establish any communications with a computer This may be a result of a computer having been removed from the domain. Whatever the cause, IPSec communications will fail. Communications are occurring, but not as expected You need to ensure that you have the correct (and compatible) IPSec policies assigned on both computers. No hard associations are being formed If there are currently soft associations in place, a hard association will not be formed. You need to completely stop all communications between the computers for approximately 5-10 minutes to allow the soft associations to time out. The easiest way to do this is to disable the network connection. After you have allowed the soft association to time out, you should check to see that a hard association has been formed. If a hard association still has not been formed, you need to examine the IPSec policy to verify that unsecured communications are not allowed. IPSec communications are failing after you configure a digital certificate for authentication You must make sure that the required digital certificate is installed on the computers that are attempting to communicate by using that IPSec policy. This can also be a result of specifying an incorrect Certificate Authority (CA). Some computers can create IPSec connections and some cannot This is most likely caused by not having the same IPSec policy applied to all the computers. If you are intentionally using different policies, you need to ensure that they share at least one common authentication and security method.
You should also be aware that IPSec-related problems can be found in the security log. You can view IKE events (negotiation successes and negotiation failures) by enabling success and/or failure auditing for the Audit Logon Events audit policy for the domain or the local computer. The IKE event category is also used for the auditing of user logon events in other services as well, but you can disable this by editing the registry. For more information on configuring and implementing auditing, refer to Chapter 5, "Implementing, Managing, and Maintaining Network Security." When success and/or failure auditing for the Audit Logon Events audit policy is enabled, IPSec records the success and/or failure of each Main Mode and Quick Mode negotiation. The establishment and termination of each negotiation is logged as a separate event for easier analysis and troubleshooting. Be aware, however, that when you enable audit logon events, the security log will likely quickly fill up with IKE events unless you opt to disable auditing of those events through registry editing. Although there are no default tools provided in Windows Server 2003 that allow you to monitor and manipulate Kerberos tickets, two Windows Server 2003 Resource Kit tools are available: kerbtray.exe You can use the kerbtray.exe utility to view cached Kerberos tickets for the current computer from within the Windows GUI. klist.exe The klist.exe utility is a command-line tool that is similar to kerbtray.exe. klist.exeallows you to view and delete cached Kerberos tickets.
You can download the Windows Server 2003 Resource Kit tools from www.microsoft.com/downloads if you search for "Windows Server 2003 Resource Kit Tools." |
