I've build a Windows service that allows a user to choose a DSN and the service will access it and peform tasks on it. The code works without error when running under a test command line application, and fails when running as the actual Windows Service.
My question is, are Windows Services not allowed to access User DSN? Is there any way to still allow users the ability to create and configure DSNs for the service to use?
check What are the access restrictions on accessing a DSN
Related
In windows service there is Logon option and there we can select local system or a specific user , hwo does it differ by choosing different options w.r.to service running
Different login credentials have different permissions wrt the resources access.
If you set the logon credential to a user, that user's access may not give the service ample permissions to use whatever resources are necessary for it to function.
So setting the right user/service account for the service is important.
How do I know what account is right for the service?
If it is a service installed by a program (or something that already was installed with Windows) then the account should be correct.
If however it is some service you created (via some programming language), then you'll have to figure out what resources are required for that service to run properly and find the correct user/service account.
So I have Windows Server 2016 TP5 and I'm playing around with the containers. I am able to do basic docker tasks fine. I'm trying to figure out how to containerize some of our IIS-hosted web applications.
Thing is, we usually use integrated authentication for the DB and use domain service accounts for the app pool. I currently don't have a test VM (that is in a domain) so I can't test if this will work inside a container.
If the host is joined to an AD domain, are its containers also part of the domain? Can I still run processes using domain accounts?
EDIT:
Also, if I specify the "USER" in the dockerfile, does this mean that my app pool will run using that (instead of the app pool identity)?
There are at least some scenarios where AD-integration in Docker container actually works:
You need to access network resources with AD credentials.
Run cmdkey /add:<network-resource-uri>[:port] /user:<ad-user> /pass:<pass> under local identity that needs this access
To apply the same trick to IIS apps without modifying AppPoolIdentity you'll need a simplest .ashx wrapper around cmdkey (Note: you'll have to call this wrapper in run-time, e.g.: during ENTRYPOINT, otherwise network credentials will be mapped to different local identity)
You need to run code under AD user
Impersonate using ADVAPI32 function LogonUser with LOGON32_LOGON_NEW_CREDENTIALS and LOGON32_PROVIDER_DEFAULT as suggested
You need transport layer network security, like when making RPC calls (e.g.: MSDTC) to an AD-based resources.
Set up gMSA by using any guide that suites you best. Note however, that gMSA requires Docker host to be in the domain.
Update: this answer is no longer relevant - was for 2016 TP5. AD support has been added in later releases
Original answer
Quick answer - no, containers are not supported as part of AD so you can't use AD accounts to run processes within a container or authenticate with it
This used to be mentioned on the MS Containers site but the original link now redirects.
Original wording (CTP 3 or 4?):
"Containers cannot join Active Directory domains, and cannot run services or applications as domain users, service accounts, or machine accounts."
I don't know if that will change in a later release.
Someone tried to hack around it but with no joy.
You can't join containers to a domain but if your app needs to authenticate then you can use managed service accounts. Saves you the hassle of having to deal with packaging passwords.
https://msdn.microsoft.com/en-us/virtualization/windowscontainers/management/manage_serviceaccounts
I know that many software are updated by a windows service installed together. I made the service to serve as an update helper and a data server for my client application. But I am stuck on how do I control my client application from this service.
First my service will check for updates on the remote server and then download files.
It will broadcast the news to clients which will ask users if they want to update now or the next execution.
On the time to update, the client application can not delete it's own executable file, so, it would make sense if it asks the server to do it while it's not executing, and then when finished deleting and renaming the files, it would re-execute the client.
If the service is in session 0, it could not be able to re-execute the client to the same user session.
The other possible problem is when the very service would need an update. It could be solved by been updated by the client instead of itself.
So, in the case of updating client and server, should I need to create a third application to do the job. if this 3rd application is a console app, it would be no problem to execute it from the service, right?
If there is a solution that doesn't include this 3rd app, it would be the best.
Note:
The service is not just an update service, but a server to inform user access and rights. The main client application will not access the user information database directly.
If the service is in session 0, it could not be able to re-execute the client to the same user session.
Yes, it would, if you use CreateProcessAsUser() to specify the user account and the desktop to run the app on. The client could convey that info to the service before terminating itself.
But in any case, updating an exe requires it to stop running first. So when updating the service, especially since the service does more than just handle client updates, it would be safer to use an installer to stop the service, replace the exe, and restart the service. In which case, why not do the client update using an installer as well? The downloaded update could be a self-contained installer that stops both client and service as needed, replaces the files, and then either has the client or service delete the installer after it exits, or the installer can ask Windows to delete the installer upon the next OS reboot.
I am creating a utility that runs as a service and starts applications. As long as I log in as an admin and start the service it will run the applications. I log out and the service (and applications) continue to run. But, if another user logs in with different credentials they cannot access the front end GUI of the applications started by the service utility.
I was wondering if there is a built in account which I could use that may solve the issue? Or if anyone has any ideas or insight in the matter?
Windows Services can only be set to "interactive" when run in the system account. Notice the placement of the "Allow service to interact with desktop" checkbox on the Log On tab when configuring the service (via the Control Panel Services application).
Beyond that, are the other users logging in via RDP? Run mstsc with the "/admin" flag to ensure that they are going to Session 0 where the service will display its windows.
And finally, beware interactive services! You are probably on Windows XP or 2003 which is why it kind-of works, but Windows Vista, 7 and 2008 behave very differently (search for "Session 0 isolation").
I created a Windows service and installed into users machine.
That windows service is very important and I do not want to user can change its startup type to "disable".
It seems "Plug and Play" service can disable the Startup drop-down listbox.
How can I make same behavior for my windows service?
I would imagine it has to do with setting the appropriate permissions on the registry key. But a user with sufficient permissions can do anything. If this is for a business application, I would try to stick to using group policy or user permissions. If this is for a commercial application then I would expect a lot of upset users and malware detection.