Renewing AD FS Certificates – Updated Guidance

TLS certificates come and go.  By their nature they have a set life span and then they must be renewed.  While this is nothing new, I’ve being doing this since the 1990s, the process may become a little more frequent for some customers as the industry is eliminating three year certificates see 3-Year Certificates to Be Eliminated in Industry-Wide Change for example.

In the posts for deploying AD FS for Office 365 one of the requirements was a valid TLS certificate which is used for the service communication certificate and SSL certificate.   As time marches on, inevitably this certificate will need to be renewed.  Unfortunately the AD FS UI did not perform all of the required steps, which prompted this post on updating the AD FS 2012 R2 SSL and service certificate.

Thankfully there have been improvements to Azure Active Directory Connect (Azure AD Connect) which will streamline the process even further.

Note that this is now the prescribed methodology for updating AD FS certificates where possible.

Starting Configuration and Requirements

If you look at the date when the current AD FS certificate will expire you can figure out when this post was created.  The current certificate is set to expire on the 21st March 2018.  This is shown below in the highlighted line.  IE is used as it easier to show the certificate properties compared to Edge.

The below are images and steps from one of my test labs.  The process is documented here: aka.ms/ADFSSSLWithAADConnect

Note that the AD FS infrastructure must be Windows 2012 R2 onwards.  AD FS 2.0 is not supported by this process.

PowerShell remoting must be enabled on all servers that are to be updated.  This accounts for many of the issues noted in the troubleshooting section at the end of the post.  Scroll down to the end for all of the gory details.

Note that Azure AD Connect must be build 1.1.553.0 or higher.  At the time or writing the latest downloadable version of Azure AD Connect was installed 1.1.654.

The provided certificate is also checked to ensure that it meets the following requirements:

• The subject name/alternate subject name for the certificate is either the same as the federation service name, or it's a wildcard certificate.
• The certificate is valid for more than 30 days.
• The certificate trust chain is valid.
• The certificate is password protected.

 

Updating AD FS Certificate using Azure AD Connect

You will still need to follow your documented process to request a new TLS certificate from the issuing CA.  In this case, the steps outlined in How To Request Certificate Without Using IIS or Exchange were used to generate the certificate request and then complete the process.

The completed certificate was then exported to a password protected .PFX file.  This is required for the process below as the certificate needs to be copied out to all of the required servers, both AD FS and WAP.

To initiate the process, launch Azure AD Connect.  You probably have a shortcut to this on the desktop.  The AzureADConnect.exe should be located in:  "C:Program FilesMicrosoft Azure Active Directory ConnectAzureADConnect.exe"

Launch AzureADConnect and from the Additional Tasks menu we need the Update AD FS SSL Certificate task.

You will be prompted for Azure AD credentials.  This account will need to be a Global Admin in the tenant.

Azure AD Connect will verify connectivity and the provided credentials.  If successful then credentials for the local AD FS servers are requested.

Again they will be verified, afterwards you will be prompted to enter the AD FS farm topology if Azure AD Connect does not already have the information.  In this lab AD FS was manually installed, and this was the first time Azure AD Connect was used to update the certificate so Azure AD Connect had no knowledge of the AD FS farm.  Running the AD FS task subsequently should populate the farm information.

The AD FS server names were manually entered one by one.

There are two AD FS servers in this farm, so we are able to move on.

Note that there was some troubleshooting involved in getting the second AD FS to appear in this list.  See the troubleshooting section below for details.  Servers must be online and accessible to be updated.

Note that removing a server from this list does NOT remove it from the AD FS farm. 

The WAP servers were then entered.  In this lab there are two WAP servers, so we can move on.

Now that all the farm information has been entered, we need to provide the updated certificate.  Note that this needs to be a password protected PFX file.  The PFX extension means that it has an associated private key.  If the file extension is .CER or .DER then it is of no use and you need to figure out what happened to the PFX file.

In the example below, note that the new certificate is valid for the next year.  Always ensure that you check the correct certificate is going to be loaded as it can be easy to select the wrong certificate.

Clicking next will allow you to chose which servers to update in this operation.  I chose to do all of the AD FS and WAP servers simultaneously.

