Як заблокувати звичайних (не адміністраторів) користувачів під час встановлення програмного забезпечення?

У нас є безліч тонких клієнтів, які працюють з Windows Embedded Standard 7 та сервером SCCM 2012 R2 для управління ними. Для тонких клієнтів увімкнено фільтри запису (FBWF), тому машинні зміни не є постійними. У рідкісних випадках нам доводиться щось оновлювати, ми просто розгортаємо це через SCCM, і він автоматично бере на себе вимкнення та повторне включення фільтрів запису для внесення змін.

Ось що має статися:
клієнт SCCM повідомляє користувача та 30-хвилинний відлік часу, щоб зберегти свою роботу та вийти із системи. Потім тонкий клієнт перезавантажується та відключає фільтр запису. На екрані входу відображається замок і помічається, що пристрій обслуговується, і не дозволить нормальним користувачам (не адміністраторам) входити в систему, поки SCCM робить це. Коли SCCM завершено, він знову вмикає фільтр запису, перезавантажує, а потім користувачі можуть знову увійти.

Проблема, яка у мене виникає, полягає в тому, що ми використовуємо зчитувачі карток близькості для входу в систему. Співробітники не вводять паролі. Вони просто торкаються свого значка. Ця система хороша, але програмне забезпечення, яке її запускає, порушує автоматизацію фільтра запису за допомогою вбудованої Windows.

Ось що насправді відбувається:
клієнт SCCM повідомляє звичайне 15-хвилинне повідомлення перед перезавантаженням із вимкненим фільтром запису. Коли він перезавантажується, відображається звичайний екран для входу. Користувачі можуть увійти в систему та використовувати її під час встановлення програмного забезпечення SCCM. Оскільки сеанс користувача активний, він знову повідомляє ще 30 хвилин перед перезавантаженням із фільтром запису.

У цьому випадку він не тільки додає додаткових 30 хвилин до часу розгортання, але й надає звичайним користувачам надійні 30-60 хвилин незахищеного часу на тонких клієнтах з будь-якими змінами, які вони вносять, перетворюючись назавжди на зображення, коли фільтр запису знову включається.

Проблема випливає з того, що Windows Embedded 7 використовує іншого постачальника даних (аналогічно GINA), ніж звичайний Windows 7, але продукт SSO повинен замінити постачальника даних облікових даних Windows, щоб функціонувати. Я зв’язався з продавцем з цього приводу, але вони просто кажуть, що це відома проблема, і для цього немає жодних виправлень чи вирішення.

Тож ось моє запитання:
Як я можу імітувати бажану поведінку іншим способом? Я знаю, що існує налаштування групової політики, де ви можете заборонити локальний вхід певним групам користувачів. Я думав, що міг би змінити відповідне налаштування реєстру до та після встановлення, але я відкритий для інших ідей.

Я не вище встановлення сценаріїв, якщо доведеться. Я добре володію сценаріями, PowerShell, VBScript тощо. Мені просто цікаво, чи є у когось яскраві ідеї, як це вирішити.

Оновлення:
я знехтував зазначити, що ці пристрої використовуються в умовах лікарні для того, щоб персонал мав діаграми на своїх пацієнтів. Вони повинні бути доступні цілодобово, тому ми не можемо обмежувати години входу або налаштовувати вікна технічного обслуговування. Ми управляємо простоями, попередньо повідомляючи про наглядових працівників, але все, що займає більше години, стає проблемою дотримання законодавства і вимагає введення в дію офіційних процедур простоїв.

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

ми просто натискаємо його через SCCM

SCCM - це технологія, що базується на тязі. Я знаю, що ви мали на увазі, але я вважаю, що з моїми хлопцями першого рівня, я маю змогу підкреслити, що SCCM не є поштовхом, який допомагає їм швидше зрозуміти це.

Я зв’язався з продавцем з цього приводу, але вони просто кажуть, що це відома проблема, і для цього немає жодних виправлень чи вирішення.

