使用上のガイドライン

aaa accounting command コマンドを設定すると、管理者が入力する show コマンド以外の各コマンドが記録され、アカウンティングサーバーに送信されます。

使用上のガイドライン

aaa-server コマンドで指定済みのサーバーグループの名前を指定する必要があります。

使用上のガイドライン

ASA は、ASA を通過する任意の TCP トラフィックまたは UDP トラフィックについてのアカウンティング情報を RADIUS サーバーまたは TACACS+ サーバーに送信できます。そのトラフィックも認証されている場合、AAA サーバーはユーザー名でアカウンティング情報を保持できます。トラフィックが認証済みでない場合、AAA サーバーは IP アドレスによってアカウンティング情報を保持できます。アカウンティング情報には、セッションの開始時刻と終了時刻、ユーザー名、ASA を通過するセッションのバイト数、使用されたサービス、および各セッションの継続時間などの情報が含まれます。

このコマンドを使用する前に、aaa-server コマンドで AAA サーバーを最初に指定する必要があります。

ACL で指定されているトラフィックのアカウンティングをイネーブルにするには、aaa accounting match コマンドを使用します。match コマンドは、include コマンドおよび exclude コマンドと同じ設定では使用できません。include コマンドおよび exclude コマンドの代わりに match コマンドを使用することを推奨します。include コマンドおよび exclude コマンドは Adaptive Security Device Manager（ASDM）によってサポートされていません。

セキュリティが同じインターフェイス間で aaa accounting include および exclude コマンドを使用することはできません。その場合は、aaa accounting match コマンドを使用する必要があります。

使用上のガイドライン

ASA は、ASA を通過する任意の TCP トラフィックまたは UDP トラフィックについてのアカウンティング情報を RADIUS サーバーまたは TACACS+ サーバーに送信できます。そのトラフィックも認証されている場合、AAA サーバーはユーザー名でアカウンティング情報を保持できます。トラフィックが認証済みでない場合、AAA サーバーは IP アドレスによってアカウンティング情報を保持できます。アカウンティング情報には、セッションの開始時刻と終了時刻、ユーザー名、ASA を通過するセッションのバイト数、使用されたサービス、および各セッションの継続時間などの情報が含まれます。

このコマンドを使用する前に、aaa-server コマンドで AAA サーバーを最初に指定する必要があります。

AAA サーバー プロトコル コンフィギュレーション モードで accounting-mode コマンドを使用して同時アカウンティングをイネーブルにしない限り、アカウンティング情報はサーバーグループ内のアクティブなサーバーにのみ送信されます。

aaa accounting match コマンドは、aaa accounting include および exclude コマンドと同じ設定では使用できません。include コマンドおよび exclude コマンドの代わりに match コマンドを使用することを推奨します。include コマンドおよび exclude コマンドは ASDM によってサポートされていません。

使用上のガイドライン

ASA で Telnet、SSH、または HTTPS ユーザーを認証する前に、telnet コマンド、 ssh コマンド、または http コマンドを使用して ASA へのアクセスを設定する必要があります。これらのコマンドでは、ASA との通信を許可する IP アドレスを指定します。

ASA へのログイン

ASA に接続した後、ログインしてユーザー EXEC モードにアクセスします。

• シリアル アクセスの認証を有効にしていない場合は、ユーザー名またはパスワードを入力しません。

• Telnet の認証をイネーブルにしていない場合は、ユーザー名を入力しません。ログインパスワード（password コマンドで設定）を入力します。

• このコマンドを使用して Telnet または SSH 認証をイネーブルにした場合は、AAA サーバーまたはローカル ユーザー データベースで定義されているユーザー名とパスワードを入力します。

特権 EXEC モードへのアクセス

特権 EXEC モードを開始するには、enable コマンドまたは login コマンドを入力します（ローカルデータベースのみを使用している場合）。

• enable 認証を設定していない場合は、enable コマンドを入力するときにシステム イネーブル パスワード（ enable password コマンドで設定）を入力します。ただし、enable 認証を使用しない場合、enable コマンドを入力した後は、特定のユーザーとしてログインしていません。ユーザー名を維持するには、enable 認証を使用してください。

• enable 認証を設定している場合、ASA によってユーザー名とパスワードの入力が求められます。

ローカルデータベースを使用する認証の場合、login コマンドを使用できます。このコマンドでは、ユーザー名は維持されますが、認証をオンにするコンフィギュレーションは必要ありません。

ASDM へのアクセス

デフォルトでは、ブランクのユーザー名と enable password コマンドによって設定されたイネーブルパスワードを使用して ASDM にログインできます。ただし、ログイン画面で（ユーザー名をブランクのままにしないで）ユーザー名とパスワードを入力した場合は、ASDM によってローカル データベースで一致がチェックされます。

HTTPS 認証では AAA サーバー グループ用の SDI プロトコルがサポートされません。HTTPS 認証で要求できるユーザー名の最大長は、30 文字です。パスワードの最大長は 16 文字です。

システム実行スペースでの AAA コマンドのサポートなし

マルチ コンテキスト モードでは、システム コンフィギュレーションで AAA コマンドを設定できません。

許可されるログイン試行の回数

次の表に示すように、aaa authentication console コマンドで選択するオプションによって、ASA CLI への認証されたアクセスに対するプロンプトのアクションは異なります。

使用上のガイドライン

ACL で指定されているトラフィックの認証をイネーブルにするには、aaa authentication match コマンドを使用します。match コマンドは、include コマンドおよび exclude コマンドと同じ設定では使用できません。include コマンドおよび exclude コマンドの代わりに match コマンドを使用することを推奨します。include コマンドおよび exclude コマンドは ASDM によってサポートされていません。

セキュリティが同じインターフェイス間で aaa authentication include および exclude コマンドを使用することはできません。その場合は、aaa authentication match コマンドを使用する必要があります。

TCP セッションのシーケンス番号は、シーケンス ランダム化をディセーブルにした場合でもランダム化されることがあります。この現象は、AAA サーバーが TCP セッションを代行処理してユーザーを認証し、アクセスを許可する場合に発生します。

One-Time 認証

所定の IP アドレスのユーザーは、認証セッションが期限切れになるまで、すべてのルールおよびタイプに対して一度だけ認証を受ける必要があります（タイムアウト値については、timeout uauth コマンドを参照してください）。たとえば、ASA に Telnet と FTP の認証を設定した場合、最初に Telnet の認証に成功したユーザーは、その認証セッションが存在する限り、FTP の認証を受ける必要がありません。

HTTP 認証または HTTPS 認証では、timeout uauth コマンドが非常に小さな値に設定されている場合でも、一度認証されたユーザーの再認証が必要になることはありません。これは、ブラウザが「Basic=Uuhjksdkfhk==」文字列をキャッシュして、当該サイトへの後続の接続すべてに使用するためです。このストリングがクリアされるのは、ユーザーが Web ブラウザのインスタンスをすべて終了し、再起動したときだけです。キャッシュをフラッシュしても意味がありません。

