New Network Services Support

   

---

The following sections describe improvements to network service support that have been made in the Windows Server 2003 family:

• TAPI 3.1 and TAPI Service Providers

• Real Time Communication Client APIs

• DHCP

• DNS

• WINS

• IAS

• IPSec

TAPI 3.1 and TAPI Service Providers

Previous Windows operating systems shipped with earlier versions of the Telephony API (TAPI), the most recent being Windows 2000 shipping with TAPI 3.0. TAPI enables applications to be created that provide various types of telephony services to users.

Windows XP and Windows Server 2003 include TAPI 3.1. TAPI 3.1 supports the Microsoft Component Object Model (COM) and provides a set of COM objects to the programmer. This enables the use of any COM-compatible programming application and scripting languages for writing telephony applications. Also included in Windows Server 2003 are TAPI service providers (TSPs) that provide functionality for H.323-based IP telephony and IP multicast audio and video conferencing on TCP/IP networks. This is in addition to the TSPs provided with earlier versions of Windows. The H.323 TSP and the media service provider (MSP) provide support for H.323 version 2 functionality. Also provided with TAPI 3.1 are the following:

• File terminals

  Allow applications to record streaming data (such as speech or video) to a file and play this recorded data back to a stream

• Pluggable terminals

  Allow a third party to add new terminal objects that can be used by any MSP

• USB phone TSP

  Allows an application to control a USB phone and use it as a streaming endpoint

• Autodiscovery of TAPI servers

  Allows clients to discover telephony servers available on the network

Additionally, for H.323, the following supplementary services (richer call-control features) have been implemented:

• Call Hold Service (ITU-T Recommendation H.450-2)

• Call Transfer Service (ITU-T Recommendation H.450-2)

• Call Diversion Services (ITU-T Recommendation H.450-3)

• Call Park and Pickup Service (ITU-T Recommendation H.450-5)

Real Time Communication Client APIs

The Real Time Communication (RTC) Client Application Programming Interfaces feature provides the next -generation communications platform based on the Session Initiation Protocol (SIP). SIP provides the protocol to set up a generic session using an e-mail address without having the need to know the location of the caller; therefore, it provides a more efficient means of communication. RTC enables rapid deployment of Internet applications that are enhanced with converged applications, such as voice, video, and data collaboration applications.

The Windows Server 2003 family now includes the RTC client APIs, which include functionality such as buddy-list management, user activity detection, the ability to create instant messaging sessions as well as audio and video sessions between two clients, telephony calls to any telephone number, application sharing, and whiteboard sessions. The client APIs include firewall tunneling to a SIP server over Secure Sockets Layer (SSL), digest and basic authentication, and NAT logic to enable real-time communications sessions across Universal Plug and Play (UPNP) “enabled NATs. The APIs provide access to a high-performance audio and video media stack. Audio and video quality has been greatly improved by other new features, including the following:

• AcousticEcho cancellation.

  Headsets are not required to make audio calls, and built-in echo cancellation provides high-quality communications.

• Quality control.

  This new algorithm dynamically alters the settings for audio and video based on detected changes in network conditions.

• Forward Error Correction.

  Forward Error Correction (FEC) is used to compensate for packet loss introduced by network congestion.

• Dynamic jitter buffers.

  Dynamic jitter buffers are used to smooth the received audio to eliminate the impact of variation in delay between received packets.

RTC client APIs enable the following scenarios:

• An ISV that develops games leverages the RTC client APIs to add buddy lists, instant messaging, and audio/video to its new game. Players can instantly message, talk, or see one another during a game session.

• An IT administrator writes a small application to alert all users of an e-mail server going off line for maintenance.

• An ISV that sells budget management and payroll applications creates an ActiveX control using the RTC client APIs. It embeds the control in its server Web pages so that department administrators can see the availability of their payroll contact, address budget questions through instant messaging or audio, and jointly analyze budget statements using application sharing.

This feature is not provided with the 32-bit version of Web Edition.

DHCP

The following improvements to Dynamic Host Configuration Protocol (DHCP) have been made in the Windows Server 2003 family:

