A hybrid deployment offers organizations the ability to extend the feature-rich experience and administrative control they have with their existing on-premises Microsoft Exchange organization to the ...
Published May 24, 2017
Version 1.0
Blog Post
Great article, Thank you!
Minor typo under the DAuth flow though.
"The Azure Auth Service returns an On-Behalf-Of Access Token to the server in contoso.com, signed with its own Private Key (to prove where it came from) and the On-Behalf-Of Access Token in the payload is encrypted using the public key of contoso.microsoft.com (which Azure Auth has because contoso.microsoft.com provided it when they set up their own Federation Trust."
Needs to say:
"The Azure Auth Service returns an On-Behalf-Of Access Token to the server in contoso.com, signed with its own Private Key (to prove where it came from) and the On-Behalf-Of Access Token in the payload is encrypted using the public key of contoso.onmicrosoft.com (which Azure Auth has because contoso.onmicrosoft.com provided it when they set up their own Federation Trust."
Also a question:
I understand that regardless of whether Dauth is being used or Oauth, the request is first made for the autodiscover endpoint which will return the EWS endpoint and it is the EWS endpoint that would return the free/busy info. I understand that this behavior can be modified by setting the 'TargetSharingEPR' attribute to the EWS endpoint (only for DAuth), however this requires customization and isn't the default behavior. Also with OAuth all request will go via Autodiscover to EWS.
My question is; Wouldn't it be easier, if DAuth had 'TargetSharingEPR' attribute value populated by default with the EWS endpoint and HCW also configured the IOC (for OAuth) with the EWS endpoint, thereby: 1. Bypassing autodiscover and 2. Reducing a couple of hops and hence avoiding a couple of 'Points of Failure'? I am sure there are some challenges to the above mentioned proposition, I am just unable to figure out what they are. TIA 🙂