I have an ASP .NET webpage which calls an ASP.NET webservice existing on the same site. Both of them require integrated windows authentication.
I get the following error during invoke of the webservice method when I run my webpage:
"The request failed with HTTP status 401: Unauthorized. "
I have no clue why it is failing. Is there a way to know which authentication protocol is being used from the website to invoke the webservice method, and why it is failing?
EDIT : As suggested, I downloaded auth diagnostics, and monitored it when i ran my webpage. Following is result:
AcceptSecurityContext
Package=NTLM Result=0x0 ContextAttr=0x12001c UserName= ClientName= ServerName=Result=0x0(Fail: context has ASC_RET_NULL_SESSION flag)
Main process: Finished, 1 issue detected
Have you gone through the Microsoft Troubleshooting HTTP 401 errors article?
How is IIS configured? Is it set up to use anonymous or Windows Auth? Also, what context is the app pool using? Perhaps the web is running under a context that doesn't have permissions to hit the web service?
Related
I have a MVC web application and a console application created as a separate project inside my web application. I want this console application to be run as a windows service at specified intervals. The console application is for sending mail to some persons. I need to include my application URL in the mail content body which redirect to my application login page. Since i am running this service for more than one instance i could't hard code the URL in code. Someone please help. I tried the below code. But it is returning null value.
var site = HttpContext.Current.Request.Url.Scheme + "://" + HttpContext.Current.Request.Url.Authority + HttpContext.Current.Request.ApplicationPath.TrimEnd('/');
var url = string.Format("<a href='{0}'>Login</a>", site);
I converted this from the comment to the question.
You are trying to obtain information from HttpContext.Current in situation when there is no HttpContext available at all - because your console application is launched directly by the operating system and not on the event of incoming http request (as oposed to request handling in your MVC application) - so there simply is no http context to use (hence HttpContext.Current is null in your console application).
You have to establish your own application logic for your console application that determines which URL to use in your emails. What would that be depends on the answer to the question "what does the url to be used in each email depend on specifically"? In other words - "how should each email know what URL to use"? Once you figure out the answer to that question then you can think of how to pass that dependency to your windows service.
Example (I do not know if it describes your case):
there are several web applications on different URLs
each of these web applications can add email to the queue to be send
windows service (console app) is scheduled to run once in a while and process the queue by sending the emails. Each email has to have an URL of the application from where it was added.
Assuming the example above you can just add the email together with the URL of the application to the queue (insted of just the email) and then retrieve that information from the queue in your console application. So then each of the emails has associated URL. It is irrelevant how would the queue itself be implemented (SQL, file, ...).
I am currently receiving a 500 error message when trying to connect my .NET WPF application to a server running SignalR that is self hosted with OWIN. I have tried setting the EnableDetailedErrors to true in the hub configuration. I have also tried OnIncomingError in the HubPipelineModule. Neither have worked. Any other ideas on how I can see the specific error?
You can use the IAppBuilder.UseErrorPage() extension method to see exception details instead of a blank 500 response. This method is available via the Microsoft.Owin.Diagnostics NuGet package.
Make sure you call UseErrorPage before calling MapSignalR or adding other middleware that may throw an exception.
More information on UseErrorPage can be found in the Add OWIN Diagnostics section of the following article: http://www.asp.net/aspnet/overview/owin-and-katana/getting-started-with-owin-and-katana
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
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.
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.
I have created an .NET 3.5 web service application project that will be hosted under IIS 7.5 on a Windows Server 2008 R2 server.
I am able to consume the service from an ASP.NET application hosted on the same server and other server throughout our network without any issues. When another employee tries to consumes the service using the SOAP protocol, they receive the following error:
XML Parser failed at linenumber 0, lineposition 0, reason is: Access
is denied.
The authentication configuration is set to Integrated Windows Authentication and the consumer will need to provide a service account's credentials when trying to consumer the service.
Has anyone else experienced this issue and do they know how to resolve it?
UPDATE
After speaking with my co-worker and vendor's customer service regarding consuming my web service, they revealed there are limitations within their INVOKE SOAP step. According to the vendor:
The Invoke SOAP object cannot interpret WSDL's containing In/Out
parameters if the WSDL message definition contains identical part
names for the input an output messages and identical data types.
The web service API contain a method and output parameter that were the same name. If you look at the web service method in a browser, it had the following structure in the response:
<soap:Body>
<MyServiceResponse>
<MyServiceResponse>
<property>...
The question now....Is this a common behavior while using the SOAP protocol or is this just limited to how vendor's product parses the SOAP message?
This appears be a vendor-specific weakness, not a SOAP specification issue. They likely have a half-implemented SOAP stack.
So I'm trying to iterate over Response.Headers for a custom caching job, but I'm getting the following error when I touch the thing:
This operation requires IIS integrated pipeline mode
It this possible to do in IIS6? Is there a workaround?
var allHeaders = HttpContext.Current.Response.Headers;
// error thrown as soon as it's accessed
AFAIK you cannot access the HTTP response headers unless you are running in integrated mode because they are sent by the server at a later stage of the execution of the request when running in standard mode.