We currently use a solution with WCF web services with Windows Identity Foundation for security.
It works fine for three years now, but it seems we have certain users (I mean windows users) which cannot connect to WCF.
From the same machine with four different Users, Two can connect to the application and two cannot.
Everybody see the server part (the first call was a wsHttpBinding call to check if server exist, if failed a message is provided else we display the login window) but it failed with services with Authentication(ws2007FederationHttpBinding). It seems to be a problem from Windows User...
Has anybody already encounter this type of problem? Any idea to solve it?
We do not have physically access to the machine (client machine) and cannot make some debug to see where it comes from.
the returned exception is:
Could not start session - Exception: SOAP security negotiation with "My service complete address"
for target "My service complete address" failed.
Related
I face some strange issue in Silverlight 5 on machine which use window 7.
I have a Silverlight app and after deploying it, it works fine on all user machine but on some of user machine it does not working.
For Example My Username : Test and password is Test.
Now when I use this info to login my app on my machine and also some of other machine then it works fine but when I use same info on other machine (Window 7) it does not work.
I have set mesg for invalid login info in wcf service and return mesg to user. I found that when I use invalid logininfo then it display mesg which I set in wcf method.
I also uninstall old Silverlight and install new on window 7 machine but then also not working.
I think there are something which block to response of wcf service. I am stuck into this issue.
Thanks,
Hitesh
I ran into the similar issue once
When you are talking about the WCF service not working on some machines,
the first thing I would check is the time on that machine(some users set their own time, which is different from the standard time in that particular time zone, WCF service just does not accept the requests from these machines) and then the security level of the WCF service and on the User machine.
Hope this info helps..
I built a WCF service that exposes itself for a web application, it accepts an object and prints the data on the clients machine. Works fine on my development machine, and the service is up and running on any machine i install it on. I can enter ip address in clients machine web browser and see it is running. Problem is when i send the object to the clients machine it returns an error, that sounds like it could be because of the clients windows firewall. Where would i start at to deal with this problem ?
There was no endpoint listening at http://192.168.1.168:2202/PrintLabel that could accept the message. This is often caused by an incorrect address or SOAP action. See InnerException, if present, for more details.
And the InnerException: Unable to connect to the remote server
With further research and discussion with people in the community i came to understand that as was mentioned at the bottom of this article.
"Self-hosted HTTP addressing for WCF is not integrated into the Windows firewall. An exception must be added to the firewall configuration to allow inbound connections using a particular URL.
But this SO question led me to a page with how to control Windows Firewall through code to enable my WCF self hosted service to accept an object.
This the link below.
http://www.shafqatahmed.com/2008/01/controlling-win.html
That link was towards the direction i needed, but based on user comments it seemed to have some bugs. A colleague found this link and i believe this technique will be the best solution for this scenario.
Does anyone recognise this error?
The SecurityContextSecurityToken with context-id=urn:uuid:xxx (key generation-id=) is not registered
It has suddenly appeared in the service trace log of my WCF service.
We had a Windows service successfully transmitting data into the WCF service for a day until it broke. The error manifests when the Windows service tries to connect to the WCF service.
It's highly unlikely that the environments changed. The two services exist on separate machines (an application server and a web server). Both are Windows Server 2003 SP1 machines, and the web server is running IIS 6.
Unfortunately, we have scarce access to the servers to help us debug, so any guesses on what might be wrong would be highly appreciated.
Indi
We had this problem with Web Service Extension 3.0, which was used before WCF. I have not experianced this with WCF, but I think that it is worth checking.
The scenario works like this:
The service starts and the user that is the identity of the service gets logged on.
When the service makes a call it is done in the security context of this user
After a while the logon token becomes so old (a day?) that the service will no longer accept it.
The easy way to test this is to restart the windows service.
I have created a WCF service on my local machine. My local machine uses Windows 7 RC1, thus the web server is IIS 7. However, my production machine is a Windows Server 2003 using IIS 6.
When I attempt to reference the service in my local environment, everything works fine. However, when I promote my service to my production machine, and try to reference the service, I receive an error. The error says:
Error: Cannot obtain Metadata from
http://www.thedomain.com/theService.svc?wsdl
If this is a Windows (R) Communication
Foundation service to which you have
access, please check that you have
enabled metadata publishing at the
specified address. For help enabling
metadata publishing, please refer to
the MSDN documentation at
http://go.microsoft.com/fwlink/?LinkId=65455.
WS-Metadata Exchange Error URI:
http://www.thedomain.com/theService.svc?wsdl
Metadata contains a reference that
cannot be resolved:
'http://www.thedomain.com/theService.svc?wsdl'.
Content Type application/soap+xml;
charset=utf-8 was not supported by
service
http://www.mydomain.com/myService.svc?wsdl.
The client and service bindings may be
mismatched.
The remote server returned an error:
(415) Cannot process the message
because the content type
'application/soap+xml; charset=utf-8'
was not the expected type 'text/xml;
charset=utf-8'..
Is there something I need to do in IIS 6 to get a WCF service to work? I'm really confused as to why it works fine locally, but not fine in production.
Thank you!
There are 4 possibilities I can think of:
Some security setting that is blocking access the the service. Check you IIS log for access denied
That the configuration of the services web.config has not been transfered to production
That metadata exchange is not configured with http get allowed
That you are using a newer binding that is not supported on IIS 6
The bindings that are supported by IIS 6 are basicHttpBinding and wsHttpBinding. See:
http://msdn.microsoft.com/en-us/library/cc949086.aspx
Hope this helps
You have locked onto the obvious difference between the two environments - one is running IIS 6 and the other is running IIS 7. That may be a difference, but not the difference that is causing the problem.
Have you compared the web.config files in the two environments?
Judging from the error messages, it looks like WCF is running on the production machine, but that there's a problem with getting the metadata. Have you tried running the service in production? It's possible that running it will work, even if metadata retrieval does not work.
Also, if you don't mind me getting a little philosophical here, you've just found the reason for staging servers. The fact is that there's a much greater difference between "1" and "2" than there is between "2" and "3". Moving from the development environment directly to production, you're encountering issues with "multiple environments" for the first time. This is similar to the difference between singular and plural.
You're also encountering issues with "different environments" for the first time. this is similar to the difference between "same one" and "different ones".
Adding a staging system in the middle gives you the chance to get all these issues out of the way ahead of time, so that when you move from staging to production, you may still have the issue of "difference", but you will not have the issues of "singular vs. plural" again - you will already have resolved them.
I have a Web application and a WCF service hosted on the same Windows 2003 development server. They each have their own IIS website node responding to drs.displayscreen.web and drs.displayscreen.service host headers respectively. The hosts file contains entries for both headers pointing back to 127.0.0.1. The web site has a service reference to drs.displayscreen.service.
Both applications work perfectly when their application pool uses the 'Network Service' account.
I need to perform some COM processing under the hood on the service so I want to run the applications under a customised identity. Both sites run on a new application pool.
When I change the application pool identity to use a new windows account created for the purpose, I get the following (inner) exception:
[EndpointNotFoundException: Could not connect to http://drs.displayscreen.service/Handler.svc. TCP error code 10060: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond 192.168.98.2:8080. ]
192.168.98.2:8080 is the address of a DNS server that is no longer in use. It is not referenced anywhere in the solution. It is not referenced by ipconfig at all.
I have made sure that the new account is a member of IIS_WPG and I have run aspnet_regiis -ga . I have also given the account explicit permission to read the hosts file.
Why does the application attempt to use the defunct DNS server to resolve the temporary url (drs.displayscreen.service) instead of the hosts file entry? It has to be a permission of some sort because it does not have this problem when running under the network service account. Help!!
Well, it appears that the answer might involve a bug in the .Net framework. I found a blog posting that clued me in to the fact that the MS .Net implementation of SocketCache.GetSocket might cache invalid sockets and another one that suggests a workaround/hack in the form of an explicit don't-use-proxies configuration setting.
We don't actually use a proxy server in the environment where this problem cropped up but it appears that SocketCache.GetSocket is overridden or behaves differently when the don't-use-proxies setting is in place. Strangely, removing the setting causes the problem to come back so obviously the SocketCache is not repaired when a valid ip/hostname is discovered and successfully used. According to the author of the first post mentioned above, the bug does not exist in Mono. :)