RADIUS नकार विरुद्ध प्रतिसाद नाही: स्थानिक लॉगिन कधी चालते

आपत्कालीन स्थानिक खाते ठेवल्याने ते प्रत्येक नाकारलेल्या लॉगिनसाठी दुसरी संधी होत नाही। Cisco IOS आणि IOS XE AAA मॉडेलमध्ये त्या डेटाबेसकडे फक्त तेव्हाच पाहिले जाते जेव्हा आधीची पद्धत विशिष्ट पद्धतीने अयशस्वी होते, आणि नकाराने उत्तर देणारा RADIUS सर्व्हर त्या पद्धतीने अयशस्वी झालेला नाही। स्थानिक खाते अगम्य पद्धतीला व्यापते, नाकारलेल्या पद्धतीला नाही। उलट मानल्यास धोरणाचा निर्णय नसलेल्या सर्व्हर बिघाडाच्या शोधात बदलतो।

पद्धतींची यादी शिडीसारखी का दिसते

अशी ओळ aaa authentication login default group radius local डावीकडून उजवीकडे वाचली जाते, आणि बहुतेक लोक ती RADIUS वापरून पहा, नंतर स्थानिक डेटाबेस वापरून पहा अशी वाचतात। यादी एक क्रम असल्याने वाक्यरचना त्या वाचनाला आमंत्रण देते। अर्थ अरुंद आहे: यादी प्रमाणीकरणाच्या पद्धतींना नावे देते, आणि एकाकडून दुसरीकडे जाण्याचा नियम आधीच्या पद्धतीच्या निकालावर अवलंबून असतो, वापरकर्त्याला आणखी एक प्रयत्न देण्यावर नाही।

त्रुटी परत करणारी पद्धत आणि अपयश परत करणारी पद्धत येथे वेगळ्या परिणामांकडे नेतात। नकार हे उत्तर आहे, कारण सर्व्हरने लॉगिन माहिती प्रक्रिया करून नाही म्हटले, आणि यादी तिथे थांबते। अगम्य सर्व्हर, कालबाह्य विनंती किंवा सत्यापित करता येणार नाही असा प्रतिसाद हे पुढील पद्धत चालवू देणारे प्रकरण आहे, आणि प्लॅटफॉर्मचे अपयश हाताळणी तशी संरचित केलेली असेल तिथेच। म्हणूनच local जोडण्याचा पारंपरिक सल्ला खंडांमध्ये काम करतो आणि चुकीच्या पासवर्डवर काहीही करत नाही। यादीऐवजी ती दोन प्रश्न म्हणून वाचा: कोणती पद्धत उत्तर देते, आणि प्लॅटफॉर्म कशाला उत्तर मानते।

पद्धतींची यादी सर्व्हर गटापासून वेगळी करा

पद्धतींची यादी एक स्तर आहे आणि सर्व्हर गट दुसरा। group radius हा कीवर्ड अशा गटाचे नाव देतो ज्याचा अंतर्गत क्रम, पुनःप्रयत्न, कालमर्यादा आणि मृत सर्व्हर शोध गटाच्या अंतर्गत येतात, तर स्थानिक पद्धत त्याच्यावरील स्तर आहे। म्हणून गटाच्या आत काहीही ट्यून केल्याने नकार फॉलबॅकमध्ये बदलू शकत नाही। दोन्हीपैकी कोणताही स्तर बदलण्यापूर्वी सेवा प्रत्यक्षात कोणत्या यादीचा संदर्भ घेते ते निश्चित करा।

AAA संरचना छापा आणि सेवा ज्या यादीकडे निर्देश करते ती वाचा, तुम्ही लिहिल्याचे आठवत असलेले मूलभूत मूल्य नाही। हे अशा उपकरणावरून करा जिथे सेवा प्रत्यक्षात संपते।

show running-config | section aaa
show radius server-group RAD-GRP
show aaa servers

सर्व्हर तक्ता प्रत्येक नोंदीची स्थिती आणि काउंटर दाखवतो, ज्यामुळे प्रयत्नादरम्यान गेटवे सर्व्हरपर्यंत पोहोचले का हे कळते। वाढत्या विनंती काउंटरसह सक्रिय असे चिन्हांकित सर्व्हर उत्तर देत होता, म्हणून अयशस्वी लॉगिन हा निर्णय आहे, कनेक्टिव्हिटी समस्या नाही।

लॉगपूर्वी प्रतिसाद वाचा

प्रतिसाद कोड परिणामाला नाव देतो आणि स्वतःचे पुढील पाऊल सूचित करतो। Access-Reject म्हणजे बॅकएंडने निर्णय घेतला, म्हणून उपयुक्त पुरावा म्हणजे जुळलेले धोरण आणि त्यामागील खाते स्थिती। Access-Challenge म्हणजे देवघेवीला दुसरा घटक असे आणखी एक समर्थित पाऊल हवे आहे, आणि स्थानिक फॉलबॅक धोरण मागणारी एखादी गोष्ट गुपचूप वगळली असती।

