Is there any way to log on to a Windows machine using WCF and C#? I am creating a Test Harness and it will needed to remotely logon a Windows user.
So far we have not been able to do it successfully as once the user has been log off from the machine, self-hosted WCF is shut down.
your problem is that you are hosting the service as a console app. When the user logs off, the app stops.
Host your service in a windows service, which will enable it to start and run without a user being logged on.
MSDN on hosting in a windows service
as a tip, in the OnStart method add the following line:
Debugger.Launch();
and a using statement:
using System.Diagnostics;
if you have problems with the service starting and immediately stopping. This should allow you to attach a debugger to the service as it is starting to debug the issue.
Using supplied credentials on the web end you could try logging in via WMI? but, it does depend what you intend to do to the remote machines - other option would be a client on the remote machines
Related
I have a small tray app which should inform the user about start and stop of an execution of an other process running under local system account. The process running with local system account is called by another service (not owned by me). "My service process" is always running just for a short time. So I can not implement a wcf callback handling. Everything works fine on my machine. But it is not running at the customer side.
The problem (exception) which occurs at the customer side is something like "there is no endpoint listening on net.pipe..."
But the tray is running.
I created a test app (console) to communicate with the tray. This works fine.
If I start this test app with psexec -I ... to run it with a local system account it is also running.
I have no idea about possible reasons and so I have two questions:
is it "allowed" to host a wcf service in a tray app (running in user context) and call it by a process running in local system account?
if yes, is there a possible policy/security setting which can prevent this functionality?
The only workaround I could think off is to create a helper service which I can use as some kind of a broker (connect from tray with a callback interface which could be used by the other process). But this seems to be a big overhead...
The answer is, it is not possible.
The reason is explained here: Connecting via named pipe from windows service (session#0) to desktop app (session #1)
It looks like my test was successful, because psexec was still running in session #1.
My implementation is now using the already above described workaround
I have a Web API using OWIN for OAuth, running in Katana/TopShelf.
When I install the Web API as a Windows Service, everything responds correctly, except a POST via resource owner flow (grant_type=password, username=x, password=y) returns 400 Bad Request (invalid_grant).
The exact same Web API, running in the same folder, except this time running in Command Line mode, using the exact same request from the same remote address, is successful.
The only delta is whether I run the .exe file directly in Console mode or I install and start it as a Windows Service.
I have to think this is a conflict at the network level but Windows Service is just acting as a thin host around the same HttpListener based host.
Whenever we see an issue like this with Topshelf it is almost always permission related. There's some resource that you have rights to but the service user doesn't. Are there resources on disk the service accesses or something similar?
We have a .NET Windows Service that occasionally shuts down on one particular server, about three times in the last month. Logging shows that the OnStop method is being called, so I don't think the service is crashing. However, we don't know what's shutting down the service.
Is there any way to find out what's shutting down the service? Is there anything I can log during OnStop? The Windows Event Viewer just shows application shut down and the security log does not show any user account authenticated at the time.
The service is running in .NET 3.5 SP1 on Windows Server 2003 SP2 (5.2.3790).
There are no service dependencies. This service doesn't depend on any other services and no other services depend on this service.
There is no way to tell from within the service since this called from the SCM - whoever asked SCM to stop your service isn't visible to the service...
I think your main option is checking the EventLog around that time... are other services being shutdown too ? is any scheduled taks running etc. ?
A "rather dirty" option (last resort/desperate) would be to set CanStop to false... in this case there will be someone seeing a problem in stopping your service and "hopefully" ask you why your service is not stoppable...
From my limited experience, permissions and security can tend to cause all sorts of problems for windows services.
Under what account does the service run? (E.g. System account, network service etc).
Something I've had to do in the past is setting up the service to run under a network account with appropriate permissions. You can do this from the Properties window (right-click on the service in the 'Services' management console. In the Log On select This account and choose the account you want to use and enter the account password.
Is it possible to spawn a process on a remote server, from a WCF service hosted as Windows Managed Service, when the service is running as LocalSystem?
I need people to be able to execute things on remote servers under the context of their own accounts (basically like PSExec - which isn't an option).
I've made some half-hearted attempts to do this before, but when using process.start, cannot get the process to run as a specific user, if the Windows service hosting the WCF component is running as LocalSystem.
I know this can be acheived by other methods, but I specifically would like to know if the above is achievable - Windows service running as LocalSystem & hosting WCF service, then spawning a process as a specified user.
Thanks
Mick
You could use the Process.Start method which allows you to specify the user under which the process will run.
We have encountered a very strange situation when we deployed an application at a customer site. This application is implemented as a service using C# on .NET 3. The application communicates with a web service that is written using gSOAP. In our .NET application, the classes that wrap the web service were created by performing "Add Service" in Visual Studio and referencing the WSDL. Communication is performed using HTTPS, but using port 35000.
What we are seeing is that when our application runs as "Local Administrator account" everything works well. However when our application runs as any other account, including "Local System account" and even a user account with network admin privileges, web service method calls sometimes time out. Other times they succeed but after a very, very long time, e.g. 100 seconds instead of less than 1 second as expected.
This customer is using Cisco switches in their network.
We have not encountered this behavior at other sites. Any insights or suggestions would be greatly appreciated.
Does the customer have BI rules on the firewall hardware? (I'm grasping at straws, but we got similar behavior from one of our clients consuming one of our services a few years back because they had enabled some funky BI rules on the firewall.)
Any event log messages for timeouts, exceptions, etc?
Is the application a windows service? Are you using RunAs to run under a different user context? Does it require desktop interaction or have any references to System.Windows.Forms?
#Comment 1:
Windows service, Web Service, WCF Service?
Enable security auditing for both the local and remote machines for resources the service is likely to use.
Another thing is to add debug level logging like this... (Sorry for the pseudo VB)
Sub OnStart(args())
LogToFile("Starting Service, processing arguments")
'process args'
LogToFile("ArgsProcessed calling main worker method")
'call main worker method'
End OnStart
Sub LogToFile(message as String)
If (AppConfigKeys[debugLogging] = True) Then
'writes "DateTime.Now.ToString() & "-" & message" to a text file log'
End If
End Sub
Embed this kind of logging into the application before and after any process that is likely to fail.