RADIUS-avvisning kontra inget svar: när lokal inloggning körs

Att hålla ett lokalt nödkonto gör det inte till en ny chans för varje avvisad inloggning. I AAA-modellen för Cisco IOS och IOS XE slås det bara upp i den databasen när den föregående metoden misslyckas på ett visst sätt, och en RADIUS-server som svarar med en avvisning har inte misslyckats på det sättet. Det lokala kontot täcker en oåtkomlig metod, inte en avvisad. Tror man något annat blir ett policybeslut till en jakt på ett serverfel som inte finns.

Varför metodlistan ser ut som en stege

En rad som aaa authentication login default group radius local läses från vänster till höger, och de flesta läser den som prova RADIUS, prova sedan den lokala databasen. Syntaxen inbjuder till den läsningen eftersom en lista är en sekvens. Semantiken är snävare: listan namnger autentiseringsmetoder, och regeln för att gå vidare från en till nästa beror på resultatet av den föregående metoden, inte på att ge användaren ett nytt försök.

En metod som returnerar ett fel och en metod som returnerar ett misslyckande leder här till olika utfall. En avvisning är ett svar, eftersom servern behandlade inloggningsuppgifterna och sade nej, och listan stannar där. En oåtkomlig server, en utgången begäran eller ett svar som inte kan valideras är det fall som låter nästa metod köra, och bara där plattformens felhantering är konfigurerad så. Därför fungerar det klassiska rådet att lägga till local vid avbrott och gör ingenting vid fel lösenord. Läs listan i stället som två frågor: vilken metod svarar, och vad plattformen räknar som ett svar.

Skilj metodlistan från servergruppen

Metodlistan är ett lager och servergruppen är ett annat. Nyckelordet group radius namnger en grupp vars inre ordning, nya försök, tidsgränser och upptäckt av död server hör till gruppen, medan en lokal metod är ett lager ovanpå. Att justera något inne i gruppen kan därför inte göra en avvisning till en reservväg. Bekräfta vilken lista tjänsten faktiskt refererar till innan du ändrar något av de två lagren.

Skriv ut AAA-konfigurationen och läs listan som tjänsten pekar på, inte det standardvärde du minns att du skrev. Gör det från enheten där tjänsten faktiskt slutar.

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

Servertabellen rapporterar status och räknare för varje post, vilket säger om gatewayen nådde servern under försöket. En server markerad som uppe med en stigande begäranräknare har svarat, så den misslyckade inloggningen är ett beslut och inte ett anslutningsproblem.

Läs svaret innan du läser loggen

Svarskoden namnger utfallet och antyder sitt eget nästa steg. Access-Reject betyder att backend fattade ett beslut, så det användbara beviset är policyn som matchade och kontostatusen bakom den. Access-Challenge betyder att utbytet vill ha ett till stött steg, som en andra faktor, och en lokal reservväg skulle tyst hoppa över något som policyn kräver.

Återskapa ett försök med ett angivet testkonto så att svaret och backend-posten kan jämföras på samma tidsstämpel. Använd en inloggningsuppgift vars misslyckande du har tillåtelse att orsaka.

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

En saknad eller okänd RADIUS-klientpost är en vanlig orsak till tyst tidsgräns, eftersom servern tar emot begäran, inte hittar någon matchande klientdefinition och kastar den utan att svara. En avvikelse i den delade hemligheten ser också oftast ut som en tidsgräns, eftersom svaret inte klarar valideringen och kastas. Inget av detta ser ut som Access-Reject, och inget av det repareras genom att lägga till ett lokalt konto. Kontrollera klientdefinitionen och hemligheten på båda sidor innan du rör metodlistan.

Varför det lokala kontot aldrig bevisade något

Ett konto som står efter en grupp i listan bevisar bara att någon planerade för ett avbrott. Det säger ingenting om huruvida planen fungerar, eftersom fallet som prövar den är fallet ingen övar på: servern slutade svara. En lokal inloggning som aldrig nås i normal drift kan bära ett utgånget lösenord eller ett låst tillstånd i månader utan att någon märker det.

Nödåtkomst är ett designbeslut, inte en bieffekt av konfigurationen. Ge den ett eget begränsat konto, en egen ansvarig och en skriftlig återställningsprocedur, och ta in rotationen av den delade hemligheten i den proceduren. Att hålla ett lokalt lösenord med samma namn för varje central användare är mönstret som tyst återinför den åtkomst du trodde att du hade tagit bort.

Testet som betyder något är avsiktligt, och det kommer att avbryta inloggningar medan det körs. Just därför hör det hemma i ett planerat fönster med återställningssteget skrivet först.

Kontrollera reservvägen under ett underhållsfönster

Ordna testet så att du aldrig tar bort den sista vägen in. Bekräfta först en oberoende administrationsväg, sedan normal tillåten åtkomst, sedan en avsiktlig avvisning, sedan det godkända avbrottsbeteendet. Dessa fyra fall har olika förväntade resultat, och att slå ihop dem till ett test är sättet folk låser sig ute från en enhet de fortfarande behöver.

Kör varje kontroll från en konsolsession eller en väg utanför bandet, så att ett fel inte kan stänga sessionen du arbetar i. Konsolen är den enda vägen som inte beror på komponenten som testas.

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

Därefter återställer du den tidigare konfigurationen och bekräftar att räknarna rör sig igen vid nästa riktiga inloggning. Om den avsiktliga avvisningen ger en lokal inloggning i stället för en avvisning, då är listan eller felhanteringen inte vad du trodde, och den upptäckten väger tyngre än avbrottet du började med. Skriv resultatet i ändringsloggen bredvid kontonamnen och datumet för testet.