- ライター：田中 政満
- 入社以来無線LANの製品担当SEとして製品や技術の調査、検証評価、及び、提案や導入を支援する業務に従事。
現在はキャンパスセキュリティや自動化に力を入れるなど、エンタープライズSDNのエンジニアとして邁進中。
目次
はじめに
従来、Cisco社の認証サーバであるIdentity Service Engine(ISE)を用いてAzureADのアカウントを利用したネットワーク認証(802.1X/EAP)を行おうとした場合、EAP-TTLS(インナーメソッド：PAP)を用いた認証になることから、これまでよく利用されていたEAP-PEAPや、EAP-TLSと比べて利用しにくい問題がありました。
Windows10や最新のAndroidなどではEAP-TTLS(PAP)をサポートするようになったため多少は利用ハードルも下がりましたが、いまだ一部のデバイスでは利用に条件が必要だったりと、EAP-PEAP/EAP-TLSのようにデバイスを問わず利用できる、とはなっていません。
しかしながら、ISE最新バージョンであるVer3.2において、EAP-TLSを利用した認証においてもAzureADのユーザ属性値を用いた認証/認可コントロールが可能な機能が実装されたため、本エントリではその機能について確認していきたいと思います。
以前に検証した内容(EAP-TTLS w/PAPによるAzureADアカウントでの802.1X)：
https://www.netone.co.jp/media/detail/20211006-1/
構成図、認証の流れ
以下の図1に検証環境の構成図を示します。今回も前回とほぼ同様の接続構成となり、証明書発行を担うCAが追加されている点が変更点となります。
図1．構成図
認証の流れは以下の図2の通りとなます。以前のEAP-TTLSと異なり、証明書ベースの認証のため、認証処理そのものはISEとサプリカントの間で完結します。
その後認可処理の過程において、AzureADに対して問い合わせが行われ、認証したユーザのグループ名や各属性値の参照が行われます。
図2．認証の流れ
パスワードベースの認証に加え、証明書認証においてもAzureADに保存されている属性情報が利用できるようになった
EAP-TLSが認証に利用できることにより、これまでEAP-TTLSがネックとなっていた環境にも利用できるようになりました。また証明書ベースの認証であるEAP-TLSを利用することにより、ユーザがパスワードの入力をする手間が省略されます。これは特にモバイルデバイスや、ネットワークの切断/再認証回数が多い環境においてはユーザの利便性の向上をもたらすことになります。
またパスワードベースの認証では避けて通れない「辞書攻撃についての耐性」についても、証明書ベースの認証であれば考慮から外すことができます。
一方、証明書認証となることのデメリットとしては、一番大きいものとして「PKI環境の運用負荷」が挙げられます。
既にプライベート認証局をベースとしたPKI環境を自社内で運用できていれば追加の考慮は必要ありませんが、導入に合わせて認証局まで含めて運用を行う場合、導入前より大きく運用負荷が上がる可能性があります。
なお、ISE3.2のEAP-TLS認証においてAzureADの値を参照する今回の機能を利用する場合、証明書のCommon Name(CN)がAzureADに存在するユーザのUser Principal Name(UPN)と一致させる必要があるため、こちらの点についても必要によっては発行するユーザ証明書のテンプレートの変更などの対応が必要となります。
まとめ
ISEの機能拡張により、ディレクトリサーバをAzure ADに移行した場合においても比較的利用しやすいEAP-TLSを利用することが可能となり導入のハードルはいくぶん下がったかと思います。
EAP-TLSを利用することによりスマートデバイスなどにも使いやすくなる一方、PKI環境の運用については注意点が必要な場合もあり、利用する際には従来と同様に、PKI環境の運用負荷まで考慮して慎重に検討を行ってからの導入を行うことをおすすめします。
※本記事の内容は執筆者個人の見解であり、所属する組織の見解を代表するものではありません。
