Enabling AD FS Security Auditing 📡 and Shipping Event Logs to Microsoft Sentinel 🛡️

 

Microsoft's identity solutions span on-premises and cloud-based capabilities. These solutions create a common user identity for authentication and authorization to all resources, regardless of location. We call this hybrid identity and one of the authentication methods available is federation with Active Directory Services (AD FS). 

Active Directory Federation Service (AD FS) enables Federated Identity and Access Management by securely sharing digital identity and entitlements rights across security and enterprise boundaries. AD FS extends the ability to use single sign-on functionality that is available within a single security or enterprise boundary to Internet-facing applications to enable customers, partners, and suppliers a streamlined user experience while accessing the web-based applications of an organization. 

In this post, I will show you how to enable AD FS security auditing (based on Microsoft documentation) and how to collect and ship AD FS event logs to a Microsoft Sentinel instance.

Enable AD FS Security Auditing 

Even though AD FS provides two primary logs such as the Admin Log and Trace Log for troubleshooting purposes, organizations can enable additional built-in auditing on their AD FS servers which is then consumed via the “Security” event channel and accessible under the "AD FS Auditing” event provider.

 

Authorize the AD FS Service Account to Write Security Logs 

The NT Service\adfssrv account must be added to the Generate Security Audits local policy to allow the service account to add entries to the security log. 

 

This policy can be found under the User Rights Assignment policy settings and accessed by navigating to Control Panel > System and Security > Administrative Tools > Local Security Policy > Security Settings > Local Policies > User Rights Assignment. Make sure the AD FS service account is there along with the local and network service accounts as shown below: 

 

 

Enable “Application Generated” Audit Policy 

The Application Generated audit policy subcategory allows you to audit applications that generate events using the Windows Auditing application programming interfaces (APIs). Applications designed to use the Windows Auditing API use this subcategory to log auditing events related to their function. 

 

AD FS requires this subcategory to be enabled to write events to the security log. This can be accomplished by opening a command prompt, on the AD FS server, with elevated privileges and running the following command:

 

 

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

 

 

Set AD FS Audit Level 

Even though the AD FS service account is allowed to write to the security log and the “Application Generated” audit policy is enabled, the number of events produced by the AD FS service is controlled by the AD FS Audit Level setting. By default, in Windows Server 2016+, the AD FS Audit Level is set to Basic.

 

The table below shows the available auditing levels, and how to enable them with the PowerShell Set-AdfsProperties cmdlet:

 

Audit Level	PowerShell syntax	Description
None	Set-AdfsProperties -AuditLevel None	Auditing is disabled and no events will be logged.
Basic (Default)	Set-AdfsProperties -AuditLevel Basic	No more than 5 events will be logged for a single request
Verbose	Set-AdfsProperties -AuditLevel Verbose	All events will be logged. This will log a significant amount of information per request.

 

The table below describes the events that are generated when the audit level is set to Basic:

 

Event Type	Event ID	Description
Fresh Credential Validation Success	1202	A request where fresh credentials are validated successfully by the Federation Service. This includes WS-Trust, WS-Federation, SAML-P (first leg to generate SSO) and OAuth Authorize Endpoints.
Fresh Credential Validation Error	1203	A request where fresh credential validation failed on the Federation Service. This includes WS-Trust, WS-Fed, SAML-P (first leg to generate SSO) and OAuth Authorize Endpoints.
Application Token Success	1200	A request where a security token is issued successfully by the Federation Service. For WS-Federation, SAML-P this is logged when the request is processed with the SSO artifact. (such as the SSO cookie).
Application Token Failure	1201	A request where security token issuance failed on the Federation Service. For WS-Federation, SAML-P this is logged when the request was processed with the SSO artifact. (such as the SSO cookie).
Password Change Request Success	1204	A transaction where the password change request was successfully processed by the Federation Service.
Password Change Request Error	1205	A transaction where the password change request failed to be processed by the Federation Service.
Sign Out Success	1206	Describes a successful sign-out request.
Sign Out Failure	1207	Describes a failed sign-out request.

 

The table below shows some of the additional events that are generated when the audit level is set to Verbose:
 