नियुक्त चाचणी खात्यासह एक प्रयत्न पुनरुत्पादित करा जेणेकरून प्रतिसाद आणि बॅकएंड नोंद एकाच वेळचिह्नावर तुलना करता येईल। अयशस्वी करण्याची परवानगी असलेली लॉगिन माहिती वापरा।

test aaa group RAD-GRP svc-ops 'LabPass!24' legacy
debug radius authentication

RADIUS क्लायंट नोंद नसणे किंवा ओळखले न जाणे हे शांत कालमर्यादेचे सामान्य कारण आहे, कारण सर्व्हर विनंती घेतो, जुळणारी क्लायंट व्याख्या सापडत नाही आणि उत्तर न देता ती टाकून देतो। सामायिक रहस्याची विसंगतीही सामान्यतः कालमर्यादेसारखी दिसते, कारण प्रतिसाद सत्यापनात अपयशी होऊन टाकून दिला जातो। त्यांपैकी काहीही Access-Reject सारखे दिसत नाही, आणि त्यांपैकी काहीही स्थानिक खाते जोडून सुधारत नाही। पद्धतींच्या यादीला हात लावण्यापूर्वी दोन्ही बाजूंनी क्लायंट व्याख्या आणि रहस्य तपासा।

स्थानिक खात्याने कधीच काही सिद्ध का केले नाही

यादीत गटानंतर बसलेले खाते फक्त एवढेच सिद्ध करते की कोणीतरी खंडाची योजना केली होती। योजना काम करते का याबद्दल ते काहीही सांगत नाही, कारण जे प्रकरण त्याची चाचणी घेते तेच प्रकरण कोणीही सराव करत नाही: सर्व्हरने उत्तर देणे थांबवले। सामान्य कारभारात कधीच न पोहोचले जाणारे स्थानिक लॉगिन महिन्यांनु महिने कालबाह्य पासवर्ड किंवा कुलूपबंद स्थिती बाळगू शकते, कोणाच्याही लक्षात येत नाही।

आपत्कालीन प्रवेश हा रचनेचा निर्णय आहे, संरचनेचा दुष्परिणाम नाही। त्याला स्वतःचे मर्यादित खाते, स्वतःचा जबाबदार आणि लिखित पुनर्प्राप्ती प्रक्रिया द्या, आणि सामायिक रहस्याचे फिरणे त्या प्रक्रियेत समाविष्ट करा। प्रत्येक केंद्रीय वापरकर्त्यासाठी एकाच नावाचा स्थानिक पासवर्ड ठेवणे हा तो नमुना आहे जो तुम्ही काढले असे वाटलेला प्रवेश गुपचूप परत आणतो।

महत्त्वाची चाचणी जाणूनबुजून असते, आणि चालू असताना ती लॉगिनमध्ये व्यत्यय आणते। म्हणूनच ती रोलबॅक पाऊल आधी लिहिलेल्या नियोजित खिडकीत येते।

देखभाल खिडकीत फॉलबॅक मार्ग तपासा

शेवटचा प्रवेशमार्ग कधीही काढू नये अशा क्रमाने चाचणी लावा। आधी स्वतंत्र व्यवस्थापन मार्ग, नंतर सामान्य परवानगी असलेला प्रवेश, नंतर जाणूनबुजून नकार, नंतर मंजूर खंड वर्तन याची खात्री करा। या चार प्रकरणांचे अपेक्षित परिणाम वेगळे आहेत, आणि त्यांना एका चाचणीत एकत्र करणे हाच तो मार्ग ज्याने लोक अजूनही आवश्यक असलेल्या उपकरणाबाहेर स्वतःला कुलूपबंद करतात।

प्रत्येक तपासणी कन्सोल सत्रातून किंवा पट्ट्याबाहेरील मार्गाने चालवा, जेणेकरून चूक तुम्ही काम करत असलेले सत्र बंद करू शकणार नाही। कन्सोल हाच एकमेव मार्ग आहे जो चाचणीतील घटकावर अवलंबून नाही।

show aaa servers
show running-config | include aaa authentication
test aaa group RAD-GRP svc-ops 'LabPass!24' legacy

त्यानंतर आधीची संरचना पुनर्संचयित करा आणि पुढील खऱ्या लॉगिनवर काउंटर पुन्हा हलतात याची खात्री करा। जाणूनबुजून केलेल्या नकाराने नकाराऐवजी स्थानिक लॉगिन निर्माण झाले, तर यादी किंवा अपयश हाताळणी तुम्ही मानलेल्या पद्धतीची नाही, आणि तो शोध तुम्ही सुरू केलेल्या खंडापेक्षा मोठा आहे। निकाल बदल नोंदीत खाते नावे आणि चाचणीच्या तारखेच्या शेजारी लिहा।