{
	"id": "765f0bc2-4977-4b69-ad1d-530d73d85c15",
	"created_at": "2026-04-06T00:13:20.588633Z",
	"updated_at": "2026-04-10T03:20:03.201819Z",
	"deleted_at": null,
	"sha1_hash": "a7220d40a45ea24475f0aeed39746223c7bf69a7",
	"title": "Impersonation and EWS in Exchange",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 71706,
	"plain_text": "Impersonation and EWS in Exchange\r\nBy o365devx\r\nArchived: 2026-04-05 20:24:15 UTC\r\nLearn how and when to use impersonation in your Exchange service applications.\r\nYou can enable users to access other users' mailboxes in one of three ways:\r\nAdd delegates and specifying permissions for each delegate.\r\nModify folder permissions directly.\r\nUse impersonation.\r\nWhen should you choose impersonation over delegation or folder permissions? The following guidelines will help\r\nyou decide.\r\nUse folder permissions when you want to provide a user access to a folder but do not want the user to have\r\n\"send on behalf of\" permissions.\r\nUse delegate access when you want to give one user permission to perform work on behalf of another user.\r\nTypically, this is a one-to-one or one-to-a-few permission - for example, a single administrative assistant\r\nmanaging the calendar for an administrator, or a single room scheduler managing the calendars for a group\r\nof meeting rooms.\r\nUse impersonation when you have a service application that needs to access multiple mailboxes and \"act\r\nas\" the mailbox owner.\r\nImpersonation is the best choice when you're dealing with multiple mailboxes because you can easily grant one\r\nservice account access to every mailbox in a database. Delegation and folder permissions are best when you're\r\nonly granting access to a few users, because you have to add permissions individually to each mailbox. Figure 1\r\nshows some of the differences between each type of access.\r\nFigure 1. Ways to access other users' mailboxes\r\nhttps://learn.microsoft.com/en-us/exchange/client-developer/exchange-web-services/impersonation-and-ews-in-exchange\r\nPage 1 of 3\n\nImpersonation is ideal for applications that connect to Exchange Online, Exchange Online as part of Office 365,\r\nand on-premises versions of Exchange and perform operations, such as archiving email, setting OOF\r\nautomatically for users on vacation, or any other task that requires that the application act as the owner of a\r\nmailbox. When an application uses impersonation to send a message, the email appears to be sent from the\r\nmailbox owner. There is no way for the recipient to know the mail was sent by the service account. Delegation, on\r\nthe other hand, gives another mailbox account permission to act on behalf of a mailbox owner. When an email\r\nmessage is sent by a delegate, the \"from\" value identifies the mailbox owner, and the \"sender\" value identifies the\r\ndelegate that sent the mail.\r\nSecurity considerations for impersonation\r\nImpersonation enables a caller to impersonate a given user account. This enables the caller to perform operations\r\nby using the permissions that are associated with the impersonated account, instead of the permissions that are\r\nassociated with the caller's account. For this reason, you should be aware of the following security considerations:\r\nOnly accounts that have been granted the ApplicationImpersonation role by an Exchange server\r\nadministrator can use impersonation.\r\nFor Exchange on-premises, you should create a management scope that limits impersonation to a specified\r\ngroup of accounts. If you do not create a management scope, the ApplicationImpersonation role is\r\nhttps://learn.microsoft.com/en-us/exchange/client-developer/exchange-web-services/impersonation-and-ews-in-exchange\r\nPage 2 of 3\n\ngranted to all accounts in an organization. If you have configured Hybrid Modern Authentication you can\r\nalso use Microsoft Entra Conditional Access to apply access control.\r\nFor Exchange Online, you should create a management scope that limits impersonation to a specified\r\ngroup of accounts. If you do not create a management scope, the ApplicationImpersonation role is\r\ngranted to all accounts in an organization. You can also use Microsoft Entra Conditional Access to apply\r\naccess control.\r\nTypically, the ApplicationImpersonation role is granted to a service account dedicated to a particular\r\napplication or group of applications, rather than a user account. You can create as many or as few service\r\naccounts as you need.\r\nYou can read more about configuring impersonation, but you should work with your Exchange administrator to\r\nensure that the service accounts that you need are created with the permissions and access that meet the security\r\nrequirements of your organization.\r\nIn this section\r\nConfigure impersonation\r\nIdentify the account to impersonate\r\nAdd appointments by using Exchange impersonation\r\nPerformance considerations for EWS impersonation\r\nWhen EWS Impersonation is used, the X-AnchorMailbox should always be correctly set. Otherwise, you may get\r\nerror messages 500 or 503 at times. It is critical for performance and also for notifications with Exchange\r\nOnline/Exchange 2013. Not setting it can double or more the time it takes to complete the call. In some cases, you\r\ncan also get timeouts.\r\nSee also\r\nDevelop web service clients for Exchange\r\nDelegate access and EWS in Exchange\r\nExchange 2013 Permissions\r\nSource: https://learn.microsoft.com/en-us/exchange/client-developer/exchange-web-services/impersonation-and-ews-in-exchange\r\nhttps://learn.microsoft.com/en-us/exchange/client-developer/exchange-web-services/impersonation-and-ews-in-exchange\r\nPage 3 of 3",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://learn.microsoft.com/en-us/exchange/client-developer/exchange-web-services/impersonation-and-ews-in-exchange"
	],
	"report_names": [
		"impersonation-and-ews-in-exchange"
	],
	"threat_actors": [],
	"ts_created_at": 1775434400,
	"ts_updated_at": 1775791203,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/a7220d40a45ea24475f0aeed39746223c7bf69a7.pdf",
		"text": "https://archive.orkl.eu/a7220d40a45ea24475f0aeed39746223c7bf69a7.txt",
		"img": "https://archive.orkl.eu/a7220d40a45ea24475f0aeed39746223c7bf69a7.jpg"
	}
}