認証チャレンジの受信に必要なアプリケーション

プロトコルまたはサービスへのネットワークアクセス認証を要求するように ASA を設定することは、すべてのプロトコルまたはサービスについて可能ですが、ユーザーが直接認証を受けることができるのは、HTTP、HTTPS、Telnet、または FTP だけです。ユーザーがこれらのサービスのいずれかの認証を受けないと、ASA は認証が必要な他のトラフィックを許可しません。

ASA が AAA 用にサポートしている認証ポートは固定値です。

• ポート 21 は FTP 用

• ポート 23 は Telnet 用

• ポート 80 は HTTP 用

• ポート 443 は HTTPS 用

ASA 認証プロンプト

Telnet および FTP の場合、ASA は認証プロンプトを生成します。

HTTP の場合、ASA はデフォルトで基本 HTTP 認証を使用し、認証プロンプトを提供します。ユーザーがユーザー名とパスワードを入力できる内部 Web ページにユーザーをリダイレクトするように ASA を設定することもできます（aaa authentication listener コマンドで設定します）。

HTTPS の場合、ASA はカスタムログイン画面を生成します。ユーザーがユーザー名とパスワードを入力できる内部 Web ページにユーザーをリダイレクトするように ASA を設定することもできます（aaa authentication listener コマンドで設定します）。

リダイレクションは、基本方式を強化したものです。これは、認証時に向上したユーザー エクスペリエンスが提供されると同時に、Easy VPN でもファイアウォール モードでも、HTTP および HTTPS と同じユーザー エクスペリエンスが提供されるためです。また、ASA での直接認証もサポートしています。

基本 HTTP 認証を使用し続けた方がよい場合もあります。ASA でリスニングポートを開く必要がない場合や、ルータ上の NAT を使用しているため、ASA で提供される Web ページの変換ルールを作成する必要がない場合、あるいは基本 HTTP 認証の方がネットワークで効果的に機能する場合です。たとえば、電子メールに URL が埋め込まれている場合などのように、ブラウザ以外のアプリケーションでは基本認証の方が適していることがあります。

正常に認証されると、ASA により元の宛先にリダイレクトされます。宛先サーバーにも独自の認証がある場合、ユーザーは別のユーザー名とパスワードを入力します。基本 HTTP 認証を使用していて、宛先サーバー用に別のユーザー名とパスワードを入力する必要がある場合は、virtual http コマンドを設定する必要があります。

（注）	aaa authentication secure-http-client コマンドを使用しないまま HTTP 認証を使用すると、ユーザー名とパスワードはクリアテキストでクライアントから ASA に送信されます。HTTP 認証をイネーブルにする場合は、必ず aaa authentication secure-http-client コマンドを使用することを推奨します。

FTP の場合、ASA ユーザー名、アットマーク（@）、FTP ユーザー名（name1@name2）を入力するオプションがあります。パスワードには、ASA パスワード、アットマーク（@）、FTP パスワード（password1@password2）を入力します。たとえば、次のテキストを入力します。

name> asa1@partreq
password> letmein@he110

この機能は、複数のログインを必要とするファイアウォールをカスケード接続している場合に有用です。複数の名前およびパスワードは、複数のアット マーク（@）で区切ることができます。

許可されるログイン試行の回数は、サポートされているプロトコルによって次のように異なります。

スタティック PAT および HTTP

HTTP 認証では、スタティック PAT が設定されている場合、ASA は実際のポートをチェックします。ASA は、マッピングポートにかかわらず、実際のポート 80 を宛先とするトラフィックを検出した場合、HTTP 接続を代行受信し、認証を実行します。

たとえば、次のように、外部 TCP ポート 889 がポート 80（www）に変換され、関係するすべての ACL でこのトラフィックが許可されるとします。

static (inside,outside) tcp 10.48.66.155 889 192.168.123.10 www netmask 255.255.255.255

この場合、ユーザーはポート 889 で 10.48.66.155 にアクセスを試み、ASA はそのトラフィックを代行受信して、HTTP 認証を実行します。ASA が HTTP 接続の完了を許可する前に、ユーザーの Web ブラウザには HTTP 認証ページが表示されます。

次の例のように、ローカル ポートがポート 80 ではないとします。

static (inside,outside) tcp 10.48.66.155 889 192.168.123.10 111 netmask 255.255.255.255

この場合、ユーザーには認証ページは表示されません。代わりに、ASA は Web ブラウザにエラーメッセージを送信して、要求されたサービスを使用する前にユーザーが認証を受ける必要があることを通知します。

ASA での直接認証

HTTP、HTTPS、Telnet、または FTP が ASA を通過することを許可せず、他のタイプのトラフィックに対しては認証を課す場合、 aaa authentication listener コマンドを設定することで、HTTP または HTTPS を使用して ASA で直接認証できます。

インターフェイスの AAA をイネーブルにすると、次の URL で ASA の直接認証を受けることができます。

http://interface_ip[:port]/netaccess/connstatus.html
https://interface_ip[:port]/netaccess/connstatus.html

または、仮想 Telnet を設定する方法もあります（virtual telnet コマンドを使用）。仮想 Telnet を設定した場合、ユーザーは ASA 上で設定された所定の IP アドレスに Telnet で接続し、ASA が Telnet プロンプトを表示します。

使用上のガイドライン

aaa authentication listener コマンドを使用しないと、aaa authentication match または aaa authentication include コマンドの設定後に HTTP/HTTPS ユーザーが ASA で認証する必要があるときに、ASA では基本 HTTP 認証が使用されます。HTTPS の場合、ASA はカスタムログイン画面を生成します。

aaa authentication listener コマンドを redirect キーワードを指定して設定すると、ASA により、すべての HTTP/HTTPS 認証要求は ASA によって提供される Web ページにリダイレクトされます。

リダイレクションは、基本方式を強化したものです。これは、認証時に向上したユーザー エクスペリエンスが提供されると同時に、Easy VPN でもファイアウォール モードでも、HTTP および HTTPS と同じユーザー エクスペリエンスが提供されるためです。また、ASA での直接認証もサポートしています。

基本 HTTP 認証を使用し続けた方がよい場合もあります。ASA でリスニングポートを開く必要がない場合や、ルータ上の NAT を使用しているため、ASA で提供される Web ページの変換ルールを作成する必要がない場合、あるいは基本 HTTP 認証の方がネットワークで効果的に機能する場合です。たとえば、電子メールに URL が埋め込まれている場合などのように、ブラウザ以外のアプリケーションでは基本認証の方が適していることがあります。

