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.