Aruba IAP-305の設定と動作に迫る (11)

前回に引き続き無線LAN接続後のアクセス制御の話です。今回は無線LAN接続後に条件に応じて動的にアクセス制御を行う方法です。IAPのソフトウェアバージョンは6.5.1.0-4.3.1.2_58595です。RadiusサーバはWindows Server2012R2を使用します。アカウント情報はActive Directory上に格納されており、NPSからADを参照する構成になります。無線LAN接続時にIEEE802.1x PEAP認証を行います。

まずはアクセスでロールベースを選択します。

f:id:ReaLiZeZNSG:20180616204122p:plain

ロールを設定することでアクセス権限を割り当てるわけですが、とりあえず作成したSSID設定と同名のロールが自動的に出来上がります。中身は全通信許可になっています。これを割り当てるだけだと前回の固定的なアクセス制御と違いはありません。今回はロールの割り当てルールを作成することで動的にロールを割り当てます。やり方が構成に応じて色々あるのですが、今回記載するのはその中の例になります。他の場合のいくつかの方法は最後に軽く触れます。

同一VLANでアクセス権限を変える

今回は、Active Directory上のアカウントが所属しているセキュリティグループに応じてアクセス制御を変えます。テストに使用するアカウントは下記のようにTestSecurityGroup01に所属しています。

f:id:ReaLiZeZNSG:20180614234927p:plain

また、セキュリティグループに所属していないTestuser02も作成しておきます。

NPSの設定

ポイントは1個だけです。新しくネットワークポリシーを作成し、Radius属性としてFilter-IdをRadiusクライアント(今回はIAP)に応答するように設定し、Filter-Idにセキュリティグループ名「TestSecurityGroup01」を指定します。

f:id:ReaLiZeZNSG:20180614235205p:plain

当然ながらアクセス制御をしたいセキュリティグループの数だけネットワークポリシーを作成する必要があります。

IAPの設定

まずアクセス制御して割り当てたいロールを作成します。今回はICMPだけ禁止して他は全て許可するロール「icmp-deny」を作成します。

f:id:ReaLiZeZNSG:20180614235438p:plain

次にこのロールを割り当てる条件を作成します。

f:id:ReaLiZeZNSG:20180614235603p:plain

NPSの設定と合わせます。Filter-IdがTestSecurityGroup01に一致する場合にロールicmp-denyを割り当てるルールです。この状態でTestuser01でPEAP認証を行い無線LANに接続するとIAPからは無線LAN端末は以下のように見えます。

f:id:ReaLiZeZNSG:20180614235916p:plain

ロールがicmp-denyになっており、Ping通信は不可だが他の通信は可というような制御がIAPで行われるようになります。IAPで行われるという部分が重要なポイントです。
尚、同じSSIDに接続してTestuser02で認証した場合はデフォルトのロールが割り当たります。

f:id:ReaLiZeZNSG:20180615004114p:plain

そもそもVLANを変える

もう1個アクセス制御の方法を記載します。今回はIAPから上位ネットワークに出ていく際に条件に応じてVLANを変える(tag VLAN)構成です。

NPSの設定

先程と同じくネットワークポリシーをいじります。今度はTonnel-Private-Group-ID属性にを追加し、割り当てたいVLAN IDを値として設定します。

f:id:ReaLiZeZNSG:20180615000850p:plain

IAPの設定

VLAN100を割り当てるロール「assign-vlan100」を作成します。

f:id:ReaLiZeZNSG:20180615001002p:plain

次にこのロールの割り当てルールを作成します。

f:id:ReaLiZeZNSG:20180615001141p:plain

無線LAN接続するとIAPからは以下のように見えます。

f:id:ReaLiZeZNSG:20180615001305p:plain

この方法だとIAPを接続する上位スイッチでtrunk設定に必要なVLANをを追加する必要があります。無線LAN端末は単にVLANに所属しているだけなのでアクセス制御はIAPの上位ネットワークで行う必要があります。ここが1個目の方法との大きな違いです。
IAP的には1個目の方法でやって欲しいんでしょうね。同一VLANだが人によって適切にアクセス権が振られるというのはコンテキストアウェアネスの一種と呼べそうでちょっとだけカッコいいです。

RadiusとLDAP(Active Directory)の話

記事タイトルと趣旨がずれるのであまり細かいことは記載しません。
今回2個目の方法でTunnel-Private-Group-IDにVLAN IDをセットする方法を紹介しました。これは慣習上このRadius属性にVLAN IDをセットすることが多いためそれを踏襲しただけであり、例えばFilter-IdにVLAN IDとして使用する100を格納してRadiusクライアントに応答するようにNPSのネットワークポリシーを作成しても問題ありません。
IAPで作成したロール割り当ての条件は単純に指定したRadius属性が特定の値だった場合に機能するだけなので、どのRadius属性が使われようと理屈では動作は同じです。つまり条件により割り当てるロールを変えるための条件となる文字列を何らかの手段で取得できれば良いわけです。

RadiusやLDAP、Authenticatorに何を使用するかで適切な方法は変わります。1個目の例のようにセキュリティグループでアクセス制御したいというケースは多いかと思います。セキュリティグループはmemberOfというLDAP(Active Directory)属性に全てのセキュリティグループが配列で格納されて返されます。
Radius認証の例になりますがセキュリティグループ単位で制御するには、Authenticatorが制御をするために必要なRadius属性を確認し、memberOf属性というLDAP(Active Directory)語をRadius属性にマッピングしてやれば良いわけです。
Authenticatorによりどの属性が必要かは製品により異なるので確認が必要です。さらに厄介な話ですが、余計なRadius属性を含めて返すと正常に動作しないケースもあります。製品が混在しこうした動作の不整合が発生する場合はRadiusクライアントで処理を分岐させるような機能が必要になります。いずれにしても十分な動作検証を行った方が良いでしょう。