aaa authentication listener コマンドを redirect オプションを指定しないで入力した場合、ASA での直接認証のみがイネーブルとなり、通過トラフィックでは基本 HTTP 認証が使用されます。redirect オプションによって、直接認証と通過トラフィック認証の両方がイネーブルになります。直接認証は、認証チャレンジをサポートしないトラフィックタイプを認証するときに役立ちます。他のサービスを使用する前に、各ユーザーを ASA で直接認証できます。

（注）	カットスループロキシの場合、ユーザーが認証ページからログアウトしても、接続はアクティブなままになります。接続を完全にクリアするには、ユーザーが SSH セッションからログアウトする必要があります。

redirect オプションをイネーブルにした場合、インターフェイスの IP アドレスを変換する同じインターフェイス、およびリスナー用に使用される同じポートに対して、スタティック PAT も設定することはできません。NAT は成功しますが、認証は失敗します。たとえば、次のコンフィギュレーションはサポートされません。

ciscoasa(config)# static (inside,outside) tcp interface www 192.168.0.50 www netmask 255.255.255.255
ciscoasa(config)# aaa authentication listener http outside redirect

次のコンフィギュレーションはサポートされます。リスナーによって、ポートはデフォルトの 80 ではなく 1080 が使用されます。

ciscoasa(config)# static (inside,outside) tcp interface www 192.168.0.50 www netmask 255.255.255.255
ciscoasa(config)# aaa authentication listener http outside port 1080 redirect

使用上のガイドライン

デフォルトでは、カットスルー プロキシのポータル ページ（/netaccess/connstatus.html）には、接続ホストに対してカットスルー プロキシ セッションがすでにアクティブになっているときにアクセスされた場合、セッション情報とログアウト ボタンが表示されます。このコマンドを使用してログアウト ボタンを削除できます。

これは、ユーザーが NAT デバイスの背後から接続し、IP アドレスで識別できない場合に便利です。1 人のユーザーがログアウトすると、その IP アドレスのすべてのユーザーがログアウトされます。

使用上のガイドライン

1 つ以上の CLI 管理方式（SSH、Telnet、シリアル コンソール）でローカル AAA 認証をイネーブルにした場合、AAA サーバーのユーザー名またはローカル データベースのユーザー名にこの機能が適用されます。

ASDM のログインは履歴に保存されません。

ログイン履歴はユニット（装置）ごとに保存されます。フェールオーバーおよびクラスタリング環境では、各ユニットが自身のログイン履歴のみを保持します。

ログインの履歴データは、リロードされると保持されなくなります。

ログイン履歴を表示するには、show aaa login-history コマンドを使用します。

使用上のガイドライン

aaa authentication match コマンドは、include および exclude コマンドと同じ設定では使用できません。include コマンドおよび exclude コマンドの代わりに match コマンドを使用することを推奨します。include コマンドおよび exclude コマンドは ASDM によってサポートされていません。

TCP セッションのシーケンス番号は、シーケンス ランダム化をディセーブルにした場合でもランダム化されることがあります。この現象は、AAA サーバーが TCP セッションを代行処理してユーザーを認証し、アクセスを許可する場合に発生します。

One-Time 認証

所定の IP アドレスのユーザーは、認証セッションが期限切れになるまで、すべてのルールおよびタイプに対して一度だけ認証を受ける必要があります（タイムアウト値については、timeout uauth コマンドを参照してください）。たとえば、ASA に Telnet と FTP の認証を設定した場合、最初に Telnet の認証に成功したユーザーは、その認証セッションが存在する限り、FTP の認証を受ける必要がありません。

HTTP 認証または HTTPS 認証では、timeout uauth コマンドが非常に小さな値に設定されている場合でも、一度認証されたユーザーの再認証が必要になることはありません。これは、ブラウザが「Basic=Uuhjksdkfhk==」文字列をキャッシュして、当該サイトへの後続の接続すべてに使用するためです。このストリングがクリアされるのは、ユーザーが Web ブラウザのインスタンスをすべて終了し、再起動したときだけです。キャッシュをフラッシュしても意味がありません。

認証チャレンジの受信に必要なアプリケーション

プロトコルまたはサービスへのネットワークアクセス認証を要求するように ASA を設定することは、すべてのプロトコルまたはサービスについて可能ですが、ユーザーが直接認証を受けることができるのは、HTTP、HTTPS、Telnet、または FTP だけです。ユーザーがこれらのサービスのいずれかの認証を受けないと、ASA は認証が必要な他のトラフィックを許可しません。

ASA が AAA 用にサポートしている認証ポートは固定値です。

• ポート 21 は FTP 用

• ポート 23 は Telnet 用

• ポート 80 は HTTP 用

• HTTPS の場合はポート 443（ aaa authentication listener コマンドが必要）

ASA 認証プロンプト

Telnet および FTP の場合、ASA は認証プロンプトを生成します。

HTTP の場合、ASA はデフォルトで基本 HTTP 認証を使用し、認証プロンプトを提供します。ユーザーがユーザー名とパスワードを入力できる内部 Web ページにユーザーをリダイレクトするように ASA を設定することもできます（aaa authentication listener コマンドで設定します）。

HTTPS の場合、ASA はカスタムログイン画面を生成します。ユーザーがユーザー名とパスワードを入力できる内部 Web ページにユーザーをリダイレクトするように ASA を設定することもできます（aaa authentication listener コマンドで設定します）。

リダイレクションは、基本方式を強化したものです。これは、認証時に向上したユーザー エクスペリエンスが提供されると同時に、Easy VPN でもファイアウォール モードでも、HTTP および HTTPS と同じユーザー エクスペリエンスが提供されるためです。また、ASA での直接認証もサポートしています。

基本 HTTP 認証を使用し続けた方がよい場合もあります。ASA でリスニングポートを開く必要がない場合や、ルータ上の NAT を使用しているため、ASA で提供される Web ページの変換ルールを作成する必要がない場合、あるいは基本 HTTP 認証の方がネットワークで効果的に機能する場合です。たとえば、電子メールに URL が埋め込まれている場合などのように、ブラウザ以外のアプリケーションでは基本認証の方が適していることがあります。

正常に認証されると、ASA により元の宛先にリダイレクトされます。宛先サーバーにも独自の認証がある場合、ユーザーは別のユーザー名とパスワードを入力します。基本 HTTP 認証を使用していて、宛先サーバー用に別のユーザー名とパスワードを入力する必要がある場合は、virtual http コマンドを設定する必要があります。

（注）	aaa authentication secure-http-client コマンドを使用しないまま HTTP 認証を使用すると、ユーザー名とパスワードはクリアテキストでクライアントから ASA に送信されます。HTTP 認証をイネーブルにする場合は、必ず aaa authentication secure-http-client コマンドを使用することを推奨します。

