I would like to display an UI that interacts with user on pre-logon screen (the screen where users usually enter their username/password)
I read that the architecture of Winlogon packages has changed and will not help me in Windows 7.
I was referred to use WTS functions, however I am still not clear on how to use them or which ones.
I already created a Service which brings up a notepad.exe (for now), however I need to trigger this Service when user is in pre-logon screen. I am not sure what or how to implement that.
what you are trying to do is use Windows Interactive Logon Architecture
Windows Vista examples here (Credential Providers)
Windows 7 technet article
There's a reason it's HARD to do this kind of thing. Programs are minions of users. Pre-logon, there's (typically) no user to be a minion of. Its a security thing.
Just have your service fire off when a user logs in.
One way to get UI to show up without anybody logged in is to have a login screensaver. Your code (which could be .NET) would run after the timeout up until either you exit or somebody presses Ctrl-Alt-Del.
There are limits to what you can do as a login screensaver, but it may work for you.
From what I understand of your requirement, you want to display a custom user interface at the Credential Provider level. You can achieve this by one of the following approaches:
(1) Write a custom CP that includes your UI as a modal dialog in the SetSelected method of the credential : This approach will allow you to customize any UI. Once the modal window gets dismissed, the actual password CP gets built (assuming you wrap the default password CP).
(2) Launch the application from a Windows Service: This approach will not stop the providers from getting initialized. Basically, the Windows Service is used to launch a process in Winsta0\Winlogon desktop. You can access the process launched using Alt+TAB. Here's the basic steps you would need to use:
WTSGetActiveConsoleSessionId to get the active session ID
WTSQueryUserToken() to get the winlogon pid
DuplicateTokenEx to duplicate the token
Adjust the token privileges by calling AdjustTokenPrivileges
CreateProcessAsUser with lpDesktop as Winsta0\Winlogon
I have used both approaches. The first one is used to introduce more secure login. The second is used to launch remote access tools, cmd prompt etc.
Related
I wrote a desktop alerts application that sends a variety of notifications to all clients that are currently logged in. The app lives in the system tray, with a right-click menu to select an alert. When an alert is sent, a pop-up displays on each client's desktop with the type of alert. The pop-up is a simple Window class:
alertWindow.showDialog();
Our PC's have a policy on them to automatically lock the screen after 10 minutes of inactivity. What I'd like to know is if there's any way to have the alerts display while the screen is locked. Any help would be appreciated.
You could put the required information into an image and then change the lock screen background with the Windows.System.UserProfile.Lockscreen class in the Windows Runtime APIs.
Windows.System.UserProfile.LockScreen.SetImageFileAsync(file);
The lockscreen itself is de-facto a different user session which runs with winlogon privileges.
i've done such thing under window 7 quite a while ago, but cant recall the details right now.
The general approach is:
open winlogon process handle
copy access token from process
create a new process with the just copied access token
create your windows on the lockscreen
it's a pretty hacky approach using many api calls but the only one that works.
As soon as I'm back at my home-pc i can see if i can find some details on how i exactly have done it.
[Edit]
I now had the chance to review the code and i have to say i'ts a little more complicated than outlined.
Key element is, that you need a service (which i wrote in C++) which runs with system permissions.
This service has to copy the impersonation token from the winlogon process and after that, launch a new process with that new token.
API functions for reference
GetTokenInformation
OpenProcessToken
DuplicateTokenEx
AdjustTokenPrivileges
[/Edit]
I have written a Windows service that allows me to remotely run and stop applications. These applications are run using CreateProcess, and this works for me because most of them only perform backend processing. Recently, I need to run applications that present GUI to the current log in user. How do I code in C++ to allow my service to locate the currently active desktop and run the GUI on it?
Roger Lipscombe's answer, to use WTSEnumerateSessions to find the right desktop, then CreateProcessAsUser to start the application on that desktop (you pass it the handle of the desktop as part of the STARTUPINFO structure) is correct.
However, I would strongly recommend against doing this. In some environments, such as Terminal Server hosts with many active users, determining which desktop is the 'active' one isn't easy, and may not even be possible.
But most importantly, if an application will suddenly appear on a user's desktop, this may very well occur at a bad time (either because the user simply isn't expecting it, or because you're trying to launch the app when the session isn't quite initialized yet, in the process of shutting down, or whatever).
A more conventional approach would be to put a shortcut to a small client app for your service in the global startup group. This app will then launch along with every user session, and can be used start other apps (if so desired) without any juggling of user credentials, sessions and/or desktops.
Also, this shortcut can be moved/disabled by administrators as desired, which will make deployment of your application much easier, since it doesn't deviate from the standards used by other Windows apps...
The short answer is "You don't", as opening a GUI program running under another user context is a security vulnerability commonly known as a Shatter Attack.
Take a look at this MSDN article: Interactive Services. It gives some options for a service to interact with a user.
In short you have these options:
Display a dialog box in the user's session using the WTSSendMessage function.
Create a separate hidden GUI application and use the CreateProcessAsUser function to run the application within the context of the interactive user. Design the GUI application to communicate with the service through some method of interprocess communication (IPC), for example, named pipes. The service communicates with the GUI application to tell it when to display the GUI. The application communicates the results of the user interaction back to the service so that the service can take the appropriate action. Note that IPC can expose your service interfaces over the network unless you use an appropriate access control list (ACL).
If this service runs on a multiuser system, add the application to the following key so that it is run in each session: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run. If the application uses named pipes for IPC, the server can distinguish between multiple user processes by giving each pipe a unique name based on the session ID.
WTSEnumerateSessions and CreateProcessAsUser.
Several people suggested WTSEnumerateSessions and CreateProcessAsUser. I wonder why no one suggested WTSGetActiveConsoleSessionId, since you said you only want to target one logged in user.
Several people sure are right to suggest CreateProcessAsUser though. If you call plain old CreateProcess the way you said, then the application's GUI will run with your service's privileges instead of the user's privileges.
That problems Session 0 , Interactive Services ,
Windows Service Allow Service To Interact With Desktop
on Windows 7 or Windows Vista
You can read this article
http://www.codeproject.com/KB/vista-security/SubvertingVistaUAC.aspx
I try explained here it's working on Windows 7
On Win2K, XP and Win2K3 the console user is logged on in Session 0, the same session the services live in. If a service is configured as interactive, it'll be able to show the UI on the user's desktop.
However, on Vista, no user can be logged on in Session 0. Showing UI from a service there is a bit trickier. You need to enumerate the active sessions using WTSEnumerateSessions API, find the console session and create the process as that user. Of course, you need also a token or user credentials to be able to do that. You can read more details about this process here.
I think as long as you have only one user logged in, it will automatically display on that user's desktop.
Anyway, be very careful when having a service start an exe.
If the write access to the folder with the exe is not restricted, any user can replace that exe with any other program, which will then be run with sytem rights. Take for example cmd.exe (available on all windows sytems). The next time the service tries to start your exe, you get a command shell with system rights...
If you launch a GUI from your service it will show up on the currently active desktop.
But only if you adjusted the service permissions: You need to allow it to interact with the desktop.
Important Services cannot directly interact with a user as of Windows Vista. Therefore, the techniques mentioned in the section titled Using an Interactive Service should not be used in new code.
This is taken from : http://msdn.microsoft.com/en-us/library/ms683502(VS.85).aspx
I wonder is it possible to run my application before login on windows.? Its actually a WinForm application(Preferably other than Windows service).
I mean my application must be running even before log in and it should sit on System Tray from which I can "show" or open Interface for user.
To have:
Something happen between system startup and user login
An icon in the notification area for users to interact with
You must break your application up into two separate components. One of these will be a WinForms/WPF application which provides the notification area icon and allows the user to interact with it. The other will be a Windows Service, or possibly a scheduled task.
Once you've done this, the windows service can focus on doing whatever needs to be done prior to logon and the notification area application can assume responsibility for showing the results, or whatever else to the end user.
To answer the question you posed in comments regarding reading data from the Event Log, yes this is possible. There are other questions on here which will give you that particular answer:
read the windows event log by particular Source
Read event log in C#
This MS article might help but it is a bit old:
http://support.microsoft.com/kb/142905
Hopefully it'll put you on the right tracks though.
I think, it doesn't make sense, to acquire user input before a user has logged into the system. So, if the application needs input from a user, why start it before the use has logged in? If the application just starts some background work, than you should use a windows service, as this is the prefered way in windows.
Type in run gpedit.msc, for Group Policy,
There you can set start up script.
Application will launch before Windows Login,
Step to produce :-
Start --> Run --> gpedit.msc --> Local Computer Policy --> Windows Settings --> Script (Startup/ShutDown),
Add you .exe
It will launch Before login.
Do not try more in Group Policy, it may happen harmful for System
By Programmatic logic,
Try with registry key
this value is updating in registry,
by our program we can update directly registry then we can call application
You can schedule any application to be run when computer is powered on using Windows Task Scheduler. There is a corresponding option there.
But why would you need this? You should use a service for this.
i wanted to know which process in Windows is user specific, i mean it get created for each user login. i tried explorer.exe but when u switch user and log into new account then it shows old login name in my code. basically i need to just log which user logging when in app.
If all you need to know is which user(s) are using your app, can you just check Environment.UserName when you start your app?
I missed the tag indicating you created a Windows Service. That's a very different type of animal than a regular application, and the advice you receive for one is not necessarily transferable to the other.
Specifically, I notice that you've tagged this question windows-7. If you're trying to run this service under Windows 7, you need to understand a few things about how the model for Windows Services was substantially altered starting with Windows Vista. Specifically, they now run in an isolated session and are prohibited from interacting directly with the user.
Also see my answer here for a better explanation.
The fundamental point is that, from the perspective of a Windows Service, there is no such concept as the currently logged-on user. A Windows Service runs in its own isolated session and is not affiliated with any particular user. That's why the code you found to determine the user associated with a particular process is not working as you expect for a Windows Service. A standard user doesn't own the process running the service. (And replacing your service with an application is also not a viable option, given how I understand your requirements. As I explain here, user-mode applications are started when a particular user logs on and will be closed whenever that user logs off.)
Another problem is that more than one user can be logged in simultaneously to a single workstation. Windows is a thoroughly multi-user operating system, so the best that you can hope for is to enumerate all of the currently logged in users. The NetWkstaUserEnum function will get you that list, but note that it includes all types of logons, including interactive users, services, and batch logons. To call this function from C#, you will need to P/Invoke—you can find information about that over on pinvoke.net.
I have been reading a lot about executing a GUI application from a Windows Service. The "Allow service to interact with desktop" check box worked for me when the Service runs as the SYSTEM user (I am using Windows XP).
Now I need the Service to run as a User defined in a domain (from the network). Everything works fine (even if no user is logged into the machine) but the GUIs are not shown (even if the same network user is logged in!).
I know that the GUIs are running, it's just that they are hidden. Why is that? Is there a way to show them if a user is logged on (like when created by the SYSTEM user and allowed interaction with desktop!) ?
if so, would it work if the user logged in is not the same as the one the service is running on?
Edit:
#casperOne: I see your solution, and it is the same that people (even you) have been posting around. In my case though, I am sure I am running on a secure environment and ONLY one user will be logged into a machine at a time. Isn't there anything one can do to simply unhide the GUIs? Why would this work with the user SYSTEM allowing interaction with desktop and not with another user?
Your approach is completely wrong, and will not work when deployed on Vista.
Services should NEVER assume a login session with a desktop to interact with.
Rather, you should have a second application which is run when the user logs in (or some other point in time) which communicates with the service and then displays UI elements when it receives notifications/responses from the service.
See this other question (and answers) for further information:
How to detect if a Window can be Shown?
Short answer: No, you can't do this
Long answer: Noooooo.
Basically, Microsoft are making changes to further prevent this. As casperOne stated, you'll need to separate your UI components away from the service.
And even on XP it didn't work on non domain joined machines (if you have multiple users using Fast User Switching the popups showed up on either the wrong desktop or no desktop at all).
As to why Microsoft changed this, do a quick search for "Shatter Attack" - by isolating service code from the desktop they completely cut off this entire family of security vulnerabilities.