• Backup and restoration with DHCP.

  The DHCP snap-in now provides new menu items for backup and restoration of DHCP databases. When the user chooses either of these menu items, a browser window is displayed, offering the selection of a location; new folders can be created as well. An IT administrator can use this feature to do backups and restores on servers running the Windows Server 2003 family. This feature is not provided with Web Edition.

• Classless static route option.

  DHCP clients can request this option to be supplied with a list of routes to add to their routing table. This arrangement allows remote access and VPN clients to perform split tunneling when connecting to remote networks. It also allows LAN clients to obtain additional routing information. For example, an IT administrator can use this feature to allow clients to split-tunnel through a virtual private network (VPN) connection and the Internet. This allows traffic destined for the Internet to avoid going through the VPN connection, while also allowing the user to access his or her organization's private network resources.

• DHCP database migrations with Netsh.

  This feature enables an easier migration of a DHCP database from one server to another if it is imported using Netsh. Doing so eliminates most manual configurations, such as manually editing the registry or re-creating scopes. The Netsh command is used to locally configure servers and routers and can also use script files to automate configuration tasks . This feature can be used in the following cases:

  • An IT administrator notices disk error messages on the DHCP server and decides to move the DHCP service before the disk fails completely.

  • Because of performance issues on the network segment on which the DHCP server resides, an IT administrator needs to divide its DHCP server. The IT administrator can use this feature to move portions of the DHCP database to another computer or computers.

• DHCP lease deletion with Netsh.

  Using the new netsh dhcp server scope scopeaddress delete lease command, you can delete a DHCP lease from the command line instead of using the DHCP snap-in. This feature enables easier management of DHCP server operations using command lines and scripts.

DNS

The following improvements to DNS have been made in the Windows Server 2003 family:

• Active Directory integrated DNS zones stored in application partitions.

  This feature enables storage and replication of the Domain Name System (DNS) zones stored in the Active Directory service in the application partition. Using application partitions to store the DNS data results in a reduced number of objects stored in the global catalog. In addition, when DNS zone data is stored in an application partition, it is replicated to only that subset of domain controllers in the domain that is specified in the application partition. By default, DNS-specific application partitions contain only those domain controllers that run the DNS server. In addition, storing DNS zone data in an application partition enables replication of the DNS zone to the DNS servers running on the domain controllers in different domains of an Active Directory forest. An IT administrator can use this feature to store a DNS zone in an application partition. This is recommended in case an Active Directory “integrated DNS zone is hosted by the DNS servers running on a member of the Windows Server 2003 family.

• Basic compliance with DNS Security Extensions.

  A DNS server running a member of the Windows Server 2003 family provides basic compliance with the Internet Engineering Task Force (IETF) “standard DNS Security Extensions protocol as defined in RFC 2535. The DNS server can store the record types (KEY, SIG, and NXT) defined in the IETF standard and include these records when responding to the queries according to RFC 2535. The server does not provide full compliance and does not perform the cryptographic operations specified in RFC 2535 (KEY/SIG record generation, message signing, and signature verification). However, the server can store and use standard KEY and SIG records generated by third-party software. An IT administrator can use a DNS server running a member of the Windows Server 2003 family as a secondary server for the signed zone with the primary copy on the server that fully supports DNS Security Extensions (per RFC 2535).

• Domain join procedure enhancements to detect incorrectly configured DNS.

  This feature simplifies debugging and reporting of an incorrect DNS configuration and helps to properly configure the DNS infrastructure required to enable a computer to join a domain. When a computer attempting to join an Active Directory domain fails to locate a domain controller because DNS is incorrectly configured or the domain controllers are not available, the debugging of the DNS infrastructure is performed. This generates a report explaining the cause of the failure and how to fix the problem. If the DNS infrastructure is properly configured to allow the computer to join the domain, an IT administrator will not notice the presence of this feature. Otherwise, if the DNS infrastructure is incorrectly configured and prevents a computer from locating a domain controller and joining a domain, it will be brought to the IT administrator's attention when the IT administrator attempts to join the computer to a domain.

