Office 365 Hybrid Coexistence and Edge Server

Posted on Leave a commentPosted in 2010, bpos, exchange, exchange online, hybrid, Office 365

One of the delights in my job is when Microsoft give me a call and ask me how something works in one of their products! Such a call came today and it involved get Office 365 hybrid coexistence working with an Edge Server.

Exchange Server Deployment Assistant does not have the answer to this issue; it always refers to a Hub Transport server within the organization. But it was an interesting challenge, as the last time I tried to get this working I got a “a local loop detected” error.

In brief, its is possible to use Edge Server as the coexistence server between your organization and your Office 365 tenant, you just need to make sure that everything you would create on the Hub Transport is either configured on the Edge Server (receive connectors and certificates) or created within the organization and replicated to the Edge Server via EdgeSync (send connectors, remote domains, accepted domains).

The reason for “a local loop detected” error was down to having the service domain for the Office 365 tenant configured as Internal Relay (as it needs to be) and not having a Send Connector on the Edge Server that pointed to the Office 365 infrastructure.

Update 26 Oct 2011

In the above I wrote that the Office 365 tenant domain as configured on-premises needs to be internal relay. This is only required if your on-premises org contains Exchange 2003. If the minimum version of Exchange installed on-premises is 2007 then the domain can be Authoritative. This is because with 2007+ you can forward emails to an authoritative domain using contact or remote-mailbox objects and a send connector for the domain.

Changing ADFS 2.0 Endpoint URL for Office 365

Posted on 3 CommentsPosted in 2007, 2010, 2013, ADFS, ADFS 2.0, certificates, exchange, exchange online, https, hybrid, IAmMEC, ISA Server 2006, mcm, Office 365, SSL, tmg

If you are configuring single sign-on for Office 365 then you will need a server running Active Directory Federation Services 2.0 (ADFS 2.0). When you install this you are asked for a URL that acts as an endpoint for the ADFS service, which if you are publishing that endpoint through a firewall such as TMG needs to be on a mutually trusted certificate as either the subject name or alternative subject name.

The documentation uses sts.yourdomain.com which means you need to have this as a valid name of the certificate. I use StartCom SSL, which provide cheap certificates (approx. $100 for as many certificates as you like), but to change a certificate to add an additional alternative subject name requires revoking the current cert, and that comes at additional cost.

So I have a certificate with lots of name on it for my domain, just not sts.mydomain.com so I set about changing the endpoint in ADFS 2.0

Firstly open the ADFS 2.0 administrative console and select the root note:

image

Click Edit Federation Service Properties in the Action Pane and modify the three values on the General tab:

image

After clicking OK, restart the AD FS 2.0 Windows Service.

After the restart, create a new Token-Signing Certificate and Token-Decrypting Certificate. These are self signed certificates. To allow you to add these you need to turn off automatic certificate rollover if enabled. This can be done from PowerShell using Set-ADFSProperties –AutoCertificateRollover $false and this cmdlet is available in Windows PowerShell Modules in the Administrative Tools menu.

To update Office 365 start the Microsoft Online Services Module for Windows PowerShell, installed as part of the Office 365 rich co-existence process. In this PowerShell window type Update-MsolFederatedDomain –DomainName yourFederatedDomain.com. You will also need to login to Office 365 in this window first (Connect-MsolService) and set PowerShell with the name of the ADFS server (Set-MsolADFSContext –Computer ADFS_ServerName). Type Get-MsolFederatedDomain –DomainName yourFederatedDomain.com to ensure that the returned URL’s and certificates are correct.

Now its time to update the TMG rule, or create a new one. The listener in TMG must have the same third party certificate and be for HTTPS with the Public Name matching the certificate subject/subject alternative name and the Path value set to /adfs/*. The To page needs to be set with the same URL and internal IP address of the ADFS 2.0 server.

image

And that should be it – after the Update-MsolFederatedDomain –DomainName yourFederatedDomain.com has completed both sides of the federation trust are aware of the certificate change and automatic login to http://outlook.com/yourFederatedDomain.com should work.