Tag Archive: ADFS

Troubleshooting Logs and Tools


SaRA tool to assess OUTLOOK client: https://diagnostics.outlook.com/#/

Also on CTRL + right click on OUTLOOK icon on the system tray! to get the connection status

Test connectivity from outside using: https://testconnectivity.microsoft.com/

Also check potential source of problems:

  • Check ADFS policies
  • Check set-CASmailbox – (post authentication) ; if POP or imap protocols are blocked for example
  • AzureAD Conditional access policies – (post authentication)
  • Authentication policies – in Exchange online (“new-authenticationpolicy”)- (pre authentication)
  • Client access rules – exchange online
  • Org level – IP blacklist – legacy authentication can be blocked
  • Org level – blacklist – EWS connections can be blocked
  • Org level – disable SMTP auth legacy – recommended
  • To protect from DDOS attack, enable ADFS extranet lockout protection and check audit log
  • IdFIX tool: https://www.microsoft.com/en-us/download/details.aspx?id=36832

Side-effect on Modern authentication:

If ADFS WAP and Internal servers are stopped ! What are the side-effects to access Outlook ??


  1. On clients with Modern authentication or ADAL! => thanks to the access tokens but we can limit the issues (valid 90 days!)
    1. If ADFS internal is restarted => Only => problem solved (no need WAP)
  2. But for OL 2010 or OL 2013 without ADAL, we are prompted to enter USER/PASSWORD (but without success)
    1. We need also the WAP working! And not only ADFS internal… to solve the problem on old clients not supporting ADAL


And also check logs:


In Exchange 2013, there are several logs in the logging folder. For Outlook clients one of the first logs to examine are the HTTP Proxy logs on CAS. The connection walk-through section shows the process that is used to connect to Exchange 2013. This complete process is logged in the HTTP Proxy log. Also, if it is possible, add Hosts file to the client for one specific CAS to reduce the number of logs.

The logs on CAS are located here by default: C:\Program Files\Microsoft\Exchange Server\V15\Logging\HttpProxy\RpcHttp

HTTP Proxy AutoDiscover Logs

Exchange 2013 has HTTP Proxy logs for AutoDiscover that are similar to the logs shown earlier that can be used to determine whether AutoDiscover is failing.

The logs on CAS are located here by default: C:\Program Files\Microsoft\Exchange Server\V15\Logging\HttpProxy\AutoDiscover

HTTP Error Logs

HTTP Error logs are failures that occur with HTTP.SYS before hitting IIS. However, not all errors for connections to web sites and app pools are seen in the httperr log. For example, if ASP.NET threw the error it may not be logged in the HTTP Error log. By default, HTTP error logs are located in C:\Windows\System32\LogFiles\HTTPERR. Information on the httperr log and codes can be found here.

IIS Logs

IIS logs can be used to review the connection for RPC/HTTP, MAPI/HTTP, EWS, OAB, and AutoDiscover. The full data for the MAPI/HTTP and RPC/HTTP is not always put in the IIS logs. Therefore, there is a possibility that the 200 connection successful may not be seen. IIS codes.

In Exchange 2013 IIS logs on the CAS should contain all user connections on port 443. IIS logs on the Mailbox server should only contain connections from the CAS server on port 444.

Most HTTP connections are first sent anonymously which results in a 401 challenge response. This response includes the authentication types available in the response header. The client should then try to connect again by using one of these authentication methods. Therefore, a 401 status found inside an IIS log does not necessarily indicate an error.

Note that an anonymous request is expected to show a 401 response. You can identify anonymous requests because the domain\username is not listed in the request.

RPC Client Access (RCA) Logs

The RCA logs can be used to find when a user has made a connection to their mailbox, or a connection to an alternate mailbox, errors that occur with the connection, and more information. RCA logs are located in the logging directory which is located at %ExchangeInstallPath%\Logging\RpcClientAccess. By default, these logs have a maximum size of 10MB and roll over when size limit is reached or at the end of the day (based on GMT), and the server keeps 1GB in the log directory.

Outlook ETL Logging (requires a support case with Microsoft to analyze the log) 

ETL logs are located in %temp%/Outlook Logging and are named Outlook-#####.ETL. The numbers are randomly generated by the system.

To enable Outlook logging

In the Outlook interface:

  • Open Outlook.
  • Click File, Options, Advanced.
  • Enable “Enable troubleshooting logging (requires restarting Outlook)”
  • Restart Outlook.

How to enable Outlook logging in the registry:

  • Browse to HKEY_CURRENT_USER\Software\Microsoft\Office\xx.0\Outlook\Options\Mail
  • DWORD: EnableLogging
  • Value: 1
  • Note: xx.0 is a placeholder for your version of Office. 15.0 = Office 2013, 14.0 = Office 2010

ExPerfwiz (Perfmon for Exchange)

You can use Perfmon for issues that you suspect are caused by performance. http://experfwiz.codeplex.com/

Exchange 2013 has daily performance logs that captures the majority of what is needed. These logs are by default located in C:\Program Files\Microsoft\Exchange Server\V15\Logging\Diagnostics\DailyPerformanceLogs

