Cisco Secure Client RDP सत्र से VPN स्थापित करने से रोकता है

साइन-इन सफल होता है और टनल फिर भी नहीं उठता। यह संयोजन लोगों को भ्रमित करता है क्योंकि वे इसे प्रमाणीकरण की समस्या के रूप में पढ़ते हैं और फिर ऐसे क्रेडेंशियल रीसेट करने में दोपहर बिता देते हैं जो कभी समस्या नहीं थे। Cisco Secure Client विशेष रूप से इसलिए VPN स्थापित करने से मना कर सकता है क्योंकि प्रयास Remote Desktop सत्र से आया था, और यह निर्णय क्लाइंट पक्ष की नीति लेती है।

कनेक्शन प्रवाह में यह कहाँ दिखता है

क्लाइंट को ऊपर से देखें। प्रोफ़ाइल लोड होती है, क्रेडेंशियल एकत्र होते हैं और प्रमाणीकरण पूरा होता है। फिर, कोई भी टनल बनने से पहले, क्लाइंट अपनी सत्र और स्थापना सेटिंग्स का मूल्यांकन उस वातावरण के सामने करता है जिसमें वह है।

उस क्षण तीन चीज़ें लिख लें: सटीक संदेश, क्लाइंट संस्करण और क्लाइंट में दिखाया गया प्रोफ़ाइल नाम। ये तीन अस्पष्ट शिकायत को ऐसे सहायता अनुरोध में बदल देते हैं जिस पर कोई कार्रवाई कर सके। संवाद का स्क्रीनशॉट लें, क्योंकि लंबे संदेश लॉग में कट जाते हैं। समय भी नोट करें, ताकि प्रशासक इसे हेडएंड से मिला सके।

वह सेटिंग जो वास्तव में निर्णय लेती है

Windows VPN Establishment नीति प्रासंगिक नियंत्रण है और इसके दो प्रलेखित मान हैं: केवल स्थानीय उपयोगकर्ता, और दूरस्थ उपयोगकर्ताओं को अनुमति दें। दूसरा समर्थित कॉन्फ़िगरेशन में Remote Desktop सत्र से टनल स्थापित करने की अनुमति देता है। पहला कई एंटरप्राइज़ प्रोफ़ाइल में डिफ़ॉल्ट रुख है।

इसे Windows Logon Enforcement से न मिलाएँ, जिसे प्रोफ़ाइल गाइड साइन-इन सत्रों के बारे में अलग नीति के रूप में प्रलेखित करता है। एक तय करती है कौन सा सत्र टनल बना सकता है, दूसरी एक साथ या साइन-इन से पहले के व्यवहार को तय करती है। गलत को बदलने से कोई दृश्य प्रभाव नहीं होता।

वह प्रोफ़ाइल पढ़ें जो वास्तव में लागू है

प्रबंधित परिनियोजन में क्लाइंट अपनी प्रोफ़ाइल हेडएंड या किसी प्रबंधित स्थान से प्राप्त करता है, और डिस्क पर संपादित प्रति अक्सर वह नहीं होती जो लागू है। इसलिए स्थानीय XML परिवर्तन सही दिख सकता है और कुछ नहीं बदलता।

प्रशासक से पूछें कि डिवाइस कौन सी प्रोफ़ाइल और कौन सी समूह नीति प्राप्त करता है, न कि लैपटॉप पर कौन सी फ़ाइल है। संस्करण अपग्रेड के बाद दोनों अक्सर मेल नहीं खाते। स्थानीय फ़ोल्डर में पुरानी प्रति अभी भी संपादक में खुलती है और अभी भी सही दिखती है। वह बस वह नहीं है जो क्लाइंट ने लागू किया।

टनल उठने के बाद RDP पथ

दूरस्थ स्थापना की अनुमति देना यह गारंटी नहीं देता कि आपका Remote Desktop सत्र बचा रहेगा। जब टनल मार्ग या स्थानीय पहुँच नियम बदलता है, तो जिस सत्र ने आपको अंदर लाया वह उसे बनाए रखने वाला पथ खो सकता है।

परिवर्तन से पहले पुनर्प्राप्ति चैनल की योजना बनाएँ: कंसोल पहुँच, आउट-ऑफ-बैंड प्रबंधन पथ, या प्रलेखित पुनःकनेक्शन प्रक्रिया। बाद में इसका निर्णय लेने का अर्थ आमतौर पर मशीन तक यात्रा होता है।

नीति से बचने के लिए सत्र चुराने की चालें, वैकल्पिक रिमोट-कंट्रोल उपकरण या स्क्रिप्ट में लिखा पासवर्ड इस्तेमाल न करें। यदि संगठन इस कार्यप्रवाह को अधिकृत नहीं करता, तो सही कदम वह प्रशासनिक पथ है जिसे वह समर्थन देता है।

प्रशासक को क्या भेजें

उन्हें संदेश का पाठ, क्लाइंट संस्करण, सक्रिय प्रोफ़ाइल का नाम, वह सत्र प्रकार जिससे आप जुड़े, और यह कि स्थानीय कंसोल का प्रयास अलग व्यवहार करता है या नहीं, दें। टाइमस्टैम्प जोड़ें।

यही अंतिम तुलना समय बचाती है, क्योंकि यह सत्र-नीति के इनकार को पूरे डिवाइस की विफलता से अलग करती है।

स्वीकृत परिवर्तन के बाद सत्यापित करें

प्रोफ़ाइल अपडेट होने के बाद नया RDP सत्र स्थापित करें और फिर से जुड़ें, फिर डिस्कनेक्ट अनुक्रम जानबूझकर करें। पुष्टि करें कि टनल उठता है, प्रबंधन पथ बचा रहता है और आपका खाता अभी भी डेस्कटॉप में साइन इन कर सकता है।

VPN प्रवेश, सत्र का बचा रहना और Windows साइन-इन अनुमति तीन अलग जाँचें हैं। एक पास होने से अन्य दो के बारे में कुछ नहीं कहा जाता।