I’m working on a system where various Windows services run on different computers in a private network. Any of the computers in the network can run client applications that interact with these services remotely. As part of our package, we have functionality that lets users see whether any of the services in the network are experiencing problems and restart any of them that are downed.
To get this to work, we used user impersonation and the Service Controller class: we ask users to provide the user name and password of an administrative account on the computer hosting the downed service, impersonate that administrator, and then restart the service with ServiceController. This works in most situations, but we can’t impersonate the administrators on some of our servers. My understanding is that for user impersonation to work, the accounts being impersonated have to be on the local machine or part of an Active Directory group, but the servers in question only have accounts that are local to themselves.
I noticed that there are lots of parameters for the LogonUser method that starts impersonation and started playing with them to see if any of them would fix my problem. When I tried setting the LogonType value to “New Credentials” (9), I saw some strange (but potentially useful) behavior:
- I can restart services on the servers that I couldn’t work with previously
- If I attempt to restart a downed service and provide an incorrect password, the service is still restarted.
Why am I seeing this behavior? If the reasons for this are good, I might use this set-up to completely get rid of asking users to log in altogether.
I figured out what’s going on:
According to Getting the Current username when impersonated, when using impersonation with the logon type of new credentials, the impersonated thread continues to act as the original user for all commands sent to the local computer. It only acts as the impersonated user when it sends commands to other computers.
This is why I observed that I didn’t need to provide a correct password: If I have a downed user on a server, and then I run a client app as an administrator on that server and try to restart it, then it doesn’t matter what credentials I supply. The impersonated thread will continue to use the administrator account since restarting the service only involves interacting with the local computer. The new credentials I put in are effectively ignored.
By the way, this means that I should only be able to put in the wrong username and password when I try to restart a service on the local computer. When I tested this some more, that’s what I observed.
That’s why it looked like I didn’t need to worry about which password I put in. How about how I accessed computers that didn’t have accounts in an Active Directory group? According to this article, “NewCredentials LogonType […] authenticates cross domain.” I’m not exactly sure what happens, but it looks like new credentials doesn’t try to authenticate against Active Directory at all. My guess is that it sends the impersonated credentials straight to the computer being accessed, allowing the impersonation of local accounts.
For the project I was working on, this means that I still have to ask users for credentials when they try to restart services, but now they can restart services on any server, even if it’s not configured to have an Active Directory account.