Question: I have a Windows Service that I want to use to programmatically unlock the workstation, using the account username and password.

This article <https://technet.microsoft.com/en-us/library/dn751047(v=ws.11).aspx> explains the logon authentication workflow on Windows in the following image:
 [![authentication workflow](https://i.stack.imgur.com/sniMO.png)](https://i.stack.imgur.com/sniMO.png)

As seen above, on step 5, the user inputs the credentials into the Logon UI. What I want to achieve is to have the Windows Service input the credentials and have winlogon perform the login.

There is no winlogon API to achieve this. As seen in other questions, using winapi's `LogonUser` function successfully performs the authentication and returns a token, but it does not switch to the application desktop and the Logon UI remains on screen.

Most articles and SO answers hint towards credentials providers, but all credentials providers samples require user interaction with the 
Logon UI.

**Update:** I see some users haven't exactly understood the question and are proposing workarounds that are not useful for my case. The workflow that I'm trying to achieve is the following:

1. Windows service starts on Windows boot (done).
2. Same Windows service has a web service and accepts HTTP requests through an API (done).
3. User provides credentials to the service through the API from another device (done).
4. Provided credentials are used to log into the work station.  

4.1 Provided credentials are used to also unlock the work station in case of lock (WinKey + L).
5. (Optional) The service exposes the Windows accounts via the API.
6. (Optional) The user is able to specify to the service what account wants to use for login.

For now, I am interested in making steps 4 and 4.1.

Answer: 
Just while passing... But isn't there, among Microsoft's samples, a credential provider that takes asynchronous input? I've certainly written one that logs on a user who scans an acceptable fingerprint no matter what tile is displayed. To me, this means that interaction with LogonUI need be no more than implicit, but perhaps I'm missing something. 

But perhaps I'm not. Though I don't doubt the intention is that the asynchronous input will come from a user acting on hardware, as with scanning a finger, I don't recall this as a rule. If it's not, then you may have your programmatic option in the form of presenting the credentials as if they've been collected asynchronously - not from a device that's obviously attached to the computer but from your side-channel of HTTP with who knows what. 

So, can you have a credential provider listen for RPC from your service for notification of credentials that your service has collected via its side-channel? Or have your service listen for RPC from your credential provider to ask what credentials are available yet? I mightn't be surprised if one direction is closed off - for security, even - but I'd have thought one or other can be made to work. 

Whether you should want to do any of this, I don't want to get into.
Pro-grammatically bypassing/logging in on a user's behalf is scary with regards to cyber security.

I'm not sure what you are trying to do, but why not deploy a run task to do the work using a service account on the machine instead?

You can configure it to run even when the user is not logged in on a specified time/event. If that doesn't work for you, could you describe your scenario a little more?