You will be prompted for the certificate file’s password.

And now we are off to the races, and Azure AD Connect will do the hard work of updating the farm.

And we are done!  Note that there is a handy verify button – we will come back to that in the section below.

Verifying Updated Certificate

If we look at the AD FS management console, note that the expiration date of the certificate is now 12 months in the future.

The same is true when we look at WAP from an external test client.  Note that the certificate is valid until 2019.

We can also perform an authentication verification using Azure AD Connect.  This is the verify button that was noted above.

You will need to provide a set of valid credentials for a federated user.  This means that you do not use @microsoftonline.com address, it will need to be a federated namespace.

Since this lab uses tailspintoys.ca as the federated namespace, the lucky volunteer called Colin Cloud will be perfect!

Troubleshooting

I would love to say all of this went well on the first try, but alas no.  There were some issues along the way.

The issues noted below are all network related.  The Azure AD Connect tool will use PowerShell remoting to perform the operations.  If it is unable to access WinRM then you will issues like the below.

Windows Firewall issue

If Windows Firewall is blocking the required traffic then you will see the below in Network Monitor.  Note that there are three SYN requests – this indicates a firewall timeout.

The AD FS server trying to be added is this case was called Tail-CA-STS2 with IP 10.0.09 – the associated network traces are shown below.

The frame summary is expanded here so you can see the three SYN frames.

Even though the traffic is not getting to the destination server, Azure AD Connect will produce an authentication pop-up.  This may make you believe that the traffic got through and that an invalid password was specified, but this is probably not the case. Ensure that WinRM is accessible.  Specifically WinRM on TCP 5985.  You will see there is a difference in the section below.

There is a Windows Firewall rule that should be enabled, this will allow the traffic to flow.

PowerShell Remoting Issue

When we configure AD FS for Office 365, a common issue with AD FS 2012 R2 was that PowerShell remoting was not enabled by default.  When using the Azure AD Module to integrate AD FS with the tenant, you would likely get this wonderful error:

Set-MsolADFSContext : The connection to <ServerName> Active Directory Federation Services 2.0 server failed due to invalid credentials.

This is discussed in part three of the AD FS 2012 R2 series and also in PSRemoting for Office 365 Configuration.

Typically I find that only the AD FS server used to perform the work with the Azure AD module was configured for PSRemoting.  The secondary servers were not.  This will lead to the situation where that first AD FS server can be added to the Azure AD Connect task, but secondary servers can not be added you will get an authentication pop-up.

We can use this command to get a high level view of the current WinRM listeners which are configured:

Winrm enumerate winrm/config/listener

AD FS Server Used By Azure AD Module

This server was previously enabled for PSRemoting by running Enable-PSRemoting as it was required to run the Azure AD module.  Note that you see a listener for TCP 5985 and TCP 5986.

Compare this to an AD FS server which was not used as an endpoint for the Azure AD module.  Note that there is only a single WinRM listener on TCP 5986.

As noted above, we can fix this by running Enable-PSRemoting

Note that afterwards, the same server (Tail-CA-STS2) now has a WinRM listener on TCP 5985 and TCP 5986.

We can now successfully add the second AD FS server to the Azure AD Connect wizard.

Firewall to WAP Connectivity Issue

It is likely the AD FS and WAP servers are on different subnets with a firewall in between.  The firewall will restrict traffic between WAP and AD FS servers.   This is the typical and recommended deployment.  In this case the firewall should only allow TCP 443 between the WAP and AD FS servers, no other ports are required for daily AD FS and WAP operations.

As you can imagine, if Azure AD Connect is trying to use PSRemoting to connect to WAP servers the traffic may be blocked.

The below is an example of this, where the DMZ WAP server on network 10.94.0/24 is not open on TCP 5985.

The frame details are shown below.

The firewall must be configured to allow TCP 5985 in order for Azure AD Connect to be able to update the certificates.

In addition, also ensure that PSRemoting is enabled on WAP.  This may not be the case for WAP 2012 R2 servers.

Winrm enumerate winrm/config/listener

Enable-PSRemoting -Confirm:$false

Now we are  able to add  the WAP server.

Cheers,

Rhoderick