RDP. Відключаємо системні, функціональні клавіші. Windows 2008R2

потрібно
Одним прекрасним ввечері з'явилася нагальна необхідність додаткового захисту від «кривих» або «умисних рук». Так як основою нашої бази даних служить MS ACCESS, то в ньому зустрічається кілька неприємних моментів таких як застосування гарячих клавіш (видалення, друк і інші) і наш розробник не спромігся їх відключити. Власне, часу розбиратися з макросами Access та правами користувачів на їх використання не було, та й сама ідея відключення всіх функціональних клавіш на клавіатурі вирішувало ще й попутні завдання вбудованого елемента керування типу «Веб-браузер» – заборона на видалення файлів створених користувачем, заборона виклику довідки і гарячих клавіш у програмах перегляду зображень і PDF. Дірку треба було швидко залатати і дочекатись нашого розробника з відпустки.

Попередній аналіз і план дій
Рішення яке відразу прийшло на розум, це створити новий запис у реєстрі Scancode Map за адресою HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Keyboard Layout і прописати в ньому всі необхідні перепризначення клавіш, але досить швидко з'ясувалося, що це не працює по RDP, та й до того ж застосовувалося повністю до системи зачіпаючи привілейованих користувачів, яким дозволено використовувати гарячі клавіші.

Далі згадав про Microsoft Keyboard Layout Creator, яким у свій час редагував розкладку клавіатури домашнього комп'ютера, але на жаль в нову версію так і не додали роботу з системними клавішами.

Вивчивши простори інтернету путнього і життєздатного рішення знайдено не було. Залишалося одне – створення власної розкладки і додавання в систему. Для початку було вивчено файли KBDRU.dll і KBDUS.dll після чого стало зрозуміло, що власними силами за вечір розібратися буде вкрай складно. Огляд програм, які можуть вирішити дану проблему не зайняв багато часу і у всіх були свої недоліки, головний з яких – установка їх на сервер, що є вкрай небажаним заходом. Гідні з програм судячи за відгуками були: KbdEdit і Keyboard Layout Manager 2000.

І тут знайшлася підказка, що можна створити розкладку на віртуальній машині за допомогою вищевказаних програм, а Microsoft Keyboard Layout Creator використовувати як компілятор інсталяційних файлів нової розкладки на сервер.

Робимо
Але не все виявилося так просто. Вивчивши KbdEdit відразу стало підозрілим, що створюваний ним файл розкладки dll весі більш 50KB а оригінал 7KB, а так само що розкладка працювати не буде в відсутність даної програми. Файли, створені Keyboard Layout Manager важили 9KB, що було цілком прийнятно.

Переходимо до налаштування KLM2000, нічого складного, створюємо нову розкладку, на базі існуючої і вибираємо редагувати, всі непотрібні системні і функціональні клавіші відключаємо (в моєму випадку все, що виділено червоним). Єдине з чим довелося трохи повозитися це з NUMPAD, щоб дані (виділено синім) клавіші не несли в собі функції системних необхідно зробити деякі перепризначення: «0» не чіпаємо, на "." вибираємо значення параметра Virtual Key – VK_OEM_PERIOD, на «1» — unassigned 0x89, «2» — 0x8A, «3» — 0x8B, «4» — 0x8C, «5» — 0x8D, «6» — 0x8E, «7» — 0x8F, «8» — 0x92, «9» — 0x93.
Зберігаємо Export, і застосовуємо в системі OK.

image

image

Далі відкриваємо Microsoft Keyboard Layout Creator, вибираємо цю розкладку намагаємося зберегти й бачимо помилку. На жаль, MKLC не пропускає розкладку з відключеними системними клавішами. Тоді копіюємо з папки Windows\System32 і Windows\SysWOW64 dll створені KLM2000, а на іншій машині за допомогою MKLC створюємо файли на базі стандартної розкладки, а у властивостях вказуємо ім'я розкладки, яке ми вказали, коли створювали розкладку за допомогою KLM2000.

Далі на сервері встановлюємо розкладку клавіатури, створену за допомогою MKLC, а файли dll створені KLM2000 копіюємо в папку Windows\System32 і Windows\SysWOW64 на сервері.

Важливо
Для коректної роботи, і це обов'язково, повинна бути тільки одна розкладка клавіатури для однієї мови. Не забуваємо про параметр в реєстрі IgnoreRemoteKeyboardLayout, щоб не чіплялася розкладка клієнта. Перезавантажуємося.

Доповнення
Якщо до цього всього додати наступні зміни для конкретного користувача в реєстрі:

  • відключити «Drag and Drop» («DragHeight» і «DragWidth»)
  • відключити контекстне меню провідника windows («NoViewContextMenu» і «NoTrayContextMenu»)
  • встановити відкриття файлів по одному клацанню миші
— то отримаємо, що користувач з під Вбудованого елемента керування типу «Веб-браузер» в MS Access ні перейменовувати, ні скопіювати, ні видалити, ні переміщати файли не зможе навіть ті, які створені MS ACCESS з під його облікового запису. (створює ACCESS файли за наступною процедурою, спочатку в папці призначення створюється тимчасовий файл, а потім він перейменовується в підсумковий, тому заборона на зміну в групових політиках тут не підходять).

Висновок
Довелося трохи експериментувати і витратити на це весь вечір, то сподіваюся комусь дана стаття буде корисною з точки зору економії часу, адже кожна зайва година для нас безцінним.

В цілому завдання з дуже швидкою заплатке була вирішена, без встановлення на сервер, яких або сторонніх програм, що є добре.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.