FTP の場合、ASA ユーザー名、アットマーク（@）、FTP ユーザー名（name1@name2）を入力するオプションがあります。パスワードには、ASA パスワード、アットマーク（@）、FTP パスワード（password1@password2）を入力します。たとえば、次のテキストを入力します。

name> asa1@partreq
password> letmein@he110

この機能は、複数のログインを必要とするファイアウォールをカスケード接続している場合に有用です。複数の名前およびパスワードは、複数のアット マーク（@）で区切ることができます。

許可されるログイン試行の回数は、サポートされているプロトコルによって次のように異なります。

スタティック PAT および HTTP

HTTP 認証では、スタティック PAT が設定されている場合、ASA は実際のポートをチェックします。ASA は、マッピングポートにかかわらず、実際のポート 80 を宛先とするトラフィックを検出した場合、HTTP 接続を代行受信し、認証を実行します。

たとえば、次のように、外部 TCP ポート 889 がポート 80（www）に変換され、関係するすべての ACL でこのトラフィックが許可されるとします。

static (inside,outside) tcp 10.48.66.155 889 192.168.123.10 www netmask 255.255.255.255

この場合、ユーザーはポート 889 で 10.48.66.155 にアクセスを試み、ASA はそのトラフィックを代行受信して、HTTP 認証を実行します。ASA が HTTP 接続の完了を許可する前に、ユーザーの Web ブラウザには HTTP 認証ページが表示されます。

次の例のように、ローカル ポートがポート 80 ではないとします。

static (inside,outside) tcp 10.48.66.155 889 192.168.123.10 111 netmask 255.255.255.255

この場合、ユーザーには認証ページは表示されません。代わりに、ASA は Web ブラウザにエラーメッセージを送信して、要求されたサービスを使用する前にユーザーが認証を受ける必要があることを通知します。

ASA での直接認証

HTTP、HTTPS、Telnet、または FTP が ASA を通過することを許可せず、他のタイプのトラフィックに対しては認証を課す場合、 aaa authentication listener コマンドを設定することで、HTTP または HTTPS を使用して ASA で直接認証できます。

インターフェイスの AAA をイネーブルにすると、次の URL で ASA の直接認証を受けることができます。

http://interface_ip[:port]/netaccess/connstatus.html
https://interface_ip[:port]/netaccess/connstatus.html

または、仮想 Telnet を設定する方法もあります（virtual telnet コマンドを使用）。仮想 Telnet を設定した場合、ユーザーは ASA 上で設定された所定の IP アドレスに Telnet で接続し、ASA が Telnet プロンプトを表示します。

使用上のガイドライン

aaa authentication secure-http-client コマンドによって、ユーザーの HTTP ベース Web 要求が ASA を通過するのを許可する前に、ASA に対するセキュアなユーザー認証方式が提供されます。このコマンドは、SSL による HTTP カットスルー プロキシ認証に使用されます。

aaa authentication secure-http-client コマンドには次の制限があります。

• 実行時に、最大で 64 個の HTTPS 認証プロセスが許可されます。64 個の HTTPS 認証プロセスすべてが実行されている場合、認証を必要とする 65 番目の新しい HTTPS 接続は許可されません。

• uauth timeout 0 が設定されると（uauth timeout が 0 に設定される）、HTTPS 認証は機能しない場合があります。HTTPS 認証を受けた後、ブラウザが複数の TCP 接続を開始して Web ページのロードを試みると、最初の接続はそのまま許可されますが、後続の接続に対しては認証が発生します。その結果、ユーザーが認証ページに正しいユーザー名とパスワードを毎回入力しても、繰り返し認証ページが表示されます。この状況を回避するには、timeout uauth 0:0:1 コマンドで uauth timeout を 1 秒に設定します。ただし、この回避策では、同じ送信元 IP アドレスからアクセスした認証されていないユーザーがファイアウォールを通過できる期間が 1 秒間発生します。

• HTTPS 認証は SSL ポート 443 で行われるため、HTTP クライアントから HTTP サーバーポート 443 へのトラフィックをブロックするように、access-list コマンドステートメントを設定しないでください。また、ポート 80 上の Web トラフィックに対してスタティック PAT を設定する場合は、SSL ポートに対してもスタティック PAT を設定する必要があります。次の例では、最初の行でスタティック PAT が Web トラフィックに対して設定されるため、HTTPS 認証コンフィギュレーションをサポートするために 2 番めの行を追加する必要があります。

static (inside,outside) tcp 10.132.16.200 www 10.130.16.10 www
static (inside,outside) tcp 10.132.16.200 443 10.130.16.10 443

使用上のガイドライン

aaa authorization command コマンドでは、CLI でのコマンド実行が認可の対象かどうかを指定します。デフォルトでは、ログインするとユーザー EXEC モードにアクセスでき、最低限のコマンドだけが提供されます。enable コマンド（または、ローカルデータベースを使用するときは login コマンド）を入力すると、特権 EXEC モードおよびコンフィギュレーション コマンドを含む高度なコマンドにアクセスできます。コマンドへのアクセスを制御する場合には、ASA にコマンド許可を設定し、各ユーザーに許可するコマンドを制限します。

サポートされるコマンド認可方式

次の 2 つのコマンド許可方式のいずれかを使用できます。

• ローカル特権レベル：ASA でコマンド特権レベルを設定します。ローカル ユーザー、RADIUS ユーザー、または LDAP ユーザー（LDAP 属性を RADIUS 属性にマッピングする場合）を CLI アクセスについて認証する場合、ASA はそのユーザーをローカル データベース、RADIUS、または LDAP サーバーで定義されている特権レベルに所属させます。ユーザーは、ユーザー特権レベル以下のコマンドにアクセスできます。すべてのユーザーは、初めてログインするときに、ユーザー EXEC モード（レベル 0 または 1 のコマンド）にアクセスします。ユーザーは、特権 EXEC モード（レベル 2 以上のコマンド）にアクセスするために再び enable コマンドで認証するか、login コマンドでログイン（ローカルデータベースに限る）できます。

（注）	ローカル コマンド認可は、ローカル データベース内にユーザーがなくても、CLI または enable 認証がなくても使用できます。代わりに、enable コマンドを入力するときにシステム イネーブル パスワードを入力すると、ASA によってレベル 15 に置かれます。次に、すべてのレベルのイネーブルパスワードを作成します。これにより、enable n（2 ～ 15）を入力したときに、ASA によってレベル n に置かれるようになります。これらのレベルは、ローカル コマンド認可をオンにしない限り使用されません詳細については、enable コマンドを参照してください。

• TACACS+ サーバー特権レベル：TACACS+ サーバーで、ユーザーまたはグループが CLI アクセスについて認証した後で使用できるコマンドを設定します。CLI でユーザーが入力するすべてのコマンドは、TACACS+ サーバーでチェックされます。

