Viscosity ने पासवर्ड याद रखा: उस चेकबॉक्स ने क्या किया

लॉगिन प्रॉम्प्ट पर वह चेकबॉक्स क्लाइंट की पसंद जैसा दिखता है, लेकिन प्रबंधित मशीन पर यह अक्सर नीति का निर्णय होता है। Viscosity का याद रखने वाला नियंत्रण क्रेडेंशियल को macOS कीचेन में संग्रहीत करता है, जब परिनियोजन संग्रहण की अनुमति देता है। मिथक यह है कि चेकबॉक्स हमेशा आपका सेट करने के लिए होता है। व्यवहार में तीन अलग चीज़ें इसे रोक सकती हैं, और उनमें से केवल एक पासवर्ड से जुड़ी है।

चेकबॉक्स वास्तव में क्या संग्रहीत करता है

याद रखने का विकल्प चुनने पर क्लाइंट से उस एक कनेक्शन और खाते के लिए मान रखने का अनुरोध होता है। आइटम कीचेन में पहुँचता है, और बाद के लॉगिन समर्थित प्रॉम्प्ट के माध्यम से इसका पुनः उपयोग करते हैं, छिपी प्राथमिकता के माध्यम से नहीं। कनेक्शन फ़ाइल में ही कुछ भी नहीं लिखा जाता। यही अलगाव यह भी समझाता है कि बाद में आइटम हटाने पर टूटी प्रोफ़ाइल के बजाय प्रॉम्प्ट क्यों आता है।

संग्रहीत मान उस प्रमाणीकरण का इनपुट है जो सर्वर वैसे भी करने वाला था। यह नहीं बदलता कि गेटवे क्या माँगता है, दूसरे कारक को बायपास नहीं करता, और एक बार वाले कोड को पुनः उपयोग योग्य रहस्य नहीं बनाता। यह टाइपिंग को छोटा करता है, उस नीति को नहीं जो परिनियोजन उस खाते पर लागू करता है।

नियंत्रण क्यों अनुपस्थित हो सकता है

व्यवस्थापक प्रबंधित इंस्टॉलेशन के लिए क्रेडेंशियल संग्रहण बंद कर सकता है, और SparkLabs याद रखने वाले नियंत्रण को उसके कीचेन व्यवहार के साथ क्रेडेंशियल संग्रहण गाइड में प्रलेखित करता है। जब चेकबॉक्स अनुपस्थित होता है, तो वह टूटा नहीं होता, और उसे दरकिनार करने वाला प्राथमिकता आदेश खोजना गलत प्रतिक्रिया है।

इसके बजाय मालिक से पूछें कि कौन-सा समर्थित वर्कफ़्लो लागू होता है। संग्रहण प्रतिबंधित करने वाले परिनियोजन का आमतौर पर कोई कारण होता है, और कारण अक्सर यह होता है कि खाता साझा है, डिवाइस विश्वसनीय नहीं है, या क्रेडेंशियल को किसी समय-सारणी के अनुसार समाप्त होना है। सेटिंग को दरकिनार करना एक जानबूझकर किए गए नियंत्रण को घटना में बदल देता है, और घटना आमतौर पर किसी और के ऑडिट के साथ आती है।

गैर-प्रबंधित इंस्टॉलेशन पर अनुपस्थित नियंत्रण संस्करण संख्या से जुड़ा सहायता प्रश्न है। छिपे हुए डिफ़ॉल्ट के बारे में अनुमान के बजाय इंस्टॉल किया गया क्लाइंट बिल्ड और प्रॉम्प्ट वास्तव में क्या दिखाता है, भेजें।

तीन प्रॉम्प्ट जो एक ही प्रॉम्प्ट नहीं हैं

एक बार वाला कोड पासवर्ड नहीं है, पासवर्ड कीचेन प्राधिकरण नहीं है, और सर्वर का अस्वीकार इनमें से कोई नहीं है। इन्हें मिलाने से ऐसी विफलताएँ बनती हैं जो गलत क्रेडेंशियल जैसी पढ़ी जाती हैं, जबकि असली समस्या कोई फ़ील्ड, संवाद या मार्ग होता है।

कीचेन संवाद डिज़ाइन से स्थानीय है। यह पूछता है कि क्या यह एप्लिकेशन इस मशीन पर इस आइटम को पढ़ सकता है, और इसे स्वीकृत करना VPN सर्वर से कुछ नहीं कहता।

इसलिए संवाद से इनकार करने पर क्लाइंट-पक्ष की विफलता होती है जिसे सर्वर कभी नहीं देखता, जबकि गलत पासवर्ड सर्वर-पक्ष का अस्वीकार करता है जिसकी क्लाइंट केवल रिपोर्ट कर सकता है। उत्तर देने से पहले संवाद पढ़ें, और जाँचें कि अनुरोध करने वाला एप्लिकेशन वही क्लाइंट है जिसकी आप अपेक्षा करते हैं, कोई इंस्टॉलर या सहायक प्रक्रिया नहीं। यह अंतर साझा मशीनों पर सबसे अधिक मायने रखता है, जहाँ एक से अधिक खाते आइटम तक पहुँच सकते हैं।

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

बाकी को रीसेट किए बिना एक क्रेडेंशियल पुनर्प्राप्त करना

यदि पासवर्ड बदलने के बाद प्रमाणीकरण विफल हो जाए, तो कीचेन को हाथ से संपादित करने के बजाय उस एक कनेक्शन के लिए क्लाइंट के प्रलेखित पुनः-प्रॉम्प्ट और अपडेट मार्ग का उपयोग करें। कुछ भी बदलने से पहले संदेश पढ़ें, क्योंकि समय-समाप्ति, प्रमाणपत्र अस्वीकार या अनुपस्थित मार्ग संग्रहीत पासवर्ड को अधिलेखित करके ठीक नहीं होते। इसे बार-बार करना मुख्य रूप से आपको क्लाइंट द्वारा दिखाई गई त्रुटि को अनदेखा करना सिखाता है। प्रभावित क्रेडेंशियल अपडेट करें, फिर पुनः कनेक्ट करें और देखें कौन-सा प्रॉम्प्ट आता है।

सहायता फ़ोरम जो पूरा कीचेन रीसेट सुझाते हैं, वह समस्या से कहीं बड़ा बदलाव है। एक कनेक्शन का संग्रहीत पासवर्ड दूसरे कनेक्शन के प्रमाणपत्र से कोई संबंध नहीं रखता, और सब कुछ साफ़ करना एक पुराने आइटम को पुनः नामांकन की पूरी दोपहर में बदल देता है।

सामान्य नियंत्रणों के माध्यम से डिस्कनेक्ट और पुनः कनेक्ट करके समाप्त करें, पुष्टि करें कि इच्छित खाता उपयोग हो रहा है और संग्रहीत आइटम हटाने पर विफलता के बजाय प्रॉम्प्ट आता है। एक स्पष्ट तरीके से क्रेडेंशियल अपडेट या हटाने के साथ पूर्वानुमेय पुनः उपयोग ही परीक्षण योग्य परिणाम है।