सिस्को स्विच पर AAA / TACACS + पासवर्ड हमेशा दूसरे पासवर्ड प्रॉम्प्ट पर विफल होता है

जब भी मैं AAA / TACACS + का उपयोग करके किसी नेटवर्क डिवाइस में लॉग इन करता हूं, अगर मैं यूज़रनेम प्रॉम्प्ट के बाद पासवर्ड प्रॉम्प्ट करता हूं, तो पासवर्ड सही होने पर दूसरा पासवर्ड प्रॉम्प्ट हमेशा विफल हो जाता है। मुझे फिर से यूज़रनेम प्रॉम्प्ट के लिए इंतजार करना होगा, और इसके तुरंत बाद पहले पासवर्ड प्रॉम्प्ट पर पासवर्ड सही करना होगा। दूसरे शब्दों में, किसी भी समय मैं दूसरा पासवर्ड प्रॉम्प्ट देखता हूं, यह काम नहीं करेगा।

नीचे दी गई बातचीत और कॉन्फ़िगर को देखें।

उपयोगकर्ता पहुँच सत्यापन
उपयोगकर्ता नाम: उपयोगकर्ता-नाम
कुंजिका:

पासवर्ड: (हमेशा यहाँ विफल रहता है)
% पहुंच अस्वीकृत

उपयोगकर्ता पहुँच सत्यापन
उपयोगकर्ता नाम: उपयोगकर्ता-नाम
कुंजिका:

लाइन 1 (साइट-नाम) पर s-site-rack-agg2.example.net से कनेक्ट किया गया।
एस-साइट-रैक agg2 #

इस व्यवहार के लिए उस दूसरे पासवर्ड प्रॉम्प्ट के साथ क्या अलग हो सकता है?

मेरे पास विशिष्ट AAA और संबंधित कॉन्फ़िगरेशन है:

आआ न्यू-मॉडल
एएए प्रमाणीकरण लॉगिन डिफ़ॉल्ट समूह tacacs + स्थानीय लाइन
आआ प्रमाणीकरण प्रमाणीकरण लॉगिन कोई नहीं
आआ आथेंटिकेशन डिफॉल्ट ग्रुप टैक्सेस + इनेबल करें
एए प्राधिकरण डिफ़ॉल्ट समूह tacacs + स्थानीय निष्पादित करता है अगर-प्रमाणित
एएए प्राधिकरण 1 डिफ़ॉल्ट समूह tacacs + को स्थानीय-प्रमाणित करता है
एएए प्राधिकरण 7 डिफॉल्ट समूह टैक्सेस + को स्थानीय रूप से प्रमाणित करता है
एएए प्राधिकरण 15 डिफ़ॉल्ट समूह tacacs + स्थानीय को आदेशित करता है यदि प्रमाणित है
आगा लेखा निष्पादन डिफ़ॉल्ट स्टार्ट-स्टॉप ग्रुप टैक्सेस +
आआ अकाउंटिंग कमांड 0 डिफॉल्ट स्टार्ट-स्टॉप ग्रुप टैक्सेस +
आआ अकाउंटिंग कमांड 1 डिफॉल्ट स्टार्ट-स्टॉप ग्रुप टैक्सेस +
आआ अकाउंटिंग कमांड 7 डिफॉल्ट स्टार्ट-स्टॉप ग्रुप टैक्सेस +
आआ अकाउंटिंग कमांड 15 डिफॉल्ट स्टार्ट-स्टॉप ग्रुप टैक्सेस +
आगा लेखा प्रणाली डिफ़ॉल्ट स्टार्ट-स्टॉप ग्रुप टैक्सेस +
!
आईपी tacacs स्रोत-इंटरफ़ेस लूपबैक 0
tacacs- सर्वर होस्ट -prmiaryipremoved- एकल-कनेक्शन
tacacs- सर्वर होस्ट -secondaryipremoved- एकल-कनेक्शन
tacacs-server टाइमआउट 10
tacacs- सर्वर निर्देशित-अनुरोध
tacacs- सर्वर कुंजी 7
!
लाइन कोन ०
 लॉगिन प्रमाणीकरण CONSOLE
