Troubleshooting and Managing ADFS 3.0

The infamous words “It’s not working”, “I can’t login”, or “The page cannot be displayed.  I’d be willing to say a fair few of us have heard these lines on more then one occasion.

Like my post that I published on preparing for an O365 migration, I thought that it would be good to put something equally as helpful together to guide you the reader on where to start when troubleshooting an ADFS issue.  These little critters pop up frequently enough that they deserve their own special post, I have taken everything I have seen on other posts and my own experiences and have put them all here in one place.

Some of the links that I have put in this blog post refer to ADFS 2.0, I have put these in intentionally as the content is still relevant for 3.0 and the steps are much the same.

ADFS is used in combination with Office 365 to create a scenario in which federated identities are used, this is also known as single sign-on.  Unlike cloud identities or synchronised identities, federated identities authenticate against an on-premises Active Directory through an ADFS server infrastructure instead of Windows Azure Active directory.  This means that ends users log into Office 365 using their on-premises credentials.

ADFS provides a robust environment that requires few frequent maintenance tasks, however there is still a requirement to perform certain tasks on an as needed basis.  This guide will provide the information and instructions for performing these tasks, it will also include a troubleshooting section for some of the more common issues that arise with an ADFS implementation.

Managing ADFS Components

ADFS is made up of two primary components:

Federation Service

The Federation Service functions as a security token service and routes authentication requests from external user accounts in partner organisations and clients on the Internet.

Web Application Proxy

The Web Application Proxy (WAP) functions as a proxy for the Federation Service in a perimeter network.

Managing the Federation Server

ADFS Management Console   

The AD FS administration tool (adfs.msc) is supplied as a Microsoft Management Console (MMC) snap-in. The administration tool is used to add account and resource partners, map partner claims, add and configure account stores, and identify and configure federation-aware Web applications

  1. Go to Start, type in AD FS and click to open the ADFS management console.
  2. adfsconsole2. The AD FS Management console will open. The following figure shows the main components of the AD FS Management console.
  3. adfsconsole2

Changing the primary Federation Server

The first server that is installed in the federation farm is automatically the primary federation server.  Any subsequent federation servers that are added to the farm will poll the primary federation server for configuration changes every 5 minutes by default.  If changes are found these will be replicated to a local instance of the configuration database, this is stored in the Windows Internal Database unless SQL has been specified.

If the primary federation server fails and there are multiple federation servers in a farm although these other servers will remain operational, changes to the ADFS configuration will not be able to be made until the primary federation server has been restored or another federation server has been promoted as the primary server.

To promote a secondary federation server to primary, run the following commands from the secondary federation server:

Set-AdfsSyncProperties –Role PrimaryComputer

Once the new primary federation server has been set, any other secondary federation servers need to be configured to sync with the primary federation server.  Run the following command on the remaining member servers:

Set-AdfsSyncProperties -Role SecondaryComputer -PrimaryComputerName {FQDN of the Primary Federation Server}

ADFS Certificate Management

Token-Signing Certificate

ADFS uses a token-signing certificate to digitally sign the token that is created when the system makes an authentication request.  This token is then sent back to the source of the request, which is referred to as the relaying party.  Once an ADFS trust is created between two environments, the token-signing certificate is exchanged.

By default, ADFS uses a self-signed certificate which comes with a validity period of one year.  ADFS by default is configured to automatically generate a new certificate when it is close to expiring.  This behaviour is controlled through the AutoCertificateRollover attribute.  To verify the current ADFS property settings, run the following command:

Get-ADFSProperties | Select AutoCertificateRollOver

It is imperative that the token-signing certificate is regularly checked to ensure that it does not expire, or that there are not any issues with the auto certificate rollover service.

SSL Certificate

ADFS requires a certificate for standard Secure Sockets Layer (SSL) server authentication on each federation server in the farm.  The same certificate should be used on each federation server in the farm, and both the certificate and the private should be available.  The SSL certificate is used for securing communications between federation servers, clients, web application proxy and federation server proxy computers.

SSL certificates that have been imported can be viewed via the Certificates snap-in for the MMC.  It is imperative that the SSL certificate used in ADFS operations is valid and does not expire.

  1. Open MMC, and add the certificate snap-in
  2. Select Local Computer under the snap-in options
  3. Open Personal, this will show all of the SSL certificates that have been imported on the server.

