Windows

Load Testing on Active Directory

If you need to conduct load performance testing on Active Directory (Domain Controllers), you can use the tool provided by MS.

It is called the Active Directory Performance Testing Tool (ADTest.exe).

Click on the link below for more info.

https://blogs.technet.microsoft.com/askpfeplat/2014/02/09/how-to-use-the-active-directory-performance-testing-tool-on-windows-server-2012/

 

Advertisements
Windows

List of critical ADFS events to monitor

As we know in ADFS event we have two types, the ADFS admin event log and ADFS Tracing debug log. The debug log is recommended to be disabled and only enable it when ADFS service has the issue.

On ADFS admin event aspect, I think here is the list of critical events in ADFS service.

Event ID 324

The Federation Service could not authorize token issuance for caller ‘defined’ to relying party ‘defined’.

Event ID 411

Token validation failed. See inner exception for more details.

Event ID 413

An error occurred during processing of a token request. The data in this event may have the identity of the caller (application) that made this request. The data includes an Activity ID that you can cross-reference to error or warning events to help diagnose the problem that caused this error.

Event ID 500

More information for the event entry with Instance ‘Error’. There may be more events with the same Instance ID with more information.

Event ID 501

More information for the event entry with Instance ‘Error’. There may be more events with the same Instance ID with more information.

Others

Other common event IDs such as error 364 or error 342 are only showing one user is trying to do authentication with ADFS but enters incorrect username or password, so it is not critical on the ADFS service level.

On the services aspects, we can monitor the ADFS services on the ADFS server and WAP server (if we have).

For the ADFS health monitoring, we can also monitor this endpoint and ensure it is returning 200 code:

Scripting

Launching PowerShell from VBScript

If you need to launch PowerShell from VBScript, use this.


Set objShell = CreateObject("Wscript.shell")

strPSScript = "D:\temp\msg.ps1"
strCMD = "powershell.exe -nologo -file " & Chr(34) & strPSScript & Chr(34)
objShell.run strCMD, 0, false

'WScript.Echo strCMD

Set objShell = Nothing

This will launch the PowerShell script and hides the window as well.

If you encounter issues with the above such that the PS script needs the PS shell window to remain open, use the script below:


strPSScript = "<script path>"
Set objShell = CreateObject("Wscript.Shell")
objShell.Run("powershell.exe -noexit -windowstyle minimized " & chr(34) & strPSScript & chr(34))

 

Scripting

PS Tip: Parsing HTML from a local File or a String

If you are familiar with Invoke-WebRequest cmdlet then you are aware that you can get a parsed HTML from the requested Web URL. DOM structure of this parsed HTML could be utilised to get access to HTML elements of the web page (see below).


$webRequest = Invoke-WebRequest "google.com"

$webRequest.ParsedHTML.getElementsByTagName("span") | % textContent

WebRequest1

Problem

What if we have the HTML files locally saved in the computer or in a string? Do we have any mechanism to parse it from a local file/string?

Solution

Answer is Yes.

Microsoft provides the HTML document class in .Net framework class library, which has a Write() method to write HTML Document using DOM 2 (Document Object Model Level 2)

WebRequest2

Solution 1 : From a string

$html = New-Object -ComObject "HTMLFile"

$html.IHTMLDocument2_write($content)

$html.all.tags("A") | % innerText

Solution 2 : From a file

Similarly we can parse HTML document from a local HTML file.


$html = New-Object -ComObject "HTMLFile"

$html.IHTMLDocument2_write($(Get-Content .\file.html -raw))

$html.all.tags("A") | % innerText

 

Note

Even the parsed HTML from Invoke-Webrequest has the type HTML Document Class


$WR = Invoke-WebRequest "http://google.com"

$WR.ParsedHtml.GetType()

Output is: HTMLDocumentClass

 

 

Scripting

PowerShell Exception 0x800A01B6 while using getElementsByTagName, getElementsByName or getElementByID

Recently, I have started writing automation scripts to automate IE websites and make use of the com-object “InternetExplorer.Application” to automate an internet explorer session.

$ie = New-Object -com "InternetExplorer.Application"
$ie.visible = $true
$ie.silent = $true

$ie.Navigate($IURL)
while ($ie.Busy) {
  [System.Threading.Thread]::Sleep(10)
}

Using $ie.Document.getElementsByTagName(“Input”) enables me to enumerate the form fields and buttons. This works for the first website that I am visiting. If I then navigate to another site, $xe.Document.getElementsByTagName(“Input”) generates the following exception:


Exception from HRESULT: 0x800A01B6
At line:1 char:1
+ $Global:ie.Document.getElementsByTagName("Input")
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 + CategoryInfo : OperationStopped: (:) [], NotSupportedException
 + FullyQualifiedErrorId : System.NotSupportedException

Workaround

Always use the following methods instead of the native ones:


IHTMLDocument3_getElementsByTagName
IHTMLDocument3_getElementsByName
IHTMLDocument3_getElementByID

Example


$ie = New-Object -com "InternetExplorer.Application"
$ie.visible = $true
$ie.silent = $true
$ie.Navigate($IURL)
while ($ie.Busy)
{
[System.Threading.Thread]::Sleep(10)
}
$ie.Document.IHTMLDocument3_getElementsByTagName("Input") $ie.Navigate($IURL2) while ($ie.Busy)
{
[System.Threading.Thread]::Sleep(10)
}
$ie.Document.IHTMLDocument3_getElementsByTagName("Input")

Windows

Securing Built-in Administrator Accounts in Active Directory

All of us know that the built-in Administrator account cannot be locked out and it has the following behaviour:

  1. The authentication package ignores the Lockout attribute and returns a failed login
  2. The Lockout attribute is reset upon successful login.

If you want to secure this account, head to the following link:

https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/appendix-d–securing-built-in-administrator-accounts-in-active-directory