Event Type	Event ID	Description
Successful Token Issuance	299	A token was successfully issued for the relying party '%s’.  See audit 500 with the same Instance ID for issued claims.  See audit 501 with the same Instance ID for caller identity. See audit 502 with the same Instance ID for OnBehalfOf identity, if any. See audit 503 with the same Instance ID for ActAs identity, if any.
Federation Service Configuration	307	The Federation service configuration was changed.
AD FS HTTP Requests	403	An HTTP request was received. Information such as client IP, client request id, user agent and date.
AD FS HTTP Requests	404	An HTTP response was dispatched.
AD FS HTTP Requests	410	Following request context headers present.
Successful Token authentication	412	A token of type '%s' for relying party '%s' was successfully authenticated.  See audit 501 with the same Instance ID for caller identity.
Successful Token Issuance	500	Additional context such as “Issued Claims” is provided by this event during the token issuance process.
Successful Token Authentication	501	Additional context such as “Caller Identity” is provided by this event during the token authentication event.
Additional Information	510	Additional information about events such as federation service configuration changes (307), HTTP requests received (403), HTTP requests dispatched (404), etc.

 

Set AD FS Audit Log Types 

Even though the “Application Generated” audit policy is enabled to cover success and failure auditing events, this does not actually set the type of events the federation service records in the security event log. This setting must be defined in the configuration of the federation service.

This configuration setting can be set via the AD FS Management snap-in. This can be accessed by navigating to Control Panel > System and Security > Administrative Tools > AD FS Management. Then, in the "Actions" pane, one could use the “Edit Federation Service Properties” option and select the “Events” tab as shown in the image below: 

 

 

Organizations can also use the PowerShell Set-AdfsProperties cmdlet, on their AD FS server, to set the AD FS LogLevel property as shown below:

 

 

Set-AdfsProperties -LogLevel Errors, FailureAudits, Information, SuccessAudits, Warnings 

 

 

Explore AD FS Security Auditing Logs 

Once the AD FS security auditing is enabled and configured, events will start showing in the “Security" Windows logs. Organizations could then use the following XPath query to filter events and only display logs from the “AD FS Auditing” event provider:

 

 

<QueryList>
  <Query Id="0" Path="Security">
    <Select Path="Security">*[System[Provider[@Name='AD FS Auditing']]]</Select>
  </Query>
</QueryList> 

 

This XPath query can be used in the Event Viewer of the AD FS server as shown in the image below to filter events:

 

 

You can also use the XPath query via PowerShell, by running the following commands:

 

 

$XPath = "*[System[Provider[@Name='AD FS Auditing']]]" 
Get-WinEvent –LogName 'Security' -FilterXPath $XPath 

 

 

Shipping AD FS Security Logs to Microsoft Sentinel 

Currently, there are two data connectors available in Microsoft Sentinel that allows the ingestion of event logs from a Windows endpoint: 

• Windows Security Events via AMA 
• Windows Forwarded Events (Preview) 

Both data connectors use Azure Monitor Agent-based connections as their main data collection method and Data Collection Rules (DCR) to specify what data should be collected and shipped to a Microsoft Sentinel instance. It is important to mention that to collect events from any system that is not an Azure virtual machine, the system must have Azure Arc installed and enabled before you enable the Azure Monitor Agent-based connector. 

 

Windows Security Events via AMA - DCR

The following Azure Resource Manager (ARM) template can be used to create a DCR and collect windows security events from the AD FS Auditing event provider.

 

 

{
    "type": "microsoft.insights/dataCollectionRules",
    "apiVersion": "2021-04-01",
    "name": "winSecurityEventsDCRName",
    "location": "<LOCATION>",
    "tags": {
        "createdBy": "Sentinel"
    },
    "properties": {
        "dataSources": {
            "windowsEventLogs": [
                {
                    "name": "eventLogsDataSource",
                    "scheduledTransferPeriod": "PT5M",
                    "streams": [
                        "Microsoft-SecurityEvent"
                    ],
                    "xPathQueries": [
                        "Security!*[System[Provider[@Name='AD FS Auditing']]] "
                    ]
                }
            ]
        },
        "destinations": {
            "logAnalytics": [
                {
                    "name": "WindowsEvents",
                    "workspaceId": "<MS SENTINEL WORKSPACE ID>",
                    "workspaceResourceId": "<MS SENTINEL WORKSPACE RESOURCE ID>"
                }
            ]
        },
        "dataFlows": [
            {
                "streams": [
                    "Microsoft-SecurityEvent"
                ],
                "destinations": [
                    "WindowsEvents"
                ]
            }
        ]
    }
}

 

 

