VPN достъп без права за отдалечен работен плот: четири отделни порти

Потребител се свързва с VPN, отваря споделена папка и вътрешно приложение, а след това опит за RDP връща „потребителският акаунт не е упълномощен за отдалечено влизане“. В това съобщение няма нищо погрешно за тунела. Между VPN акаунт и интерактивен работен плот стоят четири независими порти и само последната го е предизвикала. Обикновено хората добавят акаунта към Administrators, което дава много повече от работния плот и не поправя портата, ако груповата политика я забранява. Ето какво всъщност прави всяка порта и как да промените само тази, която отказва.

Четири порти в фиксиран ред

Шлюзът първо решава дали идентичността може изобщо да установи тунел: RADIUS политика, групово условие, проверка на сертификат, разрешение на Access Server. След това маршрутизирането и защитните стени решават дали пакетът от пула на тунела достига слушателя TCP 3389 на дестинацията. След това NLA ръкостискането на клиента удостоверява акаунта пред дестинацията. Едва след тези три локалният орган за сигурност проверява дали акаунтът има правото за влизане, което изисква интерактивна отдалечена сесия.

Понеже редът е фиксиран, всяка порта скрива тези зад нея. Неуспешен тунел не казва нищо за маршрутизирането; блокиран порт не казва нищо за правото за влизане; успешен тест на порт не казва нищо за допускането. Затова „VPN работи, но RDP не“ не е един проблем, а граница между две от тези порти, и затова текстът на грешката е най-бързият начин да разберете коя сте срещнали.

Правото, което всъщност отказва сесията

Влизането в отдалечен работен плот изисква потребителското право Разрешаване на влизане чрез услуги за отдалечен работен плот, SeRemoteInteractiveLogonRight. То се проверява при влизане, не при установяване на тунела, затова акаунт може да се разхожда в мрежата с часове и пак да му бъде отказан работен плот. Диалогът, който го показва, е в «Локални политики», «Задаване на права на потребителите», а домейн еквивалентът е в GPO.

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

Четете действащата политика, не локалния диалог

Локалната политика се презаписва от всяка домейн 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 за правото за влизане изброява настройките по подразбиране за всяка роля на машина и правилото, че отказът побеждава разрешението.