RADIUS-avvising mot ikkje noko svar: når lokal innlogging køyrer

Å halde ein lokal naudkonto gjer han ikkje til ein ny sjanse for kvar avvist innlogging. I AAA-modellen for Cisco IOS og IOS XE blir det berre slått opp i den databasen når den førre metoden feilar på ein bestemd måte, og ein RADIUS-tenar som svarar med ei avvising har ikkje feila på den måten. Den lokale kontoen dekkjer ein utilgjengeleg metode, ikkje ein avvist. Trur ein noko anna, blir ei policyavgjerd til ei jakt på ein tenarfeil som ikkje finst.

Kvifor metodelista ser ut som ein stige

Ei line som aaa authentication login default group radius local blir lesen frå venstre mot høgre, og dei fleste les ho som prøv RADIUS, prøv deretter den lokale databasen. Syntaksen inviterer til den lesinga fordi ei liste er ein sekvens. Semantikken er snevrare: lista nemner autentiseringsmetodar, og regelen for å gå vidare frå éin til den neste avheng av resultatet frå den førre metoden, ikkje av å gje brukaren eit nytt forsøk.

Ein metode som returnerer ein feil, og ein metode som returnerer eit nederlag, fører her til ulike utfall. Ei avvising er eit svar, fordi tenaren handsama påloggingsdetaljane og sa nei, og lista stoppar der. Ein utilgjengeleg tenar, ei utlopen førespurnad eller eit svar som ikkje kan validerast er tilfellet som lèt den neste metoden køyre, og berre der feilhandsaminga til plattforma er konfigurert slik. Difor verkar det klassiske rådet å leggje til local ved utfall og gjer ingenting ved feil passord. Les lista i staden som to spørsmål: kva metode svarar, og kva plattforma reknar som eit svar.

Skil metodelista frå tenargruppa

Metodelista er eitt lag, og tenargruppa er eit anna. Nøkkelordet group radius nemner ei gruppe der den interne rekkjefølgja, nye forsøk, tidsavbrot og påvising av død tenar høyrer til gruppa, medan ein lokal metode er eit lag over ho. Difor kan justering inne i gruppa ikkje gjere ei avvising om til ein reserveveg. Stadfest kva liste tenesta faktisk viser til, før du endrar nokon av dei to laga.

Skriv ut AAA-konfigurasjonen og les lista tenesta peikar på, ikkje standardverdien du hugsar at du skreiv. Gjer det frå eininga tenesta faktisk blir avslutta på.

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

Tenartabellen viser tilstand og teljarar for kvar oppføring, noko som fortel deg om gatewayen nådde tenaren under forsøket. Ein tenar merkt som oppe med ein stigande førespurnadsteljar har svara, så den mislukka innlogginga er ei avgjerd og ikkje eit tilkoplingsproblem.

Les svaret før du les loggen

Svarkoden nemner utfallet og antyder sitt eige neste steg. Access-Reject tyder at backend tok ei avgjerd, så det nyttige beviset er policyen som passa, og kontotilstanden bak han. Access-Challenge tyder at utvekslinga vil ha eitt støtta steg til, til dømes ein andre faktor, og lokal reserveveg ville stille hoppe over noko policyen krev.

Gjenskap eitt forsøk med ein angjeven testkonto, slik at svaret og backend-oppføringa kan samanliknast på same tidsstempel. Bruk ein påloggingsdetalj du har lov til å la feile.

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

Ei manglande eller ukjend RADIUS-klientoppføring er ei vanleg årsak til stille tidsavbrot, fordi tenaren mottek førespurnaden, finn ingen samsvarande klientdefinisjon og kastar han utan å svare. Uoverenskomst i den delte løyndomen ser også vanlegvis ut som eit tidsavbrot, fordi svaret ikkje består valideringa og blir kasta. Ingen av desse ser ut som Access-Reject, og ingen av dei blir reparert ved å leggje til ein lokal konto. Kontroller klientdefinisjonen og løyndomen på begge sider før du rører metodelista.

Kvifor den lokale kontoen aldri beviste noko

Ein konto som står etter ei gruppe på lista, beviser berre at nokon planla for eit utfall. Han seier ingenting om planen verkar, fordi tilfellet som prøver han, er tilfellet ingen øvar på: tenaren slutta å svare. Ei lokal innlogging som aldri blir nådd i normal drift, kan bera eit utlope passord eller ein låst tilstand i månadsvis utan at nokon merkar det.

Naudtilgang er ei designavgjerd, ikkje ein biverknad av konfigurasjonen. Gje han sin eigen avgrensa konto, sin eigen ansvarlege og ein skriftleg gjenopprettingsprosedyre, og ta rotasjon av den delte løyndomen inn i den prosedyren. Å halde eit lokalt passord med same namn for kvar sentral brukar er mønsteret som stille gjeninnfører tilgangen du trudde du hadde fjerna.

Testen som betyr noko, er medviten, og han vil avbryte innloggingar medan han køyrer. Nettopp difor høyrer han heime i eit planlagt vindauge med tilbakerullingssteget skrive først.

Kontroller reservevegen i eit vedlikehaldsvindauge

Set testen i rekkjefølgje slik at du aldri fjernar den siste vegen inn. Stadfest først ein uavhengig administrasjonsveg, deretter normal tillaten tilgang, deretter ei medviten avvising, deretter den godkjende utfallsåtferda. Desse fire tilfella har ulike venta resultat, og å slå dei saman til éin test er måten folk låser seg ute av eit apparat dei framleis treng.

Køyr kvar kontroll frå ein konsollsesjon eller ein ut-av-band-veg, slik at ein feil ikkje kan lukke sesjonen du arbeider i. Konsollen er den eine vegen som ikkje avheng av komponenten som blir testa.

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

Etterpå gjenopprettar du den førre konfigurasjonen og stadfestar at teljarane flyttar seg igjen ved neste reelle innlogging. Viss den medvitne avvisinga gjev ei lokal innlogging i staden for ei avvising, er lista eller feilhandsaminga ikkje det du trudde, og den oppdaginga er viktigare enn utfallet du starta med. Skriv resultatet inn i endringsloggen ved sida av kontonamna og datoen for testen.