Windows असा पासवर्ड नाकारतो जो त्याने एक मिनिटापूर्वी दुसरीकडे स्वीकारला होता, त्यामुळे प्रयत्नाचे मूल्यांकनच झाले नसताना खाते बिघडलेले दिसते। त्रुटी 691 चा अर्थ प्रमाणीकरणादरम्यान कनेक्शन नाकारले गेले असा आहे, आणि गुप्त शब्द चुकीचा असो, खाते नाव अनपेक्षित ओळखीत बदलले असो, किंवा सर्व्हरकडील धोरणाने कनेक्शन नाकारले असो, क्लायंट तोच मजकूर दाखवतो। तीन वेगवेगळी दुरुस्ती एकच संदेश वाटून घेतात, म्हणून रीसेट कधी मदत करतो आणि कधी काहीच बदलत नाही। जो भाग तुम्ही एकट्याने तपासू शकता त्यापासून सुरुवात करा: क्लायंटने पाठवलेली नेमकी स्ट्रिंग आणि ती घेतलेला क्रेडेन्शियल साठा। नंतर सर्व्हरला विचारा की त्याने कोणता निर्णय नोंदवला, कारण संवाद हे नाकारणे आहे, निदान नाही।

नाकारले जाण्याचे तीन मार्ग, एक संवाद

चुकीचा गुप्त शब्द या संवादापर्यंत पोहोचण्याचा फक्त पहिला मार्ग आहे। खाते नाव तुम्ही हेतू न केलेल्या ओळखीत बदलू शकते, खात्याकडे डायल-इन परवानगी नसू शकते, किंवा पासवर्ड स्वीकारल्यानंतर सर्व्हरची अट कनेक्शन नाकारू शकते। यापैकी प्रत्येकजण तोच क्लायंट मजकूर निर्माण करतो, आणि प्रत्येकाची स्वतःची दुरुस्ती आहे।

म्हणूनच रीसेट सोमवारी काम करताना दिसतो आणि मंगळवारी काहीच करत नाही। संवादाला निदान नाही, नाकारणे म्हणून वाचा, आणि खात्याला हात लावण्यापूर्वी प्रोफाइल नाव आणि अयशस्वीतेची स्थानिक वेळ नोंदवा।

हे तीन प्रकार वेगवेगळ्या स्तरांवरही अयशस्वी होतात। चुकीचा गुप्त शब्द ओळख-पुराव्यात अयशस्वी होतो, चुकीचा खाते स्वरूप शोधात अयशस्वी होतो, आणि धोरणाची अट ओळख सिद्ध झाल्यानंतर अधिकृततेत अयशस्वी होते। फक्त पहिलीच पासवर्ड बदलून दुरुस्त होते। उर्वरित दोनांना सर्व्हरच्या निर्णय-नोंदीत प्रवेश असलेल्या व्यक्तीची गरज असते, म्हणून पुढील पायरी आणखी एक रीसेट नाही, माहितीची विनंती आहे।

क्लायंटने प्रत्यक्षात काय पाठवले

गेटवे चालवणाऱ्यांसोबत स्वीकारलेले खाते स्वरूप निश्चित करा, कारण कोरडे वापरकर्तानाव, डोमेन-पात्र नाव आणि वापरकर्ता मुख्य नाव वेगवेगळ्या खाते संदर्भांमध्ये बदलू शकतात। त्यापैकी फक्त एकच परवानगी असलेली ओळख असू शकते। पाचव्या प्रयत्नानंतर नाही, पहिल्या प्रयत्नापूर्वी गेटवे कोणते स्वरूप अपेक्षित करतो ते विचारा, आणि क्लायंट तुम्ही टाइप केलेल्या क्रेडेन्शियलऐवजी साठवलेले क्रेडेन्शियल पुन्हा वापरत आहे का ते तपासा।

Windows मशीनवरील दोन फक्त-वाचन क्वेऱ्या प्रोफाइल आणि संवादावर मात करू शकणारे कोणतेही कॅशे केलेले क्रेडेन्शियल दाखवतात। दोन्हीपैकी कोणतेही सर्व्हरला डायल करत नाही:

Get-VpnConnection -Name 'Corp VPN' | Format-List Name, ServerAddress, TunnelType, AuthenticationMethod
cmdkey /list | Select-String -Pattern 'corp' -SimpleMatch

पासवर्डला दस्तऐवजातून कॉपी केलेला मजकूर नाही, डेटा म्हणून घ्या। स्क्रिप्टमधून गेलेल्या मूल्यात असे एस्केप अक्षर असू शकतात जे कधीही गुप्त शब्दाचा भाग नव्हते, आणि कॉन्फिगरेशन निर्यातीने ते अवतरण चिन्हांत ठेवले असेल। बसवण्यासाठी प्रत्येक विशेष अक्षर काढणे हे खरे मूल्य शोधण्यापेक्षा वेगळे बदल आहे, म्हणून प्रथम खरे मूल्य निश्चित करा।

धोरणाचा निर्णय मिळवा, रीसेट नाही

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

प्रशासकाला प्रोफाइल नाव, प्रयत्न केलेले खाते आणि वेळ-चिन्ह पाठवा। आणखी एक पासवर्ड रीसेटऐवजी संबंधित निर्णय-नोंद आणि तिचे कारण मागा, आणि इव्हेंट जे धोरण नाव वाहते तेही मागा। Microsoft चे दूरस्थ-प्रवेश त्रुटी कोड संदर्भ क्रेडेन्शियल आणि प्रमाणीकरण अयशस्वीतेत 691 ची नोंद करते, आणि म्हणूनच संवाद तीनही प्रकरणे वेगळी करू शकत नाही।

खाते बिनशर्त परवानगीत बदलल्याने अधिकृततेचा निर्णय कायमचा अपवाद होतो। ते उपयुक्त काम करणारी अटही काढून टाकते, आणि पुढे धोरणाचा आढावा घेणाऱ्याला ते का बदलले हे कळणार नाही। त्याऐवजी मालकाला इच्छित धोरणाची पुष्टी करायला सांगा, जेणेकरून स्वीकृती जाणीवपूर्वक राहील।

आणखी एकदा प्रयत्न करा, मग तुलना करा

तुम्ही ओळखलेल्या एकमेव दुरुस्तीनंतर तोच प्रोफाइल पुन्हा वापरा। प्रवेश स्वीकारला गेला आणि काही अंतर्गत संसाधन अजूनही अयशस्वी झाले, तर अयशस्वीता दुसऱ्या स्तरावर गेली आहे आणि आता पासवर्डबद्दल काहीच सांगत नाही। प्रोफाइल अपरिवर्तित ठेवणे हेच त्या तुलनेला अर्थपूर्ण बनवते।

नाकारणे स्पष्ट होण्यापूर्वी पत्ता-कुटुंब अक्षम करण्याचा किंवा तपशीलवार ट्रेसिंग सुरू करण्याचा मोह टाळा। ट्रेसिंग निर्णय नाही, प्रमाण निर्माण करते, आणि पहिला उपयुक्त निकाल प्रयत्न नाकारणारा घटक आणि त्याने नोंदवलेले कारण हेच राहते। ते कळल्यावर, पुनःप्रयत्न एकतर दुरुस्तीची पुष्टी करतो किंवा नवे आणि अरुंद लक्षण निर्माण करतो।

संबंधित लेख