लाइन vty 0 4
 स्थान
 निष्पादन-समय ६० ०
 पासवर्ड 7
 ट्रांसपोर्ट इनपुट टेलनेट ssh

cisco cisco-ios aaa

— generalnetworkerror
स्रोत

कभी भी इसकी तह तक नहीं गया क्योंकि विफल-पासवर्ड ने TACACS को उत्तर वापस करने के लिए समय दिया, इसलिए दूसरा संकेत lineपासवर्ड से था । सही पासवर्डों को तुरंत टीएसीएसीएस से प्रतिक्रिया मिली। नए ACS सर्वर पर ले जाने से समस्या का समाधान हो गया, समान कॉन्फ़िगरेशन, इसलिए ऐसा लगता है कि यह ACS समस्या थी।

— Generalnetworkerror

जवाबों:

जब आप यह कोशिश कर रहे हों तो मैं आपके TACACS + सर्वर पर डिबग करूँगा।

मुझे लगता है कि आप केवल TACACS प्रमाणीकरण का उपयोग करना चाहते हैं और केवल स्थानीय लॉग-इन पर वापस आ सकते हैं यदि यह सर्वर तक नहीं पहुंच सकता है?

इसका उपयोग करके देखें:
aaa authentication login default group tacacs+ line aaa authentication enable default group tacacs+ enable

इस साइट को भी देखें: इसके कुछ अच्छे उदाहरण और स्पष्टीकरण हैं

http://my.safaribooksonline.com/book/networking/cisco-ios/0596527225/tacacsplus/i13896_ headâ _4_2 # X2ludGVybmFsX0h0bWxWaWV3P3htbGlkPTA1OTY1MjcyMjUlMkZpNTAzNjNfX2hlYWRhX180XzEmcXVlcnk9

मेरा अनुमान है कि चूंकि आपके पास "स्थानीय" कीवर्ड है:
aaa authentication login default group tacacs+ local line

TACACS + प्रमाणीकरण विफल हो जाता है, इसलिए राउटर स्थानीय प्रमाणीकरण करने का प्रयास करता है। मुझे लगता है कि आपको हमें line vtyस्वीकृत कॉन्फ़िगरेशन प्रदान करना चाहिए । यदि आपके पास है
line vty 0 15 login local

तब यह एक उपयोगकर्ता नाम / पासवर्ड प्रमाणीकरण करता है अन्यथा इसका पासवर्ड कर रहा है

— knotseh
स्रोत

जोड़ा गया line

— अभयारण्य

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

— generalnetworkerror

मुझे लगता है कि आपका कॉन्फ़िगरेशन काफी खतरनाक है और यदि आप 'सक्षम / लाइन' या 'लोकल' को फॉलबैक के रूप में उपयोग कर रहे हैं तो आप अनिर्णयपूर्ण लगते हैं, सही उत्तर स्थानीय है, कभी भी 'इनेबल' का उपयोग न करें और विशेष रूप से कभी भी 'लाइन' का उपयोग न करें (लाइन टू है) तरीका 'एनक्रिप्टेड' वन-वे हैशेड नहीं)।

मैं इसके बजाय इस कॉन्फ़िगरेशन की सिफारिश करूंगा:

