रिमोट डेस्कटॉप अधिकारांशिवाय 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 चा लॉगऑन अधिकार संदर्भ मशीन भूमिकेनुसार डीफॉल्ट आणि नकार परवानगीवर मात करतो हा नियम सूचीबद्ध करतो.