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-ը, որը ձախողվում է, մինչ պորտի թեստը հաջողվում է, ICMP-ին այլ կերպ պատասխանող firewall է, ոչ թե RDP-ի արգելափակման ապացույց։ Microsoft-ի մուտքի իրավունքի տեղեկանքը թվարկում է մեքենայի դերով լռելյայնները և այն կանոնը, որ մերժումը հաղթում է թույլտվությանը։