+7 (812) 325 84 00

+7 (499) 322 07 96

Детальный контроль прав доступа к функции Remote Control на клиенте SCCM

Я всегда много рассказывал на семинарах про "тонкую доработку SCCM по потребностям", и призывал к этому слушателей. Приведу хороший пример.

1. Общая постановка задачи
Пару месяцев назад клиент, эксплуатирующий инсталляцию SCCM 2012 R2, обратился с весьма специфическим вопросом.
 
Для нужд удаленной поддержки рабочих мест клиентская служба ТП активно использовала механизм Remote Control (RC) в составе клиента Configuration Manager. Однако, поддержкой разного ПО занимались совершенно разные группы Help Desk; при этом, на рабочем месте могло быть установлено более одного целевого приложения. Стандартный механизм создания коллекций компьютеров с применением соответствующих политик клиента SCCM как ACL для Remote Control не годился, так как настройки прав доступа в политике не кумулятивные; политика, применяемая с наибольшим приоритетом, или последней, “затирает” все остальные. Таким образом, эффективной в каждом конкретном случае становится только одна политика (в нашем случае, для одного из приложений).
 
В сообществе пользователей SCCM этот вопрос к Microsoft (сделать настройки прав доступа к RC объединяемыми для набора нескольких политик) уже поднимался, см. https://configurationmanager.uservoice.com/forums/300492-ideas/suggestions/13748199-ability-to-set-multiple-remote-control-privileges. В SCCM Client Settings часть параметров действительно может объединяться из разных политик (некоторые разделы Inventory, например), но к правам доступа RC это, увы, не относится. После детального анализа задачи стало ясно, что штатными средствами ее не решить.
 
Клиент был весьма озабочен вопросами безопасности, и ситуация, когда кто-то получал удаленный доступ к чужому рабочему столу за пределами своей зоны ответственности, была неприемлема. Правильно разграничить доступ подразделений поддержки только к “своему” приложению не получалось, из-за возможности иметь более одного приложения на контролируемой системе. Дело осложнялось еще и тем, что число пользователей одного приложения могло быть большим (до 500 человек и больше); при этом, очень хотелось автоматизировать логику добавления системы с приложением в соответствующую коллекцию компьютеров (с последующим автоматическим назначением на нее ACL для Remote Control). Ручное добавление каждого объекта-компьютера в нужную коллекцию никого не устраивало; приложения тоже были самые разные, от “толстого” клиента 1C до веб-сервиса, не оставляющего никаких следов в системе нигде, кроме кэша браузера в профиле пользователя. Поэтому от идеи инвентаризации каких-либо объектов, уникально идентифицирующих приложение (вроде файла по фиксированному пути или ключа реестра), пришлось отказаться сразу.
Однако, имелись глобальные группы домена AD, каждая из которых содержала всех пользователей, использующих каждое приложение - это и были группы доступа. Сразу же возникла мысль попробовать использовать эти группы и механизм SCCM UDA (User Device Affinity) для построения коллекций компьютеров, к компоненту Remote Control на которых бы предоставлялся доступ соответствующих групп Help Desk.

2.   Условия

Для примера рассмотрим следующий сценарий, близкий к реальным условиям клиента. Имеется четыре приложения – 1C, Directum, CRM, Invest, для поддержки которых необходимо организовать доступ разных групп службы ТП.

Глобальные группы доступа пользователей к приложениям: DOMAIN\Access_1C, DOMAIN\Access_Directum, DOMAIN\CRM_Access, DOMAIN\Access_Invest;  

Соответствующие (создаваемые в рамках решения) коллекции компьютеров в SCCM: 1C, Directum_5_3, PC_Remote_control_CRM, PC_Remote_control_Invest;
Соответствующие глобальные группы учетных записей пользователей ТП, которым предоставляется доступ к Remote Control для
компьютеров в целевых коллекциях: DOMAIN\SCCM-RC_Access_1C, DOMAIN\SCCM-RC_Access_Directum, DOMAIN\SCCM-RC_Access_CRM, DOMAIN\SCCM-RC_Access_Invest.
Решение строим для этих условий.

3.    Формирование коллекций компьютеров
Механизм сопоставления User Device Affinity требует требует включения в политиках домена параметров аудита Audit account logon events и Audit logon events, как описано в статье “How Automatic User Device Affinity Works in SCCM 2012”, https://blogs.technet.microsoft.com/sudheesn/2015/03/05/how-automatic-user-device-affinity-works-in-sccm-2012. Сбор данных из журналов безопасности осуществляется SCCM автоматически. Порог срабатывания (время работы пользователя в системе, по прошествии которого он становится “Primary User”), контролируется через политику клиента SCCM, раздел “Сопоставление пользователей и устройств”, например, так:


Приступаем к созданию коллекций. Пример для коллекции для компьютеров с CRM:

Коллекция формируется на основе запроса WQL:

Сам запрос WQL:

Идея запроса взята отсюда: “ConfigMgr User Device Affinity (UDA) Collection Query”, https://deploymentramblings.wordpress.com/2017/05/22/configmgr-user-device-affinity-uda-collection-query/. При выполнении этого запроса формируется коллекция компьютеров, основные пользователи (Primary Users в терминологии SCCM) входят в доменную группу DOMAIN\CRM_Access.

Итак, по результатам настройки UDA у нас есть четыре коллекции, которые динамически и в реальном времени формируют списки компьютеров, за которыми работают пользователи соответствующих приложений. Первая часть автоматизированного решения получена.
4. Контроль доступа к Remote Control