Це дуже погано, оскільки це здається, що причиною цієї проблеми є вбудована програма аутентифікації картки. Тримайте постачальника, можливо, вони дійсно виправлять своє програмне забезпечення.

На справжню відповідь - я бачу кілька можливих варіантів вирішення для вас, жодне з них не є особливо хорошим.

• Налаштуйте вікно технічного обслуговування для цих клієнтів, щоб ваше первинне перезавантаження видалило клієнтів з їх фільтра запису, фактичного корисного вантажу та перезавантаження, що виникає внаслідок цього, відбувається у неробочий час, коли співробітників немає у терміналах. Це здається найменш болісним варіантом. Не потрібно робити СККМ складнішими, ніж це є.
• Створіть шаблон місцевої групової політики, який додасть групу безпеки до права користувача заборонити вхід, а потім призначте / скасуйте її як частину розгортання програми.
• Використовуйте PowerShell, щоб встановити право заборонити користувач. Я вважаю, що розширення спільноти PowerShell (PSCX) має Set/Get-Privilegesкомандлети, які дозволять вам маніпулювати призначеннями прав користувача
• Ви можете використовувати API, якщо хочете. Ось приклад .

Здається, ніхто не торкався можливості використання послідовності завдань для вирішення цього питання, тому дозвольте мені перерахувати переваги (якщо припустити, що ви насправді не з ними знайомі, але, будь ласка, прочитайте навіть якщо ви є):

Якщо все, що встановлено та налаштовано, обробляється з SCCM, ви повинні мати можливість використовувати послідовність завдань для цього. В основному для OSD, використання TS не тільки для OSD і може надати наступні переваги:

Немає входу на робочу станцію

TS запускається перед запуском winlogon.exe, тому немає можливості, щоб користувач ненавмисно ввійшов у систему, так як немає вікна входу. Що підводить мене до мого другого моменту:

Спеціальний фоновий екран

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

TS - це дійсно просто прославлений сценарій, але він має багато функціональних можливостей і поєднується таким чином, щоб скоротити час розробки, і я знайшов випадки використання поза OSD.

Здається, у вас вже є сценарій, щоб зробити те, що вам потрібно зробити, тому ви повинні бути в змозі помістити це в TS з мінімальним налагодженням і розпочати роботу.

Ви не вказали, чи програмне забезпечення SSO використовує облікові дані Active Directory, тож рішенням було б скористатися функцією Active Directory "Час входу в систему". Це на рівні кожного користувача, але його можна легко прописати в Powershell ( це є прикладом). В основному, встановіть години реєстрації на "заборону" входу у вікні оновлення SCCM, і користувачі не зможуть увійти до клієнтів, поки SCCM робить це. Вам потрібно буде виконати перше примусове перезавантаження, яке вийде з них (функція годин входу не працює на користувачів, які ввійшли в систему), але в іншому випадку це було б безболісно реалізувати.

Може захотіти перевірити це і перевірити, чи працює він:

Сценарій на початку діяльності SCCM, щоб зробити наступне:

• Видаліть ідентифікатор NT AUTHORITY \ Authentication Users з локальної групи користувачів
• Видаліть NT AUTHORITY \ Interactive identitet з локальної групи користувачів
• Видаліть групу користувачів домену з локальної групи користувачів

В кінці:

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

Фактичні групи, які ви додаєте / видаляєте, можуть залежати від налаштування ваших комп'ютерів.

Щось трохи причепніше, початок діяльності SCCM може скопіювати ярлик до logoff.exe в папку "Меню Старту всіх користувачів \ Папка запуску" (як правило, C: \ ProgramData \ Microsoft \ Windows \ Меню "Пуск" \ "Програми \ StartUp"). Це призведе до відмови від сеансу, як тільки вони ввійдуть у систему. Для безпеки вам може знадобитися сценарій запуску / відключення для видалення цього ярлика. (Я вважаю, що ярлики при запуску можна обійти, утримуючи клавішу shift під час входу).