A while back I was asked to create an application that interacted with an Outlook 365 mailbox or EWS (Exchange Web Services) as it should be more accurately called. Now it had been a while since I last did this and of course now, with the advent of Azure, its myriad of connected services and of course 2FA this has gotten much more complicated than just asking for a User Name/Password combination. I found this excellent article here that told me exactly what I need to know. However, for a number of reasons including:-
- I can never remember where the link is.
- The instructions are not easy to follow, and very misleading in some places
- The instructions are dual purpose
- The Instructions are DANGEOROUSLY incomplete
I have decided to write a more concise series of blog(s) that will hopefully be simpler to follow, less prone to misconfiguration and will also plug that dangerous gap that I have alluded to. No spoilers though….
This blog specifically deals with connecting to EWS mail accounts via an unattended .NET service application (Application Permissions). If you require to connect using ‘Delegated Permissions’ (i.e. a user is present for 2FA) then stop reading now as I do not cover this at all. Many 365 accounts nowadays use 2 Factor Authentication which give you an issue when trying to connect via a service application as there is no attendant user to react to any 2FA dialogs that may arise. Instead Microsoft allow you to access this account using OAuth which enables 2FA to be sidestepped.
There are 3 distinct stages that will be covered within this series of articles.
- Configure EWS Connectivity in Azure.
- Code Exchange Connectivity in .NET.
- Secure Azure Application Registration.
If you are in the position of ‘Configuring Exchange Connectivity’ I would urge you NOT to skip the latter of these three articles’. You see, what is not at all clear from the official documentation is that by default when registering an application and associating it with the EWS application you are actually giving that application access to Every. Single. Mailbox. within the organisation. Given the hacks that you see daily in the press this kind of default behaviour does not seem to be a wise choice at all. Indeed, it was only further down the line when I came to make some iterative changes to the service application (and could connect to an entirely unrelated inbox using the same credentials) that I realised that further securitisation was required. So here we try to bring in all of the elements required to make your EWS integrations well behaved and with the lowest surface attack area.