• Manage DNS clients using Group Policy.

  This feature allows administrators to configure the DNS client settings on computers running a member of the Windows Server 2003 family using Group Policy. This simplifies the steps required to configure domain members when adjusting DNS client settings such as enabling and disabling dynamic registration of the DNS records by the clients, using devolution of the primary DNS suffix during name resolution, and populating DNS suffix search lists. In addition to providing simplified administration, Group Policy support for the DNS suffix search list is an important feature, which is required in a transition to an environment without NetBIOS. An IT administrator can use this Group Policy feature to configure DNS clients.

• Stub zones and conditional forwarding.

  Stub zones and conditional forwarding are two DNS server features that provide the ability to control the routing of DNS traffic on a network. A stub zone allows a DNS server to be aware of the names and addresses of servers that are authoritative for the full copy of a zone, without that server having to hold a complete copy of the zone or having to send queries to the DNS root servers. A DNS server running Windows 2000 can be configured to forward DNS queries to only one set of DNS servers. The conditional forwarding feature in the Windows Server 2003 family provides improved granularity, supporting name-dependent forwarding. For example, a DNS server can be configured to simultaneously

  • Forward queries for names ending in usa.microsoft.com to a first set of DNS servers.

  • Forward queries for names ending in europe.microsoft.com to a second set of DNS servers.

  • Forward all other queries to a third set of DNS servers.

  An IT administrator can use this feature to control the routing of DNS traffic on their network.

• Support for EDNS0 protocol.

  The EDNS0 protocol defined in RFC 2671 allows DNS servers to accept and transmit UDP DNS messages with a payload size greater than 512 octets. This feature is useful for an IT administrator when DNS responses, such as service location (SRV) resource record queries used to locate Active Directory domain controllers, are larger than 512 octets. Prior to the Windows Server 2003 family, these responses required extra round trips to set up and tear down a TCP session. In the Windows Server 2003 family, by using the EDNS0 protocol, many of these responses can be returned in a single UDP round trip without requiring TCP session setup and teardown .

• Additional enhancements.

  The DNS Server service in the Windows Server 2003 family also supports the following additional enhancements:

  • Round- robin support for all resource record (RR) types.

    By default, the DNS Server service will perform round-robin rotation for all RR types.

  • Enhanced debug logging.

    The enhanced DNS Server service debug logging settings can help troubleshoot DNS problems.

  • Automatic Name Server resource record.

    DNS Server can now control automatic Name Server (NS) resource record registration on a server and zone basis.

WINS

The following improvements to the Windows Internet Name Service (WINS) have been made in the Windows Server 2003 family:

• Filtering records.

  Improved filtering and new search functions help you locate records by showing only those records that fit the criteria you specify. These functions are particularly useful in analyzing very large WINS databases. You can use multiple criteria to perform advanced searches for WINS database records. This improved filtering capability allows you to combine filters for customized and precise query results. Available filters include record owner, record type, NetBIOS name, and IP address with or without subnet mask. Because you can now store query results in the cache of the memory on your local computer, the performance of subsequent queries is increased, and network traffic is reduced.

• Accepting replication partners .

  When determining a replication strategy for your organization, you can define a list that controls the source of incoming name records during pull replication between WINS servers. In addition to blocking name records from specific replication partners, you can also choose to accept only name records owned by specific WINS servers during replication, excluding the name records of all servers that are not on the list.

IAS

The following improvements to IAS have been made in the Windows Server 2003 family. IAS is not available with Web Edition:

• Support for IEEE 802.1x authentication for secure wireless and local area networks.

  IAS has been enhanced to allow authentication and authorization of users and computers connecting to IEEE 802.11b wireless access points and Ethernet switches using IEEE 802.1X authentication. The remote access policy NAS-Port-Type condition now includes the ability to select wireless and Ethernet connection types.

  For secure wireless or Ethernet connections, you should use either certificates (EAP-TLS) or passwords protected with Protected EAP (PEAP) and MS-CHAP v2 authentication. EAP-TLS uses certificates to authenticate credentials and provide encryption key material. EAP-TLS requires a certificate infrastructure to issue certificates to both the IAS servers and the wireless or Ethernet clients. With PEAP and MS-CHAP v2, you can use password-based authentication securely because the MS-CHAP v2 authentication exchange is encrypted with a secure TLS channel, preventing offline dictionary attacks against user passwords. The PEAP authentication exchange also produces encryption key material. PEAP with MS-CHAP v2 requires certificates to be installed only on the IAS servers.

  PEAP allows for a resumption of the TLS session created from an initial PEAP authentication. This feature of PEAP, known as fast reconnect , causes subsequent authentications based on the TLS session to occur very quickly because most of the messages of a full PEAP authentication are not sent. PEAP fast reconnect minimizes connection and authentication times and does not require a user to resubmit authentication credentials, such as a username or password. For example, wireless clients that roam from one wireless authentication protocol to another have more seamless network connectivity and are not prompted for authentication credentials.

  To select PEAP with MS-CHAP v2 on an IAS server, perform the following steps: In the Internet Authentication Service snap-in, click EAP Methods on the Authentication tab of the profile properties of a remote access policy. In the Select EAP Providers dialog box, click Protected Extensible Authentication Protocol (PEAP) and either edit its properties or move it to the top of the list of EAP types.

• Session time reflects account restrictions.

  IAS now calculates a session time for a connection as needed that is based on the user or computer account's expiration time and permitted logon hours. For example, a user account is restricted to logon from 9:00 A.M. to 5:00 P.M., Monday through Friday. If a connection is made using the user account at 4:00 P.M. on Friday, IAS will automatically calculate a maximum session time of 1 hour for the connection and send the maximum session time as a RADIUS attribute to the access server. At 5:00 P.M., the access server terminates the connection. This new feature provides network access behavior that is consistent with account date and time restrictions.

• IAS and cross-forest authentication.

  If Active Directory forests are in cross-forest mode with two-way trusts, IAS can authenticate the user account in the other forest. An IT administrator can use this feature to provide authentication and authorization for accounts in other two-way trusted Active Directory forests that are in cross-forest mode.

• IAS as a RADIUS proxy.

  This feature allows IAS to forward RADIUS authentication and accounting messages between access servers and RADIUS servers. This functionality includes the following:

  • Flexible rule-based forwarding

  • Load balance and failover between multiple RADIUS servers and load balancing of RADIUS requests

  • Ability to force an access client to use a compulsory tunnel, with or without user authentication

  • Selective forwarding of authentication and accounting requests to different RADIUS servers

    This feature allows the following scenarios:

  • An IT administrator can create an IAS-based RADIUS proxy located in one domain to authenticate and authorize users in another domain that does not have a trust relationship or has only a one-way trust relationship, or is in another forest.

  • An ISP offering outsourced dial-up, VPN, or wireless services to a corporation can forward user authentication and accounting requests to a corporate RADIUS server.

  • In some network perimeter configurations, an IT administrator can install an IAS proxy in the network perimeter. Requests can be forwarded from the IAS proxy at an ISP to an IAS server in the organization's network.

  • ISPs working with partner ISPs or network infrastructure providers can use an IAS RADIUS proxy in a roaming consortium.

  • IT administrators can use IAS for organization networks that connect with partner networks to forward authentication of users from other companies to their user account database.

• Logging RADIUS information to a SQL database.

  IAS can be configured to send logging information for accounting requests, authentication requests, and periodic status to a Structured Query Language (SQL) server. This allows IT administrators to use SQL queries to obtain historical and real-time information about connection attempts that use RADIUS for authentication. To configure, obtain properties of the SQL Server logging method in the Remote Access Logging folder of the Internet Authentication Service snap-in.