Troubleshooting ADFS

Whilst ADFS is a robust identity management solution, there times when things can go wrong.  Please see below for a breakdown on the most common issues that occur with an ADFS deployment and ways to troubleshoot and resolve them.

Enable additional logging

Additional logging provides more information about the interactions of the ADFS farm which will assist in any troubleshooting activities.  To enable additional logging, please follow the steps outlines below:

  1. Check the current log level for ADFS by running this command:


  1. Confirm that the SuccessAudits and FailureAudits have not been configured and add these into the logging results:

Set-AdfsProperties -LogLevel ((Get-AdfsProperties).LogLevel+’SuccessAudits’,’FailureAudits’)

  1. To ensure that the audit results are visible in the event logs, enable application generated auditing:

# Verify

. $env:\systemroot\system32\AUDITPOL.exe /GET /SUBCATEGORY:”Application Generated”

# Configure

. $env:\systemroot\system32\AUDITPOL.exe /SET /SUBCATEGORY:”Application Generated” /FAILURE:ENABLE /SUCCESS:ENABLE

When an ADFS request is processed, there will be more information available in the application log which will assist in the troubleshooting process.

ADFS Diagnostics Module (Section taken from TechNet)

The ADFS diagnostics module contains commandlets to gather configuration information of an ADFS server, as well as commandlets to perform health checks to detect configuration issues based on common root causes, for example duplicate SPN’s, Certs, etc.

The tool can be downloaded from the TechNet Script Centre:

Some examples of the types of commands that can be used:

Get information about the system 


Get information about the AD FS farm deployment 


Perform health checks 

Test-AdfsServerHealth | ft Name,Result  -AutoSize

“There was a problem accessing the site.”, “The page cannot be displayed” Internal Authentication works, external does not.

Typically this issue occurs when the proxy server is unable to establish a secure communication with the ADFS server.  If authentication is working internally, but externally users are unable to authenticate, start by checking the following on the proxy server:

  1. The system clock – make sure that the time on the proxy and adfs server are the same.
  2. Service account – verify that the service account which is used by the proxy server to obtain its configuration information from the ADFS server has not been deleted, the password reset or the password has expired.
  3. Name resolution – verify by performing an NSLOOKUP on the proxy server that it is able to correctly resolve the ADFS service name and that the IP address of the ADFS server is correct.

“There was a problem accessing the site.”, “The page cannot be displayed” Both internal and external users are unable to authenticate.

Start by checking the following on the ADFS Servers, in addition to checking the points above on the Proxy Server.

  1. Certificate Expiration Date – Open the ADFS management console and browse to certificates in the left window.  If the token-signing or token-decrypting certificates have expired, refer to this link for more information:
  2. SSL Certificate Expiration Date – Open MMC, and add the certificates snap-in.  Follow the prompts to add the certificate store for the local computer and once loaded select Personal from the left navigation pane, from here you should be able to see the SSL cert and check its expiration date.
  3. ADFS & Azure AD in Sync – Confirm that the ADFS server and Azure AD are in sync, by verifying that the certificate thumbprints for each match.  Refer to this link for more information:
  4. Verify the health of the Azure AD trust – If the ADFS farm was configured using Azure AD Connect, the application can check for the current health of the AD FS and Azure ADtrust and take appropriate actions if required to repair the trust. Refer to this link for more information:
  5. Authenticate on ADFS server – After verifying that the certificates are all valid and have not expired, and that the trust is setup correctly, test authentication on the ADFS server – browse to: https://ADFS-ServiceName/adfs/ls/idpinitiatedsignon.htm.If authentication succeeds on the ADFS server, move onto trying an internal workstation, followed by an external machine if that is successful.
  6. Check Event Viewer – If authentication is still proving to be troublesome, begin reviewing the ADFS logs in the event viewer, sometimes the application and or system logs will yield results also.  If there are errors present, you can correlate the event ID’s here:

“There was a problem accessing the site.”, “The page cannot be displayed” External users are able to authenticate but internal users are unable to authenticate.

