Lync Online ADFS Sign-in Issues (server is unavailable) for non-domain joined client PCs and a Windows CA

June 17th, 2012 | Tags: , , ,


Update: The recent release of Lync Server 2013 and Lync MX (the Windows App Store version of Lync) has meant that the steps detailed below are critical for securing Office Web App and Lync MX – specifically in scenarios where certificates are provisioned via an internal certificate authority and client computers are not domain-joined.

The reason for this is because Lync MX will not utilise LDAP and Office Web App will be unable to use LDAP unless the client is domain-joined, so HTTP for CRL and CDP discovery is vital – ensure the Certificate Revocation List (CRL) Distribution Point (CDP) for the certificates issued to Lync and Office Web App servers points to an HTTP resource in addition to an LDAP resource.

Update 2: Another article specifically aimed at Office Web App can be found here

Below is an example of a well formed certificate, followed by steps to enable this capability:

CRL Example:

CDP Example:


I’ve been working more recently with Lync Online and the varying types of deployment topologies, mostly Office 365 Shared or Office 365-S (the most commonly referred to version, available to small/medium size business) – it’s the one you can sign up to via

To leverage your existing Active Directory with Office 365-S you need to deploy Active Directory Federation Services (ADFS 2.0), this is a service hosted on a single or multiple IIS web servers (or a farm as Microsoft refer to it). If you want to allow external clients (via the Internet, rather than a VPN) you also need to configure an ADFS Proxy, this essentially acts as a reverse ADFS proxy. In all my test environments to-date I have not needed to deploy an ADFS proxy, but it’s also worth noting that there is one gotcha to my previous statement – for Outlook access to Exchange Online a proxy is required for both internal and external access. Put simply this is due to the fact that Exchange Online redirects part of the authentication from the Micrsosoft Exchange Online service back into the tenants ADFS service via the Internet – there is no VPN tunnel established between the Office 365 shared data centres and the customer.

So with the background covered I’ll dig into the problem I experienced with Lync Online, specifically for ADFS provisioned accounts accessed via client PCs that were not members of my ADFS domain. I elected to use a privately signed certificate for my ADFS service, this was because it limited the amount of manual client-side intervention (CA certificates deployed via AD) and was easier/cheaper to provision, it was a lab environment after all…famous last words!

Prior to this issue (“Server is unavailable” within Lync) and subsequent resolution, I’ve never really needed to customise my Windows CA installation – I’ve become a victim of Microsoft’s intuitive wizard-driven installations (this, I fear, is where the problem stemmed from) 🙂

The out-of-box installation (post-wizard) for a Windows Certificate Authority is configured to publish CDP and Authority Information Access (AIA) to LDAP-based clients only, I needed to enable HTTP access to CRLs (via CDP) and AIA. But before I tell you how I did this, let me explain, in simple terms, what this is used for:

  • CRL Distribution Point (CDP) – this is the published location of your certificate revocation list, here we can see a list of thumbprints for certs that have been revoked by an administrator. (see image below)

  • Authority Information Access (AIA) – this is the location used to publish PKI topology information, i.e. which server holds information for a specific certificates.

Without both CDP and AIA information ADFS and most PKI-based applications with fail.

So what is required it to enable publishing to either LDAP and HTTP or just HTTP (which would be sufficient for cover both on/off Domain scenarios)

Ashamedly, the answer is simple (and many thanks to the folks at Microsoft Support for pointing this out)!

1. To set the CDP (CRLs) for your Windows CA access CA management tool (Start -> Run -> CertSrv.msc), right click your CA server and click Properties and go to the Extensions tab. Ensure that “Include in CRLs… and Include in the CDP…” is selected for HTTP (see below)

2. To set AIA change the extension drop-down to AIA and ensure that “Include in the AIA…” is selected for HTTP (see below)

Once these steps are completed you will need to re-provision the signed ADFS certificate and assign to the IIS website(s) hosting ADFS and the ADFS Service Communications Certificate within the ADFS 2.0 management console. I hope this helps!