Securing the Web Service

Mar 4, 2011 at 12:49 AM

Hi Maik,

we are calling the web service from a deployment wizard at the client which works great. However we need to avoid users having direct access to the web service url. What is the easiest way to do this?

Thanks,

Simon.

Mar 11, 2011 at 4:19 PM

As it is hosted on IIS you can use all IIS features to protect it as all other web pages. You could e.g. disable anonymous authentication and restrict the access to specific users only. Or you could configure pass through authentication in which case the credentials of the calling users would be used to actually execute the functions.

Regards

Maik

Apr 29, 2011 at 4:48 PM

wouldn't disabling anonymous authentication cause issues when calling the web service from pxe? (Sorry if this is a dumb question...not too familiar with IIS).

May 2, 2011 at 7:13 PM

only if you restrict it to windows integrated authentication as WinPE isn't a member of the domain. But as long as you can supply Username and password for your web service call (which MDT will do out of the box) you should be fine.

Regards

Maik

May 2, 2011 at 10:02 PM

Hi Maik,

I'm trying to lock this down from a specific group of users, but even though I have an explicit deny in place for their permissions, unless I actually remove the "Users" group from the folder permissions, then it still allows this one group access to the webservice.  The problem though, is that if I remove Users from the folder permissions, then my PXE webservice calls fail as well (even though I still have anonymous authentication enabled).  Thoughts or suggestions? I suspect this is a permissions issue to work out in IIS, but I'm not sure where to start...

May 11, 2011 at 3:28 PM
Edited May 11, 2011 at 3:44 PM

Doesn't look like you can have anonymous access on at any level and still block certain user groups.  I've tried everything I can from modifying the folder permissions to ASP.NET authentication methods, and things work until you bring anonymous access into the picture.  This is obviously problematic for my webservice calls from PXE.  I know you said that MDT can pass credentials to the webservice if I supply them, but what about passing them automatically without a prompt?  Is there a way to hard code account info for the request?

May 11, 2011 at 4:04 PM

Bump..

Is it possible to integrate Windows Authentication to PrettyGoodFrontEndClone if I would like to restrict access to Deployment Webservice and allow only the users I need to. I was thinking that if I prompt for the credentials in a .hta window and then launch the deployment frontend. I'm pretty green at scripting so any help would be much appreciated. :)

May 11, 2011 at 4:21 PM

One thing I'm looking at right now is ASP.net impersonation...http://support.microsoft.com/kb/306158

My thought is that I could restrict access to all user level objects, while granting permission to administrators and network services.  Then impersonate the network service/admin user when making the web call from PXE.  The only problem (right now, at least) is that I don't know where/which file(s) to insert the code from the KB article

May 27, 2011 at 4:42 AM

FWIW, we ended up using Basic Authentication, and passing the username and password (hashed) for access from within an hta in WinPE. It's not bullet proof, but in conjunction with removing the F8 functionality, users will have a hard time getting interactive access. It works well.

Simon.

May 27, 2011 at 1:56 PM

Simon, I'm very interested in what you've done...just send you a PM...

Jun 7, 2011 at 9:25 PM
Edited Jun 7, 2011 at 10:01 PM
MaikKoster wrote:

only if you restrict it to windows integrated authentication as WinPE isn't a member of the domain. But as long as you can supply Username and password for your web service call (which MDT will do out of the box) you should be fine.

Regards

Maik

Bump!

Hey Maik...Simon sent me info on what he used, and I'm looking over that, but I'm also curious what you mean by your line above?  I haven't been able to find anything on MDT in this regard.

[edit]

I found this in your archive: Using Webservices with authentication in MDT 2010 and you mention that, "You just need to set [the username and password] if you are calling the webservice before the “real” MDT has started, e.g. during Pre-execution Hook or if you use parts of MDT within your custom solution..." though there is no mention of how you would set them (in my case during the pre-execution hook)...can you offer any insight on this?

Jun 10, 2011 at 6:24 PM

Hi Maik,

I found this bit from your article discussing your PrettyGoodFrontEndClone:

"Optional: + UserID, UserPassword and UserDomain to supply credentials in case your webservice is restricted"

I noticed in PGFEC's Cs.ini that there's a section that looks like:

[Initialize]
UserID=
UserPassword=
UserDomain=
DeleteComputerFirst=False
OUParentPath=OU=MyComputer
OULevel=0

and I assume that this section here will allow you to hard code in a username for a restricted web service (or in the case of your Custom Boot Wizard, the SCCM_bootstrap.ini file)?  I haven't had a chance to test this yet, as I'm pretty swamped with other projects atm...but was hoping for a bit of clarification at least.  Thanks!

Jun 14, 2011 at 8:05 AM

You are absolutely right. This will enable you to specify a Username and passwort for a web service call. Seems I missed some important information in my post ;-)

Seems I need to prepare a nice post about securing web services.

Jun 14, 2011 at 2:06 PM
Edited Jun 15, 2011 at 5:51 PM

Hi Maik,

Thanks for letting me know! One other question (the answer may be fairly obvious)...does it matter what type of authentication is enabled on the IIS side?  Meaning, is the MDT scripting for user authentication limited to working with Basic or Windows Authentication on the IIS end?  Just wasn't sure if it needed one over the other.  Thanks!

[edit]

Heh, so much for going from memory...IIS authentication options include Anonymous, ASP.NET Impersonation, Forms, and Windows...guess that really only leaves one obvious choice :)

Anywho, I added the Initialize section to my SCCM_Bootstrap.ini file for the CustomBootWizard and supplied the user, pass, and domain, changed the authentication type in IIS to Windows, and made sure that the user was added to the NTFS security...but sadly it didn't work.  Got the message stating that there were no operating systems available for this site...SO, my next question, what do I need to look at in order to de-bug this?

I can logon as the user I created to make the calls, and can access the web service just fine.  If I try to access the page as a user that is denied access, I can enter the credentials of the web service user and it will work correctly then as well...so it would seem that the user info is not getting passed correctly from within PXE, but I'm not really sure how I would go about testing this...suggestions???

Jun 15, 2011 at 8:59 PM

Ok, looks like I got it working...not sure exactly what it was that made the difference, but here is what I ended up doing to get the CustomBootWizard to work: 1) added the appropriate user/pass/domain info to the CS.ini under the [Initialize] header (the SCCM_Bootstrap.ini file already had this added to it earlier).  2) Under the [Settings] section for both CS.ini and SCCM_Bootstrap.ini I added Initialize to the Priority section.  Looks like I simply missed that from earlier since it had been a while since implementing the web service :)