VPN गट धोरणासाठी ASA LDAP गट मॅपिंग विरुद्ध DAP
LDAP गुणधर्म नकाशा आणि DAP धोरण दोन्ही गट धोरण निवडतात, पण ते वेगवेगळ्या टप्प्यांवर चालतात. तुमच्या ASA सत्राने प्रत्यक्षात काय वापरले ते शोधा.
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 कडे पाहणे पूर्णपणे थांबवा. एका वेळी एक नोंद बदला आणि नवीन सत्र पुन्हा तपासा, कारण पुन्हा जोडलेले सत्र हाच तुम्ही नुकतीच लिहिलेली संरचना प्रतिबिंबित करणारा एकमेव पुरावा आहे.