Server-to-Server Authorization in Exchange 2010
Last modified: May 21, 2009
Applies to: Exchange Server 2007 | Exchange Server 2010
The Microsoft Exchange Server 2010 server-to-server authorization feature provides authentication and authorization control for applications that have to propagate trust among servers in order to provide a mechanism for supporting single sign-on (SSO) for a single user or account to multiple servers. This provides a chain of trust between the client, the middle-tier servers, and the computer on which the Client Access server role is installed. Server-to-server authorization allows applications, services, and servers to act on behalf of other accounts to access resources in the mailbox database. This enables independent software vendors (ISVs), system integrators, and corporate developers to create applications that are a part of a trusted subsystem but do not have full access to Exchange resources and the Active Directory directory service.
For example, an application server connects to a Client Access server on behalf of a client. The user provides credentials to the client application, which has authenticated access to the application server. The application server uses the client's identity in a request to act on the client's behalf to access data from the Client Access server. Using its own credentials, the application server establishes a connection to the HTTP or HTTPS port on the Client Access server. The connection to Exchange Web Services provides the application server data that can be served back to the client application. In this case, the application server impersonates the client so that it can access data on behalf of the client.
For a server-to-server authorization scenario to work, the following conditions must be met:
The client must authenticate with the initial server. In the previous example, the initial server was an application server.
The calling server must have impersonation rights, ms-Exch-EPI-Impersonation, set on the security descriptor of the Client Access server object in Active Directory. This allows the caller to impersonate another entity on the server. This is set by means of the ms-Exch-EPI-Impersonation right.
The initial server must have access to the client's user principal name (UPN), Security Identifier (SID), or primary Simple Mail Transfer Protocol (SMTP) address so that it can identify the client on behalf of which it will act.
The client must have permissions to a mailbox in a forest.
The initial server must have the ms-Exch-EPI-May-Impersonate right set on either the mailbox database or the account that is to be impersonated so that it can impersonate an account.
If the initial server cannot authenticate the user, or if the Client Access server cannot authorize either the user or the initial server, the scenario will fail.
Important
When using Exchange impersonation, the Client Access server logs the activity as if users were performing the action themselves.
Potential User Scenarios
The following are potential user scenarios for server-to-server authorization:
Web portals for interoperability
Restriction of users to a subset of all resources
Calendar sharing between groups that have limited trust
Schedule modifications by an external entity
Server-to-server authorization in a resource forest environment
Web Portals for Interoperability
A financial services company wants to provide a highly available electronic mail client for desk workers. The company selects Exchange 2010 to run its e-mail infrastructure because of the new features it offers. They use a Web portal to limit the disruption in the user interface during the transition. The Web portal servers log on to Exchange 2010 on behalf of the desk workers, using a Web service to provide them with the new features to which they now have access. Users only have to enter their credentials one time, and the logon to the computer that is running Exchange 2010 is performed silently and securely on their behalf.
Restriction of Users to a Subset of All Resources
User A creates a subfolder in his mailbox which is to be shared by all members of a team. He grants those members read and write access to the items in that folder, but not to any other part of his mailbox. Even when the user is working through an intermediary server, this access control is respected.
Calendar Sharing Between Groups That Have Limited Trust
Company A has a secure group, B. Mail to and from that group must be sent to a special Microsoft Exchange server in a secure facility, but people outside the group must be able to schedule meetings with people inside the group. A pair of servers is created to relay free/busy information from within the secure facility to outside the secure facility so that meetings can be scheduled efficiently.
Schedule Modifications by an External Entity
Room details for speakers at a large conference are arranged by an external organizing firm. Using intermediary authorization, employees of that firm can directly modify the calendar items that correspond to talks the individual speakers are giving, but cannot affect or read their schedules in any other way.
Server-to-Server Authorization in a Resource Forest Environment
The most common authorization model used for an Exchange 2010 configuration in a large organization is the resource forest topology, in which different classes of resources are isolated from one another into individual Active Directory forests without mutual trust. In this topology, the computers that host Exchange 2010 mailboxes are kept within one Active Directory forest, and the management of other resources, including user accounts, computer access, and resource access, occurs within one or more other Active Directory forests. In this model, the servers in the Exchange 2010 forest are typically allowed to trust the user forests for authentication data, but that trust is usually not reciprocated.