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