Mac ले बारम्बार VPN पासवर्ड किन माग्छ: किचेन कि खाता?
Mac ले लगइन किचेनको पासवर्ड, प्रशासक पासवर्ड वा VPN खाता नै माग्न सक्छ। संवाद कसको हो पढ्नुहोस्, त्यसपछि सही भण्डार ठीक गर्नुहोस्।
तपाईं Mac अनलक गर्नुहुन्छ, VPN क्लाइन्ट खोल्नुहुन्छ, र टनेल सुरु हुनुअघि नै पासवर्ड पाना देखा पर्छ। तपाईं गेटवेको पासवर्ड टाइप गर्नुहुन्छ, र त्यो या त अस्वीकार हुन्छ या पाना एकछिनपछि फेरि आउँछ। त्यसपछि निद्राबाट उठेपछि, लगआउट भएपछि वा क्लाइन्ट अपडेट भएपछि फेरि सोध्छ। त्यो पाना विरलै प्रमाणहरू माग्ने VPN सर्भर हो; सामान्यतया macOS स्थानीय रेकर्ड पढ्न, अनलक गर्न वा बदल्न अनुमति माग्छ, र पासवर्ड त्यो रेकर्डको मालिकको हो, तपाईंको VPN खाताको होइन।
पानालाई त्यसको पछाडिको पहिचानसँग मिलाउनुहोस्
चार प्रम्प्ट लगभग उस्तै देखिन्छन्, र एउटा मात्र गेटवेसँग सम्बन्धित छ। शब्दावली, पहुँच माग्ने प्रक्रिया र तल उल्लेख गरिएको वस्तुले तपाईंको अगाडि कुन छ भन्छ।
| What the sheet says | Whose password it wants | What it does not do |
|---|---|---|
| Enter the password for the login keychain | The local keychain password, normally your Mac login password | It does not authenticate you to the VPN server |
| An app wants to use confidential information stored in your keychain | Approval for that app to retrieve one item | It does not grant privileges at the gateway |
| macOS wants to make changes, and asks for administrator authorization | An admin account on this Mac, for the named setting | It does not change the VPN account password |
| The client itself asks for a username and password to connect | The remote account, certificate or profile credential | It does not unlock anything local |
स्थानीय पहुँचबारेको संवादले सर्भरबारे केही पनि प्रमाणित गर्दैन। गेटवेको अस्वीकृति क्लाइन्टभित्र विक्रेताको त्रुटि-पाठसँग देखिन्छ, किचेन अनलक गर्ने प्रस्ताव गर्ने सिस्टम पानाको रूपमा होइन। उल्टो पनि उत्तिकै सामान्य छ: किचेन पानामा गेटवेको पासवर्ड टाइप गर्दा रेकर्ड लक रहन्छ र एक असफल प्रयास थपिन्छ।
संवादले मालिक, भण्डार र कार्यको नाम लिन्छ
किचेन प्रम्प्टहरू पुनःप्राप्तिबारे हुन्, टाढाको कुनै कुरासँग प्रमाणीकरणबारे होइन। Apple को अनुरोध-संवाद वर्णन साँघुरो छ: एकपटक अनुमति दिनुहोस्, सधैं अनुमति दिनुहोस् र अस्वीकार गर्नुहोस् ले त्यो एपले भण्डारित वस्तु पढ्न सक्छ कि सक्दैन नियन्त्रण गर्छ। तीनमध्ये कुनैले पनि गेटवेमा विशेषाधिकार दिँदैन वा सर्भरले तपाईंको पासवर्डबारे के सोच्छ भन्ने बदल्दैन।
जब अनुरोधकर्ता भर्खरै अपडेट भएको क्लाइन्ट हो, पुनः स्वीकृति अपेक्षित हुन्छ: नयाँ बिल्ड वस्तुको पहुँच नियन्त्रण सूचीसँग मिल्दैन, त्यसैले macOS फेरि सोध्छ। निदान गर्दा एकपटक अनुमति दिनुहोस् भनी जवाफ दिनुहोस्। सधैं अनुमति दिनुहोस् त्यो एपलाई स्थायी अनुमति हो र तपाईंले अपेक्षा नगरेको सहायक प्रक्रियाका लागि गलत जवाफ हो; अस्वीकार गर्नुहोस् र बाइनरी तपाईंले स्थापना गरेको क्लाइन्ट होइन भने विक्रेतालाई जाँच्नुहोस्।
प्रशासकीय अधिकार माग्ने प्रम्प्ट तेस्रो प्रकार हो। यसले बदलिँदै गरेको प्रणाली सेटिङ वा संरक्षित भण्डारको नाम लिन्छ, र मागेको प्रमाण यो Mac मा प्रशासक खाता हो। हरेक व्यक्तिगत किचेन वस्तुलाई यो चाहिँदैन; नेटवर्क कन्फिगरेसनपछाडिका वस्तुलाई सामान्यतया चाहिन्छ, किनकि कन्फिगरेसन प्रणालीको हो, तपाईंको लगइन सत्रको होइन।
Mac मा VPN पासवर्ड कहाँ बस्न सक्छ
किचेन एउटा सम्भावित भण्डार हो, भण्डारको परिभाषा होइन। System Settings मा बनाइएको अन्तर्निहित VPN कन्फिगरेसनले आफ्ना प्रमाणहरू नेटवर्क कन्फिगरेसनसँगै, व्यवस्थित प्रणाली सेटिङका रूपमा राख्छ। तेस्रो-पक्ष क्लाइन्टले सामान्यतया तपाईंको लगइन किचेनमा एउटा वस्तु राख्छ: सेवा नामले कुञ्जी गरिएको सामान्य पासवर्ड, वा सर्भर, प्रोटोकल र खाताले कुञ्जी गरिएको इन्टरनेट पासवर्ड। धेरै नयाँ एपले यसको सट्टा डेटा-संरक्षण किचेन प्रयोग गर्छन्, जसका वस्तुहरू किचेन पहुँचमा कहिल्यै देखिँदैनन्।
मानिसहरू किचेन पहुँचमा VPN को नाम खोज्छन्, केही भेट्दैनन् र पासवर्ड भण्डारण भएको छैन भनी निष्कर्ष निकाल्छन्। Apple को TN3137 टिप्पणी भन्छ कि किचेनका एकभन्दा बढी कार्यान्वयन छन्; त्यो सूचीमा नहुनु सामान्य हो, बिग्रेको वस्तुको प्रमाण होइन।
रेकर्डका प्रकार पनि अदलबदल गर्न मिल्दैन। खाता पासवर्ड, निजी कुञ्जीको पासफ्रेज, क्लाइन्ट प्रमाणपत्र र IPsec साझा रहस्य फरक तरिकाले असफल हुन्छन् र फरक ठाउँमा मर्मत हुन्छन्; भण्डारित पासवर्ड फेरि टाइप गर्दा अस्वीकृत प्रमाणपत्रका लागि केही हुँदैन. Mac व्यवस्थापनमा भर्ना भएको छ भने, प्रोफाइल अर्को मालिक हो: VPN पेलोडले प्रमाण बोक्न र रिफ्रेसमा फेरि लागू गर्न सक्छ, त्यसैले स्थानीय वस्तु मेट्नु प्रशासकले नबदलेसम्म अस्थायी हुन्छ।
जब लगइन पासवर्ड र किचेन पासवर्ड फरक पर्छन्
लगइन किचेनले सामान्यतया तपाईंको Mac लगइन पासवर्ड प्रयोग गर्छ, त्यसैले दुवै फरक पर्न सक्छन्। अर्को खाताबाट प्रशासकले तपाईंको पासवर्ड रिसेट गर्नु, पुनःप्राप्ति प्रवाह वा डाइरेक्टरी परिवर्तनले किचेन पुरानो मानमा लक राख्न सक्छ, र त्यसपछि macOS ले तपाईंले भर्खरै सेट नगरेको पासवर्ड माग्छ।
लगइन गर्दा प्रणालीले किचेन अनलक गर्न सकेन भन्ने चेतावनी देख्न सक्नुहुन्छ। यसलाई अपडेट गर्न पुरानो पासवर्ड चाहिन्छ, जो सम्झना छ भने ठीक र छैन भने बेकार। दुई इमानदार मर्मत हुन् किचेन पहुँच, सम्पादन, किचेन "login" का लागि पासवर्ड परिवर्तन, वा आवश्यक प्रमाण फेरि हालेर नयाँ लगइन किचेन। दोस्रो विकल्पले भण्डारित वस्तुहरू नष्ट गर्छ।
एउटा VPN ले पुरानो प्रमाण अस्वीकार गर्छ भनेर सम्पूर्ण किचेन रिसेट नगर्नुहोस्: त्यसले असम्बन्धित खाता हटाउँछ र वस्तु फेरि पहिचान हुँदैन।
एउटा आदेशले स्थानीय बनाम टाढाको प्रश्न टुंग्याउँछ। किचेनलाई सिधै वस्तु सोध्नुहोस्:
security find-internet-password -s vpn.example.com -a [email protected] -g
security find-generic-password -s "Client Name" -a [email protected] -gतपाईंको क्लाइन्टको सेटिङबाट सर्भर र खाता प्रयोग गर्नुहोस्। तपाईं आफैं किचेनलाई सोध्दा त्यही स्वीकृति पाना देखिन्छ भने प्रम्प्ट स्थानीय हो र सर्भर दर्शक हो। त्यस्तो वस्तु छैन भने क्लाइन्टले तपाईंले अनुमान गरेको ठाउँमा पासवर्ड भण्डारण गर्दैन। -g फ्ल्यागले रहस्य टर्मिनलमा छाप्छ, त्यसैले स्क्रिन साझेदारीबाट बच्नुहोस्।
क्लाइन्टले साँच्चै पढ्ने रेकर्ड अपडेट गर्नुहोस्
गेटवेमा खाता बदलिएको छ भने पहिले त्यहाँ बदल्नुहोस्, त्यसपछि क्लाइन्टको सेटिङमार्फत भण्डारित रेकर्ड अपडेट गर्नुहोस्। किचेन वस्तु हातले सम्पादन गर्नु विश्वसनीय हुँदैन: क्लाइन्टले अर्को सेवा-र-खाता जोडी पढ्न सक्छ, र व्यवस्थित प्रोफाइलले तपाईंको सम्पादन माथि लेख्छ।
पुरानो भन्ने शंका लागेको वस्तुका लागि, केही मेट्नुअघि सेवा, खाता र प्रोटोकल मिलाउनुहोस्:
security delete-generic-password -s "Client Name" -a [email protected]अर्को जडानको समान नामको वस्तु मेट्नु सामान्य आफैं सिर्जना गरेको अवरोध हो। हटाउने काम स्थानीय मात्र हो: यसले गेटवेमा सत्र रद्द गर्दैन, यन्त्र प्रमाणपत्र खोल्दैन वा खाताको पासवर्ड बदल्दैन।
मर्मत रिबुटपछि टिक्छ भनी पुष्टि गर्नुहोस्
जडान गर्नुहोस्, निद्राबाट उठ्नुहोस्, लगआउट र फेरि लगइन गर्नुहोस्, त्यसपछि एकपटक रिबुट गर्नुहोस्। पाना बिनाको सफा क्रम र अपेक्षित खाताको नाम बताउने क्लाइन्ट स्थिति मात्र गणना हुने प्रमाण हो। प्रम्प्ट कहाँ फर्कन्छ भन्नेले कुन तह छुट्यो भन्छ: अपडेटपछि त्यो स्वीकृति हो, नेटवर्क परिवर्तनपछि क्लाइन्टको आफ्नै प्रम्प्ट, रिबुटपछि स्थिति फेरि लागू गर्ने प्रोफाइल।
किचेन फेरि छुनुअघि क्लाइन्टमा पासवर्ड सम्झने वा सधैं सोध्ने सेटिङ जाँच्नुहोस्। केही कन्फिगरेसन, विशेष गरी प्रति-प्रयोगकर्ता प्रमाणीकरणसहित IKEv2, डिजाइनअनुसार हरेक जडानमा सोध्छन्; किचेन मर्मतले सहयोग गर्दैन।
तपाईंले कुन वस्तु बदल्नुभयो, कुन भण्डारको त्यो थियो र कुन खातासँग सम्बन्धित थियो लेख्नुहोस्, ताकि अर्को प्रम्प्ट सेकेन्डमै भेट्टाइयोस्। Apple को किचेन पहुँच अनुरोध पृष्ठ ती तीन बटनले के अधिकृत गर्छन् भन्ने सन्दर्भ हो।