以前
こちらでIntune連携について概要を紹介しました。
実際にIntune連携の設定をしてみると少し課題があるので、今回はその課題の解決方法を解説します。
前提として、以下の点を覚えておいて下さい。
- ClearPassは認証時に認証ソース、認可ソースとしてEndpoint Repositoryという内部データベースを参照する
- Endpoint Repository は端末のMACアドレスを一意のキーとしてエントリーを保持している
- ClearPassはExtensionというAPIを使ってIntuneから端末情報をEndpoint Repositoryにインポートする。この時、Intuneが持っている端末のMACアドレスを使う
上記の中でIntuneが持っているMACアドレス情報が、端末が認証時に使うMACアドレスと一致しないケースがあります。
以下のケースでは、Intuneが管理しているのは、Wi-Fiの物理インタフェースではなく、Wi-Fi Direct Adapter のMACアドレスになっています。
Intuneの管理画面で端末のMACアドレス
Windows端末のMACアドレス
ClearPass の Endpoint Repository を確認すると、エントリーが2つできてしまいます。
その結果、認証時に認可ソースとしてEndpoint Repository を参照しても、正しいエントリーを参照することができません。
ClearPass Endpoint Repository
この課題は、iOSやAndroid端末のMACアドレスのランダム化（MAC Randomization）でも起こる可能性があります。
この課題を解決するために、まずClearPassの認証・認可ソース参照仕組みについて少し解説します。
ClearPass の認証・認可ソース参照の仕組み
ClearPassは、入力情報として認証リクエストを受け取ったあと、その情報を元に認証ソース、認可ソースを参照し、それらの情報を使ってポリシー演算をして結果を出力します。Endpoint Repository の参照もこの時に行ってます。
このEndpoint Repository はSQLデータベースです。
認証リクエストの中に含まれている端末のMACアドレスを使ってこのデータベースを参照しています。
実際に、Endpoint Repository の設定を確認すると、SQL文でそのことを確認できます。
Endpoint Repository の設定
IntuneのMACアドレスとWi-FiのMACアドレス不一致時の対応策この課題を解決するためには、IntuneとWi-Fi端末をマッチングさせるために、なんらかの一意な情報が必要になります。
今回はその情報として、ユーザIDを使います。
IntuneはAzure ADのアカウント情報を端末と紐づけています。
Wi-Fi接続してくる端末も、802.1X認証に同じアカウント情報を使っている必要がありますが、
こちらで解説したように、Azure AD と ClearPassを使っているのであれば、それらを連携させることで、
EAP-TLSのクライアント証明書のCommon Name がAzure ADのアカウントになっています。
ClearPass Onboardを使っていなくとも、Azure ADを使っていれば、クライアント証明書にAzure ADのアカウントを使っている方が自然です。
実際に、Intuneからインポートした端末の属性情報と、認証リクエストの中のクライント証明書のCommon Nameを確認してみましょう。
Intuneからインポートした端末の属性情報
認証リクエストに含まれているクライアント証明書の中身
上記を見てみると、"Intune User Principal Name" と "Certificate:Subject-CN" が一致していることが分かります。
この情報を使って Endpoint Repository のエントリーを参照することで、Wi-Fi認証時にIntune端末の属性情報を参照することができます。
方法は簡単で、「認証」＞「ソース」＞「Endpoint Repository」の画面で新しいフィルタを作成し、
そのSQL文の条件として、"Intune User Principal Name" = "Certificate:Subject-CN" と設定します。
実際の設定は以下の通りです。
Endpoint Repository にフィルタを追加
フィルタークエリーのSQL文
SELECT attributes->>'Intune Azure AD Device Id' AS aad_id, attributes->>'Intune Model' AS model, attributes->>'Intune OS Version' AS os_version, attributes->>'Intune Operating System' AS operating_system, attributes->>'Intune Managed Device Owner Type' AS owner_type, attributes->>'Intune User Principal Name' AS upn, attributes->>'Intune Device Name' AS device_name, attributes->>'Intune Last Updated' AS last_updated, attributes->>'Intune Compliance State' AS compliance_state, attributes->>'Intune Last Sync Date Time' AS last_sync_dt, attributes->>'Intune Device Registration State' AS dr_state FROM tips_endpoints WHERE attributes->>'Intune User Principal Name' = '%{Certificate:Subject-CN}' ORDER BY attributes->>'Intune Last Updated' DESC limit 1;
以下に一部抜粋FROM
tips_endpoints WHERE attributes->>
'Intune User Principal Name' =
'%{Certificate:Subject-CN}'Endpoint Repository は tips_endpoints というテーブル名で保存されており、
検索条件として
'Intune User Principal Name' =
'%{Certificate:Subject-CN}'としています。
あとは、エントリーの中の利用したい値を設定しています。
設定後のEndpoint Repositoryのフィルタ画面
あとは、Wi-Fi 認証のサービス設定の認可ソースとして、このEndpoint Repositoryを指定し、Role MappingやEnforcement Profile でIntuneの属性情報を使ってポリシーを設定するだけです。
設定後のWi-Fi認証時のアクセストラッカーのログを確認すると、認可ソースからIntuneの属性情報を正しく取得できていることが確認できます。
初めての方には少し難しいかもしれませんが、今回のようにClearPassの内部データベースの参照をうまくカスタマイズすることで、
ClearPassで実現できることの幅がかなり膨らみます。
全てがマニュアルにまとまっているわけでは無いので、ここでもまた活用例を紹介していこうと思います。
何かこういうことができないか、ピンポイントでご質問があれば、Airheads Communityで投稿頂ければ私も確認してみますので、
是非これからもClearPassをどんどん活用してもらえると嬉しいです！
------------------------------
Keita Shimono,
Aruba Japan SE Manager & Airheads Leader
------------------------------