I'm having a bizarre issue where I'm hitting a WCF service on a remote machine (still in same domain) and it's saying I'm logged in as someone else. On the client side, if I check the Principal.WindowsIdentity.GetCurrent(), it says I'm "COMPANYNAMEHERE\Albert". But when it goes over to the server side, it says I'm "COMPANYNAMEHERE\Albert_Admin". I've had 3 other users test the service and they authenticate fine, it's just me that has this issue.
I've had other devs log onto my machine and they're fine. I've hit other WCF services as my account with the same problem.
The IT folks are stumped, as am I. Anyone out there know what might be causing this?
Turns out something in my local desktop profile (I don't know what) was causing integrated security to resolve me as my _Admin account. I had tested my login on a co-worker's machine and everything worked fine. So my network admin suggested I wipe out my local profile and that seemed to do the trick.
Related
I have a very weird problem.
We have a Hyper-V failover cluster, where some guest VMs start to show specific problems after a live migration.
In each case, the live migration mostly works, but after it has been migrated, we can't log into some software (our product WinGate) any more. The SSPI handshake succeeds, we can RDP to the image, so it's not networking.
But ADSI fails to open a search object to retrieve a user object, and gives error 8007203A.
Since networking is working, SSPI is working, obviously domain connectivity is working to some degree, but the ADSI failure is very perplexing.
Has anyone else seen this? I feel it's most likely a bug in Windows, but we have been seeing this for over 18 months now - since we set up the cluster.
P.s. all hosts and VMs are 2k12R2 fully patched.
P.p.s. all VM MACs are fixed.
OK, looks like I found the answer.
Problem is NLA reclassified the domain network adapter after a live migrate, and set it to an unidentified network. This then kicked in the firewall to block ADSI.
thanks to this blog I was able to force NLA to view the adapter as a domain adapter (by adding a domain DNS suffix to the adapter), and the problem is solved. Hope this helps someone else!
I've recently stumble across this problem but cannot fins a reason for this and a workaround.
I've logged on with my domain admin account on a server (Windows Server 2008 R2) and started a service that were set to start manually. After wards when another user with a domain account logged on and had a look at the service as were experiencing problems it showed that the service were in the stopped state although in my session which were still open it showed that it started.
He started the service and everything work after that.
Can anyone shed some light on this for me? And on what to do rectify this or have a workaround for this?
Appreciate you comments and suggestions.
Your service does not to answer correctly to the SCM with SERVICE_CONTROL_INTERROGATE and it span another process with the StartServiceCtrlDispatcher(DispatchTable).
We can't do anything there unless you patch your application or contact your software vendor.
I rented a server for a month to try some things out. I'm fairly new to servers and everything and trying to learn. I now want to have projects on this server using VisualSVN.
I've installed VisualSVN and added some users to gain access to these repositories. However, everytime I try to login, the authentication window keeps popping up (no matter what I fill in as a username and password).
How do I solve this issue? I'm unable to connect to the repository due to the login window popping up forever after entering the username and password.
I've been having the same issue! (RESOLVED!!!)
The way I fixed the problem was to change some firewall settings on the server.
If you go into windows firewall settings and make two new "rules" (one for inbound port 443 and one for outbound port 443), you should be good to go. Allow the connection for all networks (public, private, etc.).
After I changed this, I only had to authenticate once and checkout worked fine.
Let me know if this works!!! This problem was killing me.
I have a WCF service hosted in the IIS (IIS 8). The service is in a Per Call Mode and the concurrency mode is set to Multiple. I have around 600 clients connecting to it. It has a HTTPS end point. It also has a net.tcp endpoint but that is not used. Not all but some of my clients face a very weird problem. The client stops working after using for a while. I have error logging and at the client side I see the error which says
There was no end point listening at ...
There are no errors on the server, or the service. The service seems to be working fine. I can browse to the service page from a browser and other clients are still able to use the service. Running a trace is also not helping. I have spent enough time trying to figure it out but with no luck. Further more, on the same computer just restarting the client seems to work and connect to the same service. The client is a WinForms Application.
I performed a DNS flush on my machine and even that does not help.
What could be the possible issue? The things that hit my mind are that maybe the client is unable to resolve the name, but that is contradictory to it connecting in the first place.
The service maybe down, but my other clients are still using the same and they do not face problems.
It might be a problem with the client machine as it Uses Win XP but I am not sure if that would cause a problem.
Or it might be a problem because of intermittent internet connection.
Has anyone ever faced such a problem before? Some insight would be really helpful
IIS can only serve a limited number of clients at a time. It will then place additional requests onto a queue. That queue is also limited. When that queue fills up then IIS returns a 500 error, which is interpreted as "There was no end point listening at ..."
You should try this piece of code.
public void Main()
{
while(thereIsStillThisProblem)
{
var pc = new Pc();
pc.OS = new Windows2012();
pc.Start();
pc.Software.Add(new ServiceHost());
}
}
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/iis/64e30660-d2f0-4e90-98cc-1652214a2b93.mspx
Edit: Just remembered that there is one more thing you can do, if you are using .net 4.5. I will let Jon Skeet explain.
I've got a working WCF service and a working Delphi client. On a normal PC, they work nicely. On a VM that's "Bridged" they work nicely if I log onto the domain (but not if I logon locally to the VM as administrator). If the VM is NATed, the connection attempt times out.
I would love to hear people's thoughts on what could be making such a difference to whether the client can successfully connect to the WCF service. Bear in mind I'm connecting with basicHttpBinding with no security.
The service is setup to use System Account (interact with desktop is NOT checked), and it starts automatically. The service URI doesn't change, the port is open, and can be telnet'd to in all scenarios.
Any ideas or pointers?
Within the VM, open Internet Explorer and verify that you can view the WSDL of the WCF service. If you can't, then your issue is connectivity and has nothing to do with your Delphi code.
Group Policies and Enterprise Security solutions that swap certificates or require certificates to be registered (we're using a UTM called CyberRoam) make a difference.
Also when Virtual Machines join a domain, their ComputerNames are added to a list maintained by the Domain Controller. When the same Virtual Machine is "moved" or "copied", its ComputerName should be changed to avoid DNS resolution issues.
I'm not claiming this as the definitive answer, however it does explain the issues I noticed in this instance.