Using ISAPI Extensions to change-out OWA Credential is not supported

  • Article

Single sign-on applications usually use an ISAPI Extension on Exchange servers in order to swap-out credentials being passed to OWA.  This type of manipulation is not supported by Microsoft.  In fact any thing which augments the behavior in this way is not supported.  While such filters/extensions may have worked with Exchange 2000 and 2003, they are less likely to work with OWA from Exchange 2007.   If you have a problem with such an Extension/Filter, please contact your software provider.  It will be up to ther software provider to find their own solution on this as its not supported my Microsoft.

When we see developers's trying to use an IFRAME to hold OWA it almost always means their program is trying to use credentials collected from their own ASP page and pass them to OWA running in an IFRAME.  The type of application is usually some sort of portal.  They would try to use the credentials entered on the portal logon page (usually ASP forms based authentication page) with OWA.  The two problems here are that the IFRAME does not share security contexts with the rest of the webpage, and the fact that you cannot directly give credentials to OWA to use.  The way they try to get around this is by using an ISAPI extension which can use the credentials entered on their page and use them in a swap-out with the credentials that OWA uses in the HTTP traffic going to the OWA server.  

An ISAPI extension is used by some developers. Such an ISAPI Extension would sit in front of OWA/DAV and change-out the credentials in the HTTP stream.  This can cause many types of problems.  It may work most of the time, however it may break WebDAV or OWA at different times – I’ve seen this happen several times.  Note though, that ISAPI extensions are very much supported.  I’ve never seen anything saying that there cannot be an ISAPI Extension sitting in front of OWA and just monitoring traffic. However, the fact is that doing such an operation on the OWA stream (changing credentials, etc) is not supported. Changing the stream of OWA amounts to hacking the application – which is not supported.

  Microsoft does not support using ISAPI extensions or filters to modify Outlook Web Access credentials on a server that is running Exchange Server
  https://support.microsoft.com/kb/938609

Note that this applies to ALL versions of Exchange.

Please also be sure to read the following:

"Enhancing Exchange" via unsupported methods.
https://blogs.msdn.com/b/webdav_101/archive/2013/06/13/quot-enhancing-exchange-quot-via-unsupported-methods.aspx

Comments

  • Anonymous
    August 10, 2010
    Is it valid for following case also? We have site protection module (it will ask for our authentication if its already been protected using ours and then normal request flow continues). So if OWA is protected using this and user will be challenged for our authentication first and then normal windows authentication, But in order to provide SSO we are doing following we have an HTTPModule and filtering BeginRequest and assigning the Impersonation token after doing LSALogonUser So will this scenario effected by the above mentioned change? Thanks, Abhilash.

  • Anonymous
    August 10, 2010
    It sounds like a similar scenerio.  The main thing is that if your modifying the traffic between the client (IE) and OWA, then its an unsupported scenerio.  This scenerio was not tested for by the product teams involved and there is no published interfaces.  Some things involving Exchange and OWA may not work properly using certain types of impersonation (special product and API specific authentication is needd).  That said, its very possible that you have something which works and perhaps quite well.  However, if there are issues with the code, you will not be able to get developer support for the code going against OWA.  If you can reproduce the same issue with a normal ASP.NET page (no OWA, WebDAV, etc. involved), then that may be a different matter.   Another thing which comes-up in conversations on SSO is running the who OWA UI in an IFRAME so that OWA appears to be part of a site.  This is something which may be possible to do by massaging some OWA files, however its not supported and such changes would have a good chance of being overwritten during an update. Being able to do SSO and hosting all of OWA in an IFRAME are features which we know developers which to have. Such features would likely be in some future full release of OWA though.

  • Anonymous
    September 05, 2010
    Hi Daniel I came across your post and was wondering if you could take a look at my question to the Exchange Forum. social.technet.microsoft.com/.../35e7fbf1-85af-44a3-afb3-22c0d8c18081 Many thanks, Craig

  • Anonymous
    September 05, 2010
    Hi Daniel I came across your post and was wondering if you could take a look at my question to the Exchange Forum and give me some advice/ social.technet.microsoft.com/.../35e7fbf1-85af-44a3-afb3-22c0d8c18081 Many thanks, Craig