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:
- 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.
- Authentication – Disable anonymous authentication. That should be a no-brainer!
- Authorization Rules – Only allow specific users access.
- 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.
- Setting NTFS Permissions on the DeploymentWebservice folder for the worker process identity.
- Optionally, you can also exclude some of the higher risk AD Functions.
- 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.
The Web Service only requires two extensions to function correctly:
- DLL extension (dll)
- Web Service extension (asmx)
The Web Service only requires two verbs to function correctly:
- GET
- POST
2) Authentication
- Disable Anonymous Authentication
- Enable Windows 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.
4) Changing the authenticatedUserOverride setting to UseWorkerProcessUser
- Open Configuration Editor
- Select Section: system.webServer/serverRuntime
- Change authenticatedUserOverride from UseAuthenticatedUser to UseWorkerProcessUser
- Select Apply
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
- 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
End state permissions will look something like the following screen shot.
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.
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