Доступ к функции SCCM Remote Control на управляемой системе, в общем случае, контролируется членством в локальной группе "Пользователи удаленного управления Configuration Manager" (в русской версии SCCM). В нее попадают объекты безопасности, прописанные в политике клиента SCCM в разделе “Средства удаленного управления”, параметр “Пользователи средств удаленного управления и удаленного помощника”. При установке значения этого параметра, перечисленные в нем пользователи и группы попадают в локальную группу "Пользователи удаленного управления Configuration Manager" на компьютере, к которому применяется политика. Но, как уже говорилось, эффективная политика – только одна, поэтому нам стандартный механизм помочь не может.

Однако, опытным путем установлено, что если параметр “Пользователи средств удаленного управления и удаленного помощника” в политике клиента SCCM оставить пустым, вот так:

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

Именно такое решение и было применено – скрипт на WSH с помощью подсистемы WMI подключается к локальным экземплярам классов клиента SCCM, и динамически проверяет принадлежность системы к каждой из анализируемых коллекций, при необходимости добавляя в локальную группу "Пользователи удаленного управления Configuration Manager" операционной системы десктопа требуемую глобальную группу доступа для Help Desk.

“Подводный камень” заключается в том, что простого способа проверить список коллекций, к которым принадлежит компьютер, с помощью локальной подсистемы WMI - нет (по крайней мере, я пока не придумал). Такая проверка возможна только, если подсоединиться по сети к подсистеме WMI самого сервера SCCM. Но очень хочется исполнять скрипт с правами локальной системы, а не сетевой учетной записи - ведь если подсоединяться к SCCM с локальной системы с помощью сетевой УЗ с паролем, это почти наверняка так или иначе приведет к ослаблению системы безопасности. Учетная же запись системы по сети подсоединиться к SCCM для проверки списка коллекций не может - для такого запроса у нее не хватает прав на уровне DCOM, а ослаблять защиту DCOM без крайней необходимости не стоит, по той же причине.

Эта задача решается с помощью переменных коллекции. Пример того, как это реализовано, для уже упомянутой коллекции PC_Remote_control_CRM:


То есть, для каждой проверяемой коллекции (и только для нее одной в рамках инсталляции SCCM), мы дополнительно определяем специальную переменную с префиксом Collection_RC_, с именем и значением, соответствующим имени самой коллекции. Переменные коллекции, в отличие от самого списка коллекций, “спускаются” в локальный WMI клиента при каждом обновлении политики; наличие их в репозитарии WMI мы проверяем программным способом.

Скрипт ManageSCCMRCAccess.vbs приведен в приложении к статье, предоставляется AS IS. Работоспособность проверена на всех версиях Windows, содержащих подсистему WMI, то есть, он гарантированно работает на Windows XP и выше - иначе говоря, на всех системах Windows, для которых существует клиент SCCM. Логика скрипта отражает условия нашей задачи (имена коллекций и групп), но он может быть адаптирован по потребностям для любого количества комбинаций “коллекция-группа доступа”. Для запроса данных SCCM используются классы и методы WMI, для управления локальной группой – интерфейс ADSI. Перед каждой проверкой коллекций производится предварительная чистка группы "Пользователи удаленного управления Configuration Manager". Это сделано для отработки ситуации, когда приложение более не используется (компьютер пропадает из коллекции), это приводит к отзыву права подключения у соответствующей группы ТП. Установка константы DEBUGLOG=True задает протоколирование работы скрипта в простой текстовый лог C:\SCCM_RC_Config.log – включить отладку полезно на случай, если что-то пошло не так.

5. Запуск скрипта

Скрипт размещается в сетевой папке с правами только для чтения для группы Domain Computers, запускается планировщиком Task Scheduler операционной системы раз в час, обнаруженные изменения вступают в силу немедленно. Этого оказалось достаточно, чтобы построить систему управления правами доступа к Remote Control, практически не требующую вмешательства администратора. Единственное, что нужно – добавлять пользователей в глобальные группы доступа к приложениям DOMAIN\Access*, но это как раз та операция, которая контролируется персоналом ИТ.

Никто, кстати, не мешает использовать любые другие способы периодического запуска скрипта, например, с помощью самого SCCM.

Скриншоты задания планировщика приведены ниже, они тривиальны. Задача назначается на целевые рабочие станции с помощью доменного GPO, раздел “Preferences”:






Отдельное замечание касается использования объектов планировщика в Group Policy Preferences. В механизме GPP уже давно обнаружена уязвимость, делающая хранение паролей в них небезопасным – см. бюллетень Microsoft Technet MS14-025 https://docs.microsoft.com/en-us/security-updates/SecurityBulletins/2014/ms14-025. В поддерживаемых версиях ОС Windows возможность хранения пользовательских паролей в GPP принудительно отключена модулями коррекции, распространяемыми через Windows Update или WSUS, и это правильно. Однако, поскольку мы запускаем задачу от системы, к нам проблема отношения не имеет.
6. Замечания

  • Все ссылки на реальную инфраструктуру клиента в скрипте и скриншотах изменены;
  • Решение тестировалось в среде SCCM 2012 R2, но оно полностью применимо и к SCCM 2016 – основные подсистемы в новой версии почти не поменялись;
  • Для анализа объектов WMI в системе Windows, из известных мне средств, удобнее всего использовать утилиту WMI Explorer от CodePlex, см. https://archive.codeplex.com/?p=wmie.