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

Корисник се поврзува со VPN, отвора споделена папка и внатрешна апликација, а потоа обидот за RDP враќа „корисничката сметка не е овластена за оддалечено најавување“. Во таа порака нема ништо погрешно за тунелот. Помеѓу VPN-сметка и интерактивна работна површина стојат четири независни порти и само последната го создаде тоа. Луѓето обично реагираат со додавање на сметката во Administrators, што дава многу повеќе од работната површина и не ја поправа портата ако групната политика ја забранува. Еве што всушност прави секоја порта и како да се смени само онаа што одбива.

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

Портата најпрво одлучува дали идентитетот воопшто може да воспостави тунел: RADIUS политика, групен услов, проверка на сертификат, дозвола на Access Server. Потоа рутирањето и firewall-ите одлучуваат дали пакетот од базенот на тунелот стигнува до TCP 3389 слушателот на дестинацијата. Потоа NLA ракувањето на клиентот ја автентификува сметката пред дестинацијата. Само по тие три, локалната безбедносна власт проверува дали сметката го има правото за најавување што го бара интерактивна оддалечена сесија.

Бидејќи редоследот е фиксен, секоја порта ги крие тие зад себе. Неуспешен тунел не кажува ништо за рутирањето; блокиран порт не кажува ништо за правото за најавување; успешен тест на порта не кажува ништо за приемот. Затоа „VPN работи, но RDP не“ не е еден проблем туку граница меѓу две од овие порти, и затоа текстот на грешката е најбрзиот начин да се знае која ја погодивте.

Правото што всушност ја одбива сесијата

Најавувањето на оддалечената работна површина бара корисничко право Дозволи најавување преку услуги за оддалечена работна површина, SeRemoteInteractiveLogonRight. Тоа се проверува при најавување, не при поставување на тунелот, затоа сметката може со часови да прелистува низ мрежата и сепак да и биде одбиена работна површина. Дијалогот што го прикажува е под Локални политики, Доделување кориснички права, а доменскиот еквивалент е во GPO.

Стандардното членство зависи од улогата на машината: работните станици и членските сервери го даваат на Administrators и Remote Desktop Users, додека доменскиот контролер само на Administrators. Овој единствен факт го објаснува најголемиот дел од конфузијата, бидејќи истата сметка успева на сервер за датотеки, а не успева на DC. Правото за одбивање го победува соодветното право за дозволување без оглед на членството во група, така што сметка што е и дозволена и одбиена е одбиена. Широка група за одбивање може да фати администратор додаден од услужност.

Читајте ја ефективната политика, не локалниот дијалог

Локалната политика ја препишува секоја доменска GPO што го дефинира истото право, така што локалниот snap-in може да прикажува список што изгледа точно, а ефективната состојба е поинаква. Извезете што машината навистина применува, потоа пронајдете го правото и читајте 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 групата не мора да стигне до секоја порта. Кога на групата и треба апликација, а не работна површина, правило за firewall ограничено на базенот на тунелот и портата на апликацијата ѝ дава ефект на таа политика, додека правото за најавување останува недопрено.

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

Сопствената конфигурација на OpenVPN по клиент и групните дозволи на Access Server можат да ги ограничат префиксите на дестинацијата во истиот дух; ниту едно од нив не дава право за најавување во Windows, а правото за најавување не може да отвори порта. Држете ги во одделни прозорци за промени, бидејќи правило за порта и право ги одобруваат различни луѓе.

Проверете во истиот редослед во кој важат портите: може ли сметката да го воспостави тунелот, дали сесијата стигнува до слушателот, дали клиентот се автентификува и дали сметката го има правото. Ping што не успева додека тестот на порта успева е firewall што одговара поинаку на ICMP, а не доказ дека RDP е блокиран. Референцата на Microsoft за правото за најавување ги наведува стандардите по улога на машина и правилото дека одбивањето го победува дозволувањето.