The steps for troubleshooting this particular scenario are pretty much a rinse and repeat of the steps above, with a couple of extra ones detailed below:

  1. Run Tracert – From an internal workstation, open a command prompt and run a tracert to the internal IP address of the ADFS Server.  This should provide a good indication as to where there may be an issue with communication to the ADFS server.
  2. Install Fiddler – Download and install Fiddler on a workstation that is on the internal network.  Open Fiddler and run a packet trace on the open session to determine what is happening when the request to authenticate is sent to the ADFS server.  It should be possible to see the request from the workstation hit the ADFS server, and the ADFS server then respond to the request.
  3. NSLOOKUP – Open a command prompt on the internal workstation and perform an NSLOOKUP to verify that it is able to correctly resolve the ADFS service name and that the IP address of the ADFS server is correct.

I hope to keep updating this post with more ways to troubleshoot ADFS, in the meantime if you have anything that I should add to this post please write it in the comments!





To ADFS or not to ADFS…

To ADFS or not to ADFS that is question…  So this is a topic that frequently comes up in discussion with customers and I thought that it would be good to put something together where we discuss the business benefits of both identity solutions.

Something I find missing from most technical articles that talk about ADFS or Synchronised or even cloud identity for that matter is why you might choose one method over another.  I think that it is really important to keep in mind as a consultant that every customer has a unique set of requirements and a solution which might fit one customer is not necessarily going to suit another.

I realise that for the most part that this is a given, but you would be surprised at how often I see a consultant design a solution based primarily on their knowledge of having done something similar before and therefore defaulting to this, instead of considering other possibilities and working in consultation with the customer to determine exactly what they need as opposed to what they tell you that they want!

There are some key questions I believe should be asked first to determine what are the primary driving factors for choosing one identity model over the other.  These questions need not be from a technical stance, but more from an operational approach and most importantly should focus on what long term aspirations the business has.  What is their 5 year roadmap, do they want to ultimately be on the cloud or do they see themselves operating in a hybrid model with some services still on-prem?

So what are these questions, what do I need to be asking my customers?  Well we need to be asking the type of questions that make them consider what their non-negotiables are, what type of user experience they are chasing and what value proposition they expect to get from the project.

To summarise, here are some template questions that are a good starting block to make the often blurred line of what the customer wants versus what they need clearer.

  1. Would you consider your user base to be fairly comfortable with the concept of logging into and authenticating to multiple systems.  – Use examples to make them really think about what you are asking them.  Most users are comfortable using for example Facebook, LinkedIn, Gmail, etc. and so the process of logging into another system is not going to be something that is new to them.  We as consultants tend to forget that most of our user base are becoming more and more comfortable with technology as a service and how it is becoming much more commonplace in our day to day world.
  2. Consider the type of support calls that you receive from your user base, what percentage of them are related to lost passwords, forgotten usernames, etc.
  3. What security do you require?  This is a rather pointed question but is essential in understanding the type of identity model to implement.  For example is there a requirement to restrict users to accessing Outlook whilst on the corporate WAN only, or do you want to limit when users are able to use ActiveSync?
  4. Do you have a current multi factor authentication model in place, is there a plan to continue to use this and try and integrate this with Azure AD, or would you be happy implementing the multifactor offering provided in Azure AD premium?
  5. Is there a concern over syncing password hashes to the cloud, could this be mitigated with a simple information session where you as a consultant explain exactly what this means and how this process happens.
  6. Do you have the in-house capability to support a complex identity model, is your IT department skilled in this particular area.  Could your IT department recover from an outage or a system failure within a specified time frame.  Could you hold them to an SLA to support this system?
  7. What are the infrastructure requirements, do you have the bandwidth to spin up new servers?
  8. What is the desired user experience, would your user’s be comfortable with entering their login details and selecting “remember my password” at first login and then at subsequent password changes?
  9. How much of your user base work from the office on a regular basis, how many of them work from home or off site?

I am certain that there will be a host of other questions that need to be asked, the above are however a good starting point to engage the customer and get a conversation happening.

Let’s now move onto looking at the different identity models themselves in more detail.

Cloud Identity

