802.1X について
802.1X では、クライアント サーバ ベースのアクセス コントロールと認証プロトコルを定義し、許可されていないクライアントが公にアクセス可能なポートを経由して LAN に接続するのを規制します。認証サーバは、Cisco NX-OS デバイスのポートに接続されるクライアントを個々に認証します。
802.1X アクセス コントロールでは、クライアントが認証されるまで、そのクライアントが接続しているポート経由では Extensible Authentication Protocol over LAN(EAPOL)トラフィックしか許可されません。認証に成功すると、通常のトラフィックはポートを通過できるようになります。
デバイスのロール
802.1X ポート ベースの認証では、ネットワーク上のデバイスにそれぞれ特定のロールがあります。
特定のロールは次のとおりです。
- サプリカント
-
LAN および Cisco NX-OS デバイス サービスへのアクセスを要求し、Cisco NX-OS デバイスからの要求に応答するクライアント デバイスです。ワークステーションでは、Microsoft Windows XP が動作するデバイスで提供されるような、802.1X 準拠のクライアント ソフトウェアが稼働している必要があります。
- 認証サーバ
- サプリカントの実際の認証を行います。認証サーバはサプリカントの識別情報を確認し、LAN および Cisco NX-OS デバイスのサービスへのアクセスをサプリカントに許可すべきかどうかを Cisco NX-OS デバイスに通知します。Cisco NX-OS デバイスはプロキシとして動作するので、認証サービスはサプリカントに対しては透過的に行われます。認証サーバとして、拡張認証プロトコル(EAP)拡張機能を備えた Remote Authentication Dial-In User Service(RADIUS)セキュリティ デバイスだけがサポートされています。この認証サーバは、Cisco Secure Access Control Server バージョン 3.0 で使用可能です。RADIUS はサプリカント サーバ モデルを使用し、RADIUS サーバと 1 つまたは複数の RADIUS クライアントとの間でセキュア認証情報を交換します。
- オーセンティケータ
- サプリカントの認証ステータスに基づいて、ネットワークへの物理アクセスを制御します。オーセンティケータは、サプリカントと認証サーバとの仲介デバイス(プロキシ)として動作し、サプリカントから識別情報を要求し、得られた識別情報を認証サーバに確認し、サプリカントに応答をリレーします。オーセンティケータには、EAP フレームのカプセル化/カプセル化解除、および認証サーバとの対話を処理する、RADIUS クライアントが含まれています。
オーセンティケータが EAPOL フレームを受信して認証サーバにリレーする際は、イーサネット ヘッダーを取り除き、残りの EAP フレームを RADIUS 形式にカプセル化します。このカプセル化のプロセスでは EAP フレームの変更または確認が行われないため、認証サーバはネイティブ フレーム フォーマットの EAP をサポートする必要があります。オーセンティケータは認証サーバからフレームを受信すると、サーバのフレーム ヘッダーを削除し、残りの EAP フレームをイーサネット用にカプセル化してサプリカントに送信します。
Note |
Cisco NX-OS デバイスがなれるのは、802.1X オーセンティケータだけです。 |
認証の開始およびメッセージ交換
オーセンティケータ(Cisco NX-OS デバイス)とサプリカント(クライアント)のどちらも認証を開始できます。ポート上で認証をイネーブルにした場合、オーセンティケータはポートのリンク ステートがダウンからアップに移行した時点で、認証を開始する必要があります。続いて、オーセンティケータは EAP-Request/Identity フレームをサプリカントに送信して識別情報を要求します(通常、オーセンティケータは 1 つまたは複数の識別情報の要求のあとに、最初の Identity/Request フレームを送信します)。サプリカントはフレームを受信すると、EAP-Response/Identity フレームで応答します。
サプリカントがブートアップ時にオーセンティケータから EAP-Request/Identity フレームを受信しなかった場合、サプリカントは EAPOL 開始フレームを送信することにより認証を開始することができます。この開始フレームにより、オーセンティケータはサプリカントの識別情報を要求します。
Note |
ネットワーク アクセス デバイスで 802.1X がイネーブルになっていない場合、またはサポートされていない場合、Cisco NX-OS デバイスはサプリカントからの EAPOL フレームをすべてドロップします。サプリカントが、認証の開始を 3 回試みても EAP-Request/Identity フレームを受信しなかった場合、サプリカントはポートが許可ステートにあるものとしてデータを送信します。ポートが許可ステートになっている場合は、サプリカントの認証が成功したことを意味します。 |
サプリカントが自己の識別情報を提示すると、オーセンティケータは仲介装置としてのロールを開始し、認証が成功または失敗するまで、サプリカントと認証サーバの間で EAP フレームを送受信します。認証が成功すると、オーセンティケータのポートは許可ステートになります。
実際に行われる EAP フレーム交換は、使用する認証方式によって異なります。
ユーザのシークレット パスフレーズは、認証時やパスフレーズの変更時などにネットワークを通過することはありません。
インターフェイスのオーセンティケータ PAE ステータス
インターフェイスで 802.1X をイネーブルにすると、Cisco NX-OS ソフトウェアにより、オーセンティケータ Port Access Entity(PAE)インスタンスが作成されます。オーセンティケータ PAE は、インターフェイスでの認証をサポートするプロトコル エンティティです。インターフェイスで 802.1X をディセーブルにしても、オーセンティケータ PAE インスタンスは自動的にクリアされません。必要に応じ、オーセンティケータ PAE をインターフェイスから明示的に削除し、再度適用することができます。
許可ステートおよび無許可ステートのポート
サプリカントのネットワークへのアクセスが許可されるかどうかは、オーセンティケータのポート ステートで決まります。ポートは、無許可ステートで開始します。このステートにあるポートは、802.1X プロトコル パケットを除いたすべての入トラフィックおよび出トラフィックを禁止します。サプリカントの認証に成功すると、ポートは許可ステートに移行し、サプリカントのすべてのトラフィック送受信を通常どおりに許可します。
802.1X 認証をサポートしていないクライアントが無許可ステートの 802.1X ポートに接続した場合、オーセンティケータはクライアントの識別情報を要求します。この状況では、クライアントは要求に応答せず、ポートは引き続き無許可ステートとなり、クライアントはネットワーク アクセスを許可されません。
反対に、802.1x 対応のクライアントが、802.1x プロトコルの稼働していないポートに接続すると、クライアントは EAPOL 開始フレームを送信して認証プロセスを開始します。応答がなければ、クライアントは同じ要求を所定の回数だけ送信します。応答がないので、クライアントはポートが許可ステートであるものとしてフレーム送信を開始します。
ポートには次の許可ステートがあります。
- Force authorized
- 802.1X ポートベースの認証をディセーブルにし、認証情報の交換を必要としないで許可ステートに移行します。ポートはクライアントとの 802.1x ベース認証を行わずに、通常のトラフィックを送受信します。この許可ステートはデフォルトです。
- Force unauthorized
- ポートが無許可ステートのままになり、クライアントからの認証の試みをすべて無視します。オーセンティケータは、インターフェイスを経由してクライアントに認証サービスを提供することができません。
- Auto
- 802.1X ポートベースの認証をイネーブルにします。ポートは無許可ステートで開始し、ポート経由で送受信できるのは EAPOL フレームだけです。ポートのリンク ステートがダウンからアップに移行したとき、またはサプリカントから EAPOL 開始フレームを受信したときに、認証プロセスが開始します。オーセンティケータは、クライアントの識別情報を要求し、クライアントと認証サーバとの間で認証メッセージのリレーを開始します。オーセンティケータはサプリカントの MAC アドレスを使用して、ネットワーク アクセスを試みる各サプリカントを一意に識別します。
サプリカントの認証に成功すると(認証サーバから Accept フレームを受信すると)、ポートが許可ステートに変わり、認証されたサプリカントからの全フレームがポート経由での送受信を許可されます。認証が失敗すると、ポートは無許可ステートのままですが、認証を再試行することはできます。認証サーバに到達できない場合、オーセンティケータは要求を再送信できます。所定の回数だけ試行してもサーバから応答が得られない場合には、認証が失敗し、サプリカントのネットワーク アクセスは認可されません。
サプリカントはログオフするとき、EAPOL ログオフ メッセージを送信します。このメッセージによって、オーセンティケータのポートは無許可ステートに移行します。
ポートのリンク ステートがアップからダウンに移行した場合、または EAPOL ログオフ フレームを受信した場合、ポートは無許可ステートに戻ります。
MAC 認証バイパス
MAC 認証バイパス機能を使用して、サプリカントの MAC アドレスに基づいてサプリカントを認証するように、Cisco NX-OS デバイスを設定できます。たとえば、プリンタなどのデバイスに接続されている 802.1X 機能を設定したインターフェイスで、この機能をイネーブルにすることができます。
サプリカントからの EAPOL 応答を待機している間に 802.1X 認証がタイムアウトした場合は、MAC 認証バイパスを使用して Cisco NX-OS デバイスはクライアントの許可を試みます。
インターフェイスで MAC 認証バイパス機能をイネーブルにすると、Cisco NX-OS デバイスは MAC アドレスをサプリカント ID として使用します。認証サーバには、ネットワーク アクセスが許可されたサプリカントの MAC アドレスのデータベースがあります。Cisco NX-OS デバイスは、インターフェイスでクライアントを検出した後、クライアントからのイーサネット パケットを待ちます。Cisco NX-OS デバイスは、MAC アドレスに基づいてユーザ名とパスワードを含んだ RADIUS アクセス/要求フレームを認証サーバに送信します。許可に成功した場合、Cisco NX-OS デバイスはクライアントにネットワークへのアクセスを許可します。
リンクのライフタイム中に EAPOL パケットがインターフェイスで検出される場合、このインターフェイスに接続されているデバイスが 802.1X 対応サプリカントであることを Cisco NX-OS デバイスが判別し、(MAC 認証バイパスではなく)802.1X 認証を使用してインターフェイスを許可します。インターフェイスのリンク ステータスがダウンした場合、EAPOL 履歴はクリアされます。
Cisco NX-OS デバイスがすでに MAC 認証バイパスを使用してインターフェイスを許可していて、802.1X サプリカントを検出した場合、Cisco NX-OS デバイスはインターフェイスに接続されているクライアントを無許可にしません。再認証を実行する際に、Cisco NX-OS デバイスは 802.1X 認証を優先再認証プロセスとして使用します。
MAC 認証バイパスで許可されたクライアントを再認証することができます。再認証プロセスは、802.1X で認証されたクライアントと同様です。再認証中に、ポートは前に割り当てられた VLAN に残ります。再認証に成功した場合、スイッチはポートを同じ VLAN 内に保持します。
再認証が Session-Timeout RADIUS 属性(Attribute [27])と Termination-Action RADIUS 属性(Attribute [29])に基づいていて、Termination-Action RADIUS 属性(Attribute [29])アクションが初期化の場合、(属性値は DEFAULT)、MAC 認証バイパス セッションが終了して、再認証中に接続が失われます。MAC 認証バイパスがイネーブルで 802.1X 認証がタイムアウトした場合、スイッチは MAC 認証バイパス機能を使用して再許可を開始します。これらの AV ペアの詳細については、RFC 3580「IEEE 802.1X リモート認証ダイヤル イン ユーザ サービス(RADIUS)使用ガイドライン」を参照してください。
MAC 認証バイパスは、次の機能と相互作用します。
-
802.1X 認証:802.1X 認証がポートでイネーブルの場合にだけ、MAC 認証バイパスをイネーブルにできます。
-
ポート セキュリティ:同じレイヤ 2 ポート上で 802.1X 認証とポート セキュリティを構成することはできません。
-
Network Admission Control(NAC)レイヤ 2 IP 検証:例外リスト内のホストを含む 802.1X ポートが MAC 認証バイパスで認証されたあとに、この機能が有効になります。
MAC 認証バイパスの注意事項と制限事項
MAC 認証バイパスには、次の注意事項と制限事項があります。
-
この機能は、Cisco Nexus 9336-FX2、Nexus 9236C、Nexus 93108TC-EX、および Nexus 93180YC-EX スイッチでサポートされています。
-
Cisco NX-OS リリース9.2(1) では、MAC 認証バイパスは N3K-C3164Q-40GE スイッチではサポートされていません。
MAC-Based Authentication(MAB)に基づくダイナミック VLAN 割り当て
Cisco Nexus 9000 シリーズ スイッチはダイナミック VLAN 割り当てをサポートします。802.1X 認証または MAB が完了した後。ポートを起動する前に、認証の結果としてピア/ホストを特定の VLAN に配置できるようにすることができます(許可の一部として)。RADIUS サーバは、一般的に Access-Accept 内にトンネル属性を含めることによって目的の VLAN を示します。VLAN をポートにバインドするこの手順は、ダイナミック VLAN 割り当てを構成します。
RADIUS からの VLAN 割り当て
802.1X または MAB によって認証が完了すると、RADIUS サーバからの応答にダイナミック VLAN 情報を含めることができるようになり、これをポートに割り当てることができます。この情報は、トンネル属性の形式の受け入れアクセス メッセージの RADIUS サーバからの応答に存在します。VLAN 割り当てのために、次のトンネル属性が送信されます。
-
Tunnel-type=VLAN(13)
-
Tunnel-Medium-Type=802
-
Tunnel-Private-Group-ID=VLANID
アクセス VLAN の設定のために、3 つのパラメータをすべて受け取る必要があります。
シングル ホストおよびマルチ ホストのサポート
802.1X 機能では、1 つのポートのトラフィックを 1 台のエンドポイント装置に限定することも(シングル ホスト モード)、1 つのポートのトラフィックを複数のエンドポイント装置に許可することも(マルチ ホスト モード)できます。
シングル ホスト モードでは、802.1X ポートで 1 台のエンドポイント装置のみからのトラフィックが許可されます。エンドポイント装置が認証されると、Cisco NX-OS デバイスはポートを許可ステートにします。エンドポイント装置がログオフすると、Cisco NX-OS デバイスはポートを無許可ステートに戻します。802.1X のセキュリティ違反とは、認証に成功して許可された単一の MAC アドレスとは異なる MAC アドレスをソースとするフレームが検出された場合をいいます。このような場合、このセキュリティ アソシエーション(SA)違反(他の MAC アドレスからの EAPOL フレーム)が検出されたインターフェイスはディセーブルにされます。シングル ホスト モードは、ホストツースイッチ型トポロジで 1 台のホストが Cisco NX-OS デバイスのレイヤ 2 ポート(イーサネット アクセス ポート)またはレイヤ 3 ポート(ルーテッド ポート)に接続されている場合にだけ適用できます。
マルチ ホスト モードに設定されている 802.1X ポートで、認証が必要になるのは最初のホストだけです。最初のホストの許可に成功すると、ポートは許可ステートに移行します。ポートが許可ステートになると、後続のホストがネットワーク アクセスの許可を受ける必要はありません。再認証に失敗したり、または EAPOL ログオフ メッセージを受信して、ポートが無許可ステートになった場合には、接続しているすべてのクライアントはネットワーク アクセスを拒否されます。マルチ ホスト モードでは、SA 違反の発生時にインターフェイスをシャットダウンする機能がディセーブルになります。マルチ ホスト モードは、スイッチツースイッチ型トポロジおよびホストツースイッチ型トポロジの両方に適用できます。
サポートされるトポロジ
802.1X ポートベースの認証は、ポイントツーポイント トポロジをサポートします。
この設定では、802.1X 対応のオーセンティケータ(Cisco NX-OS デバイス)ポートにサプリカント(クライアント)を 1 台だけ接続することができます。オーセンティケータは、ポートのリンク ステートがアップ ステートに移行したときにサプリカントを検出します。サプリカントがログオフしたとき、または別のサプリカントに代わったときには、オーセンティケータはポートのリンク ステートをダウンに変更し、ポートは無許可ステートに戻ります。
ユーザ単位の DACL について
Cisco NX-OS リリース 10.2(1)以降、IEEE 802.1X を使用した認証後のポリシー適用として、Cisco ISE サーバからユーザ単位のダイナミック アクセス コントロール リスト(DACL)をダウンロードできます。
ユーザ単位の DACL を設定して、異なるレベルのネットワークアクセスおよびサービスを 802.1X 認証ユーザに提供できます。RADIUS サーバは、802.1X ポートに接続されるユーザを認証する場合、ユーザ ID に基づいて ACL 属性を受け取り、これらをスイッチに送信します。スイッチは、ユーザセッションの期間中、その属性を 802.1X ポートに適用します。スイッチは、セッションが終了するたびに、または認証が失敗した場合に、ユーザ単位の DACL 設定を削除します。
RADIUS は、ベンダー固有属性などのユーザ単位属性をサポートします。ベンダー固有属性(VSA)は、オクテット ストリング形式で、認証プロセス中にスイッチに渡されます。ユーザ単位 DACL に使用される VSA は、入力方向の inacl#<n>
であり、その場合、n
は 1 から 32 です。構文は次のとおりです。
ip:inacl#<n>=permit | deny [protocol] [source_subnet] [dest_subnet] [operator][port]
例1:ip:inacl#1=permit udp any any eq 5555
例2:ip:inacl#2=deny udp any any eq 6666
VSA は入力方向に限りサポートされます。
クリティカル認証
Cisco NX-OS リリース 10.1(1) から、ポートの 802.1X クリティカル認証は、ISP ドメイン内の RADIUS サーバに到達できなかったときに認証に失敗した 802.1X ユーザに対応します。クリティカル認証機能は、802.1X 認証が RADIUS または ISE サーバを介してのみ実行される場合にサポートされます。802.1X ユーザが RADIUS 認証に失敗した場合でも、ネットワークへのアクセスは許可されます。これを行うには、dot1x authentication event server dead action authorize コマンドを使用します。この機能をディセーブルにするには、このコマンドの no 形式を使用します。