What was required
One fine evening, there was an urgent need for additional protection from "curves" or "intentional hands." Since the basis of our database is MS ACCESS, there are several unpleasant moments in it, such as the use of hot keys (delete, print, etc.) and our developer did not bother to turn them off. Actually, there was no time to deal with Access macros and the rights of users to use them, and the very idea of ​​disabling all the function keys on the keyboard also solved the associated tasks of the built-in “Web Browser” control — prohibiting deletion of files created by the user, prohibition of calling help and hotkeys in image viewer and PDF.
Hole had to be patched quickly and wait for our developer from the holidays.
Preliminary analysis and action plan
The solution that immediately came to mind is to create a parameter in the Scancode Map registry under the address HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ Keyboard Layout and register in it all the necessary key remapping, but rather quickly it became clear that this does not work via RDP, and yes the same was applied fully to the system, affecting privileged users who are allowed to use hotkeys.
Then I remembered the Microsoft Keyboard Layout Creator, which I once used to edit the keyboard layout of my home computer, but alas, they didn’t add work with system keys to the new version.
Having studied the Internet, no viable solution was found. There was only one thing left - creating your own layout and adding it to the system. For a start, the files KBDRU.dll and KBDUS.dll were studied, after which it became clear that it would be extremely difficult to figure it out on my own over the evening. An overview of the programs that can solve this problem did not take much time and everyone had their flaws, the most important of which was installing them on the server, which is a very undesirable measure. Worthy of the programs judging by the reviews were: KbdEdit and Keyboard Layout Manager 2000.
')
And then there was a hint that you can create a layout on a virtual machine using the above programs, and use the Microsoft Keyboard Layout Creator as a compiler for the installation files for the new layout on the server.
Do
But not everything was so simple. Having studied KbdEdit, it became immediately suspicious that the dll layout file created by it weighs more than 50KB and the original 7KB, as well as that the layout will not work in the absence of this program. The files created by the Keyboard Layout Manager weighed 9KB, which was perfectly acceptable.
Go to the KLM2000 setup, nothing complicated, create a new layout based on the existing one and choose to edit, disable all unnecessary system and function keys (in my case, everything that is highlighted in red). The only thing with which I had to tinker with NUMPAD was that the data (highlighted in blue) did not carry the system functions. Some reassignments need to be done: “0” do not touch, select “Virtual Key” - “VK_OEM_PERIOD”, “1” - unassigned 0x89, “2” - 0x8A, “3” - 0x8B, “4” - 0x8C, “5” - 0x8D, “6” - 0x8E, “7” - 0x8F, “8” - 0x92, “9” - 0x93.
Save the Export, and use it in the OK system.


Next, open the Microsoft Keyboard Layout Creator, select this layout, try to save and see the error. Unfortunately, MKLC does not miss the layout with disabled system keys. Then we copy from the Windows \ System32 and Windows \ SysWOW64 dll folders created by KLM2000, and on another machine using MKLC we create installation files based on the standard layout, and in the properties we specify the layout name, which we specified when we created the layout using KLM2000.
Next, on the server, install the keyboard layout created with the MKLC, and copy the dll files created by the KLM2000 to the corresponding Windows \ System32 and Windows \ SysWOW64 folders on the server.
Important
To work correctly, and this is mandatory, there should be only one keyboard layout for one language. Do not forget about the parameter in the registry IgnoreRemoteKeyboardLayout, so as not to cling to the layout of the client. Reboot.
Addition
If you add to this all the following changes for a specific user in the registry:
- disable “Drag and Drop” (“DragHeight” and “DragWidth”)
- disable context menu in explorer (“NoViewContextMenu” and “NoTrayContextMenu”)
- set the opening of files on one click
- then we get that the user from under the Inline control of the type “Web browser” in MS Access cannot rename, copy, delete, or move files even those created by MS ACCESS from under his account. (creates ACCESS files according to the following procedure; first, a temporary file is created in the destination folder, and then it is renamed to the final one; therefore, the prohibition on changing in group policies is not appropriate here).
Conclusion
I had to experiment a bit and spend the whole evening on it, I hope this article will be useful to someone from the point of view of saving time, because every extra hour is invaluable for us.
In general, the problem of a very fast patch was solved, without installing any third-party programs on the server, which is good.