All existing ADFS cmdlets use the lowercase version "Adfs" instead of "ADFS". Change our function to be consistent with the existing cmdlets

The following TODO item exists in the code:

function: Get-AdfsEvents

TODO: Add warning if environment is not Win2016

If the * was used for the -Server flag, but the environment is not Win2016 or higher, we should issue a warning, and use the default "LocalHost" for the -Server flag

Get-ADFSEvents cmdlet supports -FilePath to read logs from file, but no documentation exists

The first three functions in the file are repeated, and should be removed:

• Enable-ADFSAuditing

• Disable-ADFSAuditing

• Set-ADFSAuditingRemote

I found that it was turning off the Auditing settings. I had them on then ran the Enable-AdfsAuditing and they were turned off. I turned them on again and re-ran the script and they got turned off again.

I looked at the source code and found this code. It looks like to me that this is the code turning them off.
Invoke-Command -Session $Session -ScriptBlock {

    $OSVersion = gwmi win32_operatingsystem
    [int]$BuildNumber = $OSVersion.BuildNumber 

    if ( $BuildNumber -le 7601 )
    {
        Add-PsSnapin Microsoft.Adfs.Powershell -ErrorAction SilentlyContinue
    }else
    {
        Import-Module ADFS -ErrorAction SilentlyContinue
    }

    $SyncProps = Get-ADFSSyncProperties
    if ( $SyncProps.Role -ne 'SecondaryComputer' ) 
    {
        if ( $Enable )
        {
            Set-ADFSProperties -LogLevel  @( "FailureAudits", "SuccessAudits", "Warnings", "Verbose", "Errors", "Information")
            Set-ADFSProperties -AuditLevel Verbose
        }else{
            Set-ADFSProperties -LogLevel  @( "Warnings", "Errors", "Information" )
        }            
    }
} 

It seems they are using the Set-ADFSProperties -LogLevel to set these based on the parameter $Enabled. However $Enabled is a local variable which is not in scope for the script block that was executing trying to use the variable $Enabled. So if it not in scope it is not set and always is false and always just sets "Warnings", "Errors", "Information" which does not include the required "FailureAudits", "SuccessAudits".

I did some testing and was able to add the param declaration to the script block and then pass the local variable $Enabled to the script block using -ArgumentList . I tested and this seemed to do the trick to get the script block to execute as expected.

Invoke-Command -Session $Session -ScriptBlock { param($Enable)

    $OSVersion = gwmi win32_operatingsystem
    [int]$BuildNumber = $OSVersion.BuildNumber 

    if ( $BuildNumber -le 7601 )
    {
        Add-PsSnapin Microsoft.Adfs.Powershell -ErrorAction SilentlyContinue
    }else
    {
        Import-Module ADFS -ErrorAction SilentlyContinue
    }

    $SyncProps = Get-ADFSSyncProperties
    if ( $SyncProps.Role -ne 'SecondaryComputer' ) 
    {
        if ( $Enable )
        {
            Set-ADFSProperties -LogLevel  @( "FailureAudits", "SuccessAudits", "Warnings", "Verbose", "Errors", "Information")
            Set-ADFSProperties -AuditLevel Verbose
        }else{
            Set-ADFSProperties -LogLevel  @( "Warnings", "Errors", "Information" )
        }            
    }
} -ArgumentList $Enable

Also I noticed that the script has defined the functions like Enable-ADFSAuditing twice as well as others. Not sure why this is. I believe only the second definition is actually used since it is redefined the second time.

Thanks,
Paul

As we still have some older servers with adfs 2.0, the log for those is not "AD FS/Admin" and "AD FS Tracing/Debug" but "AD FS 2.0/Admin" and "AD FS 2.0 Tracing/Debug"

I was not able to list those logs using Get-EventLog so I was checking for existence via

if ($null -ne (Get-WinEvent -LogName "AD FS 2.0/Admin" -MaxEvents 1 -ErrorAction Ignore) ) {
    $Log = "AD FS 2.0/Admin"
}

Not sure this is correct practice, or how it should be correctly handled.

I can make PR for 2.0 support but need a guidance how to correctly check it :-)

The following TODO item exists in the code:

function: Process-EventsForAnalysis

TODO: Validate that all events have the same correlation ID, or no correlation ID

When we do the first pass through the events to build the hashtable of instance IDs, we should validate the correlation IDs

Put up a warning if we ever see an event with a different correlation ID (it's okay for it to have no correlation ID)

Fiddler captures HTTP requests and saves a set of files that can be parsed. Details on Fiddler serialization

The EventLog script can do the following steps to get the logs associated with the requests in a Fiddler trace:

1. Open "raw" folder in the Fiddler .saz file, find all <sessid#>_c.txt files
2. Locate the client requests to ADFS (parse the requests for URLs containing "adfs/ls")
3. Pull out the "client-request-id" query string parameter (might need to also look in _s.txt in the case where the server returns the ID, but the client never redirects with it)
4. Send the correlation ID to Get-ADFSEvents to collect the events associated with the current request
5. Repeat 1-4 for each independent correlation ID that gets discovered (as a Fiddler trace could contain multiple requests)

The current script should be altered to include a -FiddlerTrace parameter, which takes the filepath to the Fiddler trace.

An example execution would be:

Get-ADFSEvents -Logs Security, Admin, Debug -FiddlerTrace c:\fiddlerTrace.saz -Server *

There is a TODO item in the code:

function: Process-EventsForAnalysis

TODO: Use for error

We should include the 411 audit data in the timeline analysis to show that token validation failed