HOWTO: Enable Auditing and Logging for AD FS Servers and the AD FS Farm

This entry is part 7 of 10 in the series Hardening Hybrid Identity

Hybrid Identity

Most Microsoft-based Hybrid Identity implementations use Active Directory Federation Services (AD FS) Servers, Web Application Proxies and Azure AD Connect installations. In this series, labeled Hardening Hybrid Identity, we’re looking at hardening these implementations, using recommended practices.

In this part of the series, we’ll look at auditing and logging settings on AD FS Servers.

Note:
This blogpost assumes you’re running AD FS Servers as domain-joined Windows Server 2016 Server Core installations. The same information applies to AD FS Servers running Windows Server 2016 with Desktop Experience (Full).

 

Why enable auditing on AD FS Servers

Auditing and logging allow for examining the processes and services running on Windows Server installations. They allow for organizations to check the default behavior and get notified of unauthorized changes and requests.

Reasons why

Active Directory Federation Services (AD FS) servers are typically placed on the internal network, close to Active Directory Domain Controllers. In a typical Hybrid Identity Implementation, the AD FS Servers is published using Web Application Proxies.

It is imperative that events are logged and that AD FS Servers are audited, as their capabilities can be misused in quite the same way Domain Controllers can be misused. As AD FS Servers are connected to the Internet (through Web Application Proxies), this functionality is available from the Internet as well.

Possible negative impact (What could go wrong?)

When logging and auditing information from AD FS servers is incomplete, an organization might not have the necessary information to retrace steps of misuse and sources of origin of this misuse.

When logging and auditing information from AD FS servers is overcomplete, an organization may be swamped in irrelevant information that is not useful and may hinder the effectiveness of the admins who want to hunt misuse.

 

Getting ready

To enable auditing and logging on AD FS servers, make sure to meet the following requirements:

Information requirements

Make a risk analysis of the ways Active Directory Federation Services (AD FS) can be misused.

AD FS Server Auditing level

Based on the risk to mitigate, determine the level of auditing information that is needed. for AD FS in Windows Server 2016, there are three levels:

  1. None; This auditing level results in zero events to be logged.
  2. Basic; This is the default auditing level in AD FS in Windows Server 2016. No more than 5 events will be logged for a single request.
  3. Verbose; At this auditing level all events are logged. This will log a significant amount of information per request.

AD FS Farm Logging Level

The events from the auditing levels are independent of the default options on the Events tab of the Federation Service properties, that are AD FS Farm-wide, as shown below:

Default options for the types of events or audits that this Federation Service will record in the event log, on the Events tab of the Federation Service Properties (GUI not available on Server Core installations of Windows Server, running AD FS)

It is considered to be a recommended practice to enable Success audits and Failure audits on the AD FS Farm. For this to work, auditing should also be enabled using the Local Security Policy MMC Snap-in.

Note:
Both the above user interface to enable types of events nor the Local Security Policy MMC Snap-in are available on Server Core installations of Windows Server 2016. Therefore, we will enable these settings through Windows PowerShell.

System requirements

Make sure the AD FS Servers are installed with the latest cumulative Windows Updates.

Privilege requirements

AD FS Server Auditing level

For making changes to the AD FS auditing level, make sure to sign in with an account that has privileges to manage every individual AD FS Server in the AD FS Farm. The AD FS auditing level is a per-AD FS server setting and needs to be configured on each AD FS server. This also holds true for configuring the auditing policy.

AD FS Farm Logging Level

For making changes to the AD FS logging evens, make sure to sign in with an account that has privileges to manage the AD FS Farm. In case of Windows Internal Database (WID) as the storage method for the AD FS Configuration database, sign in with an account that has local administrator privilege on the primary AD FS Server.

Who to communicate to

As the AD FS servers operate as part of a chain, notify all stakeholders in the chain. This means sending a heads-up to the load balancer guys and gals, the networking guys and gals, the rest of the Active Directory team and the teams that are responsible for Azure AD, Office 365 and cloud applications. It’s also a good idea to talk to the people responsible for backups, restores and disaster recovery.