セキュリティ コンテキストとコマンド許可

マルチ セキュリティ コンテキストでコマンド許可を実装する場合の重要な考慮点を次に示します。

• AAA 設定はコンテキストごとに個別であり、コンテキスト間で共有されません。

コマンド許可を設定する場合は、各セキュリティ コンテキストを別々に設定する必要があります。これにより、異なるセキュリティ コンテキストに対して異なるコマンド認可を実行できます。

セキュリティ コンテキストを切り替える場合、管理者は、ログイン時に指定したユーザー名で許可されるコマンドが新しいコンテキスト セッションでは異なる可能性があることや、新しいコンテキストではコマンド許可がまったく設定されていない可能性があることを念頭に置いてください。コマンド許可がセキュリティ コンテキストによって異なる場合があることを管理者が理解していないと、混乱が生じる可能性があります。この動作は、次の仕組みによってさらに複雑になります。

• changeto コマンドによって開始された新しいコンテキストセッションでは、前のコンテキストセッションで使用されたユーザー名に関係なく、管理者 ID として常にデフォルトの enable_15 ユーザー名が使用されます。これにより、enable_15 ユーザーに対してコマンド許可が設定されていない場合や、enable_15 ユーザーの認可が前のコンテキスト セッションでのユーザーの認可と異なる場合に、混乱が生じる可能性があります。

これは、発行される各コマンドを特定の管理者に正確に関連付けることができる場合に限り有効となる、コマンド アカウンティングにも影響します。changeto コマンドの使用が許可されているすべての管理者は enable_15 ユーザー名を他のコンテキストで使用できるため、enable_15 ユーザー名でログインしたユーザーをコマンド アカウンティング レコードで簡単に特定できるとは限りません。コンテキストごとに異なるアカウンティング サーバーを使用する場合は、enable_15 ユーザー名を使用していたユーザーを追跡するために数台のサーバーのデータを相関させる必要が生じます。

コマンド許可を設定する場合は、次の点を考慮します。

• changeto コマンドの使用が許可されている管理者は、実質的に、他のコンテキストそれぞれで enable_15 ユーザーに許可されているすべてのコマンドを使用する許可を持ちます。

• コンテキストごとに別々にコマンドを認可する場合は、changeto コマンドの使用を許可されている管理者に対して拒否されるコマンドについて、enable_15 ユーザー名でも同様に使用を拒否されることを、各コンテキストで確認してください。

セキュリティコンテキストを切り替える場合、管理者は特権 EXEC モードを終了し、再度 enable コマンドを入力して必要なユーザー名を使用できます。

（注）	システム実行スペースでは aaa コマンドがサポートされないため、システム実行スペースではコマンド許可を使用できません。

ローカル コマンド認可の前提条件

• aaa authentication enable console コマンドを使用して、ローカル、RADIUS、または LDAP 認証の enable 認証を設定します。

enable 認証は、ユーザーが enable コマンドにアクセスした後にユーザー名を維持するために必要です。

または、コンフィギュレーションが不要な login コマンド（認証を伴う enable コマンドと同じ）を使用できます。enable 認証ほどセキュアではないため、このオプションは推奨しません。

CLI 認証（aaa authentication {ssh | telnet | serial } console ）を使用することもできますが、必須ではありません。

• RADIUS が認証に使用されている場合、aaa authorization exec コマンドを使用して、RADIUS からの管理ユーザー特権レベルのサポートをイネーブルにすることができますが、必須ではありません。このコマンドは、ローカル、RADIUS、LDAP（マッピング済み）、および TACACS+ の各ユーザーの管理認可もイネーブルにします。

• 次に示すユーザー タイプごとの前提条件を確認してください。

• コマンド特権レベルの設定については、privilege コマンドを参照してください。

TACACS+ コマンド認可

TACACS+ コマンド認可をイネーブルにし、ユーザーが CLI でコマンドを入力すると、ASA はそのコマンドとユーザー名を TACACS+ サーバーに送信し、コマンドが認可されているかどうかを判別します。

TACACS+ サーバーによるコマンド認可を設定するときは、意図したとおりに機能することが確認できるまで、コンフィギュレーションを保存しないでください。間違いによりロック アウトされた場合、通常は ASA を再始動することによってアクセスを回復できます。

TACACS+ システムが完全に安定して信頼できることを確認します。必要な信頼性レベルについて、通常は、完全冗長 TACACS+ サーバー システムと ASA への完全冗長接続が必要です。たとえば、TACACS+ サーバー プールに、インターフェイス 1 に接続された 1 つのサーバーとインターフェイス 2 に接続された別のサーバーを含めます。TACACS+ サーバーが使用できない場合にフォールバック方式としてローカル コマンド許可を設定することもできます。この場合、ローカル ユーザーおよびコマンド特権レベルを設定する必要があります。

TACACS+ サーバーの設定については、CLI コンフィギュレーション ガイドを参照してください。

TACACS+ コマンド認可の前提条件

• aaa authentication {ssh | telnet | serial } console コマンドを使用して CLI 認証を設定します。

• aaa authentication enable console コマンドを使用して enable 認証を設定します。

使用上のガイドライン

aaa authorization exec コマンドを使用すると、ユーザーの service-type クレデンシャルはコンソールアクセスの許可の前に検査されます。

no aaa authorization exec コマンドによる管理認可をディセーブルにする場合、次の点に注意してください。

• コンソール アクセスの許可の前に、ユーザーの service-type クレデンシャルはチェックされません。

• コマンド認可が設定されている場合、RADIUS、LDAP、および TACACS+ ユーザーについて AAA サーバーで特権レベル属性が見つかると、特権レベル属性が引き続き適用されます。

ユーザーが CLI、ASDM、または enable コマンドにアクセスするときにユーザーを認証するように aaa authentication console コマンド tを設定すると、ユーザー コンフィギュレーションに応じて aaa authorization exec コマンドで管理アクセスを制限できます。

（注）	シリアルアクセスは管理認証に含まれないため、aaa authentication serial console を設定している場合は、認証したユーザーはすべてコンソールポートにアクセスできます。コマンド認可を設定した場合、コンソールユーザーにはコマンドの使用について引き続き制限が適用されます。

ユーザーを管理認証対象に設定するには、次の各 AAA サーバー タイプまたはローカル ユーザーの要件を参照してください。

• LDAP マッピング済みユーザー：LDAP 属性をマッピングするには、ldap attribute-map コマンドを参照してください。

