Доступ через 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 про право входу перелічує значення за замовчуванням для кожної ролі машини та правило, що відмова переважає дозвіл.