You can configure more than one authentication mechanism on a Receive connector. For a Receive connector, the authentication setting determines the set of authentication mechanisms that are enabled by the server to authenticate sessions that submit messages to the server. The sending server determines which authentication mechanism is used.

Table 1 lists the authentication mechanisms that you can configure on a Receive connector. To configure the Receive connector authentication mechanism, use the Authentication tab of the Receive connector properties in the Exchange Management Console or the AuthMechanism parameter with the Set-ReceiveConnector cmdlet in the Exchange Management Shell.

Table 1   Authentication mechanisms for Receive connectors

Authentication mechanism	Description
None	No authentication options are offered.
Transport Layer Security (TLS)	The connector offers STARTTLS to clients.
Integrated Windows authentication	The connector offers AUTH plus NTLM GSSAPI to clients. GSSAPI enables clients to negotiate either NTLM or Kerberos.
Basic authentication	The connector offers AUTH plus LOGIN to clients. The user name and password are received in clear text from the client. This mechanism requires a Windows account to validate credentials.
Basic authentication over TLS	This is the policy modifier for Basic authentication. The connector offers AUTH plus LOGIN to the client only after the client has negotiated TLS. This mechanism also requires that TLS be set as the authentication mechanism.
Exchange Server authentication	The connector offers EXPS plus GSSAPI for Exchange servers that are running earlier versions of Exchange Server and X-ANONYMOUSTLS to clients for Exchange 2007 servers.
Externally Secured (for example, with IPsec)	This option considers any connection as coming from another authoritative server.

For a Send connector, the SmartHostAuthMechanism setting determines how the sending server authenticates with the target smart host. The SmartHostAuthMechanism can only have one value. If a SmartHostAuthMechanism is configured, the authentication must succeed before mail is sent. If the authentication mechanism that is used by the sending Exchange 2007 server isn't provided by the smart host, the server won't send e-mail messages and the session will end. If the authentication mechanism used by the sending Exchange 2007 server is provided, but authentication fails, the server will also not send e-mail messages and the session will end.

Table 2 lists the authentication mechanisms that you can configure on a Send connector. To configure the Send connector authentication mechanism, use the Configure the Smart Host Authentication dialog on the Network tab of the Send connector properties in the Exchange Management Console or the SmartHostAuthMechanism parameter with the Set-SendConnector cmdlet in the Exchange Management Shell.

Table 2   Authentication mechanisms for smart host connectors

Authentication mechanism	Description
None	Anonymous access is allowed.
Basic authentication	The connector must use AUTH plus LOGIN. This requires that you provide a user name and password. Basic authentication sends credentials in clear text. All smart hosts with which this Send connector is authenticating must accept the same user name and password. If the RequireTLS parameter is also set to $True, the connector must use TLS before submitting credentials, but no server certificate verification is performed.
Basic authentication requires TLS	This is a policy modifier for Basic authentication. It requires that the connector use TLS before it tries AUTH. It also requires the sending server to perform X.509 certificate validation of the receiving server. Certificate validation includes checking the certificate revocation list (CRL) and matching the server identity against the list of smart hosts configured on the connector before it tries AUTH. One of the fully qualified domain names (FQDN) listed as a smart host must be present in the server certificate for name matching to succeed. Therefore, if the FQDN of the smart host points to an MX record, the listed smart host FQDN must be present in the certificate.
Exchange Server authentication	The connector must use either EXPS plus GSSAPI for Exchange servers that are running earlier versions of Exchange Server or X-ANONYMOUSTLS for Exchange 2007 servers.
Externally secured (for example, with IPsec)	The network connection is secured by using a method that is external to the Exchange server.

Transport Layer Security

Domain Security

Externally Secured Authentication

Exchange 2007 transport servers use the Windows authorization model for an SMTP session to determine whether the sender is authorized to submit messages to a specific connector, to a specific recipient, and as a specific sender, for example. An SMTP session receives an initial set of permissions (anonymous). After a session is authenticated, more permissions are available to the session. This changes the set of actions that are authorized for the session.

In the Windows authorization model, permissions are granted through an access control interaction that compares the access token to the access control lists (ACL). An access token lists a set of security principals. A security principal can be a user account, computer account, or security group. Every security principal has an associated security identifier (SID). Each session is assigned an access token. The ACLs are defined on the connector object in Active Directory or ADAM. A DACL contains a set of access control entries (ACE). Each ACE either allows or denies a permission to a security principal. When the transport server checks to determine whether the session is granted a permission, such as submit e-mail, it calls a Windows access check API and supplies the session access token and the connector's DACL as parameters together with the requested permission.

This process is identical to the way a file read permission is determined. The access token, the file DACL, and the requested permission are submitted to the same API. The API checks each security principal that is listed in the access token against each ACE in the DACL to determine whether the requested permission is allowed or denied. In addition to the Windows SIDs that are provided by Active Directory, ADAM, or the local Security Accounts Manager (SAM) database on a computer, Exchange 2007 defines additional SIDs. These SIDs represent logical groups. Table 3 lists the SIDs that are defined by Exchange 2007 for use during transport authentication.

