Exchange 2010 OWA SSO between 2 separate forests

Question

Hi,

I'm currently in the process of trying to configure OWA SSO between 2 different forests using ADFS 2 - guide at:  http://allmsft.blogspot.co.uk/2012/02/owa-sp2-and-adfs.html

I'm running into some big issues, similar to the last posts on the thread. I don't have any ADFS or certificate errors in the event logs.

I repeatedly receive an error "Outlook Web App didn't initialize" with error 29 in the event log showing

The authentication type specified in the C:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\owa\web.config file is incorrect. The correct authentication type is "Windows".

The web.config above has the authentication type set to Windows. The actual web app I'm using is a new OWA site, with a separate web.config and the authentication type set to "None". It's almost as if the wrong web.config file is being read.

If anyone has an idea on how to resolve this I'd love to hear it.

On a separate note, am I going about this the right way?

I have 2 different AD forests org A and org B. I want to give org A users Exchange mailboxes in orgB and I want orgA users to be able access these mailboxes without additional authentication.

What's the best way to achieve this? Is it possible?

Thanks

 

---

IT Support/Everything

Answer 1

If you switched the authentication type to Forms do you get the same error when starting it up?

If you do then it sounds unrelated to the WIF stuff and possibly related to the generic OWA configuration.

---

Developer Security MVP | www.syfuhs.net

Answer 2

Assuming you get this working with SP2, which I haven't tried (I did a working configuration with Ken's article based on SP1 with OWA/ADFS and a local forest), then for the remote forest I'd imagine you'll need to also use a shadow account in the local forest and Send LDAP claims using the local UPN in order for the C2WTS transition to work correctly.

Regards,

Mylo

Answer 3

I tried switching to forms and integrated authentication, but still can't get this working.

Using a user account within the same domain as the

exchange server, browsing to http://xchangesso.dom.local/owa , I can see the URL redirects working, going to the correct /adfs, then after 2-3 seconds I get a page cannot be displayed error:

Outlook Web App didn't initialize. If the problem continues, please contact your
helpdesk.

In the Event log, Event ID 29 is registered:

The authentication type specified in  C:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\owa\web.config file is incorrect, the correct authentication type is "Windows"

In my web.config, "Windows" is the correct authentication type.

I may have to blast the owa site away and rebuild.

All the federation metadata pages display OK with valid certs.

Mylo, I've seen that article by Ken. I may opt for that, but I was hoping I could get this to work:
http://allmsft.blogspot.co.uk/2012/02/owa-sp2-and-adfs.html

---

IT Support/Everything

Answer 4

Can you make sure that in ADFS the relying party address is configured as https://fooserver/owa/, e.g. with the ending slash?

---

Developer Security MVP | www.syfuhs.net

Answer 5

I have the same error:

The authentication type specified in  C:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\owa\web.config file is incorrect, the correct authentication type is "Windows"

I verify that in ADFS the relying party address is configured as https://fooserver/owa/ ,   with the ending slash

Any other ideas?

Answer 6

I had the exact same issue. I used the guide(URL) you mention and the only difference I added into it was http://support.microsoft.com/kb/2722087. That did not work. I rebuild everything and kept using local system for C2WTS instead of dedicated account. When I finished the rebuild, it worked! Honestly I do not know what's different besides the account for C2WTS

---

Jorge de Almeida Pinto [MVP-DS] | Principal Consultant | BLOG: http://jorgequestforknowledge.wordpress.com/

Answer 7

I've been in touch with a Microsoft technician over this, the advice was "Don't do it". When I first started, there was an unofficial guide on how to do it on Technet which has since been pulled. The MS technician said that the stance had changed from unsupported to advised against and unsupported. His words were "it weakens security, leaves Exchange in an unsupported configuration and future updates will break Exchange if you get this to work"

Can't really argue with that...

---

IT Support/Everything

Answer 8

Hi bd50,

"it weakens security, leaves Exchange in an unsupported configuration and future updates will break Exchange if you get this to work"

Did the technician elaborate how it weakens security?

