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.
Related
I am using shellobj unit to list network shares with subfolders using IShellFolder interface but it doens't work in windows service application. Can some one advise a way to solve that problem
thanks
As David mentioned you have to make sure your service runs in the correct context. See this post here.
The logon account determines the security identity of the service at
run time, that is, the service's primary security context. The
security context determines the service's ability to access local and
network resources. For example, a service running in the security
context of a local user account cannot access network resources.
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
Why the option ‘Allow service to interact with desktop’ is only available for Local System account and not for any other account while configuring a windows service from control panel? I want to configure the windows service so as to allow interaction with desktop irrespective of the account it is configured to run with. How to achieve it?
that is a good question! I have never seen an official explanation from Microsoft, but I would guess that the reason has to do with permissions and rights and not wanting to mislead users.
Not all users are created equal. Some do not have the rights to display a user interface on session 0, or interact fully with arbitrary programs (and resources) it is running alongside. Having those users able to show GUI elements from a service may lead to confusion. For example, if a user account having limited rights starts an instance of Windows Explorer as a service, that window may not be able to accept dropped files from a "regular" explorer started by the interactive user. This sort of thing may be very difficult to diagnose and explain!
Note that Windows can certainly do what you like and we code it all the time in our service applications (http://www.CoreTechnologies.com/). Windows is simply not making that option available to you for any arbitrary user.
Of course please please take a step back and beware changes in Vista. "Session 0 Isolation" is a game changer for interactive Windows Services!
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.
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