I have a windows service that polls a folder continuously for new files.For local directories this works fine.But when it comes to UNC Paths on another system in the same network,the service cannot access the folder it seems.I have refereed to this post https://serverfault.com/a/881272 ; it states that i need to run the service as the currently logged in user.How im i supposed to do that?
The path i wish to monitor using the service is
\DESKTOP-PC\Users\me\myfolder
Please advice
UPDATE:
I have developed the service using topshelf.I want to poll a folder on another local machine in the same network.I go to network places,double click on the computername,it asks for credentials,i enter the username and password of the remote computer i get access to the files on the system for that user(in explorer).
Now when i set the service to run as the local machine user under this machine,it cannot access the remote UNC Path that is accessible using explorer.I have tried installing it as the remote machine user,but it fails.
myService.exe install -username:DESKTOP-REMOTE\myname -password:mypassword
Open the Control Panel > Administrative Tools > Services window on
your Windows server.
Stop your windows service.
Open the Properties > Log On dialog.
Change the service user account to the target user account.
Start your service.
If you are developing the service in Visual Studio, and want to emulate a different account you can also press shift + right mouse click on devenv.exe and click on "run as different user".
Also make sure you are specifying the full path to the folder and that the account you use has full rights to the folder.
If you try to run your service under the desktop-remote\myname account you probably will fail. The local machine only likes accounts belonging to itself.
What I would do is to turn it around. Make the remote computer share a folder for your machine to poll. That way the remote machine has control over which data it is publishing, just like an object has its properties to private or public. If you are ok with having anyone who knows the address \\desktop-remote\my-not-so-secret-folder\ being able to read it, set it so anyone can read. If you are more secretive, suffix the folder with $ like so: \\desktop-remote\my-secret-folder$. Now it is not visble but still reachable.
You can also create a special account that has access to said folder.
Then you let your service run any account (with network access) of your choosing on your local machine. Let it try to connect to the remote folder with the special account.
(I have learned, the hard way, that reading a shared folder is slightly different between machines without domain and machines in a domain; the anyone-can-read does not work. At least in WindowsXP it was that way. I have since then not have the need to share a folder.)
HTH
When you set the service to run as the local system account, it cannot access the remote UNC Path that is accessible using explorer with local machine account.
Simply because the explorer manages logged on user credentials, so, you have added UNC path credentials to the LOGGED user only.
When you change it to Local System Account, the user credentials to the share is not stored.
Try to create a local user without password expiration and then enable it access to the Share.
All you will need to do is to setup windows service with this new account registered.
I was facing this problem with my UNC storage in the Azure cloud.
What worked is setting up the credentials in the windows credentials manager:
windows credential manager
You can get the connection string from the Azure portal.
This resolved our problem.
You can have a look at Impersonation. Also, if the service is running as a localuser, then it would help to create the same user with similar password on the machine where the folder resides.
Have a look here (the OP in this post is experiencing the same issue and he/she has given the shared folder “Everyone access to full control”.
https://serverfault.com/questions/177139/windows-service-cant-access-network-share
Related
I wanted to run local desktop applications which are installed in Program Files and Program File (x86) folders only, the application should run with administrator privileges as logged in user context. I have googled and got to know some.
Required as per my idea:-
File Explorer GUI with Socket Client
A Service
Local Application Launching Executable with Socket Server ( console application)
Note: The communication between File Explorer will happen using socket client and server. The service will launch the local application server in system context.
Imagine that File Explorer, Service and Application Launching server are installed.
Using File explorer the app will be selected and selected application information will be sent to the server. The server will do check on the requested path whether it is from trusted path or not.
If it is from trusted path, the server will get handle from "winlogon.exe" and get the handle to the access token, then duplicate the access token and adjust its privileges (default system privilege will be there and i don't want that as system will have full privileges) then use CreateProcessAsUser to launch the application.
Once launched bring the UI to the foreground. The application need to be run in user context with administrator privileges.
My questions are stated below:-
To achieve this do i need to enable the interactive process in the
service ?
If interactive is necessary, the communication between the
user and local server is happening using socket and user do not
interact with service directly, just wanted to know whether am i
following the Microsoft safety measures as stated in below
documentation or am i breaching it?.
https://learn.microsoft.com/en-us/windows/win32/services/interactive-services
Do we have any other way to launch an application with admin
privileges in logged on user context without actual administrator privilege ?
The targeted OS is Windows 10 1803 and 1809.
Have a look for the tools psexec or paexec (they're mostly identical, the major difference being that the later is open-source).
These tools allow you to start a process as another user and/or on another computer. This should work from a service as well.
Goal:
I periodically upload new .exe file to windows server 2003 via FTP and I want to run it manually by hitting Url of a web site on same server. Exe needs to be run under an Admin account, and not the NETWORK SERVICE account.
What I achieved so far:
I have been able to successfully run applications like notepad under the Admin account on the server via a web request by using any of these:
PsExec,
.net process.Start() with credentials supplied to process.StartInfo and even
by impersonating admin and then using process.Start without credentials (http://www.f4cio.com/programmatically-impersonate-in-csharp)
The problem:
The above methods run my exe but Task Manager, or a call to System.Security.Principal.WindowsIdentity.GetCurrent().Name shows me that it is running under NETWORK SERVICE.
I suspect that this file has added security constraints because it arrived from ftp link. Checking run-as-administrator in properties of file is not an option because file will be replaced periodically and all needs to be automated. Also manual server configuration should be minimal or ideally non-existent. Code-only single-web-page solution is ideal. Editing both that asp.net web page and exe is ok. (I tried something with exe self-restarting).
Not sure about this, but I suspect this has to do with you website running under the NETWORK SERVICE user. Whatever privileges your website-user has, the same are probably granted / passed on as you try to run your executable.
Is this server on an internal network or protected in some other way? (I should hope so!). If so, you might try changing App Pool that the website is running under to an admin account (in IIS, right click the App Pool running the site, select Advanced Settings, and look for the Identity setting). If I'm right, that will allow you to run your executable as an admin too.
Be aware however, that this may increase the security risk of your setup: Allowing your site to run under an admin account means easier access to your entire server if anyone is able to penetrate whatever security measures you have in place. Make sure access to this server is tightly limited, and preferably, that it in turn does not have access to other systems, since that would in turn make them vulnerable by extension.
I have a stand-alone IIS7 Server that is not joined to a domain and that is running an simple ASP.Net application. This application has an ActiveReports report that has an image control where I set the path of the image during run time to a network share on another server. When I run the application locally in Visual Studio on a desktop that is joined to the same domain as the network share, I am able to get the images, but when I deploy the application to the stand-alone IIS server and run it locally on the IIS server I am not able to get the images. I added permissions on the network share for the username and password of the login for the IIS server and I am able to navigate using Windows Explorer to the network share from the IIS server now, but I can't get the permissions right on IIS.
What is the correct way to set the permissions so that the application can access the image files on the network share?
When IIS access network resources it uses the security context (account) associated with the IIS process. This is primarily controlled by the Application Pool unless you are doing any kind of impersonation at the code level.
In order to correct you issue you'll probably need to make sure the application pool is running using a security account that has access to the network resource. Here are some links that may help
http://technet.microsoft.com/en-us/library/cc771170(v=WS.10).aspx
http://www.iis.net/learn/manage/configuring-security/application-pool-identities
Also, don't forget, if you are using windows file services for your network share there are two levels of permissions, those that are set at a share level and those that are set at the file level if using NTFS. Here is some info:
http://technet.microsoft.com/en-us/library/cc754178.aspx
One idea: on the IIS7 server, create a Virtual Directory that points to the share. When creating a Virtual Directory, IIS will let you enter credentials needed to access a share.
Then, you'll need your image paths to reference the share.
I created a windows service that's basically a file watcher that wont run unless a user is logged into the machine its on.
The service is running on a Windows Server 2003 machine. It is designed to listen for excel files in a folder. When there is a excel file, it starts to send some information to a web service. When it's done, it copies the processed file to a archive folder.
Can anyone help me?
Best regards
Baris
Run it as a user that has rights to log on as service on the machine. Make sure this user has an access to the directory you watch.
What i always do in a scenario like that is give the user logon as batch job and logon as a service rights. 1 of these 2 will most likely fix your problem.
You can configure this in the local group policy editor as described here
Be aware though that if your computer is in a domain it is possible that the group policy gets pushed to the server every 15 mins so you might have to talk to a system admin to get things sorted.
When you actually only want to run when someone is logged in, do not use a service but an autostart application in that case.
If you have to be a service because of account privileges, the service may detect the current logins itself, but you may combine a service with a client (autostart) application that connects to the service. That way, you can also show tray incos, status informations and enable the user to control your service using the client application.
Using Win7 and higher, services themselves (running in session 0) can no longer display UI interactions on the user's desktop.
Keep in mind that there may be multiple users logged in on current operating systems...
I have a windows service which basically consists of a FileSystemWatcher. This service works well when monitoring local folders. The service will not, however, start when I specify a mapped drive in its app.config.
I've changed the account type of the service to LocalSystem, LocalService, and NetworkService without any difference. Most of my testing has been done with LocalSystem.
Any suggestions?
You need an account that has access to the mapped drive. The ones you mentioned do not.
Make a domain account and run the service under it. Grant it local admin, if you like, but also give it full rights to the folder it needs to monitor.