• EAP-TLS unauthenticated access.

  EAP-TLS unauthenticated access provides a means to grant guest access for a wireless or switch client that does not have a certificate installed. If a network access client does not provide credentials, IAS determines whether unauthenticated access is enabled in the remote access policy that matched the connection attempt. EAP-TLS supports one-way authorization or unauthenticated access where the client does not send credentials.

  This feature allows the following scenarios:

  • An IT administrator can use this feature to allow wireless or switch clients that do not have certificates to connect to a restricted virtual local area network (VLAN) for bootstrap configuration.

  • An IT administrator can use this feature to allow access to visitors or business partners to the corporation's network to access the Internet. This is done by giving them access to a restricted VLAN or by IP filters that allow traffic to go to the Internet.

  • A wireless ISP can use this feature to allow access to potential subscribers. The potential subscribers can get access to a restricted VLAN with local information. After the user subscribes for Internet access, the client can connect to the Internet.

• RADIUS client configuration supports a range of IP addresses.

  To simplify administration of Remote Authentication Dial-In User Service (RADIUS) clients when numerous wireless access points are on the same subnet or within the same IP address space, IAS allows you to configure a range of addresses for a RADIUS client.

  The address range for RADIUS clients is expressed in the network prefix length notation w.x.y.z/p , where w.x.y.z is the dotted decimal notation of the address prefix and p is the prefix length (the number of high-order bits that define the network prefix). This is also known as Classless Inter-Domain Routing (CIDR) notation. An example is 192.168.21.0/24. To convert from subnet mask notation to network prefix length notation, p is the number of high-order bits set to 1 in the subnet mask.

  An IT administrator can use this feature to simplify management of wireless access points.

• Improvement to negotiating EAP authentication method.

  This feature allows you to select multiple EAP types when configuring remote access policies. This allows IAS to negotiate the EAP authentication method with clients from multiple selected EAP methods. An IT administrator can use this feature when network access clients use different EAP authentication methods and can configure the server to specify a list of allowed EAP authentication methods.

• Object identifier checking for user certificates and smart cards.

  To require specific types of user-level certificates for specific types of connections, IAS supports the specification of individual certificate issuance policy object identifiers (OIDs) that must be included in the certificate of the access client as part of the remote access policy profile settings. For example, if an IT administrator wants to ensure that remote access VPN connections use a smart card certificate rather than a locally installed user certificate, the administrator configures the appropriate remote access policy to require the object identifier for the Smart Card Logon certificate issuance policy (1.3.6.1.4.1.311.20.2.2) to be present in the certificate offered by the remote access VPN client. You can configure a list of object identifiers required to be present in the user certificate offered by the access client by using the Allow Certificates With These OIDs attribute on the Advanced tab on the properties of a remote access policy profile. No required object identifiers are specified by default.

• Load balancing as RADIUS proxy.

  This feature provides the ability to balance the load of authentication across multiple RADIUS servers when IAS is used as a RADIUS proxy. This provides the ability to scale up and handle geographic failover. The IAS RADIUS proxy dynamically balances the load of connection and accounting requests across multiple RADIUS servers and increases the processing of large numbers of RADIUS clients and authentications per second. Additionally, the RADIUS proxy can be configured to mark certain RADIUS servers with higher preference. The RADIUS servers with lower preference are not used if higher ones are available.

  This feature enables the following scenarios:

  • An IT administrator can use this feature to scale up wireless, virtual private network (VPN), or dial-up authentication to process a large number of connection requests using multiple RADIUS servers.

  • An IT administrator can use this feature to ensure that connection requests fail over to nearby RADIUS servers if they are available and to configure RADIUS servers at a remote site as backup RADIUS servers.

