कार्यात पासवर्ड न ठेवता 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 ला अदृश्य असते।

प्रमाणीकरण पद्धत आणि खाते कार्याच्या स्वतःच्या नोंदींमध्ये लिहा। सर्व्हरचे धोरण बदलणाऱ्या पुढील व्यक्तीला कोणती रचना चालू आहे हे माहीत असणे आवश्यक आहे। ते उत्तर केवळ पुनर्कनेक्शन वर्तनातून दिसत नाही। पुढील फिरकी पहिल्यांदा जिथे पाहील तिथे ते लिहा।