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-ის შესვლის უფლების ცნობარი ჩამოთვლის მანქანის როლის მიხედვით ნაგულისხმევებს და წესს, რომ უარყოფა ამარცხებს ნებართვას.