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

Question

У нас много тонких клиентов, работающих под управлением Windows Embedded Standard 7, и сервер SCCM 2012 R2 для управления ими. У тонких клиентов включены фильтры записи (FBWF), поэтому изменения на машине не сохраняются. В редких случаях, когда нам нужно что-то обновить на них, мы просто развертываем это через SCCM, и он автоматически отключает и включает фильтры записи, чтобы зафиксировать изменения.

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

Проблема, с которой я столкнулся, заключается в том, что мы используем считыватели бесконтактных карт для входа в систему. Сотрудники не вводят пароли. Они просто касаются своей картой. Эта система хороша, но программное обеспечение, которое ее запускает, нарушает автоматизацию фильтра записи с Windows Embedded.

Вот чтона самом делепроисходит:
Клиент SCCM выдает обычное 15-минутное уведомление перед перезагрузкой с отключенным фильтром записи. Когда он перезагружается,нормальныйОтображается экран входа в систему. Пользователи могут войти в систему и использовать ее, пока SCCM устанавливает программное обеспечение. И поскольку сеанс пользователя активен, он снова выдает еще одно 30-минутное уведомление перед перезагрузкой с включенным фильтром записи.

В этом сценарии это не только добавляет дополнительные 30 минут ко времени развертывания, но и дает обычным пользователям 30–60 минут незащищенного времени на тонких клиентах, поскольку любые внесенные ими изменения навсегда сохраняются в образе при повторном включении фильтра записи.

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

Итак, вот мой вопрос:
Как можно имитировать желаемое поведение другим способом? Я знаю, что есть параметр групповой политики, с помощью которого можно запретить локальный вход определенным группам пользователей. Я думал, что смогу поменять местами соответствующие параметры реестра до и после установки, но я открыт для других идей.

Я не против скриптовых установок, если придется. Я свободно владею скриптами, PowerShell, VBScript и т. д. Мне просто интересно, есть ли у кого-нибудь яркие идеи, как решить эту проблему.

---

Обновлять:
Я забыл упомянуть, что эти устройства используются в больничной среде для персонала, чтобы вести карты пациентов. Они должны быть доступны 24 часа в сутки, поэтому мы не можем ограничивать время входа или настраивать окна обслуживания. Мы управляем временем простоя, заранее уведомляя руководителей смен, но все, что занимает больше часа, становится проблемой соответствия требованиям законодательства и требует введения в действие официальных процедур простоя.

Answer 1

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

мы просто передаем его через SCCM

SCCM — это технология на основе pull-based. Я понимаю, что вы имели в виду, но я обнаружил, что с моими ребятами из Tier-1 любая возможность подчеркнуть, что SCCM — это не технология на основе push-based, помогает им быстрее это понять.

Я связался с поставщиком по этому поводу, но он просто сказал, что это известная проблема и для нее нет решения или способа ее обойти.

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

Переходя к реальному ответу, я вижу несколько возможных решений для вас, но ни одно из них не является особенно хорошим.

• Настройте окно обслуживания для этих клиентов, чтобы ваша первоначальная перезагрузка для удаления клиентов из их фильтра записи, ваша фактическая полезная нагрузка и последующая перезагрузка происходили в нерабочее время, когда сотрудники не присутствуют на терминалах. Это кажется наименее болезненным вариантом. Не нужно усложнять SCCM, чем он уже есть.
• СоздатьЛокальная групповая политикашаблон, который добавляет группу безопасности к праву пользователя «Запретить вход в систему», а затем назначает/отменяет ее назначение в рамках развертывания вашего приложения.
• Используйте PowerShell для установки права Deny Logon User. Я считаю, чтоРасширения сообщества PowerShell (PSCX)содержит Set/Get-Privilegesкомандлеты, которые позволят вам управлять назначениями прав пользователей
• Вы можете использовать API, если хотите. Вотпример.

Answer 2

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

Если все, что вы устанавливаете и настраиваете, обрабатывается с помощью SCCM, вы должны иметь возможность использовать последовательность задач для достижения этого. В первую очередь для OSD использование TS нетолькодля OSD и может обеспечить следующие преимущества:

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

TS выполняется до запуска winlogon.exe, поэтому нет возможности случайного входа пользователя, так как нет окна входа. Что приводит меня ко второму пункту:

Пользовательский фоновый экран

Вы можете предоставить экран-заставку с сообщением о проведении технического обслуживания или с любой другой информацией, которую вы хотите там видеть.

TS на самом деле — это просто разрекламированный скрипт, но он обладает множеством функций и составлен таким образом, чтобы сократить время разработки, и я нашел варианты его использования за пределами OSD.

Похоже, у вас уже есть скрипт, который выполняет то, что вам нужно, поэтому вы сможете поместить его в TS с минимальной отладкой и приступить к работе.

Answer 3

Вы не указали, использует ли программное обеспечение SSO учетные данные Active Directory, поэтому решением было бы использовать функцию Active Directory "Logon Hours". Она действует на уровне пользователя, но ее можно легко запрограммировать в Powershell (этотНапример). По сути, установите часы входа в систему на "отказать" в окне обновления SCCM, и пользователи не смогут войти в систему клиентов, пока SCCM делает свое дело. Вам понадобится эта первая принудительная перезагрузка, которая выведет их из системы (функция часов входа не работает для вошедших пользователей), но в противном случае ее реализация будет безболезненной.

Answer 4

Возможно, стоит протестировать это и посмотреть, работает ли это:

Скрипт в начале действия SCCM, выполняющий следующие действия:

• Удалить идентификатор NT AUTHORITY\Authenticated Users из локальной группы Users
• Удалить NT AUTHORITY\Interactive идентификатор из локальной группы пользователей
• Удалить группу «Пользователи домена» из локальной группы «Пользователи»

В конце:

Добавьте удаленные вами субъекты безопасности обратно в локальную группу «Пользователи».

Фактические группы, которые вы добавляете/удаляете, могут зависеть от текущей конфигурации ваших компьютеров.

Что-то более прицепное, начало активности SCCM может скопировать ярлык для logoff.exe в папку All Users Start Menu\Startup (обычно C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp). Это приведет к выходу из сеанса сразу после входа в систему. Для безопасности вы можете захотеть иметь сценарий запуска/выключения, чтобы удалить этот ярлык. (Я считаю, что ярлыки запуска можно обойти, удерживая клавишу shift во время входа в систему).