I recently created a web service which all worked fine until I moved it from my local PC to our development server. I now get a HTTP status 401: Access Denied message when I try to connect from a small test website. I googled around and found the following code:
SoiisdevJobService.JobsService jService = new SoiisdevJobService.JobsService();
jService.Credentials = System.Net.CredentialCache.DefaultCredentials;
And it now works, but I'm not sure what this code actually does. Can someone explain it to me? I'm using IIS 6, Windows auth, and in my config I've set the auth mode to Windows and to deny non-authed users. In my small test app I've set the same in my config.
Why do I need to provide the code above? I expected this to just work.
It is because you have turned off access for non-authenticated users. See the quote below from the Microsoft website (http://support.microsoft.com/kb/811318/EN-US):
When Anonymous access authentication is turned off for the Web service
application, all the caller applications must provide the credentials
before making any request. By default, the Web service client proxy
does not inherit the credentials of the security context where the Web
service client application is running.
Related
I am getting an "Access is denied" error on a 2012 R2 server when my web app on that server tries to access a self-hosted WCF service on that server using named pipes.
I do not have this issue on my development machine (Win 7). I can access the WCF service via the client test app on both the server and my development machine.
If I enable ASP.NET Impersonation on the web site using a user account that has full control permissions to the install folder for the WCF service, then the error goes away. I do not want to use impersonation since I understand it has significant performance penalties (not to mention security issues) and the WCF service is called for every user input during a session.
The strange thing is... If I set the app pool to run as either the user with rights to the service folder as described above or as a user with admin privileges, then I still get the error if ASP.NET Impersonation is disabled. The error will go away only after I enable ASP.NET Impersonation on the web site.
I do not have access to the source for the WCF service.
In this case, the web app was located on the D:\ drive and the Anonymous Authentication user (IUSR) did not have RX permissions to the web app location.
Note that if you are using Windows Authentication, then the same issue occurs if the Windows Authenticated user does not have RX permissions to the location of the web app.
The problem was resolved once I gave the authenticated user the proper permission.
Sometimes the solution really is just plain simple...
"Ain't got no gas in it" - Slingblade.
The request failed with HTTP status 401: Unauthorized.
When I test in the browser it works, but when I call it from another application I don't have access. What to do? The application where the webservice is using windows authentication. It's propably there the problem is, I suppose!
I solved it:
They are on the same domain but not on the same application. I pass
the authentication with the webservice call:
cm.Credentials = System.Net.CredentialCache.DefaultCredentials;
Windows Authentication for a web service provides some challenges; the web service would need to be on the same domain for that to work I believe, so that it could use the user's credentials.
Do you have to use windows credentials? Using a ticketing system, which requires the user to first login through another web service method, can work just as well.
I have implemented web service with Basic Authentication with .Net 4. To implement basic authentication I have implemented HttpModule. When I call my web service via Internet Explorer, it prompts for Username password, I enter valid username/password and it works perfectly fine.
However when I deploy me web service on Dev Environment and call my service in internet explorer. That gives me user prompt; I enter valid username/password but it keeps prompting me username/password, eventually after three tries I get Error message 401.2 - access is denied.
My Authentication settings are:
Anonymous Access Enabled
Basic Authentication Disabled
Windows Authentication Disabled
In my HttpModule every time User is authenticated, I log if authentication was successful. And I can see in log file, all three times authentication was successful. But it still error out. :(
By the way If I run web services in Integrated mode, it works fine. Unfortunately my requirement is to run web services in Classic mode.
Environment Details:
OS: Windows Server 2008 R2,
IIS: 7.5 Classic mode
I am stuck with this from last 4 days. Please help!
Call me crazy, but wouldn't you have to have Basic Authentication Enabled to be authenticating anyone successfully?
I'm guessing that you have identity impersonation turned on and anonymous turned on which is causing your ASP.Net application to execute as the "IUSER_" account. The "IUSER_" account does not have access to a specific resource you are trying to access (could be API call, file, bla, bla).
If you do have identity impersonation turned off and you have anonymous turned on then your ASP.Net code should be running as the application pool account. Which means that account does not have access to a specific resource you are trying to access (bla, bla, bla).
Here is an old skool MSDN article that discusses IIS and ASP.Net security. Like I mentioned it is old, but the concepts still ring true.
I have a web service running in IIS 6.0 on Windows 2003. It's authentication mode is Integrated Windows security (anonymous disabled), and authorization is done with Authorization Manager and an XML authorization store. My test user is a domain user (admin, actually) with membership in an authorized role.
I am testing this (for now) on the web server (localhost), and using (for now) Internet Explorer to access the web service (.asmx).
I can successfully open the web service (wsdl) page through localhost, like this:
http://localhost:8080/MyService/MyService.asmx
Using this url, integrated windows authentication succeeds (silently), and I am sucessfully authorized by AzMan to access the service. The same goes for the server name:
http://myserver:8080/MyService/MyService.asmx
Now I need to use the external host name (www.mysite.no) to access the service (this in order to get ssl to work with a certificate issued to that sitename). To do this, I add the host name to my HOSTS file, like this:
127.0.0.1 www.mysite.no
...then type this into IE:
http://www.mysite.no:8080/MyService/MyService.asmx
What happens then is that authorization fails. I get the IE/Windows login box and enter my correct credentials three times. Then I get a 401.1:
HTTP Error 401.1 - Unauthorized: Access is denied due to invalid credentials.
Internet Information Services (IIS)
How is authorization through AzMan influenced by the host name?
Edit: I have reason to believe AzMan has nothing to do with it - it seems to be the authentication that fails.
I have reproduced the problem on another server. The essence seems to be that accessing localhost via an entry in the local host file somehow messes up the integrated windows authentication between the browser and IIS.
I have worked around the problem, now my curiosity is all that's left...
Enable audit login failure auditing & check the security event log on the host.
1) On the webserver, go to Control Panel, Administrative Tools, Local Security Policy.
2) Go to local policies, audit policy. Add failure for 'audit logon events'.
3) Close the MMC. Open a command prompt and type gpupdate.
4) browse to http://www.mysite.no. You will get the error again.
5) Launch event viewer (control panel, admin tools, event viewer). Navigate to the security event log and look for the login failure(s).They shoudl tell you something descriptive, like 'the user has not been granted the specified logon type'. Unfortunately the login type itself is not descriptive; logon type 2 is interactive (locally), 3 is 'access this computer over the network', 5 is 'logon as a service' (NT service, not WCF service). The rights required can be granted in the local security policy.
Also, check to see if you have a proxy enabled in IE. If your traffic is being routed to the proxy, it is possible that the proxy does not support NTLM. Add the host as a proxy exception while you test using IE.
My first guess is that it's not the host name.
The first thing to do is narrow down the problem as there are a couple things that could be going wrong.
First set the IIS site to anonymous access, and make sure you can pull up the web service. That will verify that you're accessing the right IIS web site and it's truly narrowed down to an authorization problem.
Also, check the Application Pool credentials, and the security settings on the file folder containing the web service as these could be contributors.
I'm getting a 401 (access denied) calling a method on an internal web service. I'm calling it from an ASP.NET page on our company intranet. I've checked all the configuration and it should be using integrated security with an account that has access to that service, but I'm trying to figure out how to confirm which account it's connecting under. Unfortunately I can't debug the code on the production network. In our dev environment everything is working fine. I know there has to be a difference in the settings, but I'm at a loss with where to start. Any recommendations?
Have you looked in the IIS logs?
I would also recommend looking in the Security event log on the server for authentication failures. You should find a footprint of the failed authorisation attempt here. Be warned though - it is not unusual to get 10s of security events a second, so ideally you need to be able to access the event log as the requests are failing.
If you do not specify which credentials to use in your ASP.NET page when you instantiate the web service then I believe it defaults to NT_Authority\Anonymous.
If you're using System.Net.CredentialCache then your web service needs to be in a trusted domain, accessed over HTTPS and using either NTLM, Kerberos or Digest Auth otherwise it does not pass the credentials from the cache.
http://msdn.microsoft.com/en-us/library/system.net.credentialcache.defaultcredentials.aspx
http://msdn.microsoft.com/en-us/library/system.net.credentialcache.defaultnetworkcredentials.aspx
http://msdn.microsoft.com/en-us/library/system.net.credentialcache.defaultcredentials.aspx
Perhaps the production server uses a different user for its application pool than your dev environment? I once spent a day figuring that one out. Another option would be the (lack of) impersonation in the web.config