I don't get the "it leaves Exchange in an unsupported configuration argument". The changes are on the IIS side and an additional web site is created. Exchange 2010 supports multiple OWA contexts. From an Exchange Management perspective, it's an additional /owa and /ecp configuration with anonymous access.

Equally, future updates will break Exchange is also baffling... futures updates may break the WIF/Exchange combination, but on the prescribed web site, e.g. as what happened with Exchange 2010 SP1 to Exchange 2010 SP2.

I can understand the supportability aspect from an MS support point-of-view because it's an additional working configuration to support but to then make these comments without further elaboration is strange.

Regards,

Mylo

Answer 9

It weakens security because it puts it in an unknown state for configuration. It was never tested or fully vetted from a security perspective, so it weakens security because of the unknown factor. There's also a lot of debate about the security of the C2WTS service because it can generate a principal context without authentication. This changes the entire threat model for OWA.

It also kind of screws certain things up, like inbox rule management. Certain things break because there are some hardcoded bits expecting Forms or Windows Auth.

Updates breaking existing configurations are a serious thing for business-critical services. Nobody wants to be put in the situation where an update to a working system breaks the system.

---

Developer Security MVP | www.syfuhs.net

Answer 10

Hi Steve,

Thanks for the reply and the inbox rule management elements weren't something I was aware of.

Can you point me to a link about the C2WTS security discussion? I'm curious how this sits in the SharePoint security side of things, given that it similarly supports protocol transition of SAML claims thru C2WTS.

Regards,

Mylo

Answer 11

Unfortunately I don't have any links to discussions. It's been discussed offline.

The problem would still apply to SharePoint if you were using C2WTS, however it's really only a problem if you don't take it into account for your threat models. The WIF and SharePoint teams have gone over it, which is why they support it.

---

Developer Security MVP | www.syfuhs.net

Answer 12

Thanks.. taken into consideration all of your valid points, it's a shame that claims are so widely embraced within the SharePoint product group, within Office 365 and yet this doesn't seem to translate to Exchange.

Regards,

Mylo

Answer 13

Remember, we're talking Exchange 2010. There's a newer version out. :) I have no idea how it compares through.

Part of their hesitation also makes sense too. Exchange has always tied into AD, especially for authentication and authorization. By configuring it to support ADFS, and more generally any WS-Fed provider, it changes the relationship to AD. Exchange would bypass ADFS for things like ActiveSync, which means a user could potentially have different credentials.

Office 365 and SharePoint support claims and federation because they were designed to support it from a very low level. Things were ripped out and replaced to support it.

---

Developer Security MVP | www.syfuhs.net

Answer 14

Hi Steve,

Again, thanks for your reply and I can't fault the logic provided. Indeed, bolting WS-Fed onto Exchange 2010 is a hodge-podge. Aside from OAuth in the back-end, I just don't see evidence of a consensus to try and unify authentication, even in an evolutionary sense, in the front-end (on-premise) for Office 2013 services.  I guess what I'm trying to say is that I would have expected to see some sort of traction in the use of exposing these sorts of services in a similar (on-premise) way that O365 works. Given, that I can authenticate via ADFS for passive clients to OWA/SharePoint in O365 in (/adfs/ls), for Lync with (/adfs/services/trust/mex) and for other rich clients such as ActiveSync/Outlook (/adfs/services/trust/2005/usernamemixed), I was surprised to see an equivalent is not available in on-premise, even if that meant providing an equivalent to the MS Fed-Gateway (on-premise) to do the protocol transition to those back-end services. 

This two-track system between on-premise versus cloud is best illustrated with EAS support in Office 2013, where I can use Outlook to connect via EAS to outlook.com, but not to my on-premise Exchange server.

"The official stance from the Product Team is that Outlook will connect to any server which provides EAS 14.x except for Exchange.  For RTM release Outlook 2013 will block connections to Exchange servers using EAS.  Connecting to Exchange over EAS is not supported."

All of a sudden the proposition of using Windows 8 devices in a BYOD context diminishes. Forgive the slight diversion, but it struck me as an opportunity lost.

Regards,

Mylo