Table 3   Exchange 2007 SIDs

Display name	SID	Logical group
Partner servers	S-1-9-1419165041-1139599005-3936102811-1022490595-10	Sender and recipient domains that are configured for Domain Security.
Hub Transport servers	S-1-9-1419165041-1139599005-3936102811-1022490595-21	Hub Transport servers in the same Exchange organization.
Edge Transport servers	S-1-9-1419165041-1139599005-3936102811-1022490595-22	Trusted Edge Transport servers.
Externally Secured servers	S-1-9-1419165041-1139599005-3936102811-1022490595-23	Trusted third-party servers that are in the same authoritative domain.
Legacy Exchange servers	S-1-9-1419165041-1139599005-3936102811-1022490595-24	Exchange Server 2003 servers that are in the same Exchange organization.

Receive Connector Permissions

Send Connector Permissions

A permission group is a predefined set of permissions that can be granted on a Receive connector. 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 allowed to those groups. The set of permission groups is predefined in Exchange 2007. Therefore, you can't create additional permission groups. Moreover, you can't modify the permission group members or the associated permissions.

Table 6 lists the permission groups, the permission group members, and the associated permissions that are available in Exchange 2007.

Table 6   Receive connector permission groups and associated permissions

Permission group name	Security principals	Permissions granted on Edge Transport servers	Permissions granted on Hub Transport servers
Anonymous	Anonymous users	Submit messages to server Accept any sender Accept routing headers	Submit messages to server Accept any sender Accept routing headers
ExchangeUsers	Authenticated users (well-known accounts are excluded)	Not available	Submit messages to server Accept any recipient Bypass anti-spam filters
Exchange Servers	Exchange 2007 servers	All receive permissions	All receive permissions
ExchangeLegacyServers	Exchange 2003 and Exchange 2000 servers	Not available	Submit messages to server Submit messages to any recipient Accept any sender Accept authoritative domain sender Accept authentication flag Accept routing headers Accept Exch50 Bypass message size limit Bypass anti-spam filters
Partner	Partner server account	Submit messages to server Accept routing headers	Submit messages to server Accept routing headers

When you create a new connector, you can specify a usage type for the connector. The usage type determines the default settings for the connector. This includes the SIDs that are authenticated, the permissions that are assigned to those SIDs, and the authentication mechanism.

Table 7 lists the usage types that are available for a Receive connector. When you select a usage type for a Receive connector, permission groups are automatically assigned to the connector. A default authentication mechanism is also configured.

Table 7   Receive connector usage types

Usage type	Default permission groups	Default authentication mechanism
Client	ExchangeUsers	TLS. BasicAuthPlusTLS.
Custom	None	None.
Internal	ExchangeServers ExchangeLegacyServers	Exchange Server authentication.
Internet	AnonymousUsers Partner	None or externally secured.
Partner	Partner	Not applicable. This usage type is selected when you establish mutual TLS authentication with a remote domain.

Table 8 lists the usage types that are available for a Send connector. When you select a usage type for a Send connector, permissions are automatically assigned to SIDs. A default authentication mechanism is also configured.

Table 8   Send Connector usage types

Usage type	Default permissions	Security principals	Default authentication mechanism for smart hosts
Custom	None	None	None
Internal	Send organization headers Send Exch50 Send routing headers Send forest headers	Hub Transport servers Edge Transport servers Exchange Servers security group Externally secured servers Exchange Legacy Interop security group Exchange 2003 and Exchange 2000 bridgehead servers	Exchange Server authentication.
Internet	Send routing headers	Anonymous User Account	None.
Partner	Send routing headers	Partner Servers	Not applicable. This usage type is selected when you establish mutual TLS authentication with a remote domain.

If you select the Custom usage type for a Send connector or a Receive connector, you must manually configure the authentication method and the authorized SIDs and assign permissions to those SIDs. If you don't specify a usage type, the connector usage type is set as Custom.

You can use the Enable-CrossForestConnector.ps1 script to simplify how permissions are configured on cross-forest connectors. The script assigns permissions in a manner that resembles permission groups. A defined set of permissions is assigned to a Send connector or Receive connector. You can modify this set of permissions as required for your connection scenario by modifying the Enable-CrossForestConnector.ps1 script contents. For more information, see Configuring Cross-Forest Connectors.

The Add-AdPermission cmdlet in the Exchange Management Shell is a global cmdlet that is used to assign permissions to objects that are stored in Active Directory. You can use the Add-AdPermission cmdlet to grant individual permissions on a Send connector or Receive connector. The Add-AdPermission cmdlet isn't typically used to manage transport permissions. However, it must be used to configure permissions in the following scenarios:

• Establish mail-flow in a cross-forest scenario.
  
  
• Accept anonymous e-mail from the Internet from a sender in an authoritative domain.
  
  