• RADIUS ユーザー：次の値のいずれかにマッピングする IETF RADIUS 数値型 service-type 属性を使用します。

  • Service-Type 5（発信）は、管理アクセスを拒否します。ユーザーは aaa authentication console コマンドで指定されたサービスを使用できません（serial キーワードを除きます。シリアルアクセスは許可されます）。リモート アクセス（IPsec および SSL）ユーザーは、引き続き自身のリモート アクセス セッションを認証および終了できます。

  • Service-Type 6（管理）は、aaa authentication console コマンドで指定されたサービスへのフルアクセスを許可します。

  • Service-Type 7（NAS プロンプト）は、aaa authentication {telnet | ssh} console コマンドを設定している場合は CLI へのアクセスを許可しますが、 aaa authentication http console コマンドを設定している場合は ASDM へのコンフィギュレーション アクセスを拒否します。ASDM モニタリング アクセスは許可します。 aaa authentication enable console コマンドを使用して enable 認証を有効にしている場合、ユーザーは、enable コマンドを使用して特権 EXEC モードにアクセスできません。

（注）	認識される service-type は、ログイン（1）、フレーム化（2）、管理（6）、および NAS プロンプト（7）のみです。その他の service-type を使用すると、アクセスは拒否されます。

• TACACS+ ユーザー：「service=shell」エントリで認可を要求し、サーバーは次のように PASS または FAIL で応答します。

  • PASS、特権レベル 1 は、aaa authentication console コマンドで指定されたサービスへのフル アクセスを許可します。

  • PASS、特権レベル 2 以降は、aaa authentication {telnet | ssh} console コマンドを設定している場合は CLI へのアクセスを許可しますが、aaa authentication http console コマンドを設定している場合は ASDM へのコンフィギュレーション アクセスを拒否します。ASDM モニタリング アクセスは許可します。aaa authentication enable console コマンドを使用して認証を有効にしている場合、ユーザーは、enable コマンドを使用して特権 EXEC モードにアクセスできません。

  • FAIL は、管理アクセスを拒否します。ユーザーは aaa authentication console コマンドで指定されたサービスを使用できません（serial キーワードを除きます。シリアルアクセスは許可されます）。

• ローカルユーザー：service-type コマンドを設定します。これは、username コマンドのユーザー名コンフィギュレーション モードです。デフォルトでは、service-type は admin で、aaa authentication console コマンドで指定されたすべてのサービスに対してフルアクセスが許可されます。

使用上のガイドライン

このコマンドは、webvpn（ASA 1000v）をサポートしないプラットフォームや、No Payload Encryption（NPE）がイネーブルになっているプラットフォームでは使用できません。

使用上のガイドライン

ACL で指定されているトラフィックの認可をイネーブルにするには、aaa authorization match コマンドを使用します。match コマンドは、include コマンドおよび exclude コマンドと同じ設定では使用できません。include コマンドおよび exclude コマンドの代わりに match コマンドを使用することを推奨します。include コマンドおよび exclude コマンドは ASDM によってサポートされていません。

セキュリティが同じインターフェイス間で aaa authorization include および exclude コマンドを使用することはできません。その場合は、aaa authorization match コマンドを使用する必要があります。

TACACS+ でネットワークアクセス認可を実行するように、ASA を設定できます。認証ステートメントと認可ステートメントは互いに独立しています。ただし、認証されていないトラフィックは、認可ステートメントに一致した場合でも拒否されます。ユーザーが認可を受けるには、まず ASA に認証される必要があります。認証セッションが期限切れになっていない場合、所定の IP アドレスを持つユーザーが認証を受ける必要があるのは、すべてのルールおよびタイプで 1 回だけです。このため、トラフィックが認証ステートメントに一致した場合でも認可が発生する可能性があります。

ユーザーの認証が完了すると、ASA は、一致するトラフィックの認可ルールをチェックします。トラフィックが認可ステートメントに一致した場合、ASA はユーザー名を TACACS+ サーバーに送信します。TACACS+ サーバーは ASA に応答し、ユーザープロファイルに基づいてそのトラフィックの許可または拒否を示します。ASA は、その応答内の認可ルールを実施します。

ユーザーに対するネットワーク アクセス認可の設定については、ご使用の TACACS+ サーバーのマニュアルを参照してください。

IP アドレスごとに 1 つの aaa authorization include コマンドが許可されます。

最初の認可試行が失敗し、2 番めの試行でタイムアウトが発生した場合は、認可されなかったクライアントを service resetinbound コマンドを使用してリセットし、そのクライアントが接続の再送信を行わないようにします。次の例は、Telnet の認可タイムアウト メッセージです。

Unable to connect to remote host: Connection timed out

（注）	ポート範囲を指定すると、予期できない結果が認可サーバーで生じる可能性があります。ASA では、サーバーがストリングを解析してポート範囲に変換できることを前提としており、ポート範囲をストリングとしてサーバーに送信します。すべてのサーバーがこのような変換を実行するとは限りません。また、ユーザーに対して特定のサービスだけを認可する場合もありますが、範囲が受け入れられると、このような認可は行われません。

使用上のガイドライン

aaa authorization match コマンドは、include および exclude コマンドと同じ設定では使用できません。include コマンドおよび exclude コマンドの代わりに match コマンドを使用することを推奨します。include コマンドおよび exclude コマンドは ASDM によってサポートされていません。

TACACS+ でネットワークアクセス認可を実行するように、ASA を設定できます。aaa authorization match コマンドによる RADIUS 認可では、ASA への VPN 管理接続の認可のみがサポートされます。

認証ステートメントと認可ステートメントは互いに独立しています。ただし、認証されていないトラフィックは、認可ステートメントに一致した場合でも拒否されます。ユーザーが認可を受けるには、まず ASA に認証される必要があります。認証セッションが期限切れになっていない場合、所定の IP アドレスを持つユーザーが認証を受ける必要があるのは、すべてのルールおよびタイプで 1 回だけです。このため、トラフィックが認証ステートメントに一致した場合でも認可が発生する可能性があります。

ユーザーの認証が完了すると、ASA は、一致するトラフィックの認可ルールをチェックします。トラフィックが認可ステートメントに一致した場合、ASA はユーザー名を TACACS+ サーバーに送信します。TACACS+ サーバーは ASA に応答し、ユーザープロファイルに基づいてそのトラフィックの許可または拒否を示します。ASA は、その応答内の認可ルールを実施します。

ユーザーに対するネットワーク アクセス認可の設定については、ご使用の TACACS+ サーバーのマニュアルを参照してください。

最初の認可試行が失敗し、2 番めの試行でタイムアウトが発生した場合は、認可されなかったクライアントを service resetinbound コマンドを使用してリセットし、そのクライアントが接続の再送信を行わないようにします。次の例は、Telnet の認可タイムアウト メッセージです。

Unable to connect to remote host: Connection timed out

