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.
Let’s harden the Web Application Proxy installations, by disabling unnecessary services running on it. This way, we lower their attack surfaces even further.
Note:
This blogpost assumes you’re running Web Application Proxies as non-domain-joined Server Core Windows Server 2016 installations. If your Web Application Proxies are domain-joined, use Group Policy to disable unnecessary services instead of PowerShell.
Why harden Web Application Proxies
Hardening provides additional layers to defense in depth approaches. It changes the default behavior of products and services to make them more resilient to unauthorized changes and compromise.
Reasons why
One of the requirements for using Active Directory Federation Services (AD FS) with Azure AD is to publish AD FS to the Internet. Web Application Proxies are mainly implemented for this purpose. In this role, they are typically implemented on perimeter networks and not domain-joined. As Internet-facing systems, they are prone to attacks.
Possible negative impact (What could go wrong?)
When Web Application Proxies are improperly hardened, access to the rest of the AD FS farm stops and/or monitoring of the Web Application Proxies stops. This functionality can be easily assessed. However, in situations with load balancers and having hardened some of the Web Application Proxies, it may be tricky to get results from the right Web Application Proxy.
Getting Ready
To disable unnecessary services on Web Application Proxies, make sure to meet the following requirements:
System requirements
Make sure the Web Application Proxies are installed with the latest cumulative Windows Updates.
Privilege requirements
Make sure to sign in with an account that has local administrator privileges on each of the Web Application Proxies. Your Web Application Proxies all have different local administrator passwords, right?
Who to communicate to
As the Web Application Proxies operate in a process, notify all stakeholders in the process. This means sending a heads-up to the load balancer guys and gals, the networking guys and gals, the rest of the Active Directory team and the teams that are responsible for Azure AD, Office 365 and cloud applications. It's also a good idea to talk to the people responsible for backups, restores and disaster recovery.
One of the challenges you can easily avoid through communications is that multiple persons and/or teams make changes to the configuration. When it breaks, you don't want to roll-back a bunch of changes, just the one that broke it. Make sure you have the proper freeze/unfreeze moments to achieve that.
Unnecessary services
Services that are of no use to Web Application Proxies can be disabled.
By default
The following Windows services are disabled, by default, on Server Core installations of Windows Server 2016:
- Computer Browser (browser)
- Net.Tcp Port Sharing Service (NetTcpPortSharing)
- Routing and Remote Access (RemoteAccess)
- Smart Card (SCardSvr)
These services do not require any further attention.
Additional services
The following Windows services are enabled and have Manual or Automatic startup types on Server Core installations of Windows Server 2016. These can be disabled:
- Internet Connection Sharing (ICS) (SharedAccess)
- Link-Layer Topology Discovery Mapper (lltdsvc)
- Print Spooler (Spooler)
- Printer Extensions and Notifications (PrintNotify)
- Smart Card Device Enumeration Service (ScDeviceEnum)
- Windows Insider Service (wisvc)
How to disable unnecessary services
To disable the above services, run the following Windows PowerShell script, when logged on with an account that has local administrative privileges on the Web Application Proxy:
Set-Service SharedAccess –StartupType Disabled
Stop-Service SharedAccess
Set-Service lltdsvc –StartupType Disabled
Stop-Service lltdsvc
Set-Service Spooler –StartupType Disabled
Stop-Service Spooler
Set-Service PrintNotify –StartupType Disabled
Stop-Service PrintNotify
Set-Service ScDeviceEnum –StartupType Disabled
Stop-Service ScDeviceEnum
Set-Service wisvc –StartupType Disabled
Stop-Service wisvc
Testing proper hardening
After hardening it's time to test the hardening. Everyone should sign off (not literally, unless that's procedure) on the correct working of the Web Application Proxies. Does authentication to cloud applications still work? Does rolling over the certificate still work? Does monitoring still work? Can we still make back-ups? Can we still restore the backups we make?
Typically, hardening is rolled out to one Web Application Proxy. When testing the hardening of the functionality behind the load balancer, make sure that the load balancer points you to the hardened system, not another one.
Re-enable services
If hardening breaks functionality, re-enable the above services to their previous state. Run the following Windows PowerShell script, when logged on with an account that has local administrative privileges on the Web Application Proxy:
Set-Service SharedAccess –StartupType Manual
Set-Service lltdsvc –StartupType Manual
Set-Service Spooler –StartupType Automatic
Start-Service Spooler
Set-Service PrintNotify –StartupType Manual
Set-Service ScDeviceEnum –StartupType Manual
Set-Service wisvc –StartupType Manual
Concluding
Disable unnecessary services on all Web Application Proxies throughout the Hybrid Identity implementation using the Windows PowerShell script above.
Login