CiscoスイッチのAAA / TACACS +パスワードが2番目のパスワードプロンプトで常に失敗する

AAA / TACACS +を使用してネットワークデバイスにログインするときはいつでも、ユーザー名のプロンプトの後にパスワードプロンプトをファットフィンガーすると、パスワードが正しい場合でも2番目のパスワードプロンプトが常に失敗します。ユーザー名のプロンプトをもう一度待つ必要があり、その直後の最初のパスワードプロンプトで正しいパスワードを取得する必要があります。つまり、2番目のパスワードプロンプトが表示されても、機能しません。

以下のサニタイズされた相互作用と設定を参照してください。

ユーザーアクセスの確認
ユーザー名：ユーザー名
パスワード：

パスワード：（常にここで失敗します）
％ アクセスが拒否されました

ユーザーアクセスの確認
ユーザー名：ユーザー名
パスワード：

1行目（サイト名）でs-site-rack-agg2.example.netに接続されています。
s-site-rack-agg2＃

この動作を説明するための2番目のパスワードプロンプトと何が違うのでしょうか？

私が持っている典型的なAAAおよび関連する構成は次のとおりです。

AAA新型
aaa authentication login default group tacacs + local line
aaa authentication login CONSOLE none
aaa authentication enable default group tacacs + enable
aaa authorization execデフォルトグループtacacs +ローカルif-authenticated
aaa承認コマンド1つのデフォルトグループtacacs +ローカルif-authenticated
aaa authorizationコマンド7デフォルトグループtacacs +ローカルif-authenticated
aaa認可コマンド15デフォルトグループtacacs +ローカルif-authenticated
AAAアカウンティングexecデフォルトスタートストップグループtacacs +
AAAアカウンティングコマンド0デフォルトのスタート/ストップグループtacacs +
aaa accounting commands 1 default start-stop group tacacs +
AAAアカウンティングコマンド7デフォルトのスタート/ストップグループtacacs +
AAAアカウンティングコマンド15デフォルトのStart-Stopグループtacacs +
AAAアカウンティングシステムのデフォルトのスタート/ストップグループtacacs +
！
ip tacacs source-interface Loopback0
tacacs-server host -prmiaryipremoved-単一接続
tacacs-server host -secondaryipremoved-単一接続
tacacs-serverタイムアウト10
tacacs-server Directed-Request
tacacs-server key 7-削除-
！
ラインコン0
 ログイン認証コンソール
ラインvty 0 4
 場所-削除-
 exec-timeout 60 0
 パスワード7-削除-
 トランスポート入力telnet ssh

あなたがこれを試みている間、私はあなたのTACACS +サーバーでデバッグをします。

サーバーにアクセスできない場合は、TACACS認証のみを使用し、ローカルログインにのみフォールバックするとします。

これを使ってみてください：
aaa authentication login default group tacacs+ line
aaa authentication enable default group tacacs+ enable

また、このサイトを参照してください：いくつかの良い例と説明があります

http://my.safaribooksonline.com/book/networking/cisco-ios/0596527225/tacacsplus/i13896_ heada _4_2＃X2ludGVybmFsX0h0bWxWaWV3P3htbGlkPTA1OTY1MjcyMjUlMkZpXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXHXkXkXlXkXXzXmXHzkXkXkXkXkXlcXYXzXmXHzkXmXHzkXkXkXkXkXmXHZkXkXlXHXzXjXmXHXkXmXHZkXmXHZZXXHZNKXH

私の推測では、「local」キーワードがあるので、
aaa authentication login default group tacacs+ local line

TACACS +認証は失敗を返すため、ルータはローカル認証を試みます。line vtyサニタイズされた構成を提供する必要があると思います。あなたが持っている場合
line vty 0 15
login local

次に、ユーザー名/パスワード認証を行います。それ以外の場合は、パスワードを実行します

私はあなたの設定が非常に危険だと思います、そしてあなたがフォールバックとして 'enable / line'または 'local'を使用している場合、あなたは決断力がないようです、正しい答えはローカルです一方向ハッシュではなく「暗号化」された方法）。

代わりにこの構成をお勧めします。

aaa new-model
! uses tacacs, fallsback to local user if tacacs not working
aaa authentication login default group tacacs+ local
! user gets enabled by tacacs or by enable password
aaa authentication enable default group tacacs+ enable
! console user is authorized as well (gets enabled, if such permission)
aaa authorization console
! configuration commands are authorized as well as exec commands (Good to prevent dangerous commands)
aaa authorization config-commands
! user privilege level is recovered from tacacs or from local account
aaa authorization exec default group tacacs+ local
! level 15 commands are authorized (you really only need this) 
aaa authorization commands 15 default group tacacs+ if-authenticated 
! level 1, 15 commands are logged (you really only need these two)
aaa accounting commands 1 default start-stop group tacacs+
aaa accounting commands 15 default start-stop group tacacs+
!
! fallback user consulted only when tacacs is broken
username sikrit privilege 15 secret <password>

「sikrit」ユーザーはtacacsが機能していないときに使用されます（TACACSが応答する場合は使用できません）。VTYで「line」パスワードを使用する必要はありません。参照されることはないため、「enable」パスワードは必要ありません。有効化されていないバックアップユーザーが必要な場合は、「特権1」で別のユーザーを作成してください。
ただし、なんらかの理由で使用したい場合は、「enable」のサポートを追加しました。

OOBを使用していて、OOBアクセスがすでに保護/認証されている場合は、TACACSが壊れているのにIOSが誤ってそうでないと考えている場合に備えて、OOBユーザーが常にローカル認証を使用できるようにすることをお勧めします。このようなものを追加します。 ：

aaa authentication login CONSOLE local
!
line con 0
 login authentication CONSOLE

私はあなたのローカルデバイスの設定がこれを非難するのではなく、むしろあなたのTACACSサーバー自体であるかどうかわかりません。TACACSは、ユーザー名/パスワードプロンプトをTACACSサーバー（および場合によっては外部IDストア）からデバイスにプロキシするため、ACS（たとえば）を使用していて、ADと通信してユーザー認証を行うように設定されている場合は、ユーザー名/パスワードプロンプトは、デバイス自体ではなくドメインコントローラからのものであると考えてください。

私は最近、ACSへのパッチで修正されたこのような問題に遭遇しました。ここでも、ACSを使用していて、ユーザー認証/グループ検証などのためにADからプルしていると想定しています。CiscoバグIDはCSCtz03211でした。基本的に、ACS 5.3は、デバイスへの1つの「ユーザー名/パスワード」認証試行ごとに、ADに複数の認証試行を送信していました。これにより、ユーザーが最初の試行でパスワードを太った場合、誤ったユーザー名/パスワードの組み合わせの複数のインスタンスがADに送信され、ユーザーのアカウントが実際にロックアウトされ、その後のログイン試行が失敗するという結果になります。ユーザーが2回目の試行でユーザー名/パスワードを正しく入力した場合でもデバイス（もちろん、この動作は、AD内のユーザーアカウントに設定したロックアウトのしきい値によって異なります）。

考慮すべきこと（TACACSサーバーの実装に関する知識なし）。