आपने सभी को एक ही VPN प्रोफ़ाइल भेजी और उसमें आपका पासवर्ड है

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

लक्षण पहले रोटेशन पर दिखता है

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

कुछ भी संपादित करने से पहले फ़ील्ड को क्रम में लगाएँ, क्योंकि सीमा वहाँ नहीं है जहाँ लोग मानते हैं।

साझा सेटिंग्स को व्यक्तिगत क्रेडेंशियल से अलग करें

इंटरैक्टिव रास्ता यह है कि पासवर्ड बाहर रखें और समर्थित प्रमाणीकरण व्यवस्था से उसे माँगने दें। इसे ध्यान से पढ़ें: सिर्फ़ मिलता-जुलता दिखने वाला फ़ील्ड हटाना इंटरैक्टिव लॉगिन में सार्वभौमिक रूपांतरण नहीं है। IKEv2 पेलोड AuthName को AuthPassword से अलग करता है, और प्रमाणीकरण विधि तय करती है कि प्रॉम्प्ट तक पहुँच ही है या नहीं; प्रमाणपत्र-आधारित विधि पासवर्ड बिलकुल नहीं माँगेगी।

प्रमाणपत्रों को भी साझा कुंजी की ज़रूरत नहीं

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

प्रोफ़ाइल संशोधन के साथ उस पहचान का जारीकरण, नवीनीकरण और निरसन दर्ज करें। जब दोनों साथ में ट्रैक होते हैं, तो नवीनीकरण घटना नहीं बल्कि निर्धारित कार्य होता है।

बिना निगरानी वाली मशीनों को तीसरा उत्तर चाहिए

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

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

वास्तव में जो आर्टिफ़ैक्ट बना है उसे जाँचें

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

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

परीक्षण पहचान के साथ हैंडऑफ़ स्वीकार करें

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

साझा सेटिंग्स के लिए एक संशोधन, प्रति व्यक्ति एक रिकॉर्ड, और निरसन का ऐसा रास्ता जो आपने सचमुच एक बार इस्तेमाल किया हो।