В большинстве организаций, применяющих в своей ИТ инфраструктуре локальные стандарты и регламенты информационной безопасности, уделяется отдельное внимание вопросу блокировки консолей рабочих станций пользователей при наступлении некоторого периода бездействия. Например, в качестве обязательного требования для большинства категорий пользователей может выставляться блокировка рабочего стола компьютера при отсутствии пользовательской активности более 15 минут. В управляемой среде Active Directory в доменных групповых политиках администраторам предоставляется ряд параметров, позволяющих централизованно настроить пользовательскую среду для форсированного применения механизма блокировки рабочего стола посредствам срабатывания программы - хранителя экрана (screen saver), или как её ещё называют, экранной заставки.
Эти параметры расположены в разделе групповой политики:
User Configuration > Policies > Administrative Templates > Control Panel > Personalization
Вот типичный возможный пример таких настроек:
Password protect the screen saver = Enable
Screen saver timeout = Enable (900 Seconds)
Force specific screen saver = scrnsave.scr
В данном примере включено обязательный запуск конкретного файла экранной заставки (scrnsave.scr) при простое более 15 минут с требованием ввода пароля пользователя при попытке последующего доступа к рабочему столу.
В системе, где применены данные параметры GPO, все настройки экранной заставки для пользователя становятся недоступными для изменений.
На практике встречается ситуация, когда за компьютером работает сменный суточный персонал, которому постоянно необходимо в режиме наблюдения видеть рабочий стол компьютера. При этом такой персонал может даже иметь несколько рабочих столов компьютеров, за которыми требуется наблюдение и не требуется интерактивное взаимодействие с клиентской ОС. Для такого рода пользователей нужен несколько иной подход с точки зрения автоматической блокировки компьютеров при простое.
Для обеспечения настроек экранной заставки для сменного персонала и для всех остальных пользователей мы можем создать две отдельные групповые политики – одна с обязательным срабатыванием экранной заставки, другая - без него. Но с использованием механизмов настройки реестра с помощью Group Policy Preferences (GPP) мы сможем гибко объединить эти настройки внутри одной групповой политики.
Для того, чтобы задействовать механизмы GPP для данной задачи, мы воспользуемся параметрами реестра, которые изменяются стандартными Административными шаблонами, указанными нами ранее. Сопоставим указанные ранее параметры GPO с ключами реестра которые они изменяют в клиентской системе:
Политика: Password protect the screen saver
Куст реестра: HKEY_CURRENT_USER
Ветка: SoftwarePoliciesMicrosoftWindowsControl PanelDesktop
Ключ: ScreenSaverIsSecure REG_SZ = 1
Политика: Screen saver timeout
Куст реестра: HKEY_CURRENT_USER
Ветка: SoftwarePoliciesMicrosoftWindowsControl PanelDesktop
Ключ: ScreenSaveTimeout REG_SZ = 900
Значение "900" означает количество секунд от момента начала бездействия до срабатывания экранной заставки (15 минут простоя)
Политика: Force specific screen saver
Куст реестра: HKEY_CURRENT_USER
Ветка: SoftwarePoliciesMicrosoftWindowsControl PanelDesktop
Ключ: ScreenSaveActive REG_SZ = 1
Ключ: SCRNSAVE.EXE REG_SZ = scrnsave.scr
Эксперименты с применением этой политики показали, что ключ реестра ScreenSaveActive добавляется лишь на системах Windows XP, а после отключения этой политики, он из реестра корректно не удаляется. Опытным путём удалось выяснить, что отсутствие этого ключа не вносит никаких изменений, поэтому будем рассматривать его как рудиментарный элемент и исключим из наших настроек GPP.
Итак, в групповой политике, действующей на наших пользователей, переведём три перечисленных параметра в состояние Not configured (если они ранее были настроены), а в разделе политики User Configuration > Preferences > Windows Settings > Registry создадим логическую группу, в которой будут храниться наши настройки, например ScreenSaver.
Внутри этой группы создадим две подгруппы настроек - Enabled и Disabled, в которых соответственно будут хранится настройки для включения и отключения форсированного применения экранной заставки. В нашем примере важно, чтобы параметры включения обрабатывались перед параметрами отключения.
В группе Enabled создадим три правила для создания/обновления ранее перечисленных ключей пользовательского реестра. Нацеливание (Item-level targeting) для этой группы использовать не будем, то есть эти параметры реестра будут применяться для всех пользователей.
В группе Disabled создадим три правила для удаления этих же ключей реестра. Группа Disabled будет иметь нацеливание на специально созданную доменную группу безопасности, в которую будут включены все пользователи, для которых нужно отключить форсированное применение экранной заставки.
Таким образом, логика обработки параметров реестра будет заключаться в обязательном включении экранной заставки для всех пользователей за исключением тех, кто включён в специальную группу безопасности. То есть при включении какого-либо пользователя в данную группу, из его пользовательского реестра будут удаляться ключи форсированной настройки экранной заставки, и он самостоятельно сможет, например, отключить её вовсе, так как в ОС диалоговые элементы пользовательского интерфейса станут доступными.
RSS - Записи
Доброго времени суток, Алексей!
Поправьте меня, если не прав.
Тоже самое можно сделать и с помощью обычной GPO. Создаем отдельную GPO, определяем в ней необходимые значения скрин-сейвера, а в Security Filtering заранее созданной групее безопасности запрещаем применять эту GPO (Deny Apply policy).
С ув.,
Андрей.
Поправляю. Если мы говорим о политике которая настраивает только настройки экранной заставки то - да (хотя трудно себе такую политику представить), а вот если в этой политике масса других настроек то, как вы понимаете, все они также не будут влиять на отфильтрованную вами группу пользователей через Security Filtering. Гибкости в таком решении нет никакой.
Более того, если потребуется какая-то более изощрённая настройка, например одним пользователям включить 15 минут, другим выключить и запретить изменять настройки, третьим включить и разрешить отключать...тогда всё равно мы прибегнем к механизмам GPP. Намёк поста в том, что в одной политике с помощью GPP мы можем обработать массу разных сценариев.
Поэтому люди и не пихают в одну политику все подряд
Намек понятен еще в прошлом посте ;)
Спасибо еще раз за демонстрацию GPP.
С ув.
Спасибо за статью! Очень доступно!
Но такой вопрос. Вот мы делаем все по данной статье. В группу Disabled в GPP добавляем всякие учетки мониторинга и прочие VIP учетки не желающие, чтобы их экран блокировался. Остальные попадают в в группу Enabled.
Но! Как быть с пользователями, которые работают в терминалах? Я имею ввиду терминальные сессии (будь то RDP или Citrix). Это обычные пользователи, у них приложение, запущенной в терминальном режиме может быть свернуто, стало быть политика сработает, раз активности нет. Хотя пользователи даже не отходили от компьютера, а лишь держали приложение свернутым. А им придется ввести пароль. А эти пользователи, повторюсь, обычные, и находятся у нас в группе применения настроек. Как быть в этом случае?
Очень надеюсь на Вашу помощь, так как проблема стоит довольно остро.
Cервера RDS - это сервера на которых в любом случае должна применяться обособленная пользовательская политика, которая будет глушить настройки любых других пользовательских политик. То есть вы можете использовать отдельную политику с включённым режимом замыкания.
Спасибо! Это именно то, что нам нужно!
Извините, что пишу здесь, но я не нашел более подходящего места.
Ситуация следующая: планируем внедрять Radmin версии 3. Он хранит группы доступа в одном единственном ключе реестра [HKEY_LOCAL_MACHINESOFTWAREWow6432NodeRadminv3.0ServerParametersNtUsers1] в бинарном виде. В объекте групповой политики, в котором производится установка самого сервера Radmin, посредством GPP я добавляю группу доменных администраторов на полный доступ. Но как быть с администраторами филиалов? То есть на ОП, где содержатся компьютеры филиала должна применяться политика добавляющая к уже имеющейся группе доменных администраторов группу администраторов филиала. Пробовал через GPP создать ключик 1 с группой администраторов филиала и с действием Update применять. Но тогда удаляются права у доменных администраторов. То есть значение ключа реестра не объединяется, а заменяется администраторами филиала.
Вопрос в следующем: можно ли как то средствами GPP добавить в существующий ключ реестра определенное значение, а не просто заменить его?
Еще раз прощу прощения, что написал именно здесь не по теме.
Надеюсь на Вашу помощь!
Попробуйте настроить один и тот же ключ реестра с разными значениями, например один для компьютеров головного филиала, а другой для компьютеров подчинённого филиала и применять эти значения с разным нацеливанием, например отталкиваясь от IP подсетей или от имени компьютера (если у вас существует какая-то регламентированная система именования).
PS: Eсли в заголовке страницы блога перейти на закладку About, - там указан мой email.
Свои пять копеек. До меня политика была настроена через административные шаблоны и дополнительно в GPP обнуление параметра ScreenSaveActive с нацеливанием на группу. у пользователей добавленных в эту группу выключалась заставка и этого было достаточно до появления windows 8.
Сделал как описано, но без правки реестра, если на клиентском ПК (Win7 проф) открыт сеанс RDP - то политика не срабатывает. Как обойти это?
После настройки данной политики напоролись на не очень приятную ситуацию. У части пользователей экран стал блокироваться не через 15 минут, а через 1, 2, у кого-то 5 минут. После разбора установили, что в ветке HOTKEY_Users лежат профили пользователей и там присутствует параметр ScreenSaveTimeout, значение которого отличается от того что в политике. Так как это единичные случаи - вывод, настройки делались локально. Путь к параметру HKU//ControlPanel/Desktop. Вдруг кому-то пригодится.
Поправлю путь HKU//ControlPanel/Desktop
А что мешает настроить GPP на обновление или удаление этого параметра?
Настройка GPP осложняется тем, что сиды у всех разные и путь до параметра тоже будет разным.
Возможно как-то использовать переменные, но я не знаю как ))). В любом случае проблема единичная и решилась удалением параметра вручную, подключившись через удаленный реестр.
Не понял. А при чём тут SID-ы. Разве значение, о котором ты говоришь что оно мешает, не хранится в HKEY_CURRENT_USER для того пользователя, который вошёл в систему? Если так, то просто удали его теми же средствами GPP и всего-то.
Спасибо. Полезная статья!
спасибо, Александр Добрынин, долго искал)
добрый день!
сделал как в статье. в реестре все прописывается. В панели управления-персонализация настройки выставляются.
НО при простое компьютера заставка не появляется.
какие еще параметры влияют на появление заставки?
может быть настройки электропитания в GPP? можно ли сделать 2 схемы электропитания. 1 - гасить экран, 2 - не гасить экран для определенной группы безопасности.
и тогда можно применить к группе компьютеров или пользователей. а не только пользователей
Подскажите неопытному пользователю, как отключить эту блокировку на рабочем ПК?