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

Window Server 2016 - ADFS 4.0 "An error occurred. The resource you are trying to access is not available. Contact your administrator for more information"

When I setup ADFS I usually browse to the URL in order to test that ADFS is operation https://fqdn.domain.com/adfs/ls/IdpInitiatedSignon.aspx

 

Although it is not a conclusive test it does give me some level or assurance that ADFS is functioning if this web page responds with the sign in page. However, I setup a new ADFS 4.0 infrastructure on Windows Server 2016 and when I browsed to the URL I received the following error. 

"An error occurred. The resource you are trying to access is not available. Contact your administrator for more information."

It turns out the IdpInitiatedSignOnPage property is disabled by default in ADFS 4.0 to enable it use the following PowerShell command on your ADFS servers. 

Set-AdfsProperties -EnableIdpInitiatedSignOnPage $True

ADFS & WAP "Unable to retrieve proxy configuration data from the Federation Service. Status Code Unauthorized (401)".

A very common problem when installing WAP servers for ADFS is the error "Unable to retrieve proxy configuration data from the Federation Service. Status Code Unauthorized (401)". 

Check the bindings for your ADFS servers http.sys file (only for ADFS 3.0, older versions use IIS). The following command can be used to display the http.sys bindings.

netsh http show sslcert

The fix for me was to add the static binding of 0.0.0.0:443, I have highlighted it below. Without this I was receiving the "Unable to retrieve proxy configuration data from the Federation Service. Status Code Unauthorized (401)" error.

To add this static 0.0.0.0:443 binding use the netsh utility, it fails if you do not enter it in stages like it is listed below. The certhash and appid used for this binding should be the same that is used in your ADFS service name binding that is displayed when you use the netsh http show sslcert command.

netsh http add sslcert ipport=0.0.0.0:443 certhash=insert hash appid={insert appid}

Now you can try to re-run the WAP configuration utility. I have found this works best by using PowerShell. The following command can be used to perform this

Install-WebApplicationProxy –CertificateThumbprint certthumbprint –FederationServiceName adfsservicename

You will then be prompted to enter administrator credentials on the ADFS servers. The GUI is misleading at this stage as it states you should use "local administrator credentials", I can confirm this is not the case as you will get an error unless they are domain credentials.

When you run the WAP configuration wizard it is worth knowing that you sometimes have to run the command 2/3 times before it works correctly (without changing anything). This first time I run the command after making the binding change return the error.

"The federation server proxy could not renew its trust with the Federation Service.  

Additional Data 

Exception details: 

The remote server returned an error: (400) Bad Request. 

User Action 

Ensure that the federation server proxy is trusted by the Federation Service. If the trust does not exist or has been revoked, establish a trust between the proxy and the Federation Service using the Federation Service Proxy Configuration Wizard by logging on to the proxy computer."

The message returned from the PowerShell window was "an error occurred validating the SSL certificate". The length of the certificate hash is invalid. Did you forget to add the preceding '0'."

Without changing anything I then rerun the command and it worked correctly.

Configuring Citrix NetScaler to Load Balance ADFS v3.0

Configuring Citrix NetScaler to Load Balance ADFS v3.0

The link below is broken, I also do not have a copy of the full document I created in July 2015. Do not e-mail me directly asking for a copy.

To ensure ADFS and the WAP servers are highly available a hardware load balance is recommended. In this example I have outlined how to configure Citrix NetScalers to do this. If you are deploying ADFS for Office 365, it is important that the service is highly available otherwise users will not be able to authenticate to ADFS. 

Microsoft supports NetScaler as a hardware load balance but there is lack of documentation around how to deploy the two solutions together.

Some of the configuration settings such as MAC based forwarding, SSL bridging, session persistence and Client IP header are some of the settings that are not obviously required.

Although the full guide I created no longer exists, I have summarised how to configure the NetScaler to load balance ADFS 3.0 below. This is not a full and conclusive guide. I won't be re-doing the guide until I am asked to do it for a customer. 

Although this diagram is for MS Lync, it's similar for ADFS. Imagine you have 2 x WAP in the DMZ and 2 x ADFS in your LAN. 

Most places won't have two separate physical NetScaler pairs. The above topology can be achieved using a single pair of Netscalers, with network interfaces on each of the DMZ/LAN networks. Netscaler vServers can then be used to load balance each component. If your security requirements state you must have a physical break then it's different.

High level steps (from memory)

• Base configure the Netscalers (NSIP, SIP, routes, default gateways etc)
• at this point it's important to have an interface on each network. If you are deploying the ADFS WAP servers, these should be in your DMZ. Therefore an interface from the NS is required on each of the separate Layer 2 networks. 
• if you have problems research "Mac based forwarding"

• Configure high availability of the Netscalers
• Easy to do, Google it. I normally set my HA configuration to Active/Passive.

• Define the server's both ADFS and WAP
• Traffic Management/Load Balancing/Server
• Create a new server object for each of the ADFS/WAP's. Set the protocol to SSL Bridge
• Create a new service one for the WAP's and one for the ADFS's. Traffic Management/Load Balancing/Services
• service 1 = "adfs_https" protocol SSL Bridge
• service 2 = "wap_https" protocol SSL Bridge
• It's important the protocol type matches on the servers/services.

At this point, if you servers are listening on TCP 443 (https) and you have configured the networking correctly the server/services will show as "up" and the light will be green. If not there is some kind of networking problem (remember your WAP servers don't listen on 443 until you have them successfully paired with the ADFS servers)

• You should configure SSL session persistence (I cant remember the exactly menu, you either do this in the service configuration or on the vServer, check eDocs)
• Now create a new vServer for each the WAP's and the ADFS's
• vserver1 = "adfs" give the vserver an IP on the network the backend servers sit on
• vserver2 = "wap" same as above
• When you create the vserver, bind them to the corresponding service (adfs - adfs etc), and set the load balancing method to round robin.

DNS 

Now you have the NS configured, on the WAP servers create a hosts file entry to point your ADFS service name i.e sso.domain.com to the NS vServer for the ADFS servers. Try to run the WAP-ADFS pairing. If you get an error check out the bindings.

http://blog.ryanbetts.co.uk/2015/12/adfs-wap-unable-to-retrieve-proxy.html