The Exchange 2007 transport permissions are part of the set of extended rights that can be assigned by using this cmdlet. The following procedure shows how you can use the Add-AdPermission cmdlet to set permissions on a Hub Transport server Receive connector to allow anonymous sessions to submit messages:

How to set permissions on a Receive connector by using the Exchange Management Shell

• Run the following command:

  	Copy Code
  Add-AdPermission -Identity "Default Hub1" -User "NT AUTHORITY\ANONYMOUS LOGON" -ExtendedRights ms-Exch-SMTP-Submit,ms-Exch-SMTP-Accept-Any-Recipient,ms-Exch-Bypass-Anti-Spam

You can use the Get-AdPermission cmdlet to view the DACL for a Send connector or a Receive connector. Run one of the following commands to retrieve the permissions that are assigned to a Receive connector and to display the results in a formatted table:

How to view the extended permissions on a Receive connector by using the Exchange Management Shell

• Run one of the following commands:

  	Copy Code
  Get-AdPermission -Identity "Default ServerName" | format-table -view User Get-AdPermission -Identity "Default ServerName" | format-table -view Identity

You can use the Remove-AdPermission cmdlet to remove any previously assigned permissions.

For more information about how to set, view, and remove permissions by using the Exchange Management Shell, see the following topics:

• Add-ADPermission
  
  
• Get-ADPermission
  
  
• Remove-ADPermission
  
  

Active Directory Service Interfaces (ADSI) Edit is a Microsoft Management Console that is provided with the Windows Support Tools. ADSI Edit is used as a low-level editor for modifying properties of Active Directory or ADAM objects that are not exposed in other management interfaces. ADSI Edit should only be used by experienced administrators.

You can use ADSI Edit to view and modify the ACLs for Send connectors and Receive connectors. After you open ADSI Edit, you locate the connector object. Exchange 2007 connectors are stored in the Configuration partition of the directory service. Send connectors are stored as an object in the Connections container. Receive connectors are stored as a child object of the Exchange 2007 transport server.

To modify Receive connector permissions by using ADSI Edit:

1. Locate the Receive connector by going to the following location:

   CN=Configuration\CN=Services\CN=Microsoft Exchange\CN=<Organization>\CN=Administrative Groups\CN=Exchange Administrative Group (FYDIBOHF23SPDLT)\CN=Servers\CN=<Server Name>\CN=Protocols\CN=SMTP Receive Connectors

2. Select a Receive connector in the results pane. Right-click and then click Properties.

3. Click the Security tab. The following screen is displayed:

   

4. Click Add to select the user or group to which permissions are being granted, or select an existing Group or user name entry.

5. Select the permissions that should be assigned to the account and select the check box in the Allow column.

To modify Send connector permissions by using ADSI Edit:

1. Locate the Send connector by going to the following location:

   CN=Configuration\CN=Services\CN=Microsoft Exchange\CN=<Organization>\CN=Administrative Groups\CN=Exchange Administrative Group(FYDIBOHF23SPDLT)\CN=Routing Groups\CN=Routing Group (DWBGZMFD01QNBJR)\CN=Connections

2. Select a Send connector in the results pane. Right-click and then click Properties.

3. Click the Security tab. The following screen is displayed:

   

4. Click Add to select the user or group to which permissions are being granted, or select an existing Group or user name entry.

5. Select the permissions that should be assigned to the account and select the check box in the Allow column.

During the protocol conversation, the SMTP server may reject certain commands because there is a lack of permissions. Table 9 lists the most common protocol rejection messages and the permissions configuration that causes the error.

Table 9   Common protocol rejection messages and their causes

SMTP server response	Cause
530 5.7.1 Client was not authenticated	The sender specified in the MAIL FROM field of the SMTP protocol doesn't have permission to submit to this server. The ms-Exch-SMTP-Submit permission must be granted to the sender.
535 5.7.3 Authentication unsuccessful	During the AUTH phase of the SMTP protocol conversation, the provided credentials were incorrect or the authenticated user doesn't have permission to submit to this server.
550 5.7.1 Client does not have permission to submit to this server	The sender specified in the MAIL FROM field of the SMTP protocol conversation was authenticated but doesn't have permission to submit to this server.
550 5.7.1 Client does not have permission to send as this sender	The sender specified in the MAIL FROM field of the SMTP protocol conversation is an address in an authoritative domain. However, the session doesn't have the ms-Exch-SMTP-Accept-Authoritative-Domain-Sender permission. This might occur if a message was submitted from the Internet to an Edge Transport server from a sender address for which the Exchange organization is authoritative.
550 5.7.1 Client does not have permission to send on behalf of the from address	The authenticated user doesn't have permission to submit a message on behalf of the sender that is specified in the header of the message. Also, the session doesn't have the ms-Exch-SMTP-Accept-Any-Sender permission.
550 5.7.1. Unable to relay	The recipient domain to which the message is addressed isn't within any of the accepted domains defined for this organization. Also, the session doesn't have the ms-Exch-SMTP-Accept-Any-Recipient permission.