I am getting the following error message when trying to call my service from another server.
Service cannot be started.
System.ServiceModel.Security.SecurityNegotiationException:
The caller was not authenticated by the service. --->
System.ServiceModel.FaultException:
The request for security token could not be satisfied because authentication failed.
in my Event Viewer when I tried to connect the client to the server.
I enabled tracing in the server and it looks like the
System.IdentityModel.Tokens.SecurityTokenValidationException is being thrown. The message says "The service does not allow you to log on anonymously."
I checked IIS -> WCF website and I do have the "Enable anonymous access" enabled.
What am I missing?
Is another security setting enabled besides the anonymous?
If you have anonymous selected and another, and have basic or some other type selected you will run into this issue. With WCF you are pretty much limited, while hosting in IIS, to a single security authentication model.
If you could elaborate a little bit I could possibly provide a better answer. :)
Related
I have published an orchestration as a WCF web service using WCF_WSHttp bindings. I think we about the SSL certificate working. It will be open to the internet, thus anyone who knows the URL could call it and pass data; so we want to add user/pass authentication. We simply one the one client/vendor to have the ability to call this webservice, no one else.
I've been reading everywhere, and cannot find any specific steps.
I think I want something like Scenario #4 here: https://seroter.wordpress.com/biztalk-and-wcf-part-ii-security-patterns/, but I cannot see how he got the "Client Credentials" box to pop-up in BT-2010.
Best I can tell is I have to:
1) In BizTalk Admin Console - set Security Mode to TransportWithMessageCredential.
2) From here: https://msdn.microsoft.com/en-us/library/bb226482.aspx, I'm a little confused about the difference between Windows and Username. An outside vendor is calling our webservice, so they are not on our domain. Do I need to set up a service account? Or can I just make up a username and insert it here somewhere?
3) Do I have to make corresponding changes to the WCF web.config that was created by the BT-2010 "WCF Servcie Publishing Wizard"
It seems like your're looking for just Basic authentication on the transport layer? All you then have to do is to create an AD user or a local user on the BizTalk machine and set the Transport client credential type to Basic.
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.
I am trying to write to a file on a server (web05) from a classic asp site running on Windows 2008 serer on IIS7 (webadmin). This fails and web05 logs an anonymous logon attempt during the course of the save operation.
Webadmin's site is running on an app pool in classic mode with a domain user as the process account. The process account has rights to "Trust this user for delegation to any service (Kerberos only)". The same applies for the web05 and webadmin servers.
The site is using Windows Authentication and the idea is that when I log on the site with my domain user, the rights of my user should define what I am allowed to do in the context of the IIS site. If I turn on Basic Authentication, everything works fine.
I have also used setspn.exe to add an SPN for the URL. If I type setspn.exe -L webadmin, I get:
HTTP/webadmin.companyname.com
TERMSRV/webadmin
TERMSRV/webadmin.companypub.local
HOST/webadmin
HOST/webadmin.companypub.local
So from what I understand the SPNs are set up correctly.
If I run processmonitor on webadmin while the save operation is executed, it says that the process is indeed impersonating my domain user - but getting "Access denied" (and as I said before, web05 logs an anonymous logon attempt).
Any idea what causes this?
Kind regards,
Simon
It sounds to me like you're a little confused over impersonation. The process isn't impersonating the domain user account its simply running as that user. There is a difference.
When a request arrives into ASP it will then impersonate a user and the thread handling the request will be running under the security token of the impersonated user. Its quite possible to have the same process impersonating multiple different users in multiple threads. In most cases where the anonymous user access is enabled this user is the Guest level IUSR account. Its most likely that its under this user your code is attempting and failing to run.
However if anonymous is turned off for the resource being accessed or the IUSR account does not have access to the resource then the a 401 response is sent back, with some indication of what authentication protocols it will accept. The browser may then attempt to authenticate the connection using either the current users credentials or request some credentials from the user.
You don't specify exactly how you are attempting to save file. Its worth pointing out couple of things though.
ASP code exection which may subsequently result in an access denied will not use the above mechanism to try to resolve the user.
Once a connection is authenticated it often continues to be re-used for subsequent requests (which is counter-intuative to the knowledge the HTTP is a "connection-less" protocol).
I am trying to clean up my previous questions. This answer is not sufficient to answer the question above, but I concluded that it is better to provide some insight than none. If op disagrees, please take necessary action.
This is a way back - but I recall wanting to run kerberos authentication on this app. The problem turned out to be that I tried to do kerberos outside the firewall. The app would work fine within the domain and firewall of the server's home domain but failed whenever requests came from outside.
I did a lot of chatting with an Irish technician in Microsoft, and he taught me a little about the limitations when using Kerberos. The reason I wanted to use Kerberos was that I didn't like the thought of Basic Windows authentication being unencrypted.
Good luck with your Kerberos quest :-)
I ran into this same issue and it turned out to be a simple change to the application pool. If enable 32-bit applications is set to FALSE then I recieved a prompt to login to the machine. Setting this value to true fixed the issue.
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