VPN समूह नीति के लिए ASA LDAP समूह मैपिंग बनाम DAP

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

दो तंत्र, दो निर्णय बिंदु

चुनाव तीन सवालों पर आता है। क्या निर्णय निर्देशिका के एक ही विशेषता मान पर निर्भर है, क्या उसे उस मान से अधिक चाहिए, और जब दोनों मेल खाते हैं तो किस तंत्र को जीतने की अनुमति है?

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

विशेषता मैप का मार्ग, कॉन्फ़िगरेशन क्रम में

मैप का मार्ग AAA सर्वर परिभाषा से शुरू होता है। विशेषता मैप उस LDAP सर्वर प्रविष्टि से जुड़ा होना चाहिए जिसे कनेक्शन प्रोफ़ाइल वास्तव में उपयोग करता है; जो मैप चल रहे कॉन्फ़िगरेशन में मौजूद है पर उस सर्वर द्वारा संदर्भित नहीं है, वह कुछ नहीं बदलता। जोड़ने की वही पंक्ति बाकी कॉन्फ़िगरेशन को जीवंत बनाती है। ASA LDAP मैपिंग गाइड 9.x रिलीज़ में मैप सिंटैक्स के लिए संदर्भ है।

मैप के अंदर, एक कथन निर्देशिका विशेषता और उस ASA विशेषता का नाम बताता है जिसे वह पोषित करता है, और आगे के कथन विशिष्ट मानों का अनुवाद करते हैं। map-name memberOf Group-Policy और उसके बाद map-value memberOf CN=VPN-Support,OU=Groups,DC=corp,DC=example Support-ReadOnly रूप है: बायाँ पक्ष वह है जो निर्देशिका ने लौटाया, दायाँ पक्ष समूह नीति का नाम है जो पहले से मौजूद होनी चाहिए। विशिष्ट नाम और नीति का प्रदर्शन नाम आपस में बदले नहीं जा सकते, और दोनों में से किसी भी स्ट्रिंग में लगभग मेल लॉगिन पर कोई त्रुटि नहीं देता।

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

DAP का मार्ग, और यह क्या जोड़ता है

DAP शर्तों का मूल्यांकन करता है और AAA परिणाम के ऊपर विशेषताएँ लागू करता है। एक रिकॉर्ड में प्राथमिकता, क्रिया और शर्तों का समूह होता है; रिकॉर्ड प्राथमिकता क्रम में मूल्यांकित होते हैं और क्रिया तय करती है कि मूल्यांकन जारी रहे या रुके। यह मान खोज से अलग निष्पादन मॉडल है, और इसीलिए यह वे नियम व्यक्त कर सकता है जो मैप नहीं कर सकता।

DAP जो जोड़ता है वह इनपुट है। शर्तें निर्देशिका विशेषताओं, एंडपॉइंट विशेषताओं और डिवाइस स्थिति का संदर्भ ले सकती हैं, और मेल खाने वाला रिकॉर्ड उस सत्र के लिए ACL, URL सूचियाँ या फ़िल्टर ले सकता है। इसलिए प्रबंधित लैपटॉप पर सहायता कर्मचारियों को केवल-पढ़ने की नीति मिले और वही कर्मचारी अनप्रबंधित डिवाइस पर प्रतिबंधित नीति पाएँ, ऐसा नियम DAP में व्यक्त किया जा सकता है, विशेषता मैप में नहीं। मैप में ठीक एक इनपुट है: वह मान जो निर्देशिका ने आपके द्वारा नामित विशेषता के लिए लौटाया।

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

जहाँ दोनों असहमत हैं

प्राथमिकता ही वह हिस्सा है जो डिज़ाइन तोड़ता है। जब एक सत्र मैप प्रविष्टि और DAP रिकॉर्ड दोनों से मेल खाता है, तो परिणाम रिलीज़ और रिकॉर्ड की क्रिया पर निर्भर करता है, इसलिए यह मानने के बजाय कि कोई एक तंत्र परिणाम का स्वामी है, इसे अपने ASA पर जाँचें।

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

जीवंत सत्र से साक्ष्य पढ़ना

उत्तर कॉन्फ़िगरेशन से नहीं, नए सत्र से पढ़ें। show vpn-sessiondb detail anyconnect filter name jdoe वह समूह नीति छापता है जो सत्र को वास्तव में मिली, और show running-config ldap attribute-map पुष्टि करता है कि मैप कौन-से मान लौटा सकता था। निर्देशिका की ओर, test aaa-server authentication LDAP-AD username jdoe password <password> वे विशेषताएँ दिखाता है जो ASA को वापस मिलीं, और debug ldap 255 परीक्षण आपकी अपेक्षा से मेल न खाने पर वह अदला-बदली दिखाता है।

फिर चार रिकॉर्ड लिखित रूप में मिलाएँ: निर्देशिका का मान, कॉन्फ़िगर किया गया मैप या DAP शर्त, स्थानीय समूह नीति और वह संसाधन जहाँ उपयोगकर्ता वास्तव में पहुँच सका। यदि पहले तीन मेल खाते हैं और चौथा नहीं, समस्या नीति के मुख्य भाग में है, चयन में नहीं. यदि सत्र सही नीति नाम दिखाता है पर गलत ACL, तो LDAP की ओर देखना पूरी तरह बंद कर दें। एक बार में एक रिकॉर्ड बदलें और नया सत्र फिर जाँचें, क्योंकि फिर से जुड़ा सत्र ही एकमात्र साक्ष्य है जो आपके द्वारा अभी लिखे गए कॉन्फ़िगरेशन को दर्शाता है।