I'm writing a software for a call-center. It's somewhat like a ATM program: user can only interactive with it, not with underlying Windows. It takes controls when user logs in to Windows, and when user exits, it logs off Windows.
How can I do that in .NET? A demo will be much appreciated.
Thank you.
Replace the Windows Shell.
By that I mean Explorer.exe, by means of editing the Windows Registry. What this does for you is instead of logging on and the system running Explorer.exe which consists of the Start Menu, Taskbar and other similar features you are familiar with, it only runs your program. There is no desktop, no context menu, no taskbar, or start menu. Thus, making your application "The Shell" or the new "Explorer.exe".
However, by doing this the user still has access to Control+Alt+Delete, so they would still be able to access the Windows Task Manager, which mind you can also be disabled via a simple Registry Key Entry.
This is the most pain free, easiest solution because you don't even have to worry about things such as disabling the WindowsKey or other annoyances.
The registry key to this is as follows:
SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
The name of the value to modify is:
Shell
And you can simply enter the value to be the fully qualified path to your program's executable file. You will only want to do this under HKEY_CURRENT_USER and only for the account that is to run your shell program. So you will need two separate accounts.
Administrator account
This account will just be a normal password protected account that will be used to manage the system
Kiosk account
This account will be the account that is logged on at all times, which runs your custom shell (your application)
Additional Notes
To disable the Task Manager the registry path is as follows:
Software\Microsoft\Windows\CurrentVersion\Policies\System
The name of the value is:
DisableTaskMgr
This is a DWORD value which to enforce the policy must be set to '1'.
What I did was to use DirectX and just use full-screen and exclusive modes, which you can see a small example of here: http://www.directxtutorial.com/tutorial9/b-direct3dbasics/dx9B2.aspx.
This is more work, but it will allow you to do what you want.
Depending on what control you have, there are steps you can do with group policy to limit what people can do on the computer. You can look at how people set up a kiosk application on Windows for some ideas.
What you want to do is run the OS in "kiosk mode".
This entails using the Group Policy Management Console to apply the kiosk mode template - as part of this you register your application as the shell.
As such there is no taskbar, or explorer view to fall back on to. The only way to run the usual shell would be to connect a keyboard to the system - press ctl-alt-delete and run explorer from the taskmanager that pops up.
And you can disable even the standard task manager if users are going to have keyboard access to the console. You will want to implement some kind of launch explorer.exe interface otherwise the system might become a bit difficult to manage :P
You can set your applications window to be always on top and to cover the entire screen. If you exclude buttons that close the window the user must know that ALT+F4 closes the window in order to exit. This has been good enough for me those times I've needed it.
Related
I have two application which is a main and a sub. both can also be opened separately and the main can also open the sub.Since the main application is in the administrative mode, the sub-application when opened from the main application is also opening in the same mode. Is there any possible way where can I open the sub-application in a normal but I need to have the base application running in the admin mode. The problem is I need to drag and drop files in the sub-application which cant be done when the application is in administrator mode.
Getting rid of Adminsitrative Privileges is surprisingly hard. It is nigh impossible to get rid of them, like starting a non-Elevated Process from a elevated one. It is a a vexing property of Windows.
There are ways but they usually involve unmanaged code (Windows API) and are not that stable.
It is possibly if you have the Application user/System Adminsitrator Specify a specific Windows User that he he maintains explicitly as one without Administrative Privileges. The way most non-elevated Services are started is by a explicit Windows User that is set in the Service Manager.
Most programmers eventualy settle to dodge this Problem entirely via an approach like this:
Have both Process A and B designed to always start non-Elevated (no Manifest or anything demand Elevation)
Modify Process A to detect that it is non-Elevated right now
Let Process A try to start a Elevated copy of itself via Runas with proper Options.
If the user is always Elevated (because the UAC is turned off or soemthing like that), it is out of your hands.
As I learned the hard way, there is also a chance that elevation might fail due to faulty Windows configuration. Again, this is out of your hands.
Of course there is the big question of why this is a Problem to begin with and if that is perhaps a XY Problem. Drag & Drop might have those limits. But do you have to use D&D for this? There are many ways to go about Interprocess Communicaiton. Most of them do not suffer such Limitations. D&D is just one of them.
I work on a .NET-based project that has certain features that we only want to be available to administrators. The methods that control access to these features are decorated with the PrincipalPermissionAttribute like so:
[PrincipalPermission(SecurityAction.Demand, Role=#"BUILTIN\Administrators")]
public static void RunAdminFeature()
{
// code here
}
Many of our users are local administrators on their systems, and yet, we've found that they still have to right-click the application icon and select the "Run as Administrator" option in order for these features to be available to them.
From the question and answer here, it would appear that this is the expected behavior on Windows 7. And if so, then it looks like modifying the application shortcut as described here might be the expected solution. If that's the case, then so be it.
My question is two-fold.
Am I doing things right programmatically? Is the attribute approach the correct one?
Is there a programmatic means of achieving restricted access to certain features that would also allow local administrators to run the application without requiring them to explicitly "Run as Administrator"?
1 The attribute approach is OK. You just need to handle the security exception correctly (e.g. offer to restart the app as administrator).
2 Hide the admin interface in your app so normal user can use, except you add a "god mode" button somewhere to enable the admin interface in elevated mode. An example is Windows Task Manager requiring elevation to see processes from all users.
For sample code for self-elevation, visit How to self-elevate an application to a high privilege level under UAC.
I'm interested in launching a window in a temporary session, like how UAC prompts appear. There's been some interest in this concept from a few people, so I figured I'd ask here. Essentially what we're going for is an elevated window like the UAC "are you sure you want to <...>" prompts, but with an arbitrary window. The end goal is to prevent window event hooks and all sorts of other issues that might occur during password entry.
I've had a quick look at the UAC APIs and a few other places, but there's nothing particularly useful out there. Obviously the UAC prompts get elevated to their own desktop session somehow, so there must be a way to create windows in such a way.
You can create a desktop using CreateDesktop. You can use SwitchDesktop to switch to the new desktop. Then you can call SetThreadDesktop on your main thread and draw your window. To get back get the handle of the default desktop by calling OpenDesktop with "Default" as lpszDesktop and use SwitchDesktop with this handle. You can also run Processes on a certain desktop. In order to do this you have to set lpDesktop member of the STARTUPINFO structure to the name of the desktop the process should be run on. Close the handles to the desktops after using them (CloseDesktop).
You can show your own window on an own desktop in this way.
The secure desktop used by UAC and by the Logon UI is called "Winlogon". In order to access it you need system rights. Luke provided an example in one of his answers.
Brian R. Bondy wrote a blog entry on desktops and window stations which is worth reading.
I've got the following question:
Is it possible te disable everything in windows except the program it's running?
I need to program an application on a touchscreen (fullscreen), where people can fill in a survey.
The only thing they should use is this program. (for protection of the survey anwsers and other secret stuff :p )
And the program should be closed when entering the right password.
So how can I disable everything else but the program I'm running?
Thanks
You should investigate Kiosk Mode. It might not be the right solution for your particular case, but it is an accepted way of restricting users to one application.
Kiosk Mode in IE
Basically you make the application full screen and disable things like the task bar etc.:
Disable the start menu and other stuff through the Group Policy Management
for the local computer (run gpedit.msc -> User Configuration ->
Administrative templates -> Start menu and Taskbar).
Source
This KB entry describes how to do that the best way by replacing the shell.
I need to design a "Conditions of Use" dialog that is presented to users after they logon to Windows XP. It must not allow the user to proceed until they check an "I agree" box. It must not be possible to shut it using Task Manager or any other method. And it should be fullscreen and modal. The "I agree" will remain checked automatically during subsequent logins for the duration of 1 month, after which the user will need to check it again. Also HR want to track who has checked the checkbox.
Is such a thing possible using .Net? I can use C# to design it but I'm not sure about how to prevent users from bypassing the dialog.
I know Windows Group Policy allows a dialog to be presented before login, but that does not allow a checkbox or any customization.
Any thoughts?
In older versions of Windows, it used to be possible to implement your own winlogon.exe, that's the application that presents the log-in user-interface. It's not so easy now, and for good reasons, Microsoft have invested a lot more effort in security than the average Joe Coder would!
Once you are past the login, the operating system becomes a little bit of a free-for all, but only because winlogon's first task is is spawn EXPLORER.EXE, if you replace the shell with your own that in turn spawns explorer when your entry criteria have been met, you will get the behaviour your want. You will, as you commented, need to disable the task-manager as this gives an opportunity to launch other applications.
Changing the default shell (all users):
open regedit (start menu > run, and type in regedit)
go to: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon.
Change Shell from explorer.exe to the new shell path e.g your application
log out and log back in.
Changing the default shell (only current user):
open regedit (start menu > run, and type in regedit).
go to: HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Winlogon.
add a new string value (Edit > New > String Value) called shell. and set the value to the path of the new shell e.g your application.
log out and log back in.
Perhaps this alternative may make things simpler... It has no checkbox.. no code...but you still force the user to acknowledge the policy and you still get to see who logs on (via the security log)
Alter the following Local Security Policies on the machine (via secpol.msc)
Set Interactive Login:Message Text For Users attempting to Log on to your warning
Set Interactive Login:Message Title For Users attempting to Log on to the title of your warning
These can be found in Security Settings\Local Policies\Security Options
Also consider Interactive Login:Do not display user last name and adjust your logging policy accordingly...
Hope that helps..
You should try to substitute a windows shell program (explorer.exe). It possible to do in system registry. And do any interaction with user from your program, and then run a standard shell.