Cloud Identity is the simplest method for providing user authentication in Office 365.  Users are completely managed and stored in the cloud.  Specifically, users are stored in the cloud in Windows Azure Active Directory and managed via the Office 365 Admin Portal or via PowerShell.  In this model users are only stored in the cloud and are not associated with any on-premises identity provider like an on-premises Active Directory.

AAD Connect (Directory Synchronization with Password Sync)

Directory Synchronization is used when you have an existing on-premises directory and you want those same users to have access to Office 365.  By installing AAD Connect, this tool will sync the user accounts up to Office 365 every 3 hours.  It eliminates the need to manually create and manage users in the cloud.  And with Password Sync, it also eliminates the need to manage user passwords in two different locations.  User identities and passwords are created and managed on-premises and synchronized to the cloud.

Federated Identity

With Federated Identity, also known as Single Sign-On, you authenticate to Office 365 using your on-premises identities.  This is commonly done with on-premises Active Directory using Active Directory Federation Services (ADFS).  ADFS requires deploying additional servers both internally and Internet-facing.   In this scenario, if for any reason users are unable to authenticate via their local AD, then users will not be able to authenticate to Office 365 and will not be able to access any of the Office 365 services.  It is therefore highly recommended that you deploy this particular scenario with high-availability / redundancy in mind.  With the release of Azure IaaS, we are seeing more customers beginning to consider and start hosting ADFS infrastructure within Azure to solve the high-availability issue.  This approach can also be beneficial when there are environmental considerations to keep in mind, for example we have a customer in Brisbane who lost access to their entire infrastructure during the 2011 floods.  By making the decision to position their ADFS servers in Azure they were able to mitigate this risk and could should an incident like this happen again continue servicing users.

If you want to know more about hosting ADFS infrastructure within Azure then I would highly recommend that you have a read of this white paper, take it to bed with you and a hot cup of jo. Office 365 Adapter: Deploying Office 365 Single Sign-On using Windows Azure. This content looks set to move soon so here is another link which also has some good reading points.  Understanding Office 365 identity and Azure Active Directory

So this gives you a good overview on each of the identity models, what’s interesting is that with each release of the directory synchronisation tool AAD Connect more features become available that begin to make synchronised identity a more appealing option to many businesses particular SMB clients.  The reason for this is largely due to the additional cost and complexity of deploying the required additional servers and high-availability that comes with a Federated Identity model.

There are a number of arguments to support both models, I believe that each model has its place and neither should be overlooked as a solution but perhaps what would be helpful would be to understand the different options from different perspectives, which is what the following aims to do.

The User Experience:

ADFS VS Synchronised

We can see in the table above which compares the user experiences that whilst ADFS does offer a more seamless sign on experience it does not differ greatly from directory synchronisation in applications like SharePoint online.  It is important to understand that whilst many tout ADFS as being SSO (Single Sign On) it is in fact not and the SSO experience is limited to the service offering in question.  For example SharePoint and CRM online are not single sign on aware applications, and users will still need to authenticate to these even when a domain joined workstation is connected to the internal network.

Skype for Business (aka. Lync) is really the only application where single sign on offers that seamless experience for the end user.  So, therefore one of the questions when considering ADFS should be,  “is the additional infrastructure, resources required and extra spend justified knowing that it is not a true SSO solution?”

Fun Fact:  Did you know that Skype for Business (aka. Lync) is what we call an active requestor application, it is aware of the ADFS server and talks directly to it to get a token to be used to connect to Office 365.  Outlook on the other hand is not and any token retrieval is handled under the hood by Office 365.

The branding is another hot topic, we would like to brand our sign on page, we can only do that with ADFS…. Mmmmh not so, once upon a time branding was only available to customers using Azure AD Premium or ADFS.   It is now a feature that is available for free and allows customers to brand their Office 365 sign on page with their corporate logo and images, you can even put a disclaimer or a hello at the bottom of the sign on page.  And get this, it’s available to you without ADFS.  Yes that is right you can brand the sign on page when using AAD Sync for all of your users.

I don’t know about you but in my experience most users won’t remember a seamless migration to the cloud nor will they have any knowledge of the fact that you may have picked up your entire organisation and moved them to exchange online.  What they will remember however is a new experience, something that is different from what they do everyday and this is something that be achieved easily and for free!

