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-adfs
>> .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

Reply via email to