Installing, Configuring, Securing and Using MDT Webservices – Part 2

by Jeremy Saunders on December 22, 2016

In Part 1 we walked through the installation and configuration of Deployment Webservices. In this part we will focus on securing the Webservice.

There are five (5) main areas that I focus on to lock down the Webservice, and I’ll include two (2) optional areas for consideration:

  1. Use Request Filtering, which is basically what the old URL Scan morphed into from IIS 7 (Windows 2008) and above. Request Filtering gives a tighter level of control over the settings and where they are applied than URL Scan ever did.
  2. Authentication – Disable anonymous authentication. That should be a no-brainer!
  3. Authorization Rules – Only allow specific users access.
  4. Changing the authenticatedUserOverride serverRuntime setting to UseWorkerProcessUser. IIS 7.5 (Windows 2008 R2) and above allows us to configure IIS so that the worker process identity is used for accessing resources, such as the file system, whilst the authenticated user is only used for authorization purposes. This means that you only need to set NTFS permissions for the worker process identity.
  5. Setting NTFS Permissions on the DeploymentWebservice folder for the worker process identity.
  6. Optionally, you can also exclude some of the higher risk AD Functions.
  7. Optionally, you can also SSL enable the site with a certificate.

1) Request Filtering

I lock down the file extensions and verbs allowed. If you have a better process, please let me know via the comments.

By default:

  • The “Allow unlisted file name extensions” (fileExtensions allowUnlisted) attribute is set to TRUE. This means that you must list all file name extensions you want to deny. So we set this to FALSE and then only need to list the minimum number of file name extensions allowed in order to ensure the Webservice functions correctly.
  • Likewise the “Allow unlisted verbs” (verbs allowUnlisted) attribute is set to TRUE. This means that you must list all verbs you want to deny. So again we set this to FALSE and then only need to list the minimum number of verbs allowed in order to ensure the Webservice functions correctly.

Request Filtering General Settings

The Web Service only requires two extensions to function correctly:

  • DLL extension (dll)
  • Web Service extension (asmx)

Request Filtering File Name Extensions Allowed

The Web Service only requires two verbs to function correctly:

  • GET
  • POST

Request Filtering HTTP Verbs Allowed

2) Authentication

  • Disable Anonymous Authentication
  • Enable Windows Authentication

Authentication

3) Authorization Rules

  • Edit the default rule and change from “All users” to “Specified users”
  • Add the MDT Domain Join Account in the format of Domain\Username
    • Set the “FQDNDomainName\Username” to match the deployment share rules (CustomSettings.ini). I DO NOT use the “NetBIOSDomainName\Username” format, as it may be slow in large/complex environments.

Authorization Rules

4) Changing the authenticatedUserOverride setting to UseWorkerProcessUser

  • Open Configuration Editor
  • Select Section: system.webServer/serverRuntime
  • Change authenticatedUserOverride from UseAuthenticatedUser to UseWorkerProcessUser
  • Select Apply

authenticatedUserOverride serverRuntime setting

5) Setting NTFS Permissions on the DeploymentWebservice folder

Your initial permissions on the “DeploymentWebservice” folder may vary depending on your default server template, security policies, etc. However, for this step you must remove the generic principals such as Users, Authentication Users, and Creator Owner, and only add the MDT domain join account.

  • Disable inheritance and convert to explicit permissions. 
  • Remove all instances of Users, Authentication Users, and Creator Owner principals.
  • Add the MDT domain join account with Read & execute permissions
      • Applies To: This folder, subfolders and files
      • Basic Permissions:
        • Read & Execute
        • List Folder Contents
        • Read

NTFS - Read & execute permissions

  • Add the MDT domain join account with Special permissions
      • Applies To: This folder and subfolders
      • Advanced Permissions:
        • Create files /write data
        • Create folders /append data

NTFS - Special permissions

End state permissions will look something like the following screen shot.

NTFS - End State

6) Exclude some of the higher risk AD Functions

Some functions are excluded by default under the Application Settings. You can certainly exclude more to limit the risk. As mentioned in Part 1, you also have the option of using Johan Arwidmark’s cut down version, as it only contains the MoveComputerToOU and AddComputerToGroup functions.

Exclude AD Functions

7) SSL enable the site with a certificate

Enabling SSL will provide an encrypted communication layer between the client (typically WinPE) and the Webservice. Whilst this is a good practice, I don’t implement this because I feel that a man in the middle attack to sniff the network traffic in an attempt to obtain the credentials for the MDT domain join account is low risk for this scenario.

Conclusion:

If you followed and implemented at least the first five (5) steps, you’re Webservice will be locked down and limited to the MDT domain join account only. This removes a large amount of exposure and risk when deploying the Webservice in any corporate environment. Part 3 will demonstrate how to use the Webservice via a PowerShell script.

 

Jeremy Saunders

Jeremy Saunders

Technical Architect | DevOps Evangelist | Software Developer | Microsoft, NVIDIA, Citrix and Desktop Virtualisation (VDI) Specialist/Expert | Rapper | Improvisor | Comedian | Property Investor | Kayaking enthusiast at J House Consulting
Jeremy Saunders is the Problem Terminator. He is a highly respected IT Professional with over 35 years’ experience in the industry. Using his exceptional design and problem solving skills with precise methodologies applied at both technical and business levels he is always focused on achieving the best business outcomes. He worked as an independent consultant until September 2017, when he took up a full time role at BHP, one of the largest and most innovative global mining companies. With a diverse skill set, high ethical standards, and attention to detail, coupled with a friendly nature and great sense of humour, Jeremy aligns to industry and vendor best practices, which puts him amongst the leaders of his field. He is intensely passionate about solving technology problems for his organisation, their customers and the tech community, to improve the user experience, reliability and operational support. Views and IP shared on this site belong to Jeremy.
Jeremy Saunders
Jeremy Saunders

Previous post:

Next post: