Доступ по VPN без прав на удалённый рабочий стол: четыре отдельные преграды

Пользователь подключается к VPN, открывает файловый ресурс и внутреннее приложение, а затем попытка RDP возвращает «учётная запись пользователя не имеет права на удалённый вход». В этом сообщении с туннелем всё в порядке. Между учётной записью VPN и интерактивным рабочим столом стоят четыре независимые преграды, и только последняя его создала. Обычно люди добавляют учётную запись в Administrators, что даёт гораздо больше, чем рабочий стол, и не исправляет преграду, если групповая политика её запрещает. Вот что на самом деле делает каждая преграда и как изменить только ту, которая отказывает.

Четыре преграды в фиксированном порядке

Шлюз сначала решает, может ли удостоверение вообще установить туннель: политика RADIUS, условие группы, проверка сертификата, разрешение Access Server. Затем маршрутизация и межсетевые экраны решают, доходит ли пакет из пула туннеля до прослушивателя TCP 3389 назначения. Затем рукопожатие NLA клиента аутентифицирует учётную запись на назначении. Только после этих трёх локальный орган безопасности проверяет, есть ли у учётной записи право входа, которое требует интерактивный удалённый сеанс.

Поскольку порядок фиксирован, каждая преграда скрывает стоящие за ней. Неудачный туннель ничего не говорит о маршрутизации; закрытый порт ничего не говорит о праве входа; успешная проверка порта ничего не говорит о допуске. Поэтому «VPN работает, а RDP нет» — не одна проблема, а граница между двумя из этих преград, и поэтому текст ошибки — самый быстрый способ узнать, на какую вы наткнулись.

Право, которое действительно отклоняет сеанс

Для входа на удалённый рабочий стол требуется право пользователя Разрешить вход через службы удалённых рабочих столов, SeRemoteInteractiveLogonRight. Оно проверяется при входе, а не при установке туннеля, поэтому учётная запись может часами бродить по сети и всё равно получить отказ в рабочем столе. Диалог, который его показывает, находится в разделе «Локальные политики», «Назначение прав пользователей», а доменный эквивалент — в GPO.

Членство по умолчанию зависит от роли машины: рабочие станции и рядовые серверы предоставляют его группам Administrators и Remote Desktop Users, а контроллер домена — только группе Administrators. Этот единственный факт объясняет большую часть путаницы, потому что одна и та же учётная запись успешно работает на файловом сервере и терпит неудачу на контроллере домена. Право отказа перевешивает соответствующее право разрешения независимо от членства в группе, поэтому учётная запись, которой и разрешено, и отказано, получает отказ. Широкая группа отказа может задеть администратора, добавленного из любезности.

Читайте действующую политику, а не локальный диалог

Локальная политика перезаписывается любой доменной GPO, определяющей то же право, поэтому локальная оснастка может показывать внешне правильный список, тогда как действующее состояние иное. Экспортируйте то, что машина действительно применяет, затем найдите право и читайте SID, а не отображаемые имена:

secedit /export /cfg C:\temp\secpol.cfg
Select-String -Path C:\temp\secpol.cfg -Pattern SeRemoteInteractiveLogonRight
gpresult /scope computer /v

В этом выводе *S-1-5-32-544 — это Administrators, а *S-1-5-32-555 — Remote Desktop Users.

Если не появляется ни одного, никто, кроме владельца политики, не может открыть рабочий стол, что бы ни предлагал локальный диалог пользователей и групп. Тогда gpresult называет победившую GPO, и именно этот объект нужно редактировать; менять локальную политику на машине, присоединённой к домену, — это тест, а не исправление.

Выдайте самое узкое подходящее право

Обычный ответ — группа Remote Desktop Users на назначении. Она несёт право по умолчанию, намного меньше группы Administrators и разделяет «может открыть рабочий стол» и «может управлять сервером». Там, где политика явно перераспределила право, добавьте группу или учётную запись в эту политику, вместо того чтобы добавлять группу, которую никто не задумывал как контроль доступа.

Add-LocalGroupMember -Group "Remote Desktop Users" -Member "CORP\a.user"

Проверьте список отказов, прежде чем что-либо добавлять. Если право отказа называет группу, содержащую пользователя, правильное изменение — удалить учётную запись из этой группы или сузить отказ, а не добавлять второе разрешение в другом месте. Запишите, какое право и где вы изменили, потому что последующее обновление GPO молча вернёт прежнее состояние, и заявка откроется снова с тем же сообщением.

Держите сетевой путь отдельным решением

Группе VPN не обязательно достигать каждого порта. Когда группе нужно приложение, а не рабочий стол, правило межсетевого экрана, ограниченное пулом туннеля и портом приложения, придаёт этой политике силу, а право входа остаётся нетронутым.

Get-NetFirewallRule -DisplayGroup "Remote Desktop"
Test-NetConnection -ComputerName 10.20.0.50 -Port 3389

Собственная конфигурация OpenVPN для каждого клиента и разрешения групп Access Server могут в том же духе ограничивать префиксы назначения; ни то, ни другое не даёт права входа Windows, а право входа не может открыть порт. Держите их в отдельных окнах изменений, потому что правило порта и право утверждают разные люди.

Проверяйте в том же порядке, в каком действуют преграды: может ли учётная запись установить туннель, доходит ли сеанс до прослушивателя, аутентифицируется ли клиент и есть ли у учётной записи право. Ping, который не проходит при успешной проверке порта, — это межсетевой экран, иначе отвечающий на ICMP, а не доказательство блокировки RDP. Справочник Microsoft о праве входа перечисляет значения по умолчанию для каждой роли машины и правило, что отказ перевешивает разрешение.