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 साइन-इन परवानगी या तीन स्वतंत्र तपासण्या आहेत. एक पास झाल्याने इतर दोनांबद्दल काहीही सांगता येत नाही.