Support for ADFS 2.0

[madhavpatel6]

Issue by rattuscz Tuesday May 22, 2018 at 13:36 GMT Originally opened as https://github.com/Microsoft/adfsLogTools/issues/16

---

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 :-)

[madhavpatel6]

Comment by bongiovimatthew-microsoft Tuesday May 22, 2018 at 17:04 GMT

---

@rattuscz, thanks for catching this, this is a great find.

I think probably the best way would be to list the providers that match 'AD FS', and then get the log link from what gets returned. That should work for both modern AD FS and 2.0

PS C:\> Get-WinEvent -ListProvider '*AD FS*'

Name     : AD FS Auditing
LogLinks : {Security}
Opcodes  : {}
Tasks    : {}

Name     : AD FS Tracing
LogLinks : {AD FS Tracing/Debug}
Opcodes  : {}
Tasks    : {}

Name     : AD FS
LogLinks : {AD FS/Admin}
Opcodes  : {}
Tasks    : {}

[madhavpatel6]

Comment by rattuscz Wednesday May 23, 2018 at 04:58 GMT

---

Oki that seems great, will try to get it in code, but that will mean probably to ditch the $script log constants

[madhavpatel6]

Comment by bongiovimatthew-microsoft Wednesday May 23, 2018 at 05:03 GMT

---

It might make sense to change the $script log constant to be an array of known strings for each log, and then check the output of -ListProvider against that list, that way you don't accidentally grab the wrong log on a machine that happens to have a log that contains "AD FS". The list of known strings would then contain both the current string const, and the 2.0 versions.