RADIUS の拒否と無応答：ローカルログインが動く条件

緊急用のローカルアカウントを保持していても、それが拒否されたすべてのログインの二度目の機会になるわけではありません。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

その後、以前の設定を復元し、次の実際のログインでカウンターが再び動くことを確認します。意図的な拒否が拒否ではなくローカルログインを生むなら、リストか障害処理が信じていたものと違うということであり、その発見は最初に始めた障害より重要です。結果をアカウント名とテストの日付の隣の変更記録に書いてください。