कार्यमा पासवर्ड नराखी Windows VPN पुनः जडान गर्नुहोस्

हरेक निगरानीविहीन पुनः जडान विधि अन्ततः एउटै प्रश्नमा आउँछ: पासवर्ड कहाँ बस्छ। लोकप्रिय उत्तर कार्यको कार्य नै हो, जुन यसका लागि सबैभन्दा खराब ठाउँ पनि हो। दुई अन्य डिजाइन अवस्थित छन्। कुन उपयुक्त हुन्छ भन्ने मेसिनले व्यक्तिबिना प्रमाणीकरण गर्न सक्छ कि र सर्भरले प्रमाणपत्र स्वीकार्छ कि भन्नेमा निर्भर गर्दछ।

कार्यको कार्यले के पढ्नयोग्य छोड्छ

निर्धारित कार्यमा आर्गुमेन्टहरू यसको परिभाषाको भाग हुन्, लुकेको रनटाइम मान होइन। जो कोहीले कार्य पढ्न, यसको ब्याकअप पुनर्स्थापना गर्न वा यसको XML निर्यात गर्न सक्छ, उसले तपाईंले टाइप गरेको स्ट्रिङ ठ्याक्कै त्यसै गरी देख्छ। चल्दा त्यही स्ट्रिङ प्रक्रिया सूचीमा देखिन्छ। निगरानी एजेन्टले यसलाई तपाईंले कहिल्यै नहेर्ने लगमा प्रतिलिपि गर्न सक्छ।

schtasks /query /tn "VPN Reconnect" /xml
cmdkey /list

उल्टो अनुमान गर्नु अघि जाँच गर्नुहोस्। पहिलो आदेशले कार्य र यसका आर्गुमेन्टसहित पूर्ण परिभाषा छाप्छ। दोस्रोले हालको खाताले कुन क्रेडेन्सियलहरू क्यास गरेको छ देखाउँछ, जुन तलका वैकल्पिक डिजाइनहरूका लागि महत्त्वपूर्ण छ। यदि पासवर्ड कार्यको XML मा देखिन्छ भने, यसलाई घुमाउनु मर्मतको आधा मात्र हो, किनकि कार्यले अझै पुरानो मान राख्छ।

भण्डारण गरिएको पूर्व-साझा कुञ्जीले वास्तवमा के दिन्छ

Add-VpnConnection -L2tpPsk कुञ्जीलाई कार्यमा होइन, जडानको फोनबुक प्रविष्टिमा लेख्छ। यो कार्यको कार्यभन्दा सानो जोखिम सतह हो। यो अझै पुनःप्राप्त गर्न सकिने रहस्य हो, किनकि मेसिनमा प्रशासकले फोनबुक पढ्न सक्छ।

तपाईंले नियन्त्रण गर्ने दुई मेसिनबीचको प्रयोगशाला लिङ्कका लागि त्यो साटासाट स्वीकार्य हुन सक्छ। साझा अन्त्य बिन्दुमा प्रयोगकर्ता क्रेडेन्सियलका लागि त्यो होइन। यसलाई इन्क्रिप्टेड भण्डारण भन्नुले को पढ्न सक्छ भन्ने बदल्दैन। फोनबुक एक कन्फिगरेसन फाइल हो। यसलाई खोल्न सक्ने व्यक्तिका लागि योजना बनाउनुहोस्, प्रयोगकर्ताका रूपमा लगइन गर्न सक्ने व्यक्तिका लागि मात्र होइन।

Winlogon क्रेडेन्सियलहरूले रहस्य हटाउँछन् र निर्भरता थप्छन्

-UseWinlogonCredential फरक बाटो लिन्छ। जडानले प्रमाणीकरण गर्छ MSCHAPv2 सँग लगइन भएको प्रयोगकर्ताको क्रेडेन्सियलविरुद्ध। त्यो खाताका लागि अतिरिक्त केही भण्डारण गरिँदैन।

यसले थप्ने निर्भरता महत्त्वपूर्ण छ। ऋण लिनका लागि इन्टरएक्टिभ लगअन हुनुपर्छ, जसले सेवा खाता र लगअन अघिको कार्य बाहिर राख्छ। जडानले त्यो प्रयोगकर्ताको क्रेडेन्सियलले सर्भरमा पुग्न सक्ने सबै पनि वंशानुगत रूपमा पाउँछ। स्विचलाई सुरक्षा सेटिङका रूपमा होइन, क्रेडेन्सियल कहाँबाट आउँछ भन्ने कथनका रूपमा पढ्नुहोस्। यसले स्रोत बदल्छ र सर्भरले पछि सत्रलाई कसरी अधिकृत गर्छ भन्नेमा केही बदल्दैन।

प्रमाणपत्र प्रमाणीकरण स्केल हुन्छ किनकि केही भण्डारण गरिँदैन

जहाँ सर्भरले EAP-TLS समर्थन गर्छ, त्यहाँ मेसिन प्रमाणपत्रले साझा रहस्य पूर्ण रूपमा हटाउँछ, र रद्दीकरण प्रमाणपत्र तहमा हुन्छ। SYSTEM का रूपमा चल्ने कार्यले इन्टरएक्टिभ लगअनबिना त्यो प्रमाणपत्र प्रस्तुत गर्न सक्छ। यसमा निर्माण गर्नु अघि सर्भरले प्रमाणपत्र प्रमाणीकरण स्वीकार्छ भनी पुष्टि गर्नुहोस्। असमर्थित विधिमा निर्भर डिजाइन समाधानभन्दा योजना हो। त्यसपछि निजी कुञ्जी कहाँ बस्छ भन्ने निर्णय गर्नुहोस्: यन्त्र पहिचानका लागि मेसिन स्टोर, व्यक्तिका लागि प्रयोगकर्ता स्टोर।

जहाँ प्रयोगकर्ता नाम र पासवर्डबाट बच्न सकिँदैन, तिनलाई कार्यको आफ्नै खातामा सीमित गरी Credential Manager मा भण्डारण गर्नुहोस्। क्लाइन्टले तिनलाई आर्गुमेन्टबाट होइन, त्यहीँबाट पढ्न दिनुहोस्। कार्यले नछापी प्राप्त गर्न सक्ने रहस्य यसको परिभाषामा लेखिएको भन्दा सानो समस्या हो।

अर्को परिक्रमण अघि कलाकृतिहरूको समीक्षा गर्नुहोस्

तपाईंले के चाहनुभएको थियो होइन, के भण्डारण गरिएको छ हेर्नुहोस्। प्रत्येक प्रयोगकर्ताको फोनबुक, सबै प्रयोगकर्ताका लागि प्रतिलिपि, कार्यको XML र डायल आदेश बोलाउने कुनै पनि स्क्रिप्ट जाँच गर्नुहोस्। त्यसपछि प्रमाणपत्र वा क्यास गरिएको क्रेडेन्सियल कार्यले प्रयोग गर्ने खातामा सीमित छ भनी पुष्टि गर्नुहोस्, किनकि तपाईंको इन्टरएक्टिभ खाताका लागि भण्डारण गरिएको क्रेडेन्सियल SYSTEM का लागि अदृश्य छ।

प्रमाणीकरण विधि र खाता कार्यकै नोटहरूमा रेकर्ड गर्नुहोस्। सर्भरको नीति बदल्ने अर्को व्यक्तिले कुन डिजाइन चलिरहेको छ जान्न आवश्यक छ। त्यो उत्तर पुनः जडान व्यवहारबाट मात्र देखिँदैन। अर्को परिक्रमणले पहिले हेर्ने ठाउँमा त्यो लेख्नुहोस्।