When your organization utilizes a Security Incident and Event Monitoring (SIEM), Security Orchestration Automation and Response (SOAR) and/or a centralized log collection solution, talk to the people responsible for it. When AD FS is not yet onboarded, get it onboarded and perform the above risk analysis with them. When AD FS is already onboarded talk through the implications of switching between the auditing levels and enabling or disabling logging of events.

 

Enabling AD FS Auditing

How to check the AD FS auditing level

To check the current AD FS auditing level run the following line of Windows PowerShell:

Get-AdfsProperties | Select Auditlevel

 

How to enable the AD FS verbose auditing level

To enable AD FS verbose auditing, run the following lines of Windows PowerShell in an elevated Windows PowerShell window or PowerShell ISE:

Set-AdfsProperties -Auditlevel verbose

Restart-Service -Name adfssrv

Repeat the above line of Windows PowerShell on each AD FS server in the AD FS Farm.

 

How to enable the auditing policy

To enable the Auditing Policy, run the following command line in an elevated Command Prompt (cmd.exe) window:

auditpol.exe /set /subcategory:”Application Generated”
/failure:enable /success:enable

Repeat the above line of Windows PowerShell on each AD FS server in the AD FS Farm.

 

Enabling AD FS Logging

How to check the AD FS auditing level

To check the current AD FS auditing level run the following line of Windows PowerShell:

(Get-AdfsProperties).Loglevel

 

How to enable logging of successes and failures

To enable AD FS logging of Success and Failure events, run the following line of Windows PowerShell in an elevated Windows PowerShell window or PowerShell ISE on one of the AD FS Servers in the AD FS Farm:

Note:
In case of Windows Internal Database (WID) as the storage method for the AD FS Configuration database, run these lines of Windows PowerShell on the primary AD FS Server.

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

 

Testing Auditing and Logging

After enabling the required levels of auditing and logging,  it’s time to test them . Everyone should sign off (not literally, unless that’s procedure) on the correct working of the AD FS servers. Does authentication to cloud applications still work and does it result in the corresponding information? Does the SIEM, SOAR and/or centralized log collection solution handle the traffic?

Helpful tools

On its ADFSHelp site, Microsoft lists the events for AD FS Servers running Windows Server 2012 R2, Windows Server 2016 and Windows Server 2019. For Windows Server 2016, there are currently 327 events listed.

Microsoft’s AD FS Events Module on GitHub can be useful to gather related AD FS events from the security, admin, and debug logs, across multiple servers. This tool allows the user to reconstruct the HTTP request/response headers from the AD FS logs when you don’t have a SIEM, SOAR and/or centralized log collection solution.

Rolling back hardening

To roll back hardening of the endpoints to Windows Server 2016’s default state, run the following two lines of Windows PowerShell in an elevated PowerShell or PowerShell ISE window:

Set-AdfsProperties -LogLevel ((Get-AdfsProperties).LogLevel | `
Where-Object {$_ -notmatch ‘Audits‘})

Set-AdfsProperties -Auditlevel basic

Additionally, run the following command line in an elevated Command Prompt (cmd.exe) window:

auditpol.exe /set /subcategory:”Application Generated” /failure:disable /success:disable

 

Concluding

Enable auditing on AD FS Servers and let these events flow into the same SIEM, SOAR and/or centralized log collection solution as your Domain Controller’s events to gain a monitoring solution for all authentication traffic both on-premises and in the cloud.

Further reading

Auditing Enhancements to AD FS in Windows Server 2016
AD FS Troubleshooting – Auditing Events and Logging
Troubleshooting ADFS: Enabling additional logging 

Series Navigation

<< HOWTO: Disable unnecessary AD FS endpointsHOWTO: Handle Time synchronization on non-domain-joined Web Application Proxies >>

leave your comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.