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.

Error Code: 500 Internal Server Error. The network logon failed. (1790)

Posted on 1 CommentPosted in certificates, https, iis, ISA Server 2004, ISA Server 2006, SSL, Windows Server 2003

This is an error visible in the web browser when connecting to a HTTPS web site behind an ISA Server.

The problem is that the firewall access rule for this web site in ISA Server is forwarding the requests to an internal server on a port that it is not listening on. For example you connect to https://server.example.com and the ISA Server forwards this request to http://internalsrv. On the Bridging tab check that the mentioned port(s) are actually working on the internal server. For example if you are listening in ISA Server on 443 for a SSL connection and the SSL/HTTPS port is ticked make sure that the port is 443, and that the web server internally is listening on 443. If its another number make sure that it is meant to be the other number and not really 443 or not ticked at all. Ditto for the HTTP port, which is 80 by default.