• Support for ignoring the dial-in properties of accounts.

  You can configure a RADIUS attribute on the profile properties of a remote access policy to ignore the dial-in properties of accounts. The dial-in properties of an account contain the following:

  • Remote access permission

  • Caller ID

  • Callback options

  • Static IP address

  • Static routes

  To support multiple types of connections for which IAS provides authentication and authorization, it might be necessary to disable the processing of account dial-in properties. This can be done to support scenarios in which specific dial-in properties are not needed. For example, the caller ID, callback, static IP address, and static routes properties are designed for a client that is dialing into a network access server (NAS). These settings are not designed for wireless access points (APs). A wireless AP that receives these settings in the RADIUS message from the IAS server might be unable to process them, which could cause the wireless client to become disconnected. When IAS provides authentication and authorization for users who are both dialing in and accessing the organization network through wireless technology, the dial-in properties must be configured to support either dial-in connections (by setting dial-in properties) or wireless connections (by not setting dial-in properties).

  You can use IAS to enable dial-in properties processing for the user account in some scenarios (such as dial-in) and to disable dial-in-properties processing for user account dial-in properties in other scenarios (such as wireless and authenticating switch). This is accomplished by configuring the Ignore-User-Dialin-Properties attribute on the Advanced tab of the profile settings for a remote access policy. The Ignore-User-Dialin-Properties attribute is set to the following:

  • To enable account dial-in properties processing, delete the Ignore-User-Dialin-Properties attribute or set it to False . For example, for a remote access policy that is designed for dial-in connections, no additional configuration is required.

  • To disable user account dial-in properties processing, set the Ignore-User-Dialin-Properties attribute to True . For example, this is set for the remote access policy that is designed for wireless or authenticating switch connections. When the dial-in properties of the user account are ignored, remote access permission is determined by the remote access permission setting for the remote access policy.

    You can also use this attribute to manage network access control through groups and the remote access permission on the remote access policy. By setting the Ignore-User-Dialin-Properties attribute to True , the remote access permission on the user account is ignored. The disadvantage to using the Ignore-User-Dialin-Properties attribute in this way is that you cannot use the additional dial-in properties of caller-ID, callback, static IP address, and static routes for connections that match the remote access policy.

• Support for computer authentication.

  Active Directory and IAS support the authentication of computer accounts by using standard user authentication methods. This allows a computer and its credentials to be authenticated for wireless or authenticating switch access clients.

• Support for the Authentication Type remote access policy condition.

  You can create remote access policies using the Authentication Type condition. This new condition allows you to specify connection constraints that are based on the authentication protocol or method that is used to validate the access client.

• Enhanced IAS SDK.

  The Windows .NET Platform Software Development Kit (SDK) contains two smaller networking SDKs ”the IAS SDK and the EAP SDK. The IAS SDK can be used to return custom attributes to the access server in addition to those returned by IAS, to control the number of user network sessions, to import usage and audit data directly into an Open Database Connectivity (ODBC) “compliant database, to create customized authorization modules, and to create customized authentication modules (non-EAP). The EAP SDK can be used to create EAP types. A developer can use the enhancements to the IAS SDK to modify or delete RADIUS attributes and to convert Access-Rejects to Access-Accepts. An ISV or a value-added reseller (VAR) can use this feature to create enhanced solutions with IAS. An IT administrator can use this feature to create custom solutions for IAS.

• Scriptable API to configure IAS.

  This feature makes available, in the IAS Platform SDK, a scriptable API that allows configuration of IAS. An ISV can use this feature to provide value-added services on top of an IAS infrastructure, and an IT administrator can use this feature to integrate their IAS with their own service management infrastructure.

• Enhanced EAP configuration for remote access policies.

  In Windows 2000, you can select only a single EAP type for a remote access policy. This means that all connections matching the conditions of the policy must use the single EAP type selected in the policy profile settings. Additionally, the configuration of an EAP type is global to all the remote access policies. These limitations can cause problems when you want to individually configure the properties for EAP types for each policy or when you want to select multiple EAP types for a type of network connection or per group. These limitations are removed for IAS in the Windows Server 2003 family. For example, you might want to select different computer certificates for EAP-TLS authentication for wireless connections versus VPN connections, or you might want to select multiple EAP types for wireless connections because some of your wireless clients use EAP-TLS authentication and others use PEAP with MS-CHAP v2.

