Exchange 2007 Transport Permissions Model
Microsoft Exchange Server 2007 will reach end of support on April 11, 2017. To stay supported, you will need to upgrade. For more information, see Resources to help you upgrade your Office 2007 servers and clients.
Applies to: Exchange Server 2007, Exchange Server 2007 SP1, Exchange Server 2007 SP2, Exchange Server 2007 SP3
This topic provides detailed information about the Microsoft Exchange Server 2007 transport permissions model. In Microsoft Exchange Server 2007, transport refers to the process of transferring messages from one server to another server. When messages are transferred between a Mailbox server and the Hub Transport server, the MAPI protocol is used. When messages are sent and received between Hub Transport servers, the Simple Mail Transfer Protocol (SMTP) is used. Each communication session between servers can have an optional authentication stage. Connection requests may require authorization checks.
Authentication is the process that tries to identify the sender of a message. If no authentication occurs or the authentication attempt fails, the sender's identity is anonymous. Authorization is the process that determines whether to allow the user, program, or device that is connecting to access to some data, functionality, or service. This access depends on the requested action. The authentication process verifies identity. The authorization process determines the level of access that is granted.
In Exchange 2007, the SMTP and MAPI protocols are provided by the Microsoft Exchange Transport service. In sessions that use either the SMTP or MAPI protocol, the Microsoft Exchange Transport service uses the Microsoft Windows authorization model to manage the permissions for a session. In the context of transport in Exchange 2007, authorization relates to whether various protocol verbs or events are accepted. For example, authorization will check for permissions that allow the sender to submit a message from a particular e-mail address or that allow a particular message size. During both the MAPI and SMTP protocol conversations, Exchange 2007 can perform session authentication. After a session is authenticated, the permission groups available to the session may change because of authentication. This enables anonymous messages from the Internet and messages submitted by authenticated users in the Exchange organization to be processed differently because of the different permission groups granted by authentication.
The default behavior for transport on an Edge Transport server role differs from the default behavior on a Hub Transport server role. This difference is not because of a code variation. The difference is caused by a difference in the default set of permissions for each role. Exchange servers that are part of the same Active Directory forest have a trust relationship. This trust relationship means that the default permissions that are configured during installation enable secure mail flow within the forest.
Each authenticated session presents an access token that lists the security identifier for each group in which the authenticating security principal has membership. Figure 1 shows the relationship between the group memberships listed on the access token and permissions that are assigned to those groups for the object that is accessed.
Figure 1 Transport authorization components in Exchange 2007
.gif "Exchange Transport Authorization Components")
The Difference between Authenticated Sessions and Authenticated Messages
A central concept of the Exchange 2007 transport model is the difference between authenticated transport sessions and authenticated messages. A message can be stamped with metadata that indicates that it is authenticated or anonymous. When one server authenticates to another server, it can then send a message and stamps it with metadata that indicates whether the message is authenticated or anonymous. The receiving server determines whether the authenticated stamp is trusted. If the receiving server trusts the sender, the authenticated stamp is left intact. If the receiving server doesn't trust the sender, it will override the sending server's authenticated stamp and stamp the message with metadata that indicates the message is anonymous. In an Exchange organization, end-to-end internal mail flow occurs between servers that trust the authenticated message stamp. An Edge Transport server that receives messages from the Internet doesn't trust the authenticated stamp of anonymous servers on the Internet. Therefore, the Edge Transport server stamps each message with metadata that indicates the message is anonymous before it sends to a Hub Transport server over an authenticated connection.
How the Message Transport Authentication and Authorization Process Works
In Exchange 2007, the following basic mechanisms are available to authenticate an SMTP session:
You can use a Windows account and password in a MAPI session. Alternatively, you can use the AUTH extension of SMTP. This includes plain text password authentication, NTLM authentication, and Kerberos authentication.
You can use a X.509 certificate by using the STARTTLS extension of SMTP. In this scenario, the server provides a certificate as part of the Transport Layer Security (TLS) negotiation. Optionally, the client also supplies a certificate.
You can use an external authentication mechanism. External authentication uses a mechanism that isn't part of Exchange, such as a physically-secured network or IPsec. This method is used when communication occurs over identified IP routes on dedicated Send connectors and Receive connectors.
The sending transport server can authenticate to the receiving transport server before it sends the message. After the sender authenticates, the receiving transport server applies those permissions to the session access token that are granted to that sender.
In Exchange 2007, Send connectors and Receive connectors manage mail flow. The connectors have a discretionary access control list (DACL) that defines the permissions that are associated with sending and receiving e-mail. The permissions on Receive connectors are most important. The DACL on the Receive connector determines the sender's permissions for messages that are submitted through the Receive connector. After an SMTP session is established to a Receive connector, the session starts with an anonymous access token for that session. A subsequent successful authentication changes the access token. If a session doesn't authenticate, the permission groups in the access token remain the same. If a session authenticates, it is granted the permissions that are assigned to the individual account or role and the permissions that are assigned to any security groups which that account belongs to.
The flow chart in Figure 2 illustrates how an Exchange 2007 transport server uses authentication and authorization in an SMTP session.
Figure 2 SMTP session authentication and authorization process
.gif "Flowchart with SMTP session authentication process")
Authentication Configurations
The set of authentication mechanisms that are configured for a Receive connector determine the authentication mechanisms that are available for use by sessions that submit messages to the Receive connector. The authentication mechanism that is configured for a Send connector determines which authentication mechanism will be used by the Send connector to authenticate to a smart host.
Authentication for Receive Connectors
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. |
Authentication for Smart Host Send Connectors
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 |
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
The TLS protocol is described in RFC 2246. TLS uses X.509 certificates. These are a form of electronic credential. TLS can be used as follows:
For confidentiality only.
For server authentication with confidentiality where the server certificate is validated.
For mutual authentication with confidentiality where both client and server certificates are validated.
During the SMTP protocol conversation, the client issues the SMTP STARTTLS command to request that TLS be negotiated for this session. The client receives an X.509 certificate from the server as part of the TLS protocol negotiation. The client authentication policy then determines whether the receiving server certificate should be validated and whether any other criteria should be applied to the certificate, such as name matching.
An optional part of the TLS negotiation enables the receiving server to also request a certificate from the sending server. If the sending server sends a certificate to the receiving server, the local policy on the receiving server determines how the certificate is validated and what permissions are granted to the sending server because of the authentication.
When TLS is used for server authentication, only the receiving server certificate is validated. If TLS is used for mutual authentication, both the sending server certificate and the receiving server certificate must be validated.
When TLS is configured on an Exchange 2007 Receive connector, the server must have an X.509 certificate. This certificate can be a self-signed certificate or a certificate that is signed by a certification authority (CA). The Exchange server looks for a certificate in the local store that matches the FQDN of the connector. The sending server selects how the TLS protocol is used. When Exchange uses TLS for confidentiality only, the Exchange client doesn't validate the certificate. For example, when Exchange uses TLS between Hub Transport servers by using the Kerberos through TLS protocol, it establishes a confidential channel between the servers and performs no validation on the certificate. The authentication between the servers occurs by using Kerberos after the TLS protocol finishes.
When TLS authentication is required, Exchange must validate the certificate. Exchange can validate the certificate in two ways: direct trust or X.509 validation. When TLS is used for Edge Transport server to Hub Transport server communication, Exchange uses a direct trust mechanism to validate the certificate.
Direct trust means that Exchange uses a trusted store, such as Active Directory or Active Directory Application Mode (ADAM). Direct trust also means that the presence of the certificate in the store validates the certificate. When direct trust is used, it doesn't matter if the certificate is self-signed or signed by a certification authority. When you subscribe an Edge Transport server to the Exchange organization, the subscription publishes the Edge Transport server certificate in Active Directory for the Hub Transport servers to validate. The Microsoft Exchange Edgesync service updates ADAM with the set of Hub Transport server certificates for the Edge Transport server to validate.
The other method that Exchange uses to validate certificates is X.509 validation. When X.509 validation is used, the certificate must be signed by a CA. Exchange uses X.509 validation when it authenticates smart hosts or when it uses Domain Security. Domain Security is explained in the following section.
Domain Security
Domain Security refers to the set of functionality in Exchange 2007 and Microsoft Office Outlook that provides a relatively low cost alternative to S/MIME or other message-level security solutions. The purpose of Domain Security is to provide administrators a way to manage secured message paths over the Internet with business partners. After these secured message paths are configured, messages that have successfully traveled over the secured path from an authenticated sender are displayed to users as "Domain Secured" in the Outlook and Outlook Web Access interface.
A Send connector verifies that the target domain is on the list of sender domains that are configured for Domain Security if the following conditions are true:
The Send connector is configured to route messages by using Domain Name System (DNS) mail exchange (MX) resource records.
The Send connector is configured as domain-secured.
If the target domain is on the list, the transport server enforces mutual TLS authentication when it sends e-mail to the domain.
The receiving server responds with an SMTP QUIT command if the following conditions are true:
Exchange cannot negotiate TLS
Server certificate validation or CRL verification fails.
The messages then queue on the sending server. The queue is in a retry state. This behavior also occurs when the name check fails.
If a Receive connector is domain-secured, the transport server checks the received mail. Then the transport server enforces mutual TLS authentication if the sender is on the list of recipient domains configured for Domain Security. If all the checks pass, the received message is marked as "Domain Secured." If the sender cannot negotiate TLS, or if the server certificate validation or CRL verification fails, the transport server rejects the message by using the SMTP protocol REJECT command. If the name check fails, an SMTP protocol REJECT also results. Then the Exchange server sends a message that has a temporary SMTP error (4xx) to the sending server. This means that the sending server should retry later. This behavior prevents transient failures caused by temporary CRL verification failures from causing an immediate NDR to the sender. The failure only delays message delivery.
For more information, see Managing Domain Security.
Externally Secured Authentication
You can select the Externally Secured authentication option if you are sure that the network connection between the servers is trusted. This connection may be an IPsec association or virtual private network. Alternatively, the servers may reside in a trusted physically controlled network. This configuration is useful in the following case:
You establish mail flow between an Exchange 2007 transport server and an earlier version of Exchange Server or any other SMTP server.
You don’t want to use Basic authentication.
Exchange connectors that are configured as Externally Secured must use dedicated Send connectors and Receive connectors because all connections to the connectors are assumed to be secure. Therefore, Send connectors that are configured as Externally Secured must use a smart host for routing messages. Also, the IP addresses of the target smart hosts must be configured on the connector. Receive connectors that are configured as Externally Secured must have the RemoteIPRanges set to the IP address range of the sending servers. TLS can also be combined with the Externally Secured authentication option to add session confidentiality. You can do this in the Exchange Management Shell if you set the RequireTLS parameter on the connectors to $True.
Authorization
During message transport, authorization is the process that determines whether a requested action, such as sending mail, is permitted to an SMTP session.
Exchange 2007 Transport Permissions
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
Receive connectors process incoming sessions to the server. The session may be established by an authenticated sender or by an anonymous sender. If a session is authenticated successfully, the SIDs in the session access token are updated. Table 4 lists the permissions that can be granted to a session connecting to a Receive connector.
Table 4 Receive connector permissions
| Permission | Display name | Description |
|---|---|---|
ms-Exch-SMTP-Submit |
Submit Messages to Server |
The session must be granted this permission or it won't be able to submit messages to this Receive connector. If a session doesn't have this permission, the MAIL FROM command will fail. |
ms-Exch-SMTP-Accept-Any-Recipient |
Submit Messages to any Recipient |
This permission allows the session to relay messages through this connector. If this permission isn't granted, only messages addressed to recipients in accepted domains are accepted by this connector. |
ms-Exch-SMTP-Accept-Any-Sender |
Accept any Sender |
This permission allows the session to bypass the sender address spoofing check. |
ms-Exch-SMTP-Accept-Authoritative-Domain-Sender |
Accept Authoritative Domain Sender |
This permission allows the session to bypass a check that prevents inbound messages from e-mail addresses in authoritative domains. |
ms-Exch-SMTP-Accept-Authentication-Flag |
Accept Authentication Flag |
This permission allows Exchange servers that are running earlier versions of Exchange Server to submit messages from internal senders. Exchange 2007 servers recognize the message as internal. |
ms-Exch-Accept-Headers-Routing |
Accept Routing Headers |
This permission allows the session to submit a message that has all received headers intact. If this permission isn't granted, the server strips all received headers. |
ms-Exch-Accept-Headers-Organization |
Accept Organization Headers |
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 strips all organization headers. |
ms-Exch-Accept-Headers-Forest |
Accept Forest Headers |
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 strips all forest headers. |
ms-Exch-Accept-Exch50 |
Accept Exch50 |
This permission allows the session to submit a message that contains the XEXCH50 command. This command is required for interoperability with Exchange 2000 Server and Exchange 2003. The XEXCH50 command provides data, such as the spam confidence level (SCL) for the message. |
ms-Exch-Bypass-Message-Size-Limit |
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 |
Bypass Anti-Spam |
This permission allows the session to bypass anti-spam filters. |
Send Connector Permissions
Send connectors process outgoing sessions to another server. The session may be established by the sender to either an anonymous or authenticated receiver. If the session is authenticated successfully, the set of SIDS in the session access token is updated. Send connector permissions determine the types of header information that can be included in a message that is sent by using the connector. Messages that are sent to other Exchange servers in the organization or to a trusted Exchange organization in a cross-forest scenario are typically allowed to send all headers. Messages that are sent to the Internet or to non-Exchange SMTP servers are not allowed to contain all headers. If headers are included in the message, the header firewall functionality of Exchange 2007 strips those headers. Table 5 lists the permissions that can be granted to a session connecting to a Send connector.
Table 5 Send connector permissions
| Permission | Display name | Description |
|---|---|---|
ms-Exch-Send-Exch50 |
Send Exch50 |
This permission allows the session to send a message that contains the EXCH50 command. If this permission isn't granted, the server sends the message but doesn't include the EXCH50 command. |
Ms-Exch-Send-Headers-Routing |
Send Routing Headers |
This permission allows the session to send a message that has all received headers intact. If this permission isn't granted, the server strips all received headers. |
Ms-Exch-Send-Headers-Organization |
Send Organization Headers |
This permission allows the session to send a message that has all organization headers intact. Organization headers all start with “X-MS-Exchange-Organization-“. If this permission isn't granted, the sending server strips all organization headers. |
Ms-Exch-Send-Headers-Forest |
Send Forest Headers |
This permission allows the session to send a message that has all forest headers intact. Forest headers all start with “X-MS-Exchange-Forest-“. If this permission isn't granted, the sending server strips all forest headers. |
Permission Groups
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 |
|
|
ExchangeUsers |
Authenticated users (well-known accounts are excluded) |
Not available |
|
Exchange Servers |
Exchange 2007 servers |
All receive permissions |
|
ExchangeLegacyServers |
Exchange 2003 and Exchange 2000 servers |
Not available |
|
Partner |
Partner server account |
|
|
Connector Usage Types
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 |
|
Custom |
None |
None. |
Internal |
|
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 |
|
|
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.
Setting Permissions by Using the Enable-CrossForestConnector Script
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.
Setting Permissions by Using the Add-AdPermission Cmdlet
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:
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:
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:
Setting Permissions by Using ADSI Edit
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:
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
Select a Receive connector in the results pane. Right-click and then click Properties.
Click the Security tab. The following screen is displayed:
.gif "Receive Connector Security Tab in ADSI Edit")
Click Add to select the user or group to which permissions are being granted, or select an existing Group or user name entry.
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:
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
Select a Send connector in the results pane. Right-click and then click Properties.
Click the Security tab. The following screen is displayed:
.gif "Send Connector Secuity tab in ADSI Edit")
Click Add to select the user or group to which permissions are being granted, or select an existing Group or user name entry.
Select the permissions that should be assigned to the account and select the check box in the Allow column.
Troubleshooting Permissions
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. |
For More Information
For more information, see the following topics: