Configure NLB Nodes for WAP (non domain joined)

You might run into some node-level trust issues if you are trying to configure an NLB cluster for the Web Application Proxy role. 

The best practice from Microsoft states that any servers running the Web Application Proxy role should reside in a DMZ network and not be domain joined. This brings it's own set of issues as the nodes don't automatically trust each other. 

Gone are the days of creating two local administrator accounts on two non-domain joined hosts with the same password and praying it "passes through" authentication requests. Although we are still going to do this, a few other steps must be completed for it to work. 

If you are configuring an NLB cluster on none domain joined nodes, you will probably be faced with "Access Denied" when you attempt to add the second host to the already existent cluster. This is even if you have matching local administrator credentials on both machines. I'm led to believe this is due to later versions of Windows inspecting the local SID's of user accounts instead of the username string. 

To resolve this do the following - 

• Create a new DWORD entry for LocalAccountTokenFilterPolicy in the registry of both nodes, this disables certain parts of UAC.  The registry path is HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System and for clarity the new entry should be a DWORD set to decimal and the value of 1.

• Configure the Trusted Hosts store on each of the nodes and create an entry for each server on each node. All the info on this can be found here http://winintro.ru/windowspowershell2corehelp.en/html/f23b65e2-c608-485d-95f5-a8c20e00f1fc.htm

• Configure (from NLB Manager) Options > Credentials on both servers with the local admin account that has been created on each of the servers.

• Configure the NLB cluster using node IP's and not DNS names (even if you have DNS names configured with the hosts file, I've found IP's seem to work better in a none domain joined NLB cluster).

Configuring Extranet Lock Protection in ADFS 2016

Extranet Lock Protection is used to protect your Internet facing ADFS from password brute force attacks. Extranet Lock Protection works much like an Account Lockout Policy in Active Directory, you set a password attempt threshold in conjunction with a period of time before the user in question can be authenticated. With ELP enabled, even if the user attempts to login to the Sign In page using valid credentials after the threshold has been met and before the lock time has expired, they will not be granted access.

ADFS ELP works separately from Active Directory account lock outs, if you enable ELP it will not disable on premise user accounts if a brute force attack has been attempted at the ADFS Sign In page.

Some comparisons should be made between the AD Account Lockout Policy and ELP.

·      Lockout threshold on ELP should be less than the threshold in AD.

·      Lockout time window on ELP should be greater than the threshold in AD.

Extranet Lock Protection is not enabled by default on Server 2012 R2 or Server 2016.

View the default using Get-AdfsProperties

Enable Extranet Lockout Protection with a threshold of 3 wrong authentication attempts and a lockout observation window of 15 minutes.

Set-AdfsProperties -EnableExtranetLockout $true -ExtranetLockoutThreshold 3 -ExtranetObservationWindow (new-timespan -Minutes 15)

Run the command Get-AdfsProperties again to ensure the change has been applied.

It’s worth noting that it takes some time for the warning to disappear from the Azure AD Connect page inside the Azure Portal. It does not seem to be instant and nothing I did seemed to force a re-evaluation.

Further reading https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/operations/configure-ad-fs-extranet-lockout-protection