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-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
RE: Experiences with on-premises Exchange 2010 and ADFS2
My attempt at garnering additional information has been unsuccessful. I will simply point out that Exchange Online does all this, and if you check out various blogs for handling hybrid configurations in Exchange 2010 RTM and Exchange 2010 SP1, you might be able to gain additional insight as to how this can be done. -Original Message- From: Steve Kradel [mailto:skra...@zetetic.net] Sent: Tuesday, July 31, 2012 6:29 PM 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
RE: Experiences with on-premises Exchange 2010 and ADFS2
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
Re: Experiences with on-premises Exchange 2010 and ADFS2
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
RE: Experiences with on-premises Exchange 2010 and ADFS2
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 --- 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
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
RE: Experiences with on-premises Exchange 2010 and ADFS2
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 --- 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
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 --- 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
RE: Experiences with on-premises Exchange 2010 and ADFS2
I know the answer is yes, but I've never done it. Let me see if the documentation is publicly available. It may take me a day or two, I'm on the road travelling home after a couple weeks in a certain pacific northwest city. -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 --- 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
