I am running a Dotnet 3.5 executable in Windows 7 Ent, as a GPO computer startup script in a domain. The script resides on a network share. The exe is run as Local System. The exe runs correctly.
I would like to access a web Service in this exe, but it appears that the Local System does not have access to network resources per documentation. However if the same exe is copied to the C Drive and run from there under the same account and same conditions (i.e. GPO startup script) then the Web Service can be accessed.
How is it that the Local System has access to the web service when running from C: drive, but not from the Network Share? Is there anything that can be done to make it work from the network share, without first being copied to the local drive? is Local System same as SYSTEM and same as NTAuthority\system?
I have tried the following so far to make it work. None of these work:
Impersonate a domain user in code.
Give Full Trust to all zones in .Net Security Configuration
Add the network share to Trusted Sites in IE.
Use the netbios name instead of the fully qualified name of the fileserver, i.e. \server\share, rather than \server.domain.com\share
The following things I cannot do to fix this problem:
Change the logon account of the Group Policy Client service to a domain user
Run the exe as logon script. It has to be startup script.
To reproduce this problem I do the following:
Create an simple exe with some network function, i.e. WebClient.DownloadString("http://www.google.com")
Deploy exe to a network share
Run as normal user to show there is no error
Run whoami to show the current user
run psexec -s -i cmd.exe
Cmd will start as SYSTEM (Local System or NT Authority\System)
Run whoami to show the current user
Run exe from network share to show it will fail to download the page.
Copy the exe to C Drive.
Run exe to show the page is downloaded.
Related
Background:
I have used developed an OPC server based on LightOPC (https://github.com/Sayen/LightOPC). This works perfectly fine as a local executable. The only problem is that I want multiple clients to connect to the same instance of the exe so they can share data. Currently, even if the DCOM settings are such that it runs as a specific user, it seems that sometimes multiple instances of the exe start. The only solution has been to set it to run as the Interactive User. However this has an issue where it won't run if no user is logged in. I believe the right way is to make it run as a windows service.
Question:
How can I take my DCOM local executable and make it into a service?
Things I tried:
Based off of this question: Create Windows service from executable I used the NSSM( the non-Sucking Service Manager ) to make my exe into a service name MYOPCSERVICE.
Then based on some other googling and examining other OPC servers that run as services, I modified the following registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\WOW6432Node\AppID{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX} (where X's are my AppId) and added a "Local Service" key with the value of "MYOPCSERVICE".
After doing this, when I used DCOMCNFG, my DCOM Application shows up as Application Type = Local Service.
However, after adding this registry key, when I try to start the service or connect to the OPC server, the service fails to start with "CoRegisterClassObject() failed. Exiting..."
I found this document: https://learn.microsoft.com/en-us/windows/win32/api/combaseapi/nf-combaseapi-coregisterclassobject which has the following:
As of Windows Server 2003, if a COM object application is registered
as a service, COM verifies the registration. COM makes sure the
process ID of the service, in the service control manager (SCM),
matches the process ID of the registering process. If not, COM fails
the registration. If the COM object application runs in the system
account with no registry key, COM treats the objects application
identity as Launching User.
I don't know if this is the issue, and I also don't really understand what it means. What is the "process ID" being referred to? Is this the 1-4 digit integer that all Windows processes have? Or is this the name of the service and does it have to match the name of the executable or the class or the AppId?
Update:
I have been experimenting more, and I am starting to get the feeling that it isn't possible to use NSSM to make the COM executable into a service. It seems like the exe of the service needs to be the one that calls CoRegisterClassObject. I have made a simple service based off of Simple Windows Service in c++ https://www.codeproject.com/script/Articles/ViewDownloads.aspx?aid=499465 and when I do so, I can successfully call CoRegisterClassObject with the AppId of {XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX} if this AppId registry key contains the string LocalService = MYOPCSERVICE.
I think Windows is enforcing a rule that only the exe registered as a service (which is nssm.exe) is allowed to call CoRegisterClassObject. However nssm spawns another exe (the local OPC executable) and it doesn't pass along this ability. Does this sound accurate? Is there any work around besides having to write all my own service handlers?
I have a web application on one of the client's machines (a virtual machine running Windows Server 2012R2). The application uses Azure Storage. For testing purposes it was decided to use an Azure Storage Emulator.
My problem is that, when I log out of the remote machine the storage emulator stops. How do I keep the Azure Storage Emulator running even if no user is logged in?
CristisS#, There are two possible solutions i could think off based on your scenario, the first one is to configure the emulator to be part of the startup programs, meaning, if the VM restarts, the application will automatically launch,all you have to do is add the emulator icon to the startup directory:
1- Enable viewing hidden files and folders
2 Navigate to: C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup\
Paste the Emulator icon there.
Another solution is by configuring autologon and linking the application to a specific user to allow the emulator to connect automatically: https://learn.microsoft.com/en-us/sysinternals/downloads/autologon
Autologon enables you to easily configure Windows’ built-in autologon mechanism. Instead of waiting for a user to enter their name and password, Windows uses the credentials you enter with Autologon, which are encrypted in the Registry, to log on the specified user automatically.
Autologon is easy enough to use. Just run autologon.exe, fill in the dialog, and hit Enable. To turn off auto-logon, hit Disable. Also, if the shift key is held down before the system performs an autologon, the autologon will be disabled for that logon. You can also pass the username, domain and password as command-line arguments:
autologon user domain password
When the application is executed with run as administrator it fails to find files on a mapped network drive using FindFirstFile. If the executable is run without run as administrator is works. The user is a local administrator on the PC. When FindFirstFile fails the error is 3, ERROR_PATH_NOT_FOUND. Is running as an administrator changing access rights or my access to the mapped drive?
I'm testing on a Windows 10 PC with a domain user that is a local administrator. Application was built using VS 2010 on the Windows 10 PC. Application is a native c++ app. I've turned off the firewall, still fails. Turned off Windows Defender, still fails. Recreated share and mapping, still fails. Ideas?
Network drives are mapped per-user. If you map a drive as your user, but run your application as Administrator, the network drive won't be mapped from the application's perspective. To get around this, you can map the drive as Administrator by opening an admin command prompt (right-click cmd -> run as Administrator) and run net use F: \\path\to\my\share.
My program uses the DXGI API to interact with DXGI Outputs and Adapters.
I am developing it using mostly command line tools, since I don't need any GUI yet.
I am also accessing my PowerShell instance through Bitvise SSH Server - whenever I run my compiled program.exe through this PowerShell instance, as far as I can tell it means that my program is running in Session 0, and that means I only have access to a subset of the DXGI functionality (see Use Direct3D in Session 0 Processes).
Is there any way that I can somehow hack around this requirement? Is there a flag I can pass to program.exe that pops it out of session 0 somehow?
If not via WinAPI and if you can use and launch additional exe to start your program.exe, I think you can try using psexec utility: http://technet.microsoft.com/en-us/sysinternals/bb897553.
I guess there are similar utilities around as well.
EDIT:
You can use psexec for starting processes on local box as well, see reference for "computer" argument:
computer Direct PsExec to run the application on the computer or computers specified. If you omit the computer name PsExec runs the application on the local system and if you enter a computer name of "\*" PsExec runs the applications on all computers in the current domain.
Another EDIT
I was able to launch notepad.exe in my session emulating what you might have had:
psexec -i 0 psexec -s -i 1 C:\windows\system32\Notepad.exe
This command line starts uses psexec to start itself in session 0 (under system account), then that new psexec calls notepad.exe to be shown in my session (session 1). And it kind of does work.
Of course, you'll need admin rights to run these commands.
Am working on Creating windows service and launching an exe application through this,
from this link i have created a windows service Windows Service
But when i create a setup and deployment and then if i install, the exe which am calling from the service is launched as LOCAL SERVICE.
Still i can the xxx.exe in task manager as LOCAL SERVICE.
I cant figure even with this help : Launching GUI from windows service
How can i launch this exe as the local username which i have logged in ?
You have a number of options for creating a process that runs under a different user from the parent process:
CreateProcessAsUser or CreateProcessWithTokenW. These require you to obtain a primary token that represents a user, calling either LogonUser or DuplicateTokenEx.
CreateProcessWithLogonW which allows you to specify the user name and password as parameters.
However, if you want the process that you create to appear on the interactive desktop, you need to do quite a bit of work. This article covers the details: Launching an interactive process from Windows Service in Windows Vista and later.