ASA ग्रुप एलियास बनाम ग्रुप URL: प्रोफ़ाइल कैसे चुना जाता है
ग्रुप एलियास लॉगिन सूची की एक प्रविष्टि है, URL मैपिंग नहीं। देखें कि ASA प्रोफ़ाइल कैसे चुनता है, फिर वह नीति पढ़ें जो सत्र वास्तव में पाता है।
कोई कनेक्शन प्रोफ़ाइल सत्र पर तभी लागू होता है जब ASA उसे चुन लेता है। यही एक वाक्य पुराने क्लाइंट-रहित पोर्टल के लिए पूरा समस्या-निवारण मॉडल है। बिना इस्तेमाल का प्रोफ़ाइल बेहतरीन एक्सेस नियम रख सकता है और फिर भी किसी पर लागू न हो। कोई भी नीति बदलने से पहले लॉगिन प्रवेश-बिंदु का पता लगाएँ।
नीचे दिए गए अंतर 9.16 दस्तावेज़ीकरण के अनुसार हैं; क्लाइंट-रहित SSL VPN को 9.17(1) और उसके बाद हटा दिया गया।
एलियास सूची की प्रविष्टि है, URL नहीं
group-alias एक लेबल देता है जिसे उपयोगकर्ता लॉगिन पृष्ठ पर ग्रुप सूची से चुनता है। वह सूची दिखाना अलग सेटिंग है, tunnel-group-list enable। एलियास केवल चयन का नाम है, और कुछ नहीं। staff नाम का एलियास कॉन्फ़िगर करने से कोई /staff URL नहीं बनता जो प्रोफ़ाइल चुने।
लोग एलियास से दोहरा काम अपेक्षित करते हैं, क्योंकि ब्राउज़र के भीतर से सूची और URL एक ही चयन जैसे दिखते हैं।
group-url वास्तव में किससे मेल खाता है
group-url आने वाले URL को कनेक्शन प्रोफ़ाइल से बाँधता है। जब वह सक्षम URL मेल खाता है, ASA उपयोगकर्ता से सूची में से चुनने को कहे बिना प्रोफ़ाइल चुन लेता है। URL पूरा और वही इच्छित होना चाहिए, उस सिंटैक्स में जो आपका रिलीज़ समर्थित करता है। उसका DNS रिकॉर्ड और प्रमाणपत्र उससे मेल खाने चाहिए जो उपयोगकर्ता टाइप करते हैं, वरना मिलान कभी नहीं होगा।
कॉपी किया गया URL प्रत्यय कॉन्फ़िगरेशन के बारे में कुछ सिद्ध नहीं करता। प्रोफ़ाइल जाँचें, एड्रेस बार नहीं।
चयन को उस नीति तक ले जाएँ जो चलती है
टनल ग्रुप चुने जाने के बाद उपकरण प्रमाणीकरण विधि और उससे जुड़ी डिफ़ॉल्ट ग्रुप नीति तय करता है। फिर उपयोगकर्ता-विशिष्ट विशेषताएँ, प्रमाणीकरण से लौटे मान और गतिशील प्राधिकरण उस आधार के भागों को ओवरराइड कर सकते हैं। जाँचें कि सत्र को वास्तव में क्या मिला। केवल नामित नीति पढ़ना आपको आधार देता है, परिणाम नहीं।
दोनों के बीच का अंतर ही «नियम सही है पर एक्सेस गलत है» वाली अधिकांश रिपोर्टों का स्रोत है।
विरासत अलगाव नहीं है
जिन विशेषताओं को आप अनिर्दिष्ट छोड़ते हैं वे डिफ़ॉल्ट ग्रुप नीति से विरासत में मिल सकती हैं। इसलिए नई नामित नीति साझा डिफ़ॉल्ट से अलग नहीं है, और उन्हें संपादित करना हर उस प्रोफ़ाइल तक पहुँचता है जो उन्हें विरासत में पाता है। प्रति प्रोफ़ाइल प्रभावी संसाधन एक्सेस, DNS सेटिंग्स और सत्र प्रतिबंधों की तुलना करें। कुछ भी साझा बदलने से पहले ऐसा करें।
एक्सेस प्रवर्तन को चयन से अलग रखें।
क्लाइंट-रहित सत्र के लिए लागू फ़िल्टर webtype ACL है। टनल क्लाइंट के लिए VPN फ़िल्टर उसका विकल्प नहीं है, केवल इसलिए कि दोनों कॉन्फ़िगरेशन में एक ही नीति ब्लॉक के पास बैठते हैं।
बेमेल स्थिति तय करें, फिर हर मार्ग जाँचें
तय करें कि पोर्टल के सामान्य URL पर और अन्य बेमेल प्रवेश-बिंदुओं पर क्या होना चाहिए। एक परीक्षण खाता पास हो जाए इसके लिए साझा डिफ़ॉल्ट संपादित करने के बजाय वास्तविक डिफ़ॉल्ट-प्रोफ़ाइल मार्ग और उसका प्राधिकरण देखें। फिर तीन नए सत्र खोलें: स्पष्ट URL, सक्षम सूची प्रविष्टि और सामान्य प्रवेश-बिंदु। हर एक के लिए चुना गया प्रोफ़ाइल और प्रभावी नीति दर्ज करें।
पहले के लॉगिन का ब्राउज़र टैब दोबारा इस्तेमाल करने से तुलना बिगड़ जाती है, क्योंकि वह सत्र पहले से प्रोफ़ाइल से बँधा है।
वह रिकॉर्ड «पोर्टल खुलता है» को लॉगिन-से-नीति मैपिंग में बदल देता है जिसे आप बाद में ऑडिट कर सकते हैं, और जब प्रोफ़ाइल सही दिखे और किसी को नियंत्रित न करे तब यही एकमात्र टिकाऊ उत्तर है।