Log Parser Studio

Log Parser Studio is a GUI for Log Parser 2.2. LPS greatly reduces complexity when parsing logs. Additionally, it can parse many kinds of logs including IIS Logs, HTTPErr Logs, Event Logs (both live and EVT/EVTX/CSV), all Exchange protocol logs from 2003-2013, any text based logs, CSV logs and ExTRA traces that were converted to CSV logs. LPS can parse many GB of logs concurrently (we have tested with total log sizes of >60GB).

Blog with tips/how to about LPS: http://blogs.technet.com/b/karywa/

Exmon tool (aka Microsoft Exchange Server User Monitor)

We use this tool to get detailed information about client traffic.


Implement password hash synchronization:



Migrating from federated authentication (ADFS) to password hash synchronization:



To test SSL/TLS and much more you can use the free online tool from Qualys: https://www.ssllabs.com/ssltest/index.html

Third-party Tool: https://www.nartac.com/Products/IISCrypto/Download


Links related to TLS which I have consulted: Solving the TLS problem ==> https://www.microsoft.com/en-us/download/details.aspx?id=55266

How to restrict the use of certain cryptographic algorithms and protocols in Schannel.dll ==> https://support.microsoft.com/en-us/help/245030/how-to-restrict-the-use-of-certain-cryptographic-algorithms-and-protoc

TLS/SSL Settings ==> https://technet.microsoft.com/en-us/library/dn786418(v=ws.11).aspx#BKMK_SchannelTR_TLS10

Managing SSL/TLS Protocols and Cipher Suites for ADFS:




Two ways to integrate/federate applications with Azure AD:

Azure marketplace:


check if the application exists:

The Microsoft Azure Marketplace is an online store that offers applications and services either built on or designed to integrate with Microsoft’s Azure public cloud.

Else, how to configure single sign-on to applications that are not in the Azure Active Directory application gallery: https://docs.microsoft.com/en-us/azure/active-directory/active-directory-saas-custom-apps

Authentication scenarios for Azure AD:


Applications integrated with Azure: the access via https://account.activedirectory.windowsazure.com/applications/default.aspx

Integrating applications with Azure AD: https://docs.microsoft.com/fr-fr/azure/active-directory/develop/active-directory-integrating-applications


Identity hybrid ports and protocols:



Azure app gallery:


If not pre-packaged in Azure marketplace: Any app that supports SAML 2.0 can be integrated directly with an Azure AD tenant using these instructions to add a custom application.

Provide credentials for a test tenant or account with your application that can be used by the Azure AD team to test the integration.

Provide the SAML Sign-On URL, Issuer URL (entity ID), and Reply URL (assertion consumer service) values for your application, as described here. If you typically provide these values as part of a SAML metadata file, then please send that as well.

Provide a brief description of how to configure Azure AD as an identity provider in your application using SAML 2.0. If your application supports configuring Azure AD as an identity provider through a self-service administrative portal, then please ensure the credentials provided above include the ability to set this up.

Configuring single sign-on to applications that are not in the Azure Active Directory application gallery:



Sign On URL (SP-initiated only) – Where the user goes to sign-in to this application. If the application is configured to perform service provider-initiated single sign on, then when a user navigates to this URL, the service provider will do the necessary redirection to Azure AD to authenticate and log on the user in. If this field is populated, then Azure AD will use this URL to launch the application from Office 365 and the Azure AD Access Panel. If this field is ommited, then Azure AD will instead perform identity provider -initiated sign on when the app is launched from Office 365, the Azure AD Access Panel, or from the Azure AD single sign-on URL (copiable from the Dashboard tab).

Issuer URL – The issuer URL should uniquely identify the application for which single sign on is being configured. This is the value that Azure AD sends back to application as the Audience parameter of the SAML token, and the application is expected to validate it. This value also appears as the Entity ID in any SAML metadata provided by the application. Check the application’s SAML documentation for details on what it’s Entity ID or Audience value is. Below is an example of how the Audience URL appears in the SAML token returned to the application

Reply URL – The reply URL is where the application expects to receive the SAML token. This is also referred to as the Assertion Consumer Service (ACS) URL.






Monitoring ADFS and the AAD Connect Sync Engine using AAD connect health:


To test connectivity:

Test-AzureADConnectHealthConnectivity [-Role] {Adfs | Sync | Adds | HybridReporting} [[-ShowResult]]

The role parameter currently takes the following values:


Test-AzureADConnectHealthConnectivity -Role ADFS -Showresult

The role parameter currently takes the following values:

  • ADFS
  • Sync
  • ADDS


AD health agent Errors:

Test Authentication Request (Synthetic Transaction) failed to obtain a token



To check and to solve this issue:

PS C:\Program Files\Azure Ad Connect Health Adfs Agent\Diagnostics> import-module .\ADFSDiagnostics.psm1
PS C:\Program Files\Azure Ad Connect Health Adfs Agent\Diagnostics> Test-AdfsServerHealth | ft name,result -autosize

