SCCM Remote Connection Profiles – исправляем глюк с именем группы

Относительно недавно в SCCM появилась возможность настраивать профили удаленного доступа – Remote Connection Profiles. Они предназначены прежде всего для интеграции с Intune, но работаю и без облачного сервиса.

SCCM активно используется моими коллегами, поэтому было логично реализовать для сотрудников удаленный доступ к своим рабочим местам именно с помощью SCCM и, в частности, с помощью Remote Connection Profiles.

Когда Remote Connection Profiles приезжает на компьютер пользователя, то он выполняет несколько действий:

1. Включает RDP
2. Включает NLA
3. Включает разрешающее правило для RDP в фаэрволе
4. Создает группу Remote PC Connect
5. Добавляет в нее пользователя, который является владельцем устройства (Primary device)

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

Поскольку документации описывающей, как работает SCCM, традиционно нет, то пришлось выполнить поиск неисправности самостоятельно. Первая гипотеза заключалась в том, что для группы назначаются прямые права на доступ по RDP. Чтобы это сделать, надо дать права на стандартный прослушиватель RDP-Tcp или создать свой и дать на него права, плюс в локальных политиках назначить соответствующее право.

Проверки политик безопасности и прав на прослушиватель RDP-Tcp показали, что ничего там не прописано для группы Remote PC Connect. Никакого нового прослушивателя тоже не было. В системных журналах всё чисто.

С помощью утилиты procmon (Process Monitor) была снята трассировка выполнения нужного конфигурационного элемента. Это очень просто сделать: нужно запустить на клиентском рабочем месте оснастку Configuration Manager, открыть закладку «Конфигурации», выбрать нужный элемент и нажать «Оценить» — в этот момент procmon запишет все, что нам нужно.

Анализ трассировки показал, что выполняются некие действия с группой Remote PC Connect, но не обнаружил ничего связанного с настройкой прав для этой группы. Таким образом остался единственный вариант: должна использоваться встроенная группа «Пользователи удаленного рабочего стола». И трассировке она попалась! Правда под не под именем «Пользователи удаленного рабочего стола», а как «Remote Desktop Users».

Стоило нам переименовать на системе группу «Пользователи удаленного рабочего стола» в «Remote Desktop Users» и нажать «Оценить», как удаленный доступ заработал! Как оказалось, клиент SCCM просто добавил пользователя в группу «Remote Desktop Users». Вот так оно и работает.

Чтобы окончательно вылечить ситуацию, требовалось переименовать группу на всех компьютерах, на которые приезжал Remote Connection Profile. Мысль о GPO (точнее GPP) была быстро отброшена, т.к. нацеливание политики можно было делать только на все компьютеры, ограничить это сложно без наличия явной группы безопасности, а имея готовую коллекцию, на которую приезжает Remote Connection Profile, на неё же можно назначить корректирующий элемент Compliance Setting, который выполнит переименование только на нужных компьютерах.

Так и поступили. Сделали элемент, который использует скрипты Powershell:

Для диагностики:

$a=gwmi -Query "Select * From Win32_Group Where LocalAccount = TRUE And SID = 'S-1-5-32-555' " -ComputerName testdell390
$a.Name -eq "Remote Desktop Users"

Для исправления:

$a=gwmi -Query "Select * From Win32_Group Where LocalAccount = TRUE And SID = 'S-1-5-32-555' " -ComputerName testdell390
$a.Rename("Remote Desktop Users")

В конечном итоге у меня сложилось мнение, что RCP можно реализовать самостоятельно небольшим скриптом: даже аффинити легко получить с помощью класса ccm_useraffinity.

Полезные ссылки:

1. Well-known security identifiers in Windows operating systems
2. WellKnownSidType Enumeration
3. How Can I Determine the Name of the Local Administrators Group?
4. Introduction to Remote Connection Profiles in Configuration Manager

Реклама