（注）	ポート範囲を指定すると、予期できない結果が認可サーバーで生じる可能性があります。ASA では、サーバーがストリングを解析してポート範囲に変換できることを前提としており、ポート範囲をストリングとしてサーバーに送信します。すべてのサーバーがこのような変換を実行するとは限りません。また、ユーザーに対して特定のサービスだけを認可する場合もありますが、範囲が受け入れられると、このような認可は行われません。

使用上のガイドライン

validate-kdc コマンドを使用して、グループ内のサーバーを認証するように Kerberos AAA サーバーグループを設定できます。認証を実行するには、Kerberos キー発行局（KDC）からエクスポートしたキータブファイルもインポートする必要があります。KDC を検証することにより、攻撃者が KDC をスプーフィングして、ユーザークレデンシャルが攻撃者の Kerberos サーバーに対して認証されるようにする攻撃を防ぐことができます。

KDC の検証を有効にすると、チケット認可チケット（TGT）を取得してユーザーを検証した後、システムは host /ASA_hostname のユーザーに代わってサービスチケットも要求します。次にシステムは、返されたサービスチケットを KDC の秘密鍵に対して検証します。これは、KDC から生成され、ASA にアップロードされたキータブファイルに保存されます。KDC 認証に失敗すると、サーバーは信頼できないと見なされ、ユーザーは認証されません。

KDC 認証を完了するには、次の手順を実行する必要があります。

1. （KDC 上。）ASA の Microsoft Active Directory にユーザーアカウントを作成します（Start > Programs > Administrative Tools > Active Directory Users and Computers に移動します）。たとえば、ASA の完全修飾ドメイン名（FQDN）が asahost.example.com の場合は、asahost という名前のユーザーを作成します。

2. （KDC 上。）FQDN とユーザーアカウントを使用して、ASA のホストサービスプリンシパル名（SPN）を作成します。

   
   C:> setspn -A HOST/asahost.example.com asahost
   

3. （KDC 上。）ASA の キータブファイルを作成します（わかりやすくするために改行を追加）。

   
   C:\Users\Administrator> ktpass /out new.keytab +rndPass
   /princ host/asahost@EXAMPLE.COM
   /mapuser asahost@example.com
   /ptype KRB5_NT_SRV_HST
   /mapop set
   

4. （ASA 上。）aaa kerberos import-keytab コマンドを使用して、キータブ（この例では new.keytab）を ASA にインポートします。

5. （ASA 上。）Kerberos AAA サーバーグループ設定に validate-kdc コマンドを追加します。キータブファイルは、このコマンドが含まれているサーバーグループでのみ使用されます。

（注）	Kerberos 制約付き委任（KCD）とともに KDC 検証を使用することはできません。サーバーグループが KCD に使用されている場合、validate-kdc コマンドは無視されます。

使用上のガイドライン

このコマンドは、ローカル ユーザー データベースによる認証だけに影響します。このコマンドを省略すると、ユーザーが間違ったパスワードを入力できる回数に制限は設けられません。

間違ったパスワードを入力した回数が設定回数に達すると、ユーザーはロック アウトされ、管理者がユーザー名のロックを解除するまで、または 10 分経過するまで、そのユーザーは正常にログインできません。ユーザー名のロックまたはアンロックにより、syslog メッセージが生成されます。

ユーザーが正常に認証されるか、ASA がリブートされると、失敗試行回数は 0 にリセットされ、ロックアウト ステータスは No にリセットされます。

使用上のガイドライン

追加できる aaa mac-exempt コマンドは 1 つだけです。aaa mac-exempt コマンドを使用する前に、mac-list コマンドを使用して MAC リスト番号を設定します。MAC リスト内の permit エントリによって MAC アドレスは認証および認可から免除され、deny エントリによって MAC アドレスの認証および認可が要求されます（認証および認可がイネーブルの場合）。追加できる aaa mac-exempt コマンドのインスタンスは 1 つだけであるため、免除するすべての MAC アドレスを MAC リストに含めてください。

使用上のガイドライン

送信元アドレスがプロキシ サーバーである場合は、この IP アドレスを認証から除外するか、許容される未処理 AAA 要求の数を増やすことを検討してください。

たとえば、ターミナル サーバーに接続しているなどの理由で、同じ IP アドレスを使用する 2 人のユーザーがブラウザまたは接続を開き、正確に同時に認証を開始しようとした場合、1 人のみが許可され、2 人目はブロックされます。

その IP アドレスからの最初のセッションは代行処理されて認証要求が送信され、もう 1 つのセッションはタイムアウトします。このことは、単一ユーザー名の接続数とは関係ありません。

使用上のガイドライン

RSA Authentication Manager（SecurID）サーバーによって生成されたノードシークレットファイルを手動でインポートできます。

RSA Authentication Manager サーバーからノードシークレットファイルをエクスポートする必要があります。詳細については、RSA Authentication Manager のドキュメントを参照してください。次に、解凍したファイルを ASA にアップロードするか、このコマンドを使用してインポートできるサーバーに配置します。

使用上のガイドライン

シングル モードで最大 100 個のサーバー グループ、またはマルチ モードでコンテキストごとに 4 つのサーバー グループを持つことができます。9.13(1) 以降では、制限はシングルモードでは 200 グループ、マルチモードでは 8 グループに増加しています。

各グループには、シングル モードで最大 16 台、マルチ モードで最大 4 台のサーバーを含めることができます。9.13(1) 以降では、マルチモードの制限はグループあたり 8 台のサーバーです。ユーザーがログインすると、コンフィギュレーション内で指定されている最初のサーバーから順に、サーバーが応答するまでこれらのサーバーが 1 つずつアクセスされます。

aaa-server コマンドで AAA サーバーグループプロトコルを定義することによって AAA サーバー コンフィギュレーションを制御し、次に aaa-server host コマンドを使用してサーバーをグループに追加します。aaa-server protocol コマンドを入力すると、aaa-server グループ コンフィギュレーション モードが開始します。

RADIUS プロトコルを使用する場合、AAA サーバー グループ コンフィギュレーション モードでは、次のことに注意してください。

• クライアントレス SSL および セキュアクライアント セッションについてマルチセッション アカウンティングを有効にするには、interim-accounting-update オプションを入力します。このオプションを選択すると、開始レコードと終了レコード以外に中間アカウンティング レコードが RADIUS サーバーに送信されます。

• ASA と AD エージェントとの間の共有秘密を指定し、RADIUS サーバーグループにフル機能の RADIUS サーバーではない AD エージェントを含めることを示すには、ad-agent-mode オプションを入力します。ユーザー アイデンティティに関連付けることができるのは、このオプションを使用して設定された RADIUS サーバー グループのみです。結果として、ad-agent-mode オプションを使用して設定されていない RADIUS サーバー グループを指定すると test aaa-server {authentication | authorization } aaa-server-group コマンドが使用できなくなります。

