કટોકટી માટે સ્થાનિક એકાઉન્ટ રાખવાથી તે દરેક નકારાયેલા લોગિન માટે બીજી તક બનતું નથી. 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

પછી પહેલાનું રૂપરેખાંકન પુનઃસ્થાપિત કરો અને ખાતરી કરો કે આગલા વાસ્તવિક લોગિનમાં કાઉન્ટર ફરી હલે છે. જો જાણી જોઈને કરેલો અસ્વીકાર અસ્વીકારને બદલે સ્થાનિક લોગિન ઉત્પન્ન કરે, તો યાદી કે નિષ્ફળતા-સંભાળ તમે માનતા હતા તે નથી, અને તે શોધ તમે શરૂ કરેલા અવરોધ કરતાં વધુ મહત્ત્વની છે. પરિણામ પરિવર્તન રેકોર્ડમાં એકાઉન્ટના નામો અને પરીક્ષણની તારીખની બાજુમાં લખો.

સંબંધિત લેખો