• Separation of authentication and authorization for IAS proxy.

  The proxy component of IAS in the Windows Server 2003 family supports the ability to separate the authentication and authorization of connection requests from access servers. The IAS proxy can forward the user credentials to an external RADIUS server for authentication and perform its own authorization using a user account in an Active Directory domain and a locally configured remote access policy. With this feature, alternative user authentication databases can be used, but connection authorization and restrictions are determined through local administration.

  This feature allows the following scenarios:

  • A visitor to an organization network can be granted access to a guest LAN by authentication using the visitor's credentials and authorization of the connection using a user account in an untrusted visitors Active Directory domain and a remote access policy configured on the IAS proxy. The visitor's credentials can be the credentials of the user account at the visitor's organization.

  • A public wireless network can use an alternative user database to authenticate wireless access and authorize logons with local user accounts in an Active Directory domain.

  This new capability is configured using the Remote-RADIUS-to-Windows-User-Mapping setting in the advanced properties of a connection request policy.

IPSec

The following improvements to IPSec have been made in the Windows Server 2003 family:

• New IP Security Monitor snap-in.

  A new IP Security Monitor snap-in provides detailed IPSec policy configuration and active security state. This replaces the Ipsecmon.exe tool provided with Windows 2000. An IPSec policy consists of a set of main-mode policies, a set of quick-mode policies, a set of main-mode filters that are associated with the set of main-mode policies, and a set of quick-mode filters (both transport-mode and tunnel-mode) that are associated with the set of quick-mode policies. The active security state consists of the active main-mode and quick-mode security associations and statistical information about IPSec-protected traffic. An IT administrator can use this new snap-in for improved IPSec monitoring and troubleshooting.

• Command-line management with Netsh.

  Using commands in the Netsh ipsec context, you can configure static or dynamic IPSec main mode settings, quick-mode settings, rules, and configuration parameters. To enter the Netsh ipsec context, type netsh -c ipsec at the command prompt. The Netsh ipsec context replaces the Ipsecpol.exe tool provided with the Windows 2000 Server Resource Kits. An IT administrator can use this feature to script and automate IPSec configuration.

• IP security and network load balancing integration.

  This feature allows a group of servers using Network Load Balancing (NLB) to provide highly available IPSec-based VPN services. This is also supported by down-level L2TP/IPSec clients. This feature also provides the capability for faster IPSec failover. An IT administrator can use this feature to integrate NLB and IPSec-based VPN services for a more secure and reliable network service. Because the IKE protocol automatically detects the NLB service, no additional configuration is required to use this feature. This feature is provided only with the Enterprise Edition and the Datacenter Edition.

• IPSec support for RSoP.

  To enhance IPSec deployment and troubleshooting, IPSec now provides an extension to the Resultant Set Of Policy (RSoP) snap-in. RSoP is an addition to Group Policy that you can use to view existing IPSec policy assignments and to simulate planned IPSec policy assignments for a computer or a user. To view existing policy assignments, you can run an RSoP logging-mode query. To simulate planned IPSec policy assignments, you can run an RSoP planning-mode query.

  Logging-mode queries are useful for troubleshooting precedence issues for IPSec policy. The results of logging-mode queries display all of the IPSec policies that are assigned to an IPSec client and the precedence of each policy. Planning-mode queries are useful for deployment planning because they allow you to simulate different IPSec policy settings. By simulating different IPSec policy settings, you can evaluate the impact of changing policy settings and determine the optimum settings, before you implement them. After you run an RSoP logging-mode query or an RSoP planning-mode query, you can view detailed settings (the filter rules, filter actions, authentication methods, tunnel endpoints, and connection type that were specified when the IPSec policy was created) for the IPSec policy that is being applied.

• IPSec NAT traversal.

  This feature allows IKE-protected and ESP-protected traffic to traverse a NAT. IKE automatically detects that a NAT is present and uses User Datagram Protocol-Encapsulating Security Payload (UDP-ESP) encapsulation to allow ESP-protected IPSec traffic to pass through the NAT. The Windows Server 2003 family support for IPSec NAT traversal is described in the Internet drafts titled "UDP Encapsulation of IPsec Packets" (draft-ietf-ipsec-udp-encaps-02.txt) and "Negotiation of NAT-Traversal in the IKE" (draft-ietf-ipsec-nat-t-ike-02.txt).

  With this support, a corporate employee can use L2TP/IPSec when connected to a private network, such as a hotel or home network. This feature also supports more general IPSec ESP transport and mode security associations across a NAT. An administrator can use this feature to configure gateway-to-gateway IPSec tunnels between two computers running members of the Windows Server 2003 family and the Routing and Remote Access service when one or both are behind a NAT. This will also permit server-to-server IPSec connections, such as a server on the perimeter network that is communicating across a NAT to an internal network server.

