Yep, those are familiar ADFS URLs. I'm going to continue researching this, and am ~60% confident it can be made to work, but it's veering into substantially uncharted territory and so would be difficult to recommend to customers.
--Steve On Tue, Jul 31, 2012 at 6:44 PM, Steve Goodman <st...@stevieg.org> wrote: > 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:skra...@zetetic.net] > 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 <mich...@smithcons.com> > 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:skra...@zetetic.net] >> 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 <mich...@smithcons.com> >> 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:skra...@zetetic.net] >>> 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 listmana...@lyris.sunbeltsoftware.com > with the body: unsubscribe exchangelist > --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to listmana...@lyris.sunbeltsoftware.com with the body: unsubscribe exchangelist