使用上のガイドライン

このコマンドを使用しないと、グループ内の障害が発生したサーバーは、グループ内のすべてのサーバーに障害が発生するまで障害状態のままになります。グループ内のすべてのサーバーに障害が発生した後に、サーバーはすべて再度アクティブにされます。

使用上のガイドライン

aaa-server コマンドで AAA サーバーグループを定義することによって AAA サーバー コンフィギュレーションを制御し、次に aaa-server host コマンドを使用してサーバーをグループに追加します。aaa-server host コマンドを使用すると、AAA サーバー ホスト コンフィギュレーション モードが開始されます。このモードから、ホスト固有の AAA サーバー接続データを指定および管理できます。

各グループには、シングル モードで最大 16 台、マルチ モードで最大 4 台のサーバーを含めることができます。9.13(1) 以降では、マルチモードの制限はグループあたり 8 台のサーバーです。ユーザーがログインすると、コンフィギュレーション内で指定されている最初のサーバーから順に、サーバーが応答するまでこれらのサーバーが 1 つずつアクセスされます。

使用上のガイドライン

時間ベース ACL を実装するには、time-range コマンドを使用して、特定の日時および曜日を定義します。次に、access-list extended time-range コマンドを使用して、時間範囲を ACL にバインドします。

使用上のガイドライン

フェーズ 1 の処理中に、IKE ピアによって下位証明書とアイデンティティ証明書の両方が渡される場合があります。下位証明書は ASA にインストールされない場合があります。このコマンドを使用すると、管理者はデバイス上にトラストポイントとして設定されていない下位 CA 証明書をサポートできます。確立されたすべてのトラストポイントのすべての下位 CA 証明書が受け入れ可能である必要はありません。つまり、このコマンドを使用すると、デバイスで、証明書チェーン全体をローカルにインストールすることなく、その証明書チェーンを認証できます。

使用上のガイドライン

インターフェイス固有のアクセス グループ ルールがグローバル ルールに優先されるため、パケットの分類時はインターフェイス固有のルールがグローバル ルールの前に処理されます。

ルーテッド モードでは、BVI とそのメンバー インターフェイスの両方にアクセス グループを適用した場合、優先順位は方向によって異なります。インバウンドでは、メンバー インターフェイスのアクセス グループが最初にチェックされ、次に BVI アクセス グループ、最後にグローバル グループがチェックされます。アウトバウンドでは、BVI アクセス グループが最初にチェックされ、次にメンバー インターフェイスのアクセス グループがチェックされます。

インターフェイス固有ルールの使用上のガイドライン

access-group コマンドは、インターフェイスに拡張 ACL をバインドします。ACL を作成するには、最初に access-list extended コマンドを使用する必要があります。

インターフェイスに対して着信または発信するトラフィックに ACL を適用できます。access-list コマンドステートメントで permit オプションを入力すると、ASA によってパケットの処理は続行されます。access-list コマンドステートメントで deny オプションを入力すると、ASA によってパケットが廃棄され、syslog message 106023（または、デフォルト以外のロギングを使用する ACE の場合には 106100）が生成されます。

インバウンド ACL の場合、per-user-override オプションを使用すると、ダウンロードされた ACL によって、インターフェイスに適用されている ACL を上書きできます。per-user-override オプションを指定しないと、ASA は既存のフィルタリング動作を維持します。 per-user-override を指定すると、ASA により、ユーザーに関連付けられているユーザーごとのアクセスリスト（ダウンロードされた場合）の permit または deny ステータスで、access-group コマンドに関連付けられている ACL の permit または deny ステータスを上書きできるようになります。さらに、次のルールが適用されます。

• パケットが到着した時点で、そのパケットに関連付けられているユーザーごとの ACL がない場合、インターフェイス ACL が適用されます。

• ユーザーごとの ACL は、timeout コマンドの uauth オプションで指定されたタイムアウト値によって管理されますが、このタイムアウト値は、ユーザーごとの AAA セッションタイムアウト値によって上書きできます。

• 既存の ACL ログ動作は同じです。たとえば、ユーザーごとの ACL が原因でユーザー トラフィックが拒否された場合、syslog メッセージ 109025 が記録されます。ユーザー トラフィックが許可された場合、syslog メッセージは生成されません。ユーザーごとのアクセス リストのログ オプションは、影響を及ぼしません。

デフォルトでは、VPN リモート アクセス トラフィックはインターフェイス ACL と照合されません。ただし、no sysopt connection permit-vpn コマンドを使用してこのバイパスをオフにする場合、動作は、グループポリシーに適用される vpn-filter があるかどうか、および per-user-override オプションを設定するかどうかによって異なります。

• [No per-user-override , no vpn-filter ]：トラフィックはインターフェイス ACL と照合されます。

• [No per-user-override , vpn-filter ]：トラフィックはまずインターフェイス ACL と照合され、次に VPN フィルタと照合されます。

• [per-user-override , vpn-filter ]：トラフィックは VPN フィルタのみと照合されます。

（注）	1 つ以上の access-group コマンドによって参照される ACL から、すべての機能エントリ（permit ステートメントおよび deny ステートメント）を削除すると、access-group コマンドはコンフィギュレーションから自動的に削除されます。access-group コマンドは、空の ACL またはコメントのみを含む ACL を参照できません。

グローバル ルールの使用上のガイドライン

access-group global コマンドは、ASA でトラフィックが到着するインターフェイスにかかわらず、すべてのトラフィックに対して 1 組のグローバルルールを適用します。

すべてのグローバル ルールは、入力（着信）方向のトラフィックにのみ適用されます。グローバル ルールは出力（発信）トラフィックには適用されません。グローバル ルールが着信インターフェイス アクセス ルールと組み合わせて設定された場合、インターフェイス アクセス ルール（特定のルール）がグローバル アクセス ルール（一般のルール）よりも前に処理されます。

使用上のガイドライン

ACL deny ステートメントに log オプションを設定している場合、トラフィックフローが ACL ステートメントと一致すると、アプライアンスによってフロー情報がキャッシュされます。キャッシュの過負荷を避けるために、syslog メッセージ 106100 で示される統計情報のために保持されるキャッシュ拒否フローの最大数が設定されています。106100 が発行されてキャッシュがリセットされる前に最大数に達した場合は、拒否フローの最大数を超過したことを示す syslog メッセージ 106101 が発行されます。

access-list alert-interval コマンドは、syslog メッセージ 106101 を生成する時間間隔を設定します。拒否フローの最大数に達した場合、最後の syslog メッセージ 106101 が生成されてから secs 秒以上が経過すると、別の syslog メッセージ 106101 が生成されます。

拒否フローの最大数メッセージの生成については、access-list deny-flow-max コマンドを参照してください。