HTTP Error 401.1 when using WinHttp.WinHttpRequest.5.1 in classic ASP site

Question

General information

Operating System: Windows Server 2003 R2 Service pack 2

Webserver: IIS 6

NTAuthenticationProviders: NTLM only

Webapplication: Classic ASP

Browsers used: IE7, IE8, IE9

There’s a Classic ASP web application called knowledgebase, within an IIS website called eblcplaza like so: eblcplaza/knowledgebase/.

eblcplaza has anonymous access AND Integrated Windows Authentication enabled. knowledgebase has anonymous access disabled and Integrated Windows Authentication enabled

knowledgebase is a Classic ASP application has its own Application pool which runs under the predefined Application pool identity “Network service”

When I’m logged in with my NT account I can access any page I want just fine. The problem is with the WinHttp.WinHttpRequest.5.1 component. It’s used in some parts of knowledgebase to do a server side request to retrieve content from some .asp scripts which reside within the web application.

The problem started when Anonymous access was turned off on knowledgebase . Note, turning it back on is not an option.

Example of a request using WinHttpRequest:

set WinHTTPRequest = Server.CreateObject("WinHttp.WinHttpRequest.5.1")

WinHTTPRequest.SetTimeouts 20000, 20000, 20000, 20000

call WinHTTPRequest.Open("POST", someUrlToAspScript, false) 

WinHTTPRequest.SetAutoLogonPolicy 0                 

WinHTTPRequest.setRequestHeader "Content-Type", "application/x-www-form-urlencoded"

WinHTTPRequest.Send strQueryString

Response.Write(WinHTTPRequest.ResponseText)

With SetAutoLoginPolicy set to 0, I get the following error message on the pages where WinHttpRequest is used:

You do not have permission to view this directory or page using the credentials that you supplied. HTTP Error 401.1 - Unauthorized: Access is denied due to invalid credentials. Internet Information Services (IIS)

With SetAutoLoginPolicy set to 2 (Do not automatically send user credentials according to MSDN), I get the following error message on the pages where WinHttpRequest is used:

You do not have permission to view this directory or page using the credentials that you supplied because your Web browser is sending a WWW-Authenticate header field that the Web server is not configured to accept. HTTP Error 401.2 - Unauthorized: Access is denied due to server configuration.

I know for a fact that my NT user account has the proper rights to access those .asp scripts and so does the Network Service account.

I tried figuring out what could be the problem for several days know, tried setting the NTAuthenticationProviders to only NTLM and both Negotiate and NTLM amongst other things, but nothing worked so far.

Please help me out, It’s starting to drive me crazy.

Regards,

Bart

Answer 1

I guess the pages in knowledgebase are accessed with the anonymous account where you start from at eblcplaza. Try to enable NTLM only on the page in eblcplaza where you use the request, you can do that on that file only. Like that your credentials get passed to knowledgebase. On both pages log the Session("username") variable.

Answer 2

First of all let's clear up what it is you asking the server to do. It will have demanded your credentials from the client with which it is now impersonating you for security purposes. The WinHTTP request it is making to a service (WinHTTP doesn't know that its the exact same application) that now demands credentials. What you want this impersonating thread to do is use your creds to authenticate against an "external" service.

I suspect that what is happening here is that the server is not cleared to re-use your credentials in this way. If I recall correctly (which may not be that certain) a server needs to be granted the right to delegate in order to do that. It may also be possible to allow this if Kerberos is used instead of NTLM to perform windows integrated security.

However all that may be academic. You should understand that an app making a http request to itself has the potential to hang when under load in a way that would require a recycle to release.

Consider this alternative. Given that ServicePage.asp is a page used both directly by the browser and by an internal ClientPage.asp do the following.

Rip out the service code from ServicePage.asp and place in a VBScript class in a new ServiceInclude.asp. Now add the this ServiceInclude.asp as an include file in ServicePage.asp where ServicePage.asp only contains the plumbing necessary to instance the class and use it to generate its output.

Modify ClientPage.asp so that instead of attempting WinHttp to ServicePage.asp it simply includes the ServiceInclude.asp, instances the contained class and uses the class to provide the service required.