• Network address translation hardware acceleration.

  IPSec now supports NAT hardware acceleration for normal ESP traffic. This feature supports the following scenarios:

  • An IT administrator can use this feature to scale L2TP/IPSec and normal IPSec connections when IPSec over NAT is used.

  • An independent hardware vendor (IHV) can use this functionality to build new cards or update older firmware to use the new encapsulation.

  The IPSec hardware acceleration interface is documented in the Windows DDK as part of TCP/IP Task Offload.

• IPSec policy filters allow logical addresses for local IP configuration.

  The IP Security Policies snap-in can now configure source or destination address fields to be interpreted by the local IPSec policy service as the addresses for the DHCP server, the DNS servers, the WINS servers, and default gateway. Therefore, IPSec policy can now automatically accommodate changes in the server's IP configuration, using either DHCP or static IP configurations. Computers running Windows 2000 or Windows XP ignore this extension to the IPSec policy.

• Certificate mapping to Active Directory computer account provides access control.

  The IP Security Policies snap-in can now be configured to map a computer certificate to the computer account within an Active Directory forest. This takes advantage of the same SChannel certificate mapping that IIS and other PKI-enabled services use. After the certificate is mapped to a domain computer account, access controls can be set using the settings for network logon rights Access This Computer From Network and Deny Access To This Computer From Network. A network administrator can now restrict access to a computer running a member of the Windows Server 2003 family using IPSec to allow access only to computers from a specific domain, computers that have a certificate from a particular issuing certification authority, a specific group of computers, or even a single computer. Computers running Windows 2000 or Windows XP ignore this extension to the IPSec policy.

• Stronger Diffie-Hellman group for Internet Key Exchange.

  IPSec now supports the use of a 2048-bit Diffie-Hellman key exchange, providing support for the Internet draft titled "More MODP Diffie-Hellman groups for IKE." With a stronger Diffie-He-llman group, the resulting secret key derived from the Diffie-Hellman exchange has greater strength. The IP Security Policies snap-in allows you to configure this new Diffie-Hellman group setting for both the local and the domain-based IPSec policy. Computers running Windows XP and Windows 2000 ignore this setting.

• Better denial-of-service protection for IKE.

  IKE in the Windows Server 2003 family has been modified to better handle denial-of-service attacks involving IKE traffic. The most common attack is garbage packets sent to UDP port 500. IKE attempts to validate the packets until there are too many incoming packets, at which point IKE starts to drop packets. When the incoming rate subsides, IKE quickly restarts inspection for valid IKE packets. The most difficult attack to prevent is a malicious user sending valid IKE initiation messages to an IKE responder, either using invalid source IP addresses or just rapidly sending from a valid source IP address. This attack is similar to the TCP Synchronize (SYN) attack launched against TCP/IP-based servers. With the new protection, the IKE responder responds to the initial valid IKE message with an IKE message containing a special value in the Responder Cookie field. If the IKE initiator does not send the next message with the Responder Cookie field properly set, the IKE exchange is ignored. When Windows Server 2003 is the IKE initiator, it reinitiates properly. The IPSec IKE module does not maintain any state on the IKE negotiation until after the response containing the properly set Responder Cookie field is received. This maintains interoperability with computers running Windows 2000 or Windows XP and third-party IPSec implementations and improves the chance that a legitimate initiator can successfully negotiate, even when the responder is under a limited attack. It is still possible for an IKE responder to be overwhelmed by a flood of legitimate IKE packets. The IKE responder recovers as fast as possible once the attack has ceased.

---

Top