Understanding Receive Connectors
Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2
Receive connectors are configured on computers that are running Microsoft Exchange Server 2010 and that have the Hub Transport server role or Edge Transport server role installed. Receive connectors represent a logical gateway through which all inbound messages are received. This topic provides an overview of Receive connectors and how the configuration of Receive connectors affects individual message processing.
Overview of Receive Connectors
Exchange 2010 transport servers require Receive connectors to receive messages from the Internet, from e-mail clients, and from other e-mail servers. A Receive connector controls inbound connections to the Exchange organization. By default, the Receive connectors that are required for internal mail flow are automatically created when the Hub Transport server role is installed. The Receive connector that's capable of receiving mail from the Internet and from Hub Transport servers is automatically created when the Edge Transport server role is installed. However, end-to-end mail flow is possible only after the Edge Transport server has been subscribed to the Active Directory site by using the Edge Subscription process. Other scenarios, such as an Internet-facing Hub Transport server or an unsubscribed Edge Transport server, require manual connector configuration to establish end-to-end mail flow.
In Exchange 2010, the Receive connector is a receive listener. This means that the connector is listening for inbound connections that match the settings of the Receive connector. A Receive connector listens for connections that are received through a particular local IP address and port, and from a specified IP address range. You create Receive connectors when you want to control which servers receive messages from a particular IP address or IP address range, and when you want to configure special connector properties for messages that are received from a particular IP address, such as a larger message size, more recipients per message, or more inbound connections.
Receive connectors are scoped to a single server and determine how that specific server listens for connections. When you create a Receive connector on a Hub Transport server, the Receive connector is stored in Active Directory as a child object of the server on which it's created. When you create a Receive connector on an Edge Transport server, the Receive connector is stored in Active Directory Lightweight Directory Services (AD LDS).
If you need additional Receive connectors for specific scenarios, you can create them by using the Exchange Management Console (EMC) or the Exchange Management Shell. Each Receive connector must use a unique combination of IP address bindings, port number assignments, and the remote IP address ranges from which mail will be accepted by this connector.
Default Receive Connectors Created During Setup
Certain Receive connectors are created by default when you install a Hub Transport or Edge Transport server role.
Default Receive Connectors Created on a Hub Transport Server
When you install the Hub Transport server role, two Receive connectors are created. No additional Receive connectors are needed for typical operation, and in most cases the default Receive connectors don't require a configuration change. The usage type and configuration of these connectors are described in the following table.
Default Receive connector configuration on Hub Transport servers
| Connector name and usage type | Configuration |
|---|---|
Client Servername This Receive connector accepts SMTP connections from all non-MAPI clients, such as POP and IMAP. |
|
Default Servername This Receive connector accepts connections from other Hub Transport servers and any Edge Transport servers you have. |
|
Note
Any Receive connector that's responsible for accepting connections from Edge Transport servers or other Hub Transport servers must have the Exchange Server authentication method assigned to it. The Exchange Server authentication method is the default authentication method when you create a Receive connector that has the Internal usage type.
Default Receive Connector Created on an Edge Transport Server
During installation, one Receive connector is created. This Receive connector is configured to accept SMTP communications from all IP address ranges and is bound to all IP addresses of the local server. It's configured to have the Internet usage type, and therefore, the connector accepts anonymous connections. In a typical installation, no additional Receive connectors are required. If you use EdgeSync, you don't need to make any configuration changes because the Edge Subscription process automatically configures permissions and authentication mechanisms. Anonymous sessions and authenticated sessions are granted different permission sets.
If you don't use EdgeSync, we recommend that you modify the settings of this Receive connector and create an additional Receive connector of the Internal usage type. To complete Receive connector configuration, follow these steps:
Modify the settings of the default Receive connector Set the local network bindings to the IP address of only the Internet-facing network adapter.
Create a Receive connector Select Internal as the connector usage type. Set the local network bindings to the IP address of only the organization-facing network adapter. Configure the remote network settings to receive mail from the remote IP addresses that are assigned to the Hub Transport servers.
Note
Any Receive connector that's responsible for accepting connections from Edge Transport servers or other Hub Transport servers must have the Exchange Server authentication method assigned to it. The Exchange Server authentication method is the default authentication method when you create a Receive connector that has the Internal usage type.
Determine whether Basic authentication is desired If you want to support Basic authentication, create a local user account and grant the necessary permissions by using the Add-ADPermission cmdlet.
For more information, see Configure Mail Flow Between an Edge Transport Server and Hub Transport Servers Without Using EdgeSync.
Receive Connector Usage Types
The usage type determines the default security settings for the connector.
The security settings for a Receive connector specify the permissions that are granted to sessions that connect to the Receive connector and the supported authentication mechanisms.
When you use the EMC to configure a Receive connector, the New SMTP Receive Connector wizard prompts you to select the usage type for the connector. You can use two different methods to specify the usage type:
Use the Usage parameter with the desired value, such as Usage
Custom. There are other required parameters based on the usage type that you specify. If you don't specify the required parameters in the New-ReceiveConnector command, the command will fail.Use the switch parameter for the desired usage type, such as Custom. There are other required parameters based on the usage type that you specify. If you don't specify the required parameters in the New-ReceiveConnector command, you're prompted for the missing parameter values so the command can continue.
Permission Groups
A permission group is a predefined set of permissions that's granted to well-known security principals and assigned to a Receive connector. Security principals include users, computers, and security groups. A security principal is identified by a security identifier (SID). Permission groups are only available for Receive connectors. The use of permission groups simplifies the configuration of permissions on Receive connectors. The PermissionGroups property defines the groups or roles that can submit messages to the Receive connector and the permissions that are assigned to those groups. The set of permission groups is predefined in Exchange 2010. This means that you can't create additional permission groups. Also, you can't modify the permission group members or the associated permissions.
The following table lists the available permission groups and identifies the security principals and the permissions that are granted when that permission group is configured for a Receive connector.
Receive connector permission groups
| Permission group name | Associated security principals (SIDs) | Permissions granted |
|---|---|---|
Anonymous |
Anonymous user account |
|
ExchangeUsers |
Authenticated user accounts |
|
ExchangeServers |
|
|
ExchangeLegacyServers |
Exchange Legacy Interop security group |
|
Partner |
Partner Server account |
|
Receive Connector Usage Types
The usage type determines the default permission groups that are assigned to the Receive connector and the default authentication mechanisms that are available for session authentication. A Receive connector always responds to a request from a sender to use TLS. The following table describes the available usage types and default settings.
Receive connector usage types
| Usage type | Default permission groups | Default authentication mechanism |
|---|---|---|
Client (unavailable on Edge Transport servers) |
ExchangeUsers |
TLS Basic authentication plus TLS Integrated Windows authentication |
Custom |
None |
None |
Internal |
ExchangeServers ExchangeLegacyServers (This permission group is unavailable on Edge Transport servers.) |
Exchange Server authentication |
Internet |
AnonymousUsers Partner |
None or Externally Secured |
Partner |
Partner |
Not applicable. This usage type is selected when you establish mutual TLS with a remote domain. |
The Receive connector permissions and authentication mechanisms are discussed later in this topic.
Receive Connector Usage Scenarios
Each usage type is appropriate for a specific connection scenario. Select the usage type that has the default settings most applicable to the configuration that you want. You can modify permissions by using the Add-ADPermission and Remove-ADPermission cmdlets. For more information, see the following topics:
The following table lists common connection scenarios and the usage type for each scenario.
Receive Connector usage scenarios
| Connector scenario | Usage type | Comment |
|---|---|---|
Edge Transport server receiving e-mail from the Internet |
Internet |
A Receive connector that's configured to accept e-mail from all domains is created automatically when the Edge Transport server role is installed. |
Hub Transport server receiving e-mail from the Internet |
Internet |
This isn't a recommended configuration. For more information, see Configure Internet Mail Flow Directly Through a Hub Transport Server. |
Edge Transport server receiving e-mail from an Exchange Server 2003 bridgehead server |
Internal |
In this scenario, the Exchange 2003 bridgehead server is configured to use the Edge Transport server as a smart host for a Send connector. |
Hub Transport server receiving e-mail submissions from a client application that uses POP3 or IMAP4 |
Client |
This Receive connector is automatically created on every Hub Transport server when the role is installed. By default, this Receive connector is configured to receive e-mail through TCP port 587. |
Hub Transport server receiving e-mail from a Hub Transport server |
Internal |
You don't have to configure Receive connectors between Hub Transport servers within the same organization. This usage type can be used to configure a cross-forest Receive connector. |
Hub Transport server receiving e-mail from an Exchange 2003 bridgehead server in the same forest |
Internal |
This is an optional configuration. Transport between Exchange 2010 and earlier versions of Exchange is accomplished through two-way routing group connectors. If you create SMTP connectors to Exchange 2003 routing groups, a routing group connector must also exist. For more information, see Create Additional Routing Group Connectors from Exchange 2010 to Exchange 2003. |
Edge Transport server receiving e-mail from a Hub Transport server |
Internal |
A Receive connector that's configured to accept e-mail from all domains is created automatically when the Edge Transport server role is installed. You can create another connector and configure it to receive e-mail only from the Exchange organization. |
Cross-forest Receive connector for a Hub Transport server in one forest receiving e-mail from a Hub Transport server in a second forest |
Custom |
For detailed configuration steps, see Configure Cross-Forest Connectors. |
Cross-forest Receive connector for a Hub Transport server in one forest receiving e-mail from an Exchange 2003 bridgehead server in a second forest |
Custom |
For detailed configuration steps, see Configure Cross-Forest Connectors. |
Hub Transport server receiving e-mail from a third-party message transfer agent (MTA) |
Internal |
Specify the IP address range from which messages will be accepted and set the authentication mechanism to either Basic authentication or Externally Secured. |
Edge Transport server receiving e-mail from a third-party MTA |
Custom |
Use the Add-ADPermission cmdlet to set the extended rights. Specify the IP address range from which messages will be accepted and set the authentication mechanism to Basic authentication. You can also select the Internal usage type and set Externally Secured as the authentication method. No additional permissions configuration is required if you select this option. |
Edge Transport server receiving e-mail from an external relay domain |
Custom |
The Edge Transport server can accept e-mail from an external relay domain and then relay to the destination recipient domain. Specify the IP address range from which messages will be accepted, set the appropriate authentication mechanism, and use the Add-ADPermission cmdlet to set the extended rights. |
Edge Transport server receiving e-mail from a domain to which you have established mutual TLS authentication |
Partner |
Mutual TLS authentication functions correctly only if the following conditions are true:
For more information, see Set-ReceiveConnector. |
Edge Transport server receiving connections from Microsoft Exchange Hosted Services server |
Custom |
The Exchange Hosted Services server can act as an externally authoritative server. To use the Externally Secured authentication mechanism, use the Set-ReceiveConnector cmdlet to set the PermissionGroup parameter to |
Hub Transport server receiving connections from an Exchange Hosted Services server |
Custom |
The Exchange Hosted Services server can act as an externally authoritative server. To use the Externally Secured authentication mechanism, use the Set-ReceiveConnector cmdlet to set the PermissionGroup parameter to |
Receive Connector Permissions
Receive connector permissions are assigned to security principals when you specify the permission groups for the connector. When a security principal establishes a session with a Receive connector, the Receive connector permissions determine whether the session is accepted and how the received messages are processed. The following table describes the permissions that can be assigned on a Receive connector to security principals. You can set Receive connector permissions by using the EMC or by using the PermissionGroups parameter with the Set-ReceiveConnector cmdlet in the Shell. To modify the default permissions for a Receive connector, you can also use the Add-ADPermission cmdlet.
Receive connector permissions
| Receive connector permission | Description |
|---|---|
ms-Exch-SMTP-Submit |
The session must be granted this permission or it will be unable to submit messages to this Receive connector. If a session doesn't have this permission, the MAIL FROM and AUTH commands will fail. |
ms-Exch-SMTP-Accept-Any-Recipient |
This permission allows the session to relay messages through this connector. If this permission isn't granted, only messages that are addressed to recipients in accepted domains are accepted by this connector. |
ms-Exch-SMTP-Accept-Any-Sender |
This permission allows the session to bypass the sender address spoofing check. |
ms-Exch-SMTP-Accept-Authoritative-Domain-Sender |
This permission allows senders that have e-mail addresses in authoritative domains to establish a session to this Receive connector. |
ms-Exch-SMTP-Accept-Authentication-Flag |
This permission allows Exchange 2003 servers to submit messages from internal senders. Exchange 2010 will recognize the messages as being internal. The sender can declare the message as trusted. Messages that enter your Exchange system through anonymous submissions will be relayed through your Exchange organization with this flag in an untrusted state. |
ms-Exch-Accept-Headers-Routing |
This permission allows the session to submit a message that has all received headers intact. If this permission isn't granted, the server will strip all received headers. |
ms-Exch-Accept-Headers-Organization |
This permission allows the session to submit a message that has all organization headers intact. Organization headers all start with X-MS-Exchange-Organization-. If this permission isn't granted, the receiving server will strip all organization headers. |
ms-Exch-Accept-Headers-Forest |
This permission allows the session to submit a message that has all forest headers intact. Forest headers all start with X-MS-Exchange-Forest-. If this permission isn't granted, the receiving server will strip all forest headers. |
ms-Exch-Accept-Exch50 |
This permission allows the session to submit a message that contains the XEXCH50 command. This command is needed for interoperability with Exchange 2003. The XEXCH50 command provides data such as the spam confidence level (SCL) for the message. |
ms-Exch-Bypass-Message-Size-Limit |
This permission allows the session to submit a message that exceeds the message size restriction configured for the connector. |
Ms-Exch-Bypass-Anti-Spam |
This permission allows the session to bypass anti-spam filtering. |
Local Network Settings
In the EMC, you use the local network settings for a Receive connector to specify the IP address and port through which the transport server accepts connections. In the Shell, use the Bindings parameter to specify the local IP address and port of the transport server through which the Receive connector accepts connections. These settings bind the Receive connector to a particular network adapter and TCP port on the transport server.
By default, a Receive connector is configured to use all available network adapters and TCP port 25. If a transport server has multiple network adapters, you may want a Receive connector to be bound to a particular network adapter, or to accept connections through an alternative port. For example, you may want to configure one Receive connector on the Edge Transport server to accept anonymous connections through the external network adapter. A second Receive connector can be configured to accept connections from only Hub Transport servers through the internal network adapter.
Note
If you choose to bind a Receive connector to a specific local IP address, that IP address must be valid for the Hub Transport server or Edge Transport server on which the Receive connector is located. If you specify an invalid local IP address, the Microsoft Exchange Transport service may fail to start when the service is restarted. Instead of binding the Receive connector to a specific IP address, you can bind the Receive connector to all available IP addresses on the Hub Transport server or Edge Transport server.
Specify the IP address of the network adapter when you configure Receive connector bindings. If the Receive connector is configured to accept connections through a port other than the default, the sending client or server must be configured to send to that port and any firewalls between the message sender and the receiving server must allow network traffic through that port.
The Local Network Settings page of the New SMTP Receive Connector wizard in the EMC includes an option to Specify the FQDN this connector will provide in response to HELO or EHLO. In the Shell, this property is set by using the Fqdn parameter with the Set-ReceiveConnector cmdlet. After an SMTP session is established, an SMTP protocol conversation starts between a sending e-mail server and a receiving e-mail server. The sending e-mail server or client sends the EHLO or HELO SMTP command and its FQDN to the receiving server. In response, the receiving server sends a success code and provides its own FQDN. In Exchange 2010, you can customize the FQDN that's provided by the receiving server if you configure this property on a Receive connector. The FQDN value is displayed to connected messaging servers whenever a destination server name is required, as in the following examples:
In the default SMTP banner of the Receive connector
In the most recent
Received:header field in the incoming message when the message enters the Hub Transport server or Edge Transport serverDuring TLS authentication
Note
Don’t modify the FQDN value on the default Receive connector named Default <Server Name> that's automatically created on Hub Transport servers. If you have multiple Hub Transport servers in your Exchange organization and you change the FQDN value on the Default <Server Name> Receive connector, internal mail flow between Hub Transport servers will fail.
Remote Network Settings
In the EMC, you use the remote network settings for a Receive connector to specify the IP address ranges from which this Receive connector accepts connections. In the Shell, you use the RemoteIPRanges parameter to specify the IP address ranges from which this Receive connector accepts connections. By default, Receive connectors are created on Hub Transport servers and Edge Transport servers that allow connections from 0.0.0.0–255.255.255.255, or from every IP address.
Note
In Exchange 2010 , the IPv6 address range 0000:0000:0000:0000:0000:0000:0.0.0.0–ffff:ffff:ffff:ffff:ffff:ffff:255.255.255.255 also exists in the default Receive connectors on a Hub Transport server.
If you're configuring a Receive connector for a specific scenario, set the remote network settings to only the IP addresses of the servers that should be allowed the permissions and configuration settings for the Receive connector. Multiple Receive connectors can have overlapping remote IP address ranges as long as one range is completely overlapped by another. When remote IP address ranges overlap, the remote IP address range that has the most specific match to the connecting server's IP address is used.
The IP address or IP address range for the remote servers from which the Receive connector will accept inbound connections is entered in one of the following formats:
IP address 192.168.1.1
IP address range 192.168.1.10-192.168.1.20
IP address together with subnet mask 192.168.1.0(255.255.255.0)
IP address together with subnet mask by using Classless Interdomain Routing (CIDR) notation 192.168.1.0/24
Receive Connector Authentication Settings
In the EMC, you use the authentication settings for a Receive connector to specify the authentication mechanisms that are supported by the Exchange 2010 transport server. In the Shell, you use the AuthMechanisms parameter to specify the supported authentication mechanisms. You can configure more than one authentication mechanism for a Receive connector. For the authentication mechanisms that are automatically configured for each usage type, see the table labeled "Receive connector usage types" earlier in this topic. The following table lists the available authentication mechanisms for a Receive connector.
Receive connector authentication mechanisms
| Authentication mechanism | Description |
|---|---|
None |
No authentication. |
TLS |
Advertise STARTTLS. Requires availability of a server certificate to offer TLS. |
Integrated |
NTLM and Kerberos (Integrated Windows authentication). |
BasicAuth |
Basic authentication. Requires an authenticated logon. |
BasicAuthRequireTLS |
Basic authentication over TLS. Requires a server certificate. |
ExchangeServer |
Exchange Server authentication (Generic Security Services application programming interface (GSSAPI) and Mutual GSSAPI). |
ExternalAuthoritative |
The connection is considered externally secured by using a security mechanism that's external to Exchange. The connection may be an Internet Protocol security (IPsec) association or a virtual private network (VPN). Alternatively, the servers may reside in a trusted physically controlled network. The |
Additional Receive Connector Properties
The property configuration for a Receive connector defines how e-mail is received through that connector. Not all properties are available in the EMC. For more information about the properties that can be configured by using the Shell, see Set-ReceiveConnector.
Using a Receive Connector for Anonymous Relay
Anonymous relay on Internet SMTP messaging servers is a serious security deficiency that could be exploited by unsolicited commercial e-mail senders, or spammers, to hide the source of their messages. Therefore, restrictions are placed on Internet-facing messaging servers to prevent relaying to unauthorized destinations.
In Exchange 2010, relaying is typically handled by using accepted domains. Accepted domains are configured on the Edge Transport server or Hub Transport server. The accepted domains are additionally classified as internal relay domains or external relay domains. For more information about accepted domains, see Understanding Accepted Domains.
You can also restrict anonymous relay based on the source of the incoming messages. This method is useful when an unauthenticated application or messaging server must use a Hub Transport server or an Edge Transport server as a relay server.
When you create the Receive connector that's configured to allow anonymous relay, you should place the following restrictions on the Receive connector:
Local network settings Restrict the Receive connector to listen only on the appropriate network adapter on the Hub Transport server or Edge Transport server.
Remote network settings Restrict the Receive connector to accept connections only from the specified server or servers. This restriction is necessary, because the Receive connector is configured to accept relay from anonymous users. Restricting the source servers by IP address is the only measure of protection that's allowed on this Receive connector.
To grant the relay permission to anonymous users on the Receive connector, you can use either of the strategies described later in this topic. Each strategy has advantages and disadvantages. For step by step instructions for both approaches, see Allow Anonymous Relay on a Receive Connector.
Granting Relay Permission to Anonymous Connections
This strategy involves the following tasks:
Creating a Receive connector with the usage type set to
Custom.Adding the Anonymous permission group to the Receive connector.
Assigning the relay permission to the Anonymous Logon security principal on the Receive connector.
The Anonymous permission group grants the following permissions to the Anonymous Logon security principal on the Receive connector:
Ms-Exch-Accept-Headers-Routing
Ms-Exch-SMTP-Accept-Any-Sender
Ms-Exch-SMTP-Accept-Authoritative-Domain-Sender
Ms-Exch-SMTP-Submit
However, to allow anonymous relay on this Receive connector, you must also grant the following permission to the Anonymous Logon security principal on the Receive connector:
- Ms-Exch-SMTP-Accept-Any-Recipient
The advantage of this strategy is that it grants the minimum required permissions to relay to the specified remote IP addresses.
The disadvantages of this strategy are as follows:
Additional configuration steps are required to grant the necessary permissions.
The messages that originate from the specified IP addresses are treated as anonymous messages. Therefore, the messages don't bypass anti-spam checks, don't bypass message size limit checks, and anonymous senders can't be resolved. The process of resolving anonymous senders forces an attempted match between the anonymous sender's e-mail address and the corresponding display name in the global address list (GAL).
Configuring the Receive Connector as Externally Secured
This strategy involves the following tasks:
Creating a Receive connector with the usage type set to
Custom.Adding the ExchangeServers permission group to the Receive connector.
Adding the
ExternalAuthoritativeauthentication mechanism to the Receive connector.
The ExchangeServers permission group is required when you select the ExternalAuthoritative authentication mechanism. This combination of authentication method and permission group grants the following permissions to any incoming connection that's permitted on the Receive connector:
Ms-Exch-Accept-Headers-Routing
Ms-Exch-SMTP-Accept-Any-Sender
Ms-Exch-SMTP-Accept-Authoritative-Domain-Sender
Ms-Exch-SMTP-Submit
Ms-Exch-Accept-Exch50
Ms-Exch-Bypass-Anti-Spam
Ms-Exch-Bypass-Message-Size-Limit
Ms-Exch-SMTP-Accept-Any-Recipient
Ms-Exch-SMTP-Accept-Authentication-Flag
The advantages of this strategy are as follows:
Ease of configuration
The messages that originate from the specified IP addresses are treated as authenticated messages. The messages bypass anti-spam checks, bypass message size limit checks, and can resolve anonymous senders.
The disadvantage of this strategy is that the remote IP addresses are considered completely trustworthy. The permissions that are granted to the remote IP addresses allow the remote messaging server to submit messages as if they originated from internal senders within your Exchange organization.
New Features in Exchange 2010 Service Pack 1
In Service Pack 1 (SP1) for Exchange Server 2010, new functionality was added to Receive connectors. This section provides an overview of these new features.
Bare Line Feed Control
When a mail server establishes an SMTP session, it issues SMTP commands to send messages. After specifying the sender and recipient information, the sending server transmits the contents of the message using the DATA command. The content that is transmitted after issuing the DATA command is known as the data stream. The data stream is terminated by a special sequence of characters: a carriage return line feed (CRLF), followed by a period, followed by another CRLF.
Line feed (LF) characters that aren’t immediately preceded by carriage return (CR) characters are known as bare line feeds. Bare line feeds aren’t allowed in SMTP communications. Although it may be possible for a message containing a bare line feed to be delivered successfully, such messages don't adhere to the SMTP protocol standards and may cause problems with messaging servers.
In Exchange 2010 SP1, you can configure your Receive connectors to reject any messages that contain bare line feeds in their data stream. This behavior is controlled by the BareLineFeedRejectionEnabled parameter of the Set-ReceiveConnector cmdlet. By default, this setting is disabled to maintain backwards compatibility. For more information about configuring this parameter, see Set-ReceiveConnector.
Extended Protection Capability
Windows offers channel binding to protect NTLM authentication over encrypted channels from authentication relay attacks. In Exchange 2010, all services provided by Exchange have been updated to support Extended Protection for Authentication. To support this feature in Transport, the Receive connectors have been updated. You can allow, require, or disable Extended Protection for Authentication on your Receive connectors.
You can use the ExtendedProtectionPolicy and ExtendedProtectionTlsTerminatedAtProxy parameters of the Set-ReceiveConnector cmdlet to control how your Transport servers handle extended protection. You can configure a Receive connector to allow or require extended protection. When you configure a Receive connector to require extended protection, any incoming connections from hosts that don't support extended protection will be rejected. To maintain backwards compatibility, the extended protection is disabled by default. For more information about configuring extended protection on your Receive connectors, see Set-ReceiveConnector.
To learn more about extended protection, see the following resources:
Microsoft Knowledge Base article 973811, Microsoft Security Advisory: Extended protection for authentication
MSDN Library topic, Integrated Windows Authentication with Extended Protection
© 2010 Microsoft Corporation. All rights reserved.