I don't think you'll have much luck. After a general chit-chat with a chap who does Exchange hosting about this, as it's something I've a passing interest revealed they gave up and went with syncing passwords.
Those bits you've found I think are related to Exchange Online (you'll see references to Windows Live IDs in some of those web.config files too) and can't be used on-premises. When those are actually in use, by Office 365 they don't use the same forms-based/interactive login that OWA uses to login, they use the following paths, initiated directly from Exchange Online (AFAIK) when the user passes credentials: /adfs/services/trust/2005/usernamemixed/* /adfs/services/trust/mex/* Steve -----Original Message----- From: Steve Kradel [mailto:[email protected]] Sent: 31 July 2012 23:29 To: MS-Exchange Admin Issues Subject: Re: Experiences with on-premises Exchange 2010 and ADFS2 My understanding of the Microsoft Federation Gateway is that it's for sharing free/busy at the server level, but not so much for federated user access to mailboxes. What I'm trying to describe is mailbox access alone--where Exchange uses ADFS2 to authenticate users, whether they are hitting OWA, ActiveSync, or RPC/HTTP--and user accounts exist to own each mailbox, but some users can only be authenticated via federation because they do not know their passwords in the Exchange-hosting forest. Example: You own and operate a company, TechnoCo, which has a sophisticated Exchange 2010 environment. You have just acquired OtherCo, which uses Active Directory extensively, but has no email capability at all. The networks are a hodgepodge of NAT and IP conflicts, so hooking up WANs and making an AD trust is out of the question in the near term. Without syncing passwords or managing separate credentials, can you provision and host mailboxes at TechnoCo for folks in OtherCo to use? So far, based on success in the lab, I believe the answer is yes for OWA, treating it pretty much like any web app with ADFS2 and the c2WTS. But the other protocols, well, that could be tricky... there is some stuff in RpcProxy's web.config pointing to the local Microsoft.Exchange.Security.Authentication.FederatedAuthService, which leads us onwards to Microsoft.Exchange.ProtectedServicehost.exe, and I could start poking at Microsoft.Exchange.Security.Authentication.FederatedAuthService.AuthService (which, yeah, I'll almost certainly do out of curiosity) but this may just go farther and farther away from supported-ness. --Steve On Mon, Jul 30, 2012 at 3:10 PM, Michael B. Smith <[email protected]> wrote: > So I asked the question of someone "in the know" and was told that this is > all handled by Autodiscover and that it's already federation aware. > > I've asked for additional details. > > This blog post seems to support it, but doesn't go into the level of > detail I know you want. :-P > > http://www.expta.com/2011/07/how-to-configure-exchange-2010-sp1.html > > -----Original Message----- > From: Steve Kradel [mailto:[email protected]] > Sent: Friday, July 27, 2012 9:43 PM > To: MS-Exchange Admin Issues > Subject: Re: Experiences with on-premises Exchange 2010 and ADFS2 > > To clarify, passive federated signin to OWA works by the client starting with > a request https://mail.foo.bar/owa/ and following a redirect over to the > ADFS2 STS, which handles authenticating the client (via one of Kerberos or > forms-based auth), the result of which renders a new HTML form for the client > to push its security token back to the OWA app, and I wouldn't expect > RPC/HTTP or ActiveSync clients to be able to follow those steps out of the > box. But, maybe they can--is there any way to make those endpoints > federation-aware? > > In addition, these clients would need to have some additional hints during > setup for identity provider-initiated sign-on, in the case where some other > environment is responsible for creating the user's token (i.e., a pure > passive federated signon would not know the current user's IdP). Please let > me know if I'm not making sense and I'll break down and make a diagram... > > --Steve > > On Fri, Jul 27, 2012 at 8:59 PM, Michael B. Smith <[email protected]> > wrote: >> Regular outlook client would use RPC/HTTP. ActiveSync is a http-based >> technology, so I'm not sure what you are asking about there... >> >> Is it supported "in general"? I dunno. But that's how Office 365 federation >> works. >> >> -----Original Message----- >> From: Steve Kradel [mailto:[email protected]] >> Sent: Friday, July 27, 2012 2:16 PM >> To: MS-Exchange Admin Issues >> Subject: Experiences with on-premises Exchange 2010 and ADFS2 >> >> Hi list, >> >> Having just configured Exchange 2010 SP2 with ADFS2 in a lab >> environment (somewhat but not entirely based on Ken St. Cyr's guide @ >> http://www.theidentityguy.com/articles/2010/10/15/access-owa-with-adf >> s .html which, although very helpful, also documents some things that >> didn't or at least do not now work), I wanted to get the list's >> perspective... >> >> * Anyone doing this now to provide federated OWA services across orgs w/o >> domain trusts? >> * If so, does Microsoft consider it a supported configuration? >> * Are users willing to accept federated OWA but not federated ActiveSync >> access? >> >> I'm pondering how folks would access any non-HTTP-browser aspects of >> Exchange (regular Outlook client, ActiveSync) in a federated arrangement, >> but it's hard to escape a dependency on password sync. >> And in that case, why federate at all? >> >> --Steve >> --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to [email protected] with the body: unsubscribe exchangelist --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to [email protected] with the body: unsubscribe exchangelist
