Managing Access to EWS Applications in Exchange 2010
Last modified: September 24, 2010
Applies to: Exchange Server 2007 | Exchange Server 2010
Administrators can manage access to Exchange Web Services (EWS) by using the Exchange Management Shell to limit access either globally for users and applications, for individual users, or for individual applications. Access control for EWS is based on domain accounts. When a connection is made with credentials that are authenticated by the local security authority, an error that indicates that only domain accounts can connect to the server is returned.
Configuring Access Control
Administrators can configure application access control for the clients that are used to connect to EWS in the following ways:
By blocking all client applications from connecting.
By allowing specific client applications to connect.
By allowing any client application to connect except for those that are specifically blocked.
By allowing any client application to connect.
Applications are identified by the user-agent string that they send in the HTTP Web request.
.gif "Security note") Security Note |
|---|
Application-level blocking is not a security feature – the user agent string is easily spoofed. If an application is allowed access to EWS, the application must still present credentials that the server authenticates before the application is allowed access. |
Administrators can also configure application access control for mailbox owners that connect to EWS in the following ways:
By blocking or allowing an entire organization.
By blocking or allowing a group of users identified by a role-based authentication scope that excludes mailbox owners that do not have access to EWS.
By blocking or allowing an individual mailbox owner.
Specific access control settings override general access control settings. For example, if an organization allows EWS access but an individual mailbox owner is denied application access, the individual setting prevails and access is denied.
Delegation and Access Management
Delegate users who do not have access to EWS will not be able to access the principal user's mailbox by using EWS, even if the principal user has EWS access.
If the delegate user has EWS access, the delegate will be able to access the principal user's mailbox through EWS even if the principal user does not have EWS access.
Impersonation and Access Management
Client applications that connect to EWS on behalf of mailbox owners might not be able to use the EWS settings of the mailbox owner. For example, an application that archives e-mail for a company has to connect to EWS no matter what the mailbox user's settings are. Other applications, such as mail clients, do have to use the mailbox owner's EWS settings.
Administrators should create an impersonation account for each application or application class that they use on their server. This will enable the administrator to configure the role-based access control scope for all uses that do not have EWS permissions.
To enable impersonation accounts, the administrator should do one of the following:
Add the Authenticated Users group to the "Pre-Win2K Compatible Access Group."
Add the "Exchange Servers" group to the "Windows Authorization Access" group.
Exchange Management Shell Cmdlets for Access Management
Administrators use the following Exchange Management Shell cmdlets to configure EWS access controls:
See Also