Одбивање на RADIUS наспроти без одговор: кога работи локалната најава

Држењето локална сметка за итни случаи не ја прави втора шанса за секоја одбиена најава. Во AAA моделот на Cisco IOS и IOS XE, таа база се проверува само кога претходниот метод не успева на определен начин, а 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

Потоа вратете ја претходната конфигурација и потврдете дека бројачите повторно се движат при следната вистинска најава. Ако намерното одбивање создаде локална најава наместо одбивање, тогаш листата или ракувањето со неуспеси не е она што сте верувале, и тоа откритие е поважно од прекинот со кој почнавте. Запишете го резултатот во записот за промени покрај имињата на сметките и датумот на тестот.