aaa new-model
! uses tacacs, fallsback to local user if tacacs not working
aaa authentication login default group tacacs+ local
! user gets enabled by tacacs or by enable password
aaa authentication enable default group tacacs+ enable
! console user is authorized as well (gets enabled, if such permission)
aaa authorization console
! configuration commands are authorized as well as exec commands (Good to prevent dangerous commands)
aaa authorization config-commands
! user privilege level is recovered from tacacs or from local account
aaa authorization exec default group tacacs+ local
! level 15 commands are authorized (you really only need this) 
aaa authorization commands 15 default group tacacs+ if-authenticated 
! level 1, 15 commands are logged (you really only need these two)
aaa accounting commands 1 default start-stop group tacacs+
aaa accounting commands 15 default start-stop group tacacs+
!
! fallback user consulted only when tacacs is broken
username sikrit privilege 15 secret <password>

'sikrit' उपयोगकर्ता का उपयोग तब किया जाना है जब tacacs काम नहीं कर रहा है (इसका उपयोग तब नहीं किया जा सकता है जब TACACS उत्तर देता है) VTY के तहत 'लाइन' पासवर्ड की कोई आवश्यकता नहीं है, क्योंकि यह कभी भी परामर्श नहीं किया जाता है। 'सक्षम' पासवर्ड की कोई आवश्यकता नहीं है, क्योंकि यह कभी भी परामर्श नहीं किया जाता है। यदि आप गैर-सक्षम बैकअप उपयोगकर्ता चाहते हैं, तो 'विशेषाधिकार 1' के साथ एक और बनाएं।
हालाँकि मैंने 'सक्षम' के लिए समर्थन जोड़ा है अगर आप इसे किसी कारण से उपयोग करना चाहते हैं।

यदि आप OOB का उपयोग कर रहे हैं, और OOB एक्सेस पहले से ही सुरक्षित / प्रमाणित है, तो आप OOB उपयोगकर्ता को हमेशा स्थानीय प्रमाणीकरण का उपयोग करने की अनुमति देना चाह सकते हैं , बस अगर TACACS टूट गया हो, लेकिन IOS गलती से सोचता है कि यह नहीं है, तो आप ऐसा महसूस करेंगे। :

aaa authentication login CONSOLE local
!
line con 0
 login authentication CONSOLE

— ytti
स्रोत

होने के साथ विचार aaa authentication login default group tacacs+ local lineएक catchall के रूप में लाइन पासवर्ड का उपयोग करने के लिए था अगर AAA टेम्पलेट एक डिवाइस पर तैनात किया गया था जहां TACACS टूट गया था और कोई स्थानीय उपयोगकर्ता परिभाषित नहीं थे। और मैं वास्तव aaa authentication login CONSOLE noneमें अपने विन्यास में था कि मैं मूल रूप से नहीं दिखा था। (हां, मैं उन उपकरणों की तुलना में भौतिक कंसोल एक्सेस पर भरोसा करता हूं, जो मुझे शायद चाहिए।)

— generalnetworkerror

मैं वास्तव में प्रयोगशाला में आपके द्वारा देखी जा रही समस्या को दोहरा नहीं सकता था। यदि आपके पास 'स्थानीय' पासवर्ड कॉन्फ़िगर नहीं है और आईओएस को लगता है कि टीएसीएसीएस उपलब्ध नहीं है, तो यह 'लाइन' पासवर्ड पूछने के लिए समझ में आता है, लेकिन मेरे लिए, टीएसीएसीएस के लिए यह 'लाइन' पर वापस नहीं आया। हो सकता है कि IOS में बग या TACACS में असफल हो जो प्रमाणीकरण को विफल करता है TACACS कनेक्शन को विफल करने जैसा लगता है ('एकल-कनेक्शन' के बिना प्रयास करने लायक हो सकता है)

— ytti

क्या दूसरा पासवर्ड बिना दूसरे संबंधित यूजरनेम प्रॉम्प्ट के हमें तुरंत बताता है कि यह lineसिस्टम पर पासवर्ड के लिए असफल रहा है बिना किसी स्थानीय उपयोगकर्ता के लिए बनाया गया है local? [ aaa authentication login default group tacacs+ local line।] tacacs + विफल, स्थानीय कोई स्थानीय उपयोगकर्ता के रूप में छोड़ दिया, तो फिर लाइन पासवर्ड?