Windows Forwarded Events (Preview) - DCR

The following Azure Resource Manager (ARM) template can also be used to create a DCR and collect windows security events from the AD FS Auditing event provider. This DCR is usually used to collect more than just Security events. Here we can collect Application, System, PowerShell, etc.

 

 

{
    "type": "microsoft.insights/dataCollectionRules",
    "apiVersion": "2021-04-01",
    "name": "otherWinEventsDCRName",
    "location": "<LOCATION>",
    "kind": "Windows",
    "properties": {
        "dataSources": {
            "windowsEventLogs": [
                {
                    "name": "eventLogsDataSource",
                    "scheduledTransferPeriod": "PT5M",
                    "streams": [
                        "Microsoft-WindowsEvent"
                    ],
                    "xPathQueries": [
                        "Security!*[System[Provider[@Name='AD FS Auditing']]] "
                    ]
                }
            ]
        },
        "destinations": {
            "logAnalytics": [
                {
                    "name": "WindowsOtherEvents",
                    "workspaceId": "<MS SENTINEL WORKSPACE ID>",
                    "workspaceResourceId": "<MS SENTINEL WORKSPACE RESOURCE ID>"
                }
            ]
        },
        "dataFlows": [
            {
                "streams": [
                    "Microsoft-WindowsEvent"
                ],
                "destinations": [
                    "WindowsOtherEvents"
                ]
            }
        ]
    }
}

 

 

Data Collection Rule Associations

Whether the Windows Security Events via AMA or Windows Forwarded Events (Preview) data connector is used, a Data Collection Rule Association (DCRA) must be created to connect the windows endpoint with the DCR and let the Azure Monitor Agent (AMA) installed collect specific events.

 

The following ARM template can be used to create a DCRA:

 

 

{
    "name": "<COMPUTERNAME/microsoft.insights/<DCR NAME>",
    "type": "Microsoft.Compute/virtualMachines/providers/dataCollectionRuleAssociations",
    "apiVersion": "2019-11-01-preview",
    "location": "<LOCATION",
    "properties": {
        "description": "Association of data collection rule. Deleting this association will break the data collection for this virtual machine.",
        "dataCollectionRuleId": "<DCR ID"
    }
}

 

 

Exploring AD FS Security Events in Microsoft Sentinel 

Once the DCR and DCRA are created, you will see events flowing to the Log Analytics workspace of the Microsoft Sentinel.

 

Events ingested via the Windows Security Events via AMA send the data to the SecurityEvent table. Use the following KQL query to explore events:

 

 

SecurityEvent 
| where TimeGenerated >= ago(1d) 
| where EventSourceName == 'AD FS Auditing'

 

 

Events ingested via the Windows Forwarded Events (Preview) send data to the WindowsEvent table. Use the following KQL query to explore events:

 

 

WindowsEvent
| where TimeGenerated >= ago(1d)
| where Provider == 'AD FS Auditing'

 

 

Deploying an AD FS Lab Environment on Demand 

Finally, if you want to automate the deployment of a lab environment in Azure that has an AD FS server set up, AD FS security auditing enabled, a Microsoft Sentinel instance deployed and a DCR and DCRA configured to collect AD FS logs, you can use the following ARM template from the Microsoft Sentinel To-Go! Project. 

 

Template: https://github.com/OTRF/Microsoft-Sentinel2Go/tree/master/grocery-list/Win10-AD-ADFS 

 

References 

• https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/troubleshooting/ad-fs-tshoot-logging 
• Testing the New Version of the Windows Security Events Connector with Azure Sentinel To-Go! - Microsoft Tech Community 
• Microsoft.Insights/dataCollectionRules - Bicep, ARM template & Terraform AzAPI reference | Microsoft Docs