GithubHelp home page GithubHelp logo

adfstoolbox's Introduction

AD FS Toolbox

Notice: This repository is no longer being actively maintained. ADFSToolbox is still being actively worked on and can be installed from here.

Details

As of 7/31/2019, we have migrated the diagnosticsModule from PowerShell to C# into a new repository. As a consequence of this change, the new repository is not publically available; however, we will still be making improvements to ADFSToolbox and releasing them here. If you feel that we should invest the time to make the new repository open source, please direct your feedback to here or respond to the issue here. This repository will remain public, but will not be actively maintained.

Notice: Additionally, the diagnostics module will no longer support AD FS 2.1 or lower. If you need to target AD FS versions 2.1 or lower please install version 1.0.13 of ADFSToolbox.

Overview

This repository contains tools for helping you manage your AD FS farm. The following tools are currently included:

  1. Diagnostics Module - PowerShell module to do basic health checks against AD FS. Determines if AD FS is in a healthy state.

  2. Events Module - PowerShell module provides tools for gathering related ADFS events from the security, admin, and debug logs, across multiple servers.

  3. Service Account Module - PowerShell module to change the AD FS service account.

  4. WID Sync Module - PowerShell module to force a full WID sync to an AD FS secondary node

Getting Started

Install through PowerShell Gallery (Recommended) for AD FS 3.0

  1. Install the PowerShell Module

    In a PowerShell window, run the following:

    Install-Module -Name ADFSToolbox -Force

  2. Import the PowerShell Module

    In a PowerShell window, run the following:

    Import-Module ADFSToolbox -Force

  3. Run the cmdlet of your choice, with the required parameters (see individual tools for details)

Install manually for AD FS 3.0

  1. Launch an elevated PowerShell window on a machine that has internet access.

  2. Install the PowerShell Module

    Install-Module -Name ADFSToolbox -Force

  3. Copy the ADFSToolbox folder located %SYSTEMDRIVE%\Program Files\WindowsPowerShell\Modules\ on your local machine to the same location on your AD FS or WAP machine.

  4. Launch an elevated PowerShell window on your AD FS machine and run the following cmdlet to import the module.

    Import-Module -Name ADFSToolbox -Force

Install through PowerShell Gallery (Recommended) for AD FS 2.1 or lower

  1. Install the PowerShell Module

    In a PowerShell window, run the following:

    Install-Module -Name ADFSToolbox -RequiredVersion 1.0.13 -Force

  2. Import the PowerShell Module

    In a PowerShell window, run the following:

    Import-Module ADFSToolbox -RequiredVersion 1.0.13 -Force

  3. Run the cmdlet of your choice, with the required parameters (see individual tools for details)

Install manually for AD FS 2.1 or lower

  1. Launch an elevated PowerShell window on a machine that has internet access.

  2. Install the PowerShell Module

    Install-Module -Name ADFSToolbox -RequiredVersion 1.0.13 -Force

  3. Copy the ADFSToolbox folder located %SYSTEMDRIVE%\Program Files\WindowsPowerShell\Modules\ on your local machine to the same location on your AD FS or WAP machine.

  4. Launch an elevated PowerShell window on your AD FS machine and run the following cmdlet to import the module.

    Import-Module -Name ADFSToolbox -RequiredVersion 1.0.13 -Force

Contributing

This project welcomes contributions and suggestions. Most contributions require you to agree to a Contributor License Agreement (CLA) declaring that you have the right to, and actually do, grant us the rights to use your contribution. For details, visit https://cla.microsoft.com.

When you submit a pull request, a CLA-bot will automatically determine whether you need to provide a CLA and decorate the PR appropriately (e.g., label, comment). Simply follow the instructions provided by the bot. You will only need to do this once across all repos using our CLA.

This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact [email protected] with any additional questions or comments.

adfstoolbox's People

Contributors

anandyadavmsft avatar avsharapov avatar bongiovimatthew-microsoft avatar dguthal avatar ehunter1878 avatar jodyhendrix avatar madhavpatel6 avatar microsoft-github-policy-service[bot] avatar microsoftopensource avatar msalim avatar msftgits avatar rattuscz avatar reed1995 avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

adfstoolbox's Issues

Non Signed Script

When i try to run this script it says it is not signed, on customers who set thier policy to allow only RemoteSigned scripts this is an issue. Am i doing something wrong or should we expect scripts to be signed especially when they are publicised by microsoft?

Feature: Collect logs for requests in Fiddler trace

Issue by bongiovimatthew-microsoft
Wednesday Feb 07, 2018 at 23:46 GMT
Originally opened as microsoft/adfsLogTools#9


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 *

Support for ADFS 2.0

Issue by rattuscz
Tuesday May 22, 2018 at 13:36 GMT
Originally opened as microsoft/adfsLogTools#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 :-)

Some commands not available

After installing the module on a Windows Server 2019 running ADFS, only a limited number of commands are available. See the attached screenshot.

image

Module wrongly assumes samAccountName

This module wrongly assumes that the samAccountName is substring of the userPrincipalName before the '@'. However, this is not always true. A user or service account can have the userPrincipalName [email protected] but the samAccountName can be completely different, e.g. i-am-a-serviceaccou.

In addition to that, in Active Directory the samAccountname is limited to 20 characters. Another limitation that is ignored.

If we follow the example above, the assumptions made in the code would lead the module to wrongfully report unhealthy configurations.

Some wrong parts in the code are

Here $serviceAccount may return a userPrincipalName. The following setspn command will return the error FindDomainForAccount: Call to DsGetDcNameWithAccountW failed with return value 0x00000525; Could not find account [email protected]

$serviceAccount = (gwmi win32_service -filter "name='adfssrv'").StartName;
# [...]
[array]$serviceAccountSPN = setspn -L $serviceAccount;

https://github.com/microsoft/adfsToolbox/blob/master/diagnosticsModule/Private/AdfsConfiguration.ps1#L59

Here you assume that the samAccountName is simply the part in the userPrincipalName before the '@', which may be a lucky guess, but is technical false.

$serviceSamAccountName = $serviceAccountPartsUpn[0]
$serviceAccountDomain = TryGetDomainNameFromUpn $adfsServiceAccount
if ($serviceAccountDomain)
{
    $adfsServiceAccountFormatted = "$serviceAccountDomain\$serviceSamAccountName"
}

https://github.com/microsoft/adfsToolbox/blob/master/diagnosticsModule/Private/AdfsHealthChecks.ps1#L380

A possible solution would be to use Get-ADUser cmdlet.

$u = Get-ADUser -Filter "samaccountname -eq '$serviceAccount'"
if (!$u) {
   Get-ADUser -Filter "userPrincipalName -eq '$serviceAccount'"
}

Those are just two of many wrong parts in the code where those assumptions are made.

Error when the service has a UPN user where the domain from UPN is not the correct to "domain\username" format

I have experienced an error in the following snippet of the code (around line 1022):
# Check for UPN style old name and convert to domain\username for SPN work items
If ($OldName.ToString() -match "@") { $OldName = ($OldName.Split("@")[1]).ToString() + "" + ($OldName.Split("@")[0]).ToString() Write-Host "tUsing $OldName in order to meet SPN requirements" -ForegroundColor "gray"
($ElapsedTime.Elapsed.ToString())+" [INFO] Using $OldName in order to meet SPN requirements" | Out-File $LogPath -Append
}

The error occurred because the old ADFS Service user was in the UPN format AND the domain part is not the same domain to use in the format 'domain\user'.

To solve, I need to change the user format in ADFS Service to 'domain\user' before to run the script again.

Powershell 2.0 compatibility

Issue by rattuscz
Monday May 28, 2018 at 16:51 GMT
Originally opened as microsoft/adfsLogTools#20


Initial try to bring script to PS 2.0 compatible version - as our ADFS 2.0 are also PS2.0 ๐Ÿ˜ข

Analytics part still does not work - ConvertFrom-Json not in ps2

Not sure if this PS2.0 compatibility is even desirable in main branch, maybe as a separate?
Anyway looking for feedback


rattuscz included the following code: https://github.com/Microsoft/adfsLogTools/pull/20/commits

Validate all events have the correlation ID

Issue by bongiovimatthew-microsoft
Saturday Feb 10, 2018 at 01:40 GMT
Originally opened as microsoft/adfsLogTools#11


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)

ADFS 2.0 detection and fix by replacing strings

Issue by rattuscz
Monday May 28, 2018 at 14:36 GMT
Originally opened as microsoft/adfsLogTools#19


related #16
Well I've ended up on this "solution".

Basically we need to evaluate available logs on the remote machines themselves, then replace "AD FS" with "AD FS 2.0" in log name, provider and also in query.

This is due to strings formatted before the log/provider name is sent to remote server ( MakeQuery receives already processed query and log.

Also not sure about using hardcoded strings in replacement, but using $script on remote would mean to either pass them all as params OR prepopulate the session with them before calling MakeQuery
Due to this I believe hardcoding AD FS 2.0 is a bit better as it's legacy and thus is not likely to ever change again.

Suggestions welcome in any way :-)


rattuscz included the following code: https://github.com/Microsoft/adfsLogTools/pull/19/commits

