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 के लिए अदृश्य है।

प्रमाणीकरण विधि और खाते को कार्य के अपने नोट्स में लिखें। सर्वर की नीति बदलने वाले अगले व्यक्ति को जानना होगा कि कौन सा डिज़ाइन चल रहा है। वह जवाब केवल पुनः कनेक्शन व्यवहार से दिखाई नहीं देता। इसे वहाँ लिखें जहाँ अगला रोटेशन पहले देखेगा।