Moving on, there are some reasons that customers will still prefer ADFS and directory federation over AAD Sync with Password Sync.  Some of these reasons include:

  • ADFS can be configured such that users who are already logged on to a domain joined and connected machine do not require any password re-entry to sign in to Office 365.  (Arguably thought if you select remember my password the same can be said for AADSync with password sync.) This gives you true single sign-on since re-entry of the password is not required. With AADSync and password sync a user must still re-enter their password, although it will be the same password as the one that they use on-premises.
  • ADFS allows for client access filtering, which restricts access to Exchange Online to users based on their IP address, you can also limit when users are able to use ActiveSync, when they can access Outlook etc. using Client Access Policies.
  • ADFS will honour Active Directory configured login time restrictions for users.
  • ADFS has the ability for users to change their passwords whilst they are outside the corporate network. (Cloud Auth also does this, but that is another post for another day)
  • ADFS permits use of on-premises deployed multi-factor authentication products.

The Admins perspective

As many of you reading this blog post would know implementing ADFS using traditional methods means a lot of additional infrastructure, it also requires additional technical knowledge that not all in house IT departments have.  In addition there is a requirement to ensure that the ADFS infrastructure is highly available at all times, an outage of ADFS can be compared to that of a domain controller going down.  It is a serious outage and would result in users being unable to authenticate.

There is also a common misconception that by installing directory synchronization with password sync that if the ADFS servers were to go offline then users could still authenticate using password sync.  This is not the case, it would take approx. 3 hours to cut over to password sync and in that time the ADFS servers could have been brought back online.  This is a caveat that is worth bearing in mind when considering using ADFS.

Another frequent complaint is that the support desk is inundated with I’ve forgotten my password requests and I need users to be able to reset their passwords on the fly.  Did you know that this functionality is available for subscribers to Azure AD Premium using directory synchronisation with password right back.  Previously a feature that was limited to ADFS.

Azure AD Premium, you hear me say… mmmh that sounds expensive!  Well its pricey compared to the free version of course, however it is a lot cheaper than implementing ADFS and it may just offer some of the key services that your customer was previously considering ADFS for!

So what are some of the cool features?  Well there is:

  • Microsoft Identity manager or Forefront Identity Manager

A whole other topic!

  • Self Service Password Reset (write back to on premises)

Enabling your users to manage their own cloud Azure Active Directory or on-premises Active Directory passwords takes just a few simple steps.

  • Advanced Security Reports

You can use Azure Active Directory’s access and usage reports to gain visibility into the integrity and security of your organization’s directory. With this information, a directory admin can better determine where possible security risks may lie so that they can adequately plan to mitigate those risks.

In the full Azure Management Portal, reports are categorized in the following ways:

  • Anomaly reports – Contain sign in events that we found to be anomalous. Our goal is to make you aware of such activity and enable you to be able to make a determination about whether an event is suspicious.
  • Integrated Application report – Provides insights into how cloud applications are being used in your organization. Azure Active Directory offers integration with thousands of cloud applications.
  • Error reports – Indicate errors that may occur when provisioning accounts to external applications.
  • User-specific reports – Display device/sign in activity data for a specific user.
  • Activity logs – Contain a record of all audited events within the last 24 hours, last 7 days, or last 30 days, as well as group activity changes, and password reset and registration activity.
  • Multi Factor Authentication

Azure Multi-Factor Authentication helps safeguard access to data and applications while meeting user demand for a simple sign-in process. It provides additional security by requiring a second form of authentication and delivers strong authentication via a range of easy verification options:

  • phone call
  • text message
  • mobile app notification—allowing users to choose the method they prefer
  • mobile app verification code
  • 3rd party OATH tokens

If you want to learn more about Azure Active Directory Premium I would encourage you to take a look a session that a colleague of mine did, Mark Rhodes at the Ignite conference on the Gold Coast.

So in summary what are we saying…  We are saying that when it comes to choosing an identity model go with the simplest solution that suits your requirements.  You are not locked into any of these identity models and should you find that your requirements change down the track then going to ADFS from synchronised is a doable exercise as is going to a synchronised identity from ADFS.