Deployment Web service 7.3 – Basic security

With the updated Version 7.3 (Download) just being published, the growing number of available functions, covering more and more demands in todays deployments, it’s not only an advantage of having such a huge toolset available. In its default implementation, the Web Service is configured to execute actions under certain user account. While this makes it pretty easy to troubleshoot and verify the functions are working, everyone with access to this web service will now be able to execute actions, he is not supposed to execute.

So you could restrict the access to the web service with the default methods available in IIS. So only authorized users are able to access the web service and by this execute all the actions. Now it could happen that you would like to let them access only a subset of these actions. For example you might want to restrict the functionality deleting computer objects in AD or the possibility to update any property of an Active Directory object. So far the only way to deal with this problem was using pass-through authentication. By enabling this option in the web service, it would take the credentials of the calling user and pass his credentials further to execute what ever he was tasked to do. By this you are able to offer the full bunch of functions to a lot more users. But you can ensure that only the ones with appropriate permission can actually execute them.

One drawback on this solution is a much higher complexity and it’s sometimes very hard to troubleshoot problems. As actually most of the problems you might experience with the web service are security related.

To create some kind of intermediate solution, I implemented a very simple security layer into the Deployment Web Service, that became active with Version 7.3. The basic idea is to still restrict the access to the web service as you did before. But optionally choose the functions you would like to have available. No fancy Role based security whatsoever. Just a plain list of functions that shall be either excluded (supposing everything else is included) or included (supposing everything else is excluded on default). Plus a combination of both.

This can be configured for either all web services at all. Or individually for each part of the web service (AD, MDT, SCCM, SMSCliCtrV2). If a function is excluded, it will neither show up on the page that shows a documentation of all available functions, nor will it be possible for anyone to call it, even if knows the name and correct properties.

Let’s start with an example. On default, the web service excludes the following Active Directory Functions that could be pretty dangerous if they can be used by anyone:

  • DeleteComputer
  • DeleteComputerForced
  • SetComputerAttribute
  • DeleteUser
  • DeleteUserForced
  • SetUserAttribute

To store this information, a couple new Application Settings have been added to the web.config. You can edit them either directly in the web.config. Or use your IIS Manager


As you can see. There are two generic include and exclude settings (IncludeFunctions, ExcludeFunctions), that will be used for all web service parts. On default all functions are included ( * ) on default. If all settings are empty, which will probably happen if you upgrade from a former version, everything will be available on default. This is to ensure backwards compatibility. So if you upgrade from a former version to 7.3 without updating the web.config, Functions like DeleteComputer might be exposed to the public.

The second setting with a value is called “ExcludeADFunctions” and is filled with a comma separated list of functions, available in the web service part covered in AD.asmx. All of these settings follow the same naming convention and are hopefully pretty self-explaining.

Excluding a function will always overrule everything else. So be sure to type in all the functions you would like to not be usable within your environment. If you would just like to just use some very few functions, excluding so many might not be the best option. In this case, just enter the ones you would like to use in the appropriate “include” setting and be sure to remove the “*”.

The combination of these settings should allow you to cover the most “basic” security demands between the former “Nothing or All” and the very individual “pass-through authentication” approach. However, it will not be able to cover more complex security demands.


If you experience any issues with this new security model or have some great suggestions for further extensions, just get back to me or start a new discussion on the MDT Customizations CodePlex project.

Das könnte Dich auch interessieren...

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.