AdfsServiceAccountModule - ADFS 2016 and 2019 compatibility issues

  1. Function GenerateSQLScripts
    ADFS 2012 database name "AdfsConfiguration" is hardcoded in line 437
    It is a bug, DB update will fail on newer ADFS version
    2016 - AdfsConfigurationV3 and 2019 - AdfsConfigurationV4

  2. Function Set-CertificateSharingContainerSecurity
    note: requires domain admin permissions
    ADFS property $ADFSProperties.CertificateSharingContainer will be always $null when running without domain admin rights
    Service account permissions set by this function grant: #GenericRead , #CreateChild , #WriteProperty , #Self
    are different to permissions in this script
    https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/deployment/install-ad-fs-delegated-admin#script-for-preparing-ad : #GenericRead , #CreateChild , #WriteProperty, #WriteOwner , #DeleteTree , #WriteDACL
    Which permissions are the right one?

  3. old service account SID in ServiceSettingsData configuration after change
    after service account change SID of old account still exists in configuration data in:
    <SecurityTokenService>....
    <AllowedOnBehalfOfCallers><Sid>S-1-5-21-xxxxxxxx.....</Sid></AllowedOnBehalfOfCallers>....
    </SecurityTokenService>
    No idea what is it about, but definitely looks strange. https://learn.microsoft.com/en-us/dotnet/api/microsoft.identityserver.policymodel.configuration.stsconfiguration.allowedonbehalfofcallers?view=adfs-2019#microsoft-identityserver-policymodel-configuration-stsconfiguration-allowedonbehalfofcallers

The future of this Github repository

As of 7/31/2019, we have migrated the diagnosticsModule from PowerShell to C# into a new repository. As a consequence of this change, the new repository is not publically available; however, we will still be making improvements to ADFSToolbox and releasing them here. This repository will remain public, but will not be actively maintained. ADFSToolbox is still being actively worked on and can be installed from here.

Like this message or respond if you think we should invest in open sourcing the new version of ADFSToolbox

[CLOSED] Test-AdfsServerToken fails if AD FS or WAP doesn't support TLS1.0

Issue by maweeras-msft
Friday May 11, 2018 at 14:28 GMT
Originally opened as microsoft/adfsManagementTools#8


If an AD FS farm has been hardened for TLS by disabling TLS1.0, TLS 1.1 as per https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/operations/manage-ssl-protocols-in-ad-fs then the Test-AdfsServerToken will fail as invoke-webrequest uses TLS 1.0 by default.

PS C:\WINDOWS\system32> $error[0] | fl * -f


PSMessageDetails      :
Exception             : System.Net.WebException: The underlying connection was closed: An unexpected error occurred on
                        a send. ---> System.IO.IOException: Unable to read data from the transport connection: An
                        existing connection was forcibly closed by the remote host. --->
                        System.Net.Sockets.SocketException: An existing connection was forcibly closed by the remote
                        host
                           at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size)
                           --- End of inner exception stack trace ---
                           at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size)
                           at System.Net.FixedSizeReader.ReadPacket(Byte[] buffer, Int32 offset, Int32 count)
                           at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest
                        asyncRequest)
                           at System.Net.Security.SslState.CheckCompletionBeforeNextReceive(ProtocolToken message,
                        AsyncProtocolRequest asyncRequest)
                           at System.Net.Security.SslState.ForceAuthentication(Boolean receiveFirst, Byte[] buffer,
                        AsyncProtocolRequest asyncRequest)
                           at System.Net.Security.SslState.ProcessAuthentication(LazyAsyncResult lazyResult)
                           at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext,
                        ContextCallback callback, Object state, Boolean preserveSyncCtx)
                           at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback
                        callback, Object state, Boolean preserveSyncCtx)
                           at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback
                        callback, Object state)
                           at System.Net.TlsStream.ProcessAuthentication(LazyAsyncResult result)
                           at System.Net.TlsStream.Write(Byte[] buffer, Int32 offset, Int32 size)
                           at System.Net.ConnectStream.WriteHeaders(Boolean async)
                           --- End of inner exception stack trace ---
                           at Microsoft.PowerShell.Commands.WebRequestPSCmdlet.GetResponse(WebRequest request)
                           at Microsoft.PowerShell.Commands.WebRequestPSCmdlet.ProcessRecord()
TargetObject          : System.Net.HttpWebRequest
CategoryInfo          : InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-WebRequest], WebException
FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand
ErrorDetails          :
InvocationInfo        : System.Management.Automation.InvocationInfo
ScriptStackTrace      : at Test-AdfsServerToken, C:\Program
                        Files\WindowsPowerShell\Modules\ADFSDiagnostics\1.1.0\Public\Test-AdfsServerToken.ps1: line 79
                        at <ScriptBlock>, <No file>: line 1
PipelineIterationInfo : {}

As a workaround setting TLS1.2 to be used like so then makes this cmdlet work.

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12

Can we have the logic for the cmdlet updated to handle the error and use TLS 1.2 if required?

[CLOSED] WAP Diagnostics Part 1

Issue by madhavpatel6
Friday Mar 23, 2018 at 20:43 GMT
Originally opened as microsoft/adfsManagementTools#3


- Refactored existing code
- Added new test cases related to WAP and ADFS
	- Checking trusted devices certificate store
	- Checking ADFS Patches
	- Checking the service principal name
	- Checking that the ADFS proxy service
	- Checking that there are no Non-Self-Signed certificates in the
	root store
	- Checking the Proxy SSL bindings
- Added new error result type that will be used to indicate when
something unexpected happened

madhavpatel6 included the following code: https://github.com/Microsoft/adfsManagementTools/pull/3/commits

WAP: Export-AdfsDiagnosticsFile fails

It appears WAP Export bug was re-introduced in version 1.0.4

Export works OK in verison 1.03

PS C:\Utils> Export-AdfsDiagnosticsFile -sslThumbprint "########################" -Verbose
VERBOSE: Export-AdfsDiagnosticsFile: Creating file ADFSDiagnosticsFile-20180926141632.json
VERBOSE: GenerateJSONDiagnosticData: Generating diagnostic data
VERBOSE: GenerateDiagnosticData: Binding each argument to relevant cmdlets
VERBOSE: GenerateDiagnosticData: Attempting to run cmdlet Test-AdfsServerHealth
Performing applicable health checks on your WAP server.
VERBOSE: IsTlsVersionEnabled: Checking if TLS 1.0 is enabled
VERBOSE: IsTlsVersionEnabled: The registry key for this TLS version does not exist at HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0
VERBOSE: IsTlsVersionEnabled: Checking if TLS 1.1 is enabled
VERBOSE: IsTlsVersionEnabled: The registry key for this TLS version does not exist at HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1
VERBOSE: IsTlsVersionEnabled: Checking if TLS 1.2 is enabled
VERBOSE: IsTlsVersionEnabled: The registry key for this TLS version does not exist at HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2
VERBOSE: TestTimeSync: Checking time synchronization.
VERBOSE: TestTimeSync: Detected that the current server is a WAP server.
VERBOSE: IsServerTimeInSyncWithReliableTimeServer: Comparing server time with reliable time server
VERBOSE: GET http://nist.time.gov/actualtime.cgi?lzbc=siqm9b with 0-byte payload
VERBOSE: received 62-byte response of content type text/xml
VERBOSE: IsServerTimeInSyncWithReliableTimeServer: Current reliable time server time UTC 09/26/2018 13:16:34
VERBOSE: IsServerTimeInSyncWithReliableTimeServer: Current server time UTC 09/26/2018 13:16:33
VERBOSE: IsServerTimeInSyncWithReliableTimeServer: Time difference in seconds 1
VERBOSE: TestProxySslBindings: Parameter AdfsSslThumbprint = c7f41c20872c8d856f912f10ddb58882ef34a468
VERBOSE: TestProxySslBindings: Attempting to get federation service name.
VERBOSE: TestProxySslBindings: Retrieved federation service name: signon.impellam.com.
VERBOSE: TestProxySslBindings: Retrieved ADFS Port: 443 TLS Port: 49443
VERBOSE: TestProxySslBindings: Attempting to validate expected SSL bindings.
VERBOSE: IsSslBindingValid: Validating SSL binding for signon.impellam.com:443.
VERBOSE: IsSslBindingValid: Successfully validated SSL binding for signon.impellam.com:443.
VERBOSE: IsSslBindingValid: Validating SSL binding for signon.impellam.com:49443.
VERBOSE: IsSslBindingValid: Successfully validated SSL binding for signon.impellam.com:49443.
Successfully completed all health checks.
GenerateDiagnosticData : Error running cmdlet ADFSToolbox\Test-AdfsServerHealth -sslThumbprint $sslThumbprint: Cannot find an overload for "TestResultsContainer" and the argument
count: "1".
At C:\Program Files\WindowsPowerShell\Modules\adfsToolbox-1.0.3\diagnosticsModule\Private\HelperUtilities.ps1:690 char:23

  • ... osticData = GenerateDiagnosticData -includeTrusts:$includeTrusts -ssl ...
  •             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    
    • CategoryInfo : NotSpecified: (:) [Write-Error], WriteErrorException
    • FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,GenerateDiagnosticData

VERBOSE: GenerateJSONDiagnosticData: Successfully generated diagnostic data
VERBOSE: Export-AdfsDiagnosticsFile: Outputting diagnostic data at C:\Utils\ADFSDiagnosticsFile-20180926141632.json
Please upload the diagnostic file located at C:\Utils\ADFSDiagnosticsFile-20180926141632.json to https://adfshelp.microsoft.com/DiagnosticsAnalyzer/Analyze.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.