RADIUS-höfnun á móti ekkert svar: hvenær staðbundin innskráning virkar

Að halda staðbundnum neyðarreikningi gerir hann ekki að öðru tækifæri fyrir hverja höfnuð innskráningu. Í AAA-líkani Cisco IOS og IOS XE er þessi gagnagrunnur aðeins hafður til ráða þegar fyrri aðferð mistekst á ákveðinn hátt, og RADIUS-netþjónn sem svarar með höfnun hefur ekki mistekist á þann hátt. Staðbundni reikningurinn nær yfir óaðgengilega aðferð, ekki hana sem var hafnað. Að trúa öðru gerir stefnuákvörðun að leit að netþjónsgalla sem er ekki til.

Hvers vegna aðferðalistinn virðist eins og stigi

Lína eins og aaa authentication login default group radius local er lesin frá vinstri til hægri, og flestir lesa hana sem prófaðu RADIUS, prófaðu svo staðbundna gagnagrunninn. Setningagerðin býður upp á þá lestur því listi er röð. Merkingin er þrengri: listinn nefnir auðkenningaraðferðir, og reglan um að fara frá einni til þeirrar næstu fer eftir niðurstöðu fyrri aðferðar, ekki eftir því að gefa notandanum aðra tilraun.

Aðferð sem skilar villu og aðferð sem skilar mistökum leiða hér til mismunandi niðurstaðna. Höfnun er svar, því netþjónninn vann úr auðkennunum og sagði nei, og listinn stöðvast þar. Óaðgengilegur netþjónn, útrunnin beiðni eða svar sem ekki er hægt að staðfesta er tilvikið sem hleypir næstu aðferð af stað, og aðeins þar sem mistakameðferð kerfisins er stillt þannig. Þess vegna virkar klassíska ráðið að bæta local við í niðurföllum og gerir ekkert við röng lykilorð. Lestu listann í staðinn sem tvær spurningar: hvaða aðferð svarar, og hvað kerfið telur svar.

Aðskildu aðferðalistann frá netþjónahópnum

Aðferðalistinn er eitt lag og netþjónahópurinn er annað. Lykilorðið group radius nefnir hóp sem innri röð, endurtilraunir, tímamörk og skynjun dauðs netþjóns tilheyra hópnum, en staðbundin aðferð er lag fyrir ofan hann. Að stilla hvað sem er innan hópsins getur því ekki breytt höfnun í varaleið. Staðfestu hvaða lista þjónustan vísar í raun í áður en þú breytir hvoru laginu sem er.

Prentaðu AAA-stillinguna og lestu listann sem þjónustan bendir á, ekki sjálfgefna gildið sem þú manst að hafa skrifað. Gerðu það af tækinu þar sem þjónustan endar í raun.

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

Netþjónataflan greinir frá stöðu og teljurum hvers færslu, sem segir þér hvort gáttin náði netþjónnum í tilrauninni. Netþjónn merktur sem í gangi með vaxandi beiðnateljara hefur verið að svara, svo misheppnuð innskráning er ákvörðun en ekki tengivandamál.

Lestu svarið áður en þú lest annálinn

Svarkóðinn nefnir niðurstöðuna og gefur í skyn sína eigin næstu skref. Access-Reject þýðir að bakendinn tók ákvörðun, svo gagnlegu sönnunargögnin eru stefnan sem passaði og reikningsstaðan bak við hana. Access-Challenge þýðir að skiptin vilja annað studd skref eins og annan þátt, og staðbundin varaleið myndi hljóðlaust sleppa einhverju sem stefnan krefst.

Endurgerðu eina tilraun með tilnefndum prófunarreikningi svo hægt sé að bera saman svarið og bakendaskráninguna á sama tíma. Notaðu auðkenni sem þér er leyft að láta mistakast.

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

Vantar RADIUS-biðlarafærslu eða hún er óþekkt er algeng orsök hljóðláts tímataks, því netþjónninn tekur við beiðninni, finnur enga samsvarandi biðlaraskilgreiningu og hendir henni án svars. Ósamræmi í sameiginlega leyninu lítur einnig yfirleitt út eins og tímatak, því svarið stenst ekki staðfestingu og er hent. Ekkert þessara lítur út eins og Access-Reject, og ekkert þeirra er lagað með því að bæta við staðbundnum reikningi. Athugaðu biðlaraskilgreininguna og leyndina báðum megin áður en þú snertir aðferðalistann.

Hvers vegna staðbundni reikningurinn sannaði aldrei neitt

Reikningur sem stendur á eftir hópi í listanum sannar aðeins að einhver hafi skipulagt niðurfall. Hann segir ekkert um hvort áætlunin virki, því tilvikið sem prófar hana er tilvikið sem enginn æfir: netþjónninn hætti að svara. Staðbundin innskráning sem aldrei er náð í venjulegum rekstri getur borið útrunnið lykilorð eða læst ástand í marga mánuði án þess að nokkur taki eftir.

Neyðaraðgangur er hönnunarákvörðun, ekki aukaverkun stillingar. Gefðu honum sinn eigin takmarkaða reikning, sinn eigin ábyrgðarmann og skriflega endurheimtaraðferð, og felldu snúning sameiginlega leyndsins inn í þá aðferð. Að halda staðbundnu lykilorði með sama nafni fyrir hvern miðlægan notanda er mynstrið sem hljóðlaust kemur aftur með aðganginn sem þú hélt að þú hefðir fjarlægt.

Prófið sem skiptir máli er viljandi, og það mun trufla innskráningar meðan það stendur yfir. Einmitt þess vegna á það heima í áætluðum glugga þar sem afturköllunarskrefið er skrifað fyrst.

Athugaðu varaleiðina í viðhaldsglugga

Raðaðu prófinu þannig að þú fjarlægir aldrei síðustu leiðina inn. Staðfestu fyrst sjálfstæða stjórnunarleið, svo venjulegan leyfðan aðgang, svo viljandi höfnun, svo samþykkta niðurfallshegðun. Þessi fjögur tilvik hafa mismunandi væntanlegar niðurstöður, og að sameina þau í eitt próf er leiðin sem fólk lokar sig úti frá tæki sem það þarf enn.

Keyrðu hverja athugun úr konsólsetu eða frá leið utan bands, svo mistök geti ekki lokað setunni sem þú vinnur í. Konsólin er eina leiðin sem er ekki háð íhlutnum sem er í prófun.

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

Eftir það skaltu endurheimta fyrri stillingu og staðfesta að teljararnir hreyfist aftur við næstu raunverulegu innskráningu. Ef viljandi höfnunin framleiðir staðbundna innskráningu í stað höfnunar, þá er listinn eða mistakameðferðin ekki það sem þú trúðir, og sú uppgötvun er mikilvægari en niðurfallið sem þú byrjaðir með. Skrifaðu niðurstöðuna í breytingaskrána við hlið reikningsnanna og dagsetningar prófsins.