Most Microsoft-based Hybrid Identity implementations use Active Directory Federation Services (AD FS) Servers, Web Application Proxies and Azure AD Connect installations. In this series, labeled Hardening Hybrid Identity, we’re looking at hardening these implementations, using recommended practices.
In this part of the series, we’ll look at best practices to handle Windows activation on non-domain-joined Web Application Proxy servers.
Note:
This blogpost assumes you’re running Web Application Proxies as non-domain-joined Server Core Windows Server 2016 installations.
If your Web Application Proxy servers are domain-joined, you can use Group Policy and Windows Server Update Services (WSUS) to take care of Windows Update. However, this option can’t be used for Web Application Proxy servers that are non-domain-joined and/or placed on a perimeter network (also commonly referred to as a DMZ network).
Why look at Windows Update for Web Application Proxies
Every software has bugs. It’s still a human job to produce code. Developers, testers and even quality assurance people also work on Monday mornings. We all make mistakes. It’s how we deal with failure, that defines us.
Microsoft software has bugs. Bugs may be innocent, or they may lead to serious problems like remote code execution, elevation of privilege, information disclosure, security feature bypasses, denial of service, spoofing and/or tampering. However, the way Microsoft handles fixing these bugs, stands out. In 2003, Microsoft started with a repetitive predictable and reported way of announcing and releasing updates to its software, including Windows, Windows Server, Office, Visual Studio, SQL Server, Exchange Server and many others: Patch Tuesday.
Below is a graphical representation of the problems solved in the September 10, 2019 update:
In recent years, Microsoft has split up the security updates from the quality improvement updates. Now, the second Tuesday of each month brings security updates. Quality updates are also released on Tuesday, but usually a week or two weeks after the security updates.
Web Application Proxies need the free updates Microsoft distributes.
Possible negative impact (What could go wrong?)
When Web Application Proxies do not install Windows Updates, they may remain vulnerable for common problems. While many admins think that a proper firewall rule prevents these attacks, some attacks operate at a higher layer than most firewalls operate; When the firewall allows TCP 443, it doesn’t merely allow the proper traffic for the Web Application Proxy. Similarly, next-generation firewalls and web application firewalls may inspect the flow of https traffic between the Internet and Web Application Proxies but may not detect the newest threats.
When Windows Servers do not install Windows Updates, their functionality may break, as fixes to the role are not added to the Operating System. This holds strongly for Windows Server 2012 R2-based Web Application Proxies, as the role was first introduced in this version and many updates were made to the role in the first year.
When Windows Servers do not install Windows Updates, they may lack new security features and settings. Updates to Root Certification Authorities (CAs), time zone updates and cipher suite updates are common updates that add to the information security baseline. The Extranet Smart Account Lockout feature in AD FS was distributed with a Windows Update to Windows Server 2016.
Four solutions for Windows Updates
There are four solutions to apply Windows Updates to non-domain-joined Web Application Proxies:
- Configure to use Windows Update on the web
- Configure to use your organization’s WSUS implementation
- Manually install Windows updates
- Use an update solution
How to do it
To apply Windows Updates to non-domain-joined Web Application Proxies, perform these actions, per scenario:
Configure to use Windows Update on the web
Microsoft offers a standardized method for downloading Windows updates from its webservers. This method is built-in, even in Server Core.
For this scenario, the following requirements need to be met:
- Each Web Application Proxy needs to be able to communicate to the following URLs using TCP 443 and TCP80, respectively:
- http://download.windowsupdate.com
- http://*.download.windowsupdate.com
- http://download.microsoft.com
- https://*.update.microsoft.com
- http://*.update.microsoft.com
- https://update.microsoft.com
- http://update.microsoft.com
- http://*.windowsupdate.com
- http://*.windowsupdate.microsoft.com/li>
- http://windowsupdate.microsoft.com
- https://*.windowsupdate.microsoft.com
- http://ntservicepack.microsoft.com
- http://wustat.windows.com
- Each Web Application Proxy needs to be able to verify the communication certificates and update signatures, by allowing access to the Certification Authorities (CAs) used.
- DNS-based name resolution to the Internet for each Web Application Proxy.
- An account with local administrator privileges on each Web Application Proxy.
Configuring automatic updates
Perform the following steps to configure a Server Core installation to use Windows Update on the web:
- Sign in with an account with local administrator privileges.
- Run sconfig.cmd.
The Server Configuration utility starts. - Enter the number 5, followed by pressing the Enter key on the keyboard to enter the Windows Update Settings sub menu.
- Press A for Automatic updates, followed by pressing Enter on the keyboard.
- In the Update Settings dialog screen, click OK.
The Web Application Proxy will check for and install updates every day at 3:00 AM. The settings take effect immediately. No reboot is required. Repeat the above steps on each Web Application Proxy.
Configure to use your organization’s WSUS implementation
Windows Server Update Services (WSUS) enables admins to deploy the latest Microsoft product updates with full manageability of the distribution of updates in their networks.
Note:
WSUS can be deployed in a disconnected scenario, where updates and metadata are exported on one WSUS server and imported on another disconnected WSUS server. This scenario makes WSUS useable in highly-restricted perimeter networks, too.
For this scenario, the following requirements need to be met:
- A fully functional WSUS server needs to be implemented and synchronized with Microsoft Update.
- DNS-based name resolution to the Internet for each Web Application
Proxy. - An account with local administrator privileges on each Web Application
Proxy.
Where the WSUS server addresses are commonly deployed using Group Policy, Web Application Proxies are typically not domain-joined. The following lines of Windows PowerShell ass the registry settings to point a Web Application Proxy to a WSUS server
Stop-Service -Name wuauserv
$Path = "HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate"
$WSUSAddress = "WSUSSERVER"
New-ItemProperty -Path $SChannelRegPath -Name DisableWindowsUpdateAccess `
–Value 1 -PropertyType DWORD
New-ItemProperty -Path $SChannelRegPath -Name WUServer `
-Value $WSUSAddress -PropertyType String
New-ItemProperty -Path $SChannelRegPath -Name WUStatusServer `
-Value $WSUSAddress -PropertyType String
New-ItemProperty -Path $SChannelRegPath+"\AU" -Name AUOptions `
-Value 5 -PropertyType DWORD
New-ItemProperty -Path $SChannelRegPath+"\AU" -Name NoAutoUpdate `
-Value 0 -PropertyType DWORD
New-ItemProperty -Path $SChannelRegPath+"\AU" -Name UseWUServer `
-Value 1 -PropertyType DWORD
Start-Service -Name wuauserv
The Windows Update client is now configured with Automatic Updates and polls the WSUS server for approved updates every 22 hours minus a random offset.
Repeat the above steps on the other Web Application Proxies.
Manually install Windows updates
In either of both scenarios, admins can manually check for updates and install updates.
For this scenario, the requirements need to be met for the previous scenarios, but most importantly an account with local administrator privileges on each Web Application Proxy is needed.
Perform these steps:
- Sign in with an account with local administrator privileges.
- Run sconfig.cmd.
The Server Configuration utility starts. - Enter the number 6, followed by pressing the Enter key on the keyboard.
- Choose between Search for (A)ll Updates or (R)ecommended Updates only by pressing either A or R on the keyboard, followed by pressing Enter on the keyboard.
- Then, select between (A)ll updates, (N)o updates or (S)elect a single update, by pressing A, N or S on the keyboard, followed by pressing Enter on the keyboard.
- Press Yes in the Restart Required dialog screen to restart the Web Application Proxy.
Repeat the above steps on the other Web Application Proxies.
Use an Update solution
3rd party patching solution might offer functionality to update Web Application Proxies. However, I would like to share a really simple solution: WSUSOffline.net,
Using "WSUS Offline Update", you can update any computer running Microsoft Windows and Office safely, quickly and without an Internet connection, for free.
Especially its option to create an ISO file, that you can easily mount on virtual machines makes it a fast solution to update hosts in the perimeter network.
Checking which updates are installed
Throughout the lifetime of a Web Application Proxy, you might need to troubleshoot Windows Updates. It might help when you are trying to figure out whether an update is installed and the server needs rebooting or whether an update is not installed. (in which case you probably won’t need to reboot) The command to use is:
wmic.exe qfe list
Concluding
It’s your choice to create media to manually update your Web Application Proxies, or let them download updates from the Internet or WSUS Servers automatically. However, please remember to implement something to keep the systems in your Hybrid Identity implementation up to date.
Further reading
Windows Update troubleshooting
Fix Windows Update errors
Registry keys for configuring Automatic Updates & WSUS
WSUS Offline Update
How To: Remove WSUS Settings and Restore Windows Update Defaults
Configure a Server Core installation of Windows Server 2016, with Sconfig.cmd
How to Patch Windows Server Core 2016
Login