Name Result
—- ——
IsAdfsRunning Pass
IsWidRunning Pass

TestSSLUsingADFSPort NotRun
TestSSLCertSubjectContainsADFSFarmName NotRun
TestAdfsAuditPolicyEnabled Pass
TestAdfsRequestToken Fail                          <===== error
CheckOffice365Endpoints NotRun
TestADFSO365RelyingParty NotRun
TestNtlmOnlySupportedClientAtProxyEnabled NotRun



on c:\windows\system32\hosts

add the line:   adfs.mydomain.com

retry the Test-ADFSserverhealth

TestSSLUsingADFSPort NotRun
TestSSLCertSubjectContainsADFSFarmName NotRun
TestAdfsAuditPolicyEnabled Pass
TestAdfsRequestToken Pass
CheckOffice365Endpoints NotRun
TestADFSO365RelyingParty NotRun
TestNtlmOnlySupportedClientAtProxyEnabled NotRun


An introduction to claims:


To test ADFS, create your own test web app:




When you deploy AD FS 2.x out of the box and install in a default setup, it will make use of a Windows Internal Database (WID)

The default setup for the WID database is that the Primary AD FS server has a read/write copy and the Secondary server(s) have a read only copy that is synchronizes from the Primary (up to 5 AD FS servers in a single farm maximum!).

If you need to move the Primary role to another server, for whatever reason, you can move the role with a simple PowerShell command.

Run this PowerShell command on the Secondary AD FS server that you want to make Primary AD FS server.

Set-AdfsSyncProperties -Role PrimaryComputer

This will now move the Primary role to the server where the command was run. If you have two or more Secondary servers in the farm you need to update the other Secondary servers.

Run this PowerShell command on the other Secondary AD FS server(s) so that they now sync with the new AD FS Primary server

Set-AdfsSyncProperties -Role SecondaryComputer -PrimaryComputerName <FQDN_ADFS_Primary>

Understanding ADFS and Federation by a example:


Comparing SAML, WS-FED and OAuth: https://blogs.technet.microsoft.com/askpfeplat/2014/11/02/adfs-deep-dive-comparing-ws-fed-saml-and-oauth/

ADFS 2.0:

If you need to configure ADFS v. 2.0 for use in Claims-based authentication scenarios, interestingly enough, ADFS v. 2.0 DOES NOT come pre-installed with Windows Server 2008 R2–even after the release of SP1. Therefore, you will not be able to install ADFS as part of the Server Roles that come with Server Manager.  Instead, you will have to separately download the release of ADFS v. 2.0 and install and configure it separately.
You can download the release of ADFS v. 2.0 from here: http://www.microsoft.com/download/en/details.aspx?id=10909
There is also an update rollup for ADFS v. 2.0 available which can be downloaded from here: http://support.microsoft.com/kb/2607496

In addition, this is an excellent article on configuring ADFS v2.0:


and http://www.theidentityguy.com/articles/tag/adfs-v2

Example of implementation with a cloud service: http://support.druva.com/entries/21437659-How-to-install-and-Configure-Active-Directory-Federation-Services-for-Druva-inSync-Cloud-SAML-integr

ADFS design and deployment:





Planning Federation Server Proxy Placement:     http://technet.microsoft.com/en-us/library/dd807130%28WS.10%29.aspx

Certificate Requirements for Federation Server Proxies:       http://technet.microsoft.com/en-us/library/dd807054%28WS.10%29.aspx

AD FS 2.0: How to Replace the SSL, Service Communications, Token-Signing, and Token-Decrypting Certificates:      http://social.technet.microsoft.com/wiki/contents/articles/2554.aspx

Troubleshooting federation server proxy problems with AD FS 2.0:       http://technet.microsoft.com/en-us/library/adfs2-troubleshooting-federation-server-proxy-problems%28WS.10%29.aspx

AD FS 2.0: Guidance for Selecting and Utilizing a Federation Service Name:      http://social.technet.microsoft.com/wiki/contents/articles/4177.aspx

AD FS 2.0 Proxy Management:      http://blogs.msdn.com/b/card/archive/2010/06/02/ad-fs-2-0-proxy-management.aspx

AD FS 2.0 Cmdlets in Windows PowerShell:      http://technet.microsoft.com/en-us/library/ee892329.aspx

Other web resources about ADFS:






A definition in French:

“Les services ADFS sont des services fédérées de gestion des identités (SSO, Single sign-On). A.D.F.Sidentifie, authentifie, et autorise lesutilisateurs à accéder à des extranets, améliore le déploiement AD(Active Directory) sur troispoints :

  • Extranet B2C
  • Fédérations interentreprises (multi-forêts)
  • Fédérations Internet B2B

La fédération des identités permet à deux entreprises et ce de manière sécurisée de partager les informations d’identité d’Active Directory d’un utilisateur, créer une meilleure efficacité opérationnelle. AFDS permet une gestion de fédération par les jetons de sécurité signés via la distribution de clés basés sur les certificats, la définition des types de jeton/claim et de l’espace de noms partagés pour les royaumes de sécurité fédérés. “