— generalnetworkerror

मुझे नहीं लगता कि इसे टैक्सेस + ओडिस_फेल्योर पर कमबैक करना चाहिए, इसे केवल टैक्सेस + रिप्लाई को मिस करने के लिए करना चाहिए। तो मैं विकल्पों में शोध करूँगा कि IOS को क्यों लगता है कि tacacs + जवाब नहीं दे रहा है (मुझे लगता है कि यह जवाब दे रहा है)। शायद कोशिश करने के लिए एक चीज, अलग-अलग टैक्सेस कॉन्फिग है (जैसे सिंगल-कनेक्शन को हटा दें), अगर यह आईओएस बग है, तो यह बग ट्रिगर को हटा सकता है।

— यति

आपने संभवतः डिबग के बारे में एक अन्य उत्तर पर मेरी टिप्पणी नहीं देखी कि tacacs + केवल पासवर्ड गलत होने पर जवाब देने के लिए 30s ले रहा है; उस समय तक, सिस्टम tacacs सर्वर रिप्लाई को मिसिंग मानता है और ऑर्ट में अगली जगह ले जाता है। जब पासवर्ड सही होता है, टैक्सेस प्रतिक्रिया तत्काल होती है।

— Generalnetworkerror

मुझे यकीन नहीं है कि आपका स्थानीय डिवाइस कॉन्फिगर इसके लिए दोषी होगा, बल्कि आपका TACACS सर्वर ही होगा। TACACS डिवाइस के लिए TACACS सर्वर (और संभवतः एक बाहरी पहचान स्टोर) से उपयोगकर्ता नाम / पासवर्ड संकेत देता है, इसलिए यदि आप ACS (उदाहरण के लिए) का उपयोग कर रहे हैं और यह उपयोगकर्ता प्रमाणीकरण करने के लिए AD से बात करने के लिए सेट है, तो आपको आवश्यकता है डिवाइस के बजाय डोमेन कंट्रोलर से आने वाले यूजरनेम / पासवर्ड प्रॉम्प्ट के बारे में सोचना।

मैं हाल ही में इस तरह से एक मुद्दे में भाग गया था जो एसीएस के लिए एक पैच द्वारा तय किया गया था - फिर से, मैं मान रहा हूं कि आप एसीएस का उपयोग कर रहे हैं और इसे उपयोगकर्ता से / समूह सत्यापन आदि के लिए विज्ञापन से खींच रहे हैं। सिस्को बग आईडी CSCtz03211 था और मूल रूप से ACS 5.3 डिवाइस के लिए एक एकल "उपयोगकर्ता नाम / पासवर्ड" के प्रयास में प्रत्येक के लिए कई ज़ोरदार प्रयास भेज रहा था। यह उस व्यवहार के परिणामस्वरूप होगा जहां यदि उपयोगकर्ता ने पहले प्रयास में पासवर्ड को मोटा-मोटा कर दिया, तो त्रुटिपूर्ण उपयोगकर्ता नाम / पासवर्ड कॉम्बो के कई उदाहरण AD को भेजे गए थे और उपयोगकर्ता का खाता वास्तव में लॉक हो गया था, इस प्रकार बाद में विफल लॉगिन प्रयासों के परिणामस्वरूप डिवाइस भले ही किसी उपयोगकर्ता ने अपना उपयोगकर्ता नाम / पासवर्ड दूसरी कोशिश में सही ढंग से टाइप किया हो (बेशक यह व्यवहार एडी के भीतर उपयोगकर्ता खातों पर आपके द्वारा सेट किए गए लॉकआउट थ्रेसहोल्ड के साथ भिन्न होता है)।

बस कुछ विचार करने के लिए (अपने TACACS सर्वर कार्यान्वयन के ज्ञान के बिना)।

— जॉन जेन्सेन
स्रोत