セキュアファイアウォールでのAzure Entraキャプティブポータルの構成
内容
概要
このドキュメントでは、Cisco Secure Firewallのキャプティブポータル（アクティブ認証）で使用するMicrosoft Azure Entra ID(MDL)の設定について説明します。
前提条件
要件
次の項目に関する知識が推奨されます。
- Security Assertion Markup Language(SAML)
- Microsoft Azure
- Cisco Secure Firewall Management Center(FMC)
- Cisco Secure Firewall Threat Defense(FTD)
Event Hubを作成するには、Azureで利用できるStandard価格レベルが必要です。さらに、輸出規制機能を有効にしたスマートライセンスでデバイスを有効化する必要があります。
使用するコンポーネント
このドキュメントの情報は、次のソフトウェアとハードウェアのバージョンに基づくものです。
- Cisco Secure FTDバージョン10.0
- Cisco Secure FMCバージョン10.0
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、初期（デフォルト）設定の状態から起動しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。
背景説明
従来のIPベースのセキュリティアーキテクチャは、動的なハイブリッド作業環境への対応に苦慮しているため、Cisco Secure Firewall Active Authentication with SAML統合は、堅牢なアイデンティティ中心のソリューションを提供します。この構成では、一元化されたIDプロバイダーとしてMicrosoft Entra ID (Azure AD)を活用することで、管理者は静的なネットワークルールを超えて、揮発性ネットワークアドレスではなく検証済みのユーザーIDに基づいてきめ細かなアクセス制御を適用できます。この統合により、シームレスなシングルサインオン(SSO)と必須のMulti-Factor Authentication(MFA)を通じてユーザエクスペリエンスが合理化されます。また、境界のないネットワーク全体で厳格な可視性とポリシー適用を維持する統合されたセキュリティポスチャが確保されます。
図
エンドポイント、FTD、Azure Entra間のキャプティブポータル
エンドポイントとAzure Entra間のキャプティブポータル
設定
フェーズ1:FMCとDNSの初期設定
注：この実習では、クラウドで提供されるFirewall Management Center(cdFMC)を使用します。ただし、手順はオンプレミスFMCと同じです。
ステップ1:Cisco Dynamic Attributes Connector(CSDAC)を有効にします
1) Integrations > Dynamic Attributes Connectorの順に選択します。
統合の選択ダイナミック属性コネクタ
2) Disabled文字列の横にあるコントロールをクリックして、CSDACを有効にします。
Ciscoダイナミック属性コネクタを有効にする
c) CSDACの有効化が完了したら、Doneをクリックします。
Ciscoダイナミック属性コネクタのステータスを有効にする
ステップ2:FTD入力インターフェイスを表す完全修飾ドメイン名(FQDN)ネットワークオブジェクトを作成します。
1) Objects > Add Network > Add Objectの順に選択します。
新しい完全修飾ドメイン名(FQDN)ネットワークオブジェクトの作成
2)設定されているネットワークオブジェクトに完全修飾ドメイン名(FQDN)を使用して名前を付けます。 FQDNを入力し、該当するオプションボタンをクリックして、ネットワークオブジェクトをFQDNタイプとして割り当てます。[Save] をクリックします。
FQDNネットワークオブジェクト変数の設定
ステップ3:DNS Aレコードの設定
1)ここに示す例では、Windows Server 2025を使用しています。必要に応じて、特定の名前解決サーバのマニュアルを参照してください。
Windows Server DNS Aレコードの設定
注：アクティブ認証を実行するクライアントは、このDNS Aレコードを解決できる必要があります。
フェーズ2：公開キーインフラストラクチャの設定
内部認証局(CA)は、アクティブ認証の設定の公開キーインフラストラクチャ(PKI)として使用できます。Cisco FMCとFTDでは、必要なSSL代行受信と復号化 – 再署名の操作を実行するために、内部CA公開キーとペア化された秘密キーが内部CAオブジェクトとしてアップロードされている必要があります。 また、内部CAは、アクティブ認証が実行されるクライアントブラウザ内で信頼される必要があります。ブラウザが証明書を信頼していることを確認する方法については、クライアントブラウザのマニュアルを参照してください。
ステップ1：内部CA証明書をFMCにインポートする
1) Objects > PKI > Internal CAsの順に選択します。[Import CA] をクリックします。
注：内部CAは、FMC上で直接作成することもできます。
ファイアウォール管理センターへの内部証明機関のインポート
注：このドキュメントのコンテンツでは、イメージのさまざまなフィールド値をカバーする空白文字が表示されます。この空白文字は、このドキュメントの発行時に意図的に使用されています。実際の値は、設定時に環境に反映されます。
ステップ2：サービスプロバイダー証明書にCAで署名する
1)サービスプロバイダー(SP)証明書は、信頼できる認証局(CA)によって署名され、PKCS#12 (.p12)形式で返される必要があります。
注：このCAは内部署名が可能です。唯一の注意事項は、内部CAがクライアントデバイスによって信頼される必要があることです。
ステップ3:FTDへのSP証明書の導入
1) Devices > Certificatesの順に選択します。
Devices And Certificatesに移動します。
2) Add Certificatesをクリックします。
新しいデバイス証明書の追加
3)アクティブ認証を実行するドロップダウンリストからデバイスをクリックし、+アイコンをクリックして新しい証明書登録を作成します。
FTDを選択し、Add Add New Certificate Enrollmentを選択します
4) Certificate Enrollmentという名前を付け、Enrollment Typeドロップダウンリストから、PKCS12 fileを選択します。
証明書の登録の設定と種類
5) Browse PKCS12 FileをクリックしてPKCS#12 fileをインポートし、必要なパスフレーズを入力します。[Save] をクリックします。
PKCS12ファイルの参照とインポート
6)登録の詳細が正しいことを確認し、Addをクリックします。
証明書の登録の詳細の確認
7)インポートが進行中を反映します。
証明書のインポート進行中のステータス
フェーズ3: Azure構成
ステップ1:SAMLツールキット用のエンタープライズアプリケーションを作成します
1) Enterprise Applicationsを検索してクリックします。
エンタープライズアプリケーションの検索とアクセス
2) + New Applicationをクリックします。
エンタープライズアプリケーション内の新しいアプリケーションの選択
3) Microsoft Entra SAML Toolkitを検索し、そのサムネイルをクリックします。
Microsoft Entra SAML Toolkitの検索と選択
4) Microsoft Entra SAML Toolkit Enterprise ApplicationにNameを割り当て、Createをクリックします。（Microsoftからの参照：Microsoft Entra SAML Toolkit統合チュートリアルの手順を読んでください）。
Samlツールキットアプリケーションへの名前の割り当て
5) Overviewページで、SAML Toolkitエンタープライズアプリケーションに特定のユーザとグループを割り当てます。この例では、テストアカウント(captive-portal-user)はactive-auth-labグループのメンバーです。
ユーザーとグループのアプリケーションへの割り当て
6)このエンタープライズアプリケーションの設定は、後の手順で続けます。
ステップ2：エントリIDのアプリケーション登録を設定します。
1) Entra IDに戻り、左側のナビゲーションメニューからApp registrationsを選択します。All applicationsフィルタをクリックして、Enterprise Applicationに指定された名前を検索します。該当するアプリケーションをクリックします。
アプリケーションの登録とすべてのアプリケーションに移動
2) Enterprise App RegistrationでEssentials値を収集してメモします。
重要：値の上にマウスのカーソルを置くと、「クリップボードにコピー」が表示され、「概要」ページの「Essentials」の下で値を収集できます。
- 表示名
- アプリケーション（クライアント）ID
- ディレクトリ（テナント）ID
表示、アプリケーション、およびディレクトリIDの値の収集
3) Add a certificate or secretハイパーリンクをクリックします。
証明書またはシークレットハイパーリンクの追加
4) + New client secretをクリックします。
新しいクライアントシークレットの追加
5)シークレットの説明を指定し、必要に応じて有効期限を調整します。[Add] をクリックします。
クライアントシークレットの説明を入力してください
6) 秘密をコピーします。
重要：クリップボードにコピーされたシークレット値をメモします。
クライアントシークレット値のコピー
ステップ 3：アプリケーション登録のためのMicrosoft Graph API権限の設定
1)左側のナビゲーションメニューからAPI Permissionsを選択し、+Add a permissionをクリックします。
APIアクセス許可の設定
2) Microsoft Graph APIをクリックします。
Microsoft Graph APIの選択
3) Delegated User.Read権限を付与し、Add permissionsをクリックします。
委任されたユーザーに読み取りアクセス許可を付与する
4)アプリケーションにUser.Read.All権限を付与します（チェックボックスをオンにします）。
アプリケーションに読み取り権限を付与
5)Group.Read.Allチェックボックスを検索してチェックし、グループに読み取り権限も付与します。Add permissionsをクリックします。
APIアクセス許可の保存
6)設定された権限が一致していることを確認し、それらに管理者の同意を与えます。
アクセス許可に対する管理者の同意を許可する
7)管理者の同意が付与されると、出力が表示されます。
許可された管理上の同意の出力
ステップ4：イベントハブ(EH)名前空間を構成します
1) Event Hubsを検索してクリックします。
検索イベントハブの構成
2)新しいEH名前空間を作成します。
イベントハブ名前空間の作成
3) EH名前空間を構成します。
注:Standard以上の価格レベルを選択する必要があります。Basic価格レベルでは、レルムの使用が禁止されます。
Event Hubの詳細設定と特定のニーズへの適用性の詳細な評価については、Azure Event Hubドキュメントを参照してください。
Review + Createをクリックします。
イベントハブの名前空間の設定を構成する
4)検証が成功したら、Createをクリックします。
イベントハブ名前空間の展開の作成
5)導入が完了したことを確認し、Go to resourceをクリックします。
イベントハブ名前空間リソースに移動
ステップ5：イベントハブの名前空間で共有アクセスポリシーを選択または作成する
1)左側のナビゲーションメニューから、Settings > Shared access policiesの順に選択します。
共有アクセスポリシーに移動
2) + Addをクリックして、新しいポリシー名を入力し、Manageチェックボックスにチェックマークを付けます。Add SAS Policyメニューパネルの下部にあるCreateをクリックします。
新しい共有アクセスポリシーの追加
共有アクセスポリシーの作成
ステップ6:EH名前空間から共有アクセスシグニチャ(SAS)情報を収集してメモする
1)新しい共有アクセスポリシーをクリックします。右側のサイドパネルにEH SASポリシーが表示されます。
プライマリ接続文字列のコピー
重要：プライマリ接続文字列をコピーしてメモします。
ステップ7：イベントハブネームスペース内にイベントハブインスタンスを作成する
1) Namespaceメニューから、Entities > Event Hubsの順に選択します。+ Event Hubをクリックして、新しいEHインスタンスを作成します。
新しいイベントハブインスタンスの作成
2)新しいEHインスタンスに名前を割り当て、確認+作成をクリックします。
イベントハブインスタンスへの名前の割り当て
3)検証が成功したら、CreateをクリックしてEvent Hubインスタンスをプロビジョニングします。
Provision Event Hubインスタンス
重要:Event Hubのインスタンス名をコピーしてメモします。
ステップ8：イベントハブネームスペース内にイベントハブインスタンスコンシューマグループを作成します
1)前のステップで設定した新しいEHインスタンスをクリックします。
Event Hubインスタンス構成へのアクセス
2) EHインスタンスから、Entities > Consumer groupsの順に選択し、新しいConsumer groupを作成します。
コンシューマグループの作成
3) コンシューマ・グループに名前を付けて、作成をクリックします。
コンシューマ・グループへの名前の割り当て
重要:Event Hubインスタンスのコンシューマ・グループ名をコピーしてメモします。
ステップ9：収集された値の確認
1)この時点では、前の手順の値に注意する必要があります。値が記録されていない場合は、収集された該当する手順を参照してください。
- フェーズ3ステップ2：アプリケーション登録（このプロセス用に作成されたエンタープライズアプリケーションの、収集された表示名で参照）
- ステップ2、サブステップ2
- 表示名
- アプリケーション（クライアント）ID
- ディレクトリ（テナント）ID
- ステップ2、サブステップ6
- クライアントシークレット
- ステップ2、サブステップ2
- フェーズ3ステップ6:Event Hub
- ステップ6、サブステップ1
- EH名前空間
- プライマリ接続文字列
- EH名前空間
- ステップ7、サブステップ3
- EHインスタンス(Event Hub)名
- ステップ8、サブステップ3
- EHコンシューマグループ名
- ステップ6、サブステップ1
ステップ10：イベントハブへのエントリID監査ログストリーミングを設定します
1) Entra IDテナント設定に戻ります。
IDテナント設定の検索とエントリへの移動
2)左側のメニューから、Monitoring > Diagnostic Settingsの順に選択します。
診断設定の監視
3) Diagnostic settings > Generalの順に選択し、+Add diagnostic settingをクリックします。
新しい診断設定の追加
4)必要な名前を診断設定に割り当て、ログを記録するにはAuditLogsチェックボックスにチェックマークを入れ、さらにStream to an event hubチェックボックスにチェックマークを入れます。上記の設定でメモした値を参照し、完了したらSaveをクリックします。
監査ログをイベントハブにストリーミング
フェーズ4: AzureとFMC/FTDのアクティブ認証構成を統合する
手順1: FMCウィザードを使用してAzure SAML/Entra IDレルムを構成する
1) FMC内で、Integrations > Identity > Realmsの順に選択します。
アイデンティティ・レルムの構成
2) Add Realmドロップダウンリストをクリックし、SAML - Azure ADを選択します。
SAML Azure ADレルムの追加
3) Azureレルムの用途を説明するために名前と説明を割り当て、構成の種類のドロップダウンリストからAzure ADを使用してパッシブに認証するか、Azure ADを使用してキャプティブポータルを使用するを選択してください。[next] をクリックします。
Azure ADレルム設定の構成
4)ベースURLとして、以前に設定したFQDNオブジェクトを選択します。次に示す文字列フォーマットでエンティティIDを入力します。
https://<fqdn-base-url>/<uniqueSuffix>
- SAMLエンティティIDサフィックス（次の構成例では緑色の下線）を設定する場合は、サフィックスが環境内の他のSSO実装間で一意であることを確認してください。この値は、Azure SAML構成とも一致している必要があります。ベースURLは設定全体を通じて同じままです。
- Assertion Consumer Services(ACS)URLは自動的に入力され、変更できません。
- FMCの前述のワークフローステップのDevices > Certificatesの下に登録されているService Provider (SP) Certificateを選択します。
- これらの値を入力したら、Download Service Provider Metadataをクリックして設定プロセスを簡単にし、予期される値がAzureに書き込まれていることを確認します。
ベースURLとエンティティIDの設定、およびSAMLメタデータのダウンロード
5) Nextをクリックして、レルム設定のシーケンス3に移動します。
手順2: FMCで構成されたSAML SPメタデータをAzure Enterpriseアプリケーションに実装する
1) Azureに戻り、Enter ID > Manage > Enterprise Applicationsの順に選択します。以前に作成したMicrosoft Entry SAML Toolkitエンタープライズアプリケーションのインスタンスを検索します。
Microsoft Entra SAMLツールキットアプリケーションの検索
2)サイドのナビゲーションメニューから、管理>シングルサインオンを選択します。
シングルサインオン構成の管理
3) SAMLシングルサインオン(SSO)モードをクリックします。
SAMLシングルサインオンモードの選択
4) Upload metadata fileをクリックし、青色のフォルダアイコンをクリックして、ローカルファイルシステムを参照し、FMCからダウンロードしたSAMLメタデータファイルを探します。
ファイアウォール管理センターからのメタデータファイルのアップロード
5)アップロードが完了したら、Addをクリックします。
SAML構成アプリケーションの追加
6)基本SAML設定のサイドパネルが表示され、自動的にアップロードされて適用されたFMC生成のSPメタデータXMLファイルから、識別子（エンティティID）やACS URLなどの値が抽出されます。ただし、サインオンURLは入力されないため、保存する前に入力する必要があります。
基本的なSAML構成の抽出
7)表示されたサインオンURLパターンを使用し、値をコピーアンドペーストして、完了したら上部のSaveをクリックします。
サインオンURL構成エントリ
フェデレーションメタデータXMLファイルのエクスポート
手順3: FMCウィザードを使用してAzure SAML/Entra IDレルムを構成する（続き）
1) FMCに戻ります。シーケンス3、SAML Identity Provider (IdP) Metadataの下で、AzureからダウンロードしたエクスポートしたフェデレーションメタデータXMLファイルをFMCにアップロードし、必要な値を自動入力します。
フェデレーションメタデータXMLファイルのアップロード
2)アップロードされると、次に示すように値が入力されます。
自動入力されたSAML IDプロバイダー値
注：出力の一部を図に示します。
3)実装プロセス全体で収集した値を、次の時点までに入力します。
- アプリの登録
- アプリケーション（クライアント）ID
- クライアントシークレット
- ディレクトリ（テナント）ID
- イベントハブ
- EH名前空間ホスト名
- EH名前空間のプライマリ接続文字列
- EHインスタンス（イベントハブ）名
- EHコンシューマグループ名
- EH名前空間ホスト名
アプリケーションおよびイベント・ハブ情報の入力
入力したら、Testをクリックして接続を確認し、提供された情報でAzureに到達できることを確認します。
注：該当する場合は、除外/含めるユーザグループとエントリ設定が一致していることを確認してください
4)ウィザードの最後の手順では、SAMLキャプティブポータルユーザのタイムアウトを設定できます。デフォルトは 1440 分です。
キャプティブポータルタイムアウトの設定
5) Nextをクリックして続行します。
Azure ADレルムの構成を進める
6)ウィザードは、実装された設定の概要を示します。 入力した値を検証して確認したら、要約の最後にあるSaveをクリックします。
レルム構成のサマリーの保存ボタン
ステップ4：ダウンロードしたユーザの確認
1) Azure Entraからユーザーをダウンロードできることを確認します。これには、Integrations > Identity > Realms ワークフローでDownload Nowボタンをクリックします。
Azure ADからのユーザーのダウンロード
2)ダイアログプロンプトに対して、Yesをクリックします。
Azure ADからのユーザーのダウンロードの確認
3)ダウンロードタスクで1人のユーザと1つのグループがダウンロードされます。これはNotifications > Tasksで確認できます。
Azure ADからユーザーをダウンロードするための通知エントリ
フェーズ5:FMCでのポリシーの設定
ステップ1：復号ポリシーの設定
1) FMCで、Policies > Security Policies > Decryptionの順に選択します。
復号化ポリシーに移動
2) Create Newドロップダウンリストをクリックして、Decryption Policy (Rule-Based)を選択します。
新しいルールベースの暗号化解除ポリシーの作成
3)新しいルールベースの復号化ポリシーに名前を割り当て、必要に応じて説明を割り当て（必要な場合）、発信接続（ユーザ保護）タブオプションをクリックして、キャプティブポータル認証（アクティブ認証）に必要な復号化 – 再署名機能を実装します。
アウトバウンド接続ポリシーの実装の詳細
4)同じダイアログ内の該当するドロップダウンリストから、以前適用した内部CAを選択します。[next] をクリックします。
5)必要に応じてオプションをカスタマイズします。
復号ポリシーオプションのカスタマイズ
6)この例では、必要なPolicy Detailsを除いて、デフォルトが使用されます。Create Policyをクリックして、設定ウィザードを完了します。
最終的な復号化ポリシーの作成
ステップ2：復号ポリシールールの設定
1)ルールベースの復号ポリシーのデフォルトレイアウトを次に示します。ルール3（非復号可能なドメイン名の事前に割り当てられたリストを参照）やルール6（非復号可能としてタグ付けされたアプリケーションを参照）などのデフォルトの有効なルールに一致しないトラフィックは、ルール7の下のDecrypt - Resignアクションの対象となります。これらのデフォルトは、デフォルトアクションとともに、必要に応じて変更できます。デフォルトでは、他のルールと一致しないトラフィックはDo Not Decryptとして設定されます。
Azure Authentication Serviceのトラフィックは検査のために暗号化を解除してはならず、専用のルールが作成されます。+ルールの追加をクリックして開始します。
規則を追加し、既定の規則に基づく復号化レイアウトを表示する
2)新しい復号ポリシールールエントリに名前を割り当て、ActionドロップダウンリストからDo not decryptを選択し、ルールを最も具体的でないルールに配置します。送信元/宛先ゾーンも、ルールをさらに絞り込むために実装されます。
Do Not Decryptルールの設定
3)ルールを追加する前に、アプリケーションタブをクリックし、Azure Authentication Serviceアプリケーションを検索してクリックします。 Add to Ruleをクリックし、次にAddをクリックする。
Azure認証サービスアプリケーションルールの追加
4) Saveをクリックします。
復号化ポリシーの保存
手順3：アイデンティティポリシーの作成
1) Policies > Security Policies > Identityの順に選択して、アイデンティティポリシーを作成します。
アイデンティティポリシーの作成
2)新しいアイデンティティポリシーを作成し、Add a new policyをクリックします。
新しいアイデンティティポリシー設定の追加
3)新しいアイデンティティポリシーに名前と、必要に応じて説明を割り当てます。[Save] をクリックします。
新しいアイデンティティポリシーの命名
ステップ4：アイデンティティポリシールールの設定
1)+ルールの追加をクリックして、新しいルールを追加します。
新しいアイデンティティポリシールールの追加
2)新しいルールに名前を付け、ActionドロップダウンリストからActive Authenticationを選択して、アクティブ認証を実行するためにルールに一致する必要がある特定のゾーン/ネットワークを絞り込みます。
アクティブ認証ルールの設定の構成
3) Addをクリックする前に、Rule EditorでRealm and Settingsタブをクリックします。前のステップで設定したレルムが認証レルムとして選択されていることを確認し、Addをクリックします。
アイデンティティルールのレルムと設定の構成
4)ルールが追加され、設定されます。[Save] をクリックします。
アイデンティティポリシールール設定の保存
ステップ5：アクセスコントロールポリシーの設定
1) Policies > Security Policies > Access Controlの順に選択し、FTDが割り当てられているAccess Control Policyをクリックします。
アクセスコントロールポリシーの設定
2)前の手順で設定した復号化ポリシーがアクセスコントロールポリシーに適用されていることを確認します。
アクセス制御への復号化ポリシーの適用
3)前の手順で設定したアイデンティティポリシーがアクセスコントロールポリシーにも適用されていることを確認します。ポリシーの変更を保存します。
アクセスコントロールへのアイデンティティポリシーの適用
4)アクティブ認証が成功した後に、クライアントのデータプレーントラフィックがセキュアファイアウォールを通過することを許可するルールが存在することを確認します。次の例では、ラボ環境に基づき、より幅広いルールセットを使用しています。
ユーザデータプレーントラフィックルールセット
ステップ6:Cisco Secure Firewallデバイスへの設定の導入
デプロイが完了すると、トラフィックを送信するクライアントは、Azure Entraでアクティブ認証を実行するようにMicrosoftサインインWebページで求められます。
ここで説明するプロセスの詳細については、「アクティブ認証用のMicrosoft Azure AD (SAML)レルムの作成（キャプティブポータル） – 章： FMC Device Config Guide 10.xのレルム」を参照してください。
確認
このセクションでは、設定が正常に動作していることを確認します。
GUI
FMCでユーザセッションとアクティビティを検証します。
- Integrations > Users > Active Sessionsの順に選択します。
FMCアクティブセッションの出力
- Integrations > Users > User Activityの順に選択します。
FMCユーザアクティビティ出力
Azureで、Microsoft Entra Admin Center:
- エンタープライズアプリケーションをフィルタリングし、該当するアプリケーションを検索またはクリックします。
Azure Entra Admin Center Enterprise Appsのナビゲーション
- Activity > Sign-in logsの順に選択します。
Azure Enterpriseアプリケーションサインインアクティビティログ
CLI
- FTD CLIでは、SAMLおよびキャプティブポータルの応答に関する統計情報を確認できます。
> debug menu captive-portal 6
SAML passed requests captive-portal 14
SAML failed requests captive-portal 0
SAML passed responses captive-portal 4
SAML failed responses captive-portal 0
Total captive-portal bee-client messages processed 4
Total captive-portal bee-client messages successful 4
Total captive-portal bee-client messages failed 0
Total bee-client reconnects 0
トラブルシューティング
キャプティブポータルのデバッグ
- system support captive-portal-debugコマンドをFTDで使用できます。次の出力では、デバッグを有効にする方法を示しています。また、キャプティブポータルのフローを理解しやすいように、出力の主要なセグメントも示しています。
> system support captive-portal-debug
Enable firewall-debug too? [n]: y
Enable identity-debug too? [n]: y
Please specify an IP protocol: tcp
Please specify a client IP address: 192.168.20.200
Please specify a client port:
Please specify a server IP address:
Please specify a server port:
Enable daq-debug too? (WARNING: current packet debug configs and logs will be overwritten) [n]:
Monitoring captive_portal and firewall and identity debug messages
!--- Baseline output pending user Captive Portal authentication
...
192.168.20.200 53650 -> 198.51.100.1 443 6 AS=0 ID=1 GR=1-1 match rule order 1, id 1 action Captive portal, active auth realm id 2
192.168.20.200 53650 -> 198.51.100.1 443 6 AS=0 ID=1 GR=1-1 didn't find active binding, initiating captive portal
192.168.20.200 53650 -> 198.51.100.1 443 6 AS=0 ID=1 GR=1-1 captive portal authentication started
192.168.20.200 53650 -> 198.51.100.1 443 6 AS=0 ID=1 GR=1-1 defer trust until captive portal redirect is sent.
192.168.20.200 53650 -> 198.51.100.1 443 6 AS=0 ID=1 GR=1-1 Current state = S_INIT, Event = EVT_CP_RULE, Next state = S_PENDING_USER
...
!--- Captive Portal probe intercepted and redirected to SAML IdP (generate_204)
...
192.168.20.200 53659 -> 198.51.100.2 80 6 AS=0 ID=1 GR=1-1 AppID session with service_id: 676, url: http://browserportal.example.com
192.168.20.200 53659 -> 198.51.100.2 80 6 AS=0 ID=1 GR=1-1 Current state = S_PENDING_USER, Event = EVT_APPID_HTTP_HEADERS, Next state = S_REDIRECTING
192.168.20.200 53659 -> 198.51.100.2 80 6 AS=0 ID=1 GR=1-1 app event changes: service, client, host, url, user-agent, client-info
192.168.20.200 53659 -> 198.51.100.2 80 6 AS=0 ID=1 GR=1-1 using ipv4 address 192.168.20.1 for redirect
192.168.20.200 53659 -> 198.51.100.2 80 6 AS=0 ID=1 GR=1-1 encrypted redirect url: https://ftd-inside.example.com/+CSCOE+/saml/sp/login?tgname=azure-entra-saml&s=xxxx=http%3A%2F%2Fbrowserportal.example.com%2Fgenerate_204
192.168.20.200 53659 -> 198.51.100.2 80 6 AS=0 ID=1 GR=1-1 Current state = S_REDIRECTING, Event = EVT_FINALIZE, Next state = S_REDIRECTED
...
!--- SAML authentication completes, identity binding created
...
192.168.20.200 54023 -> 198.51.100.2 80 6 AS=0 ID=2 GR=1-1 looked for user_id with realm_id 2 auth_type 2, returning realm_id 2 auth_type 8 user_id 0
192.168.20.200 54023 -> 198.51.100.280 6 AS=0 ID=2 GR=1-1 found active binding for user_id 0 usernames azure-entra-saml\captive-portal-user@onmicrosoft.example.com in realm 2
192.168.20.200 54023 -> 198.51.100.2 80 6 AS=0 ID=2 GR=1-1 IdentityFlowSetupEventHandler Retrieved identity info: user_id 0, username azure-entra-saml\captive-portal-user@onmicrosoft.example.com, authRealmId 2, src sgt 0, src sgt type unknown, dst sgt 0, dst sgt type unknown, deviceType 0, locationIP ::
192.168.20.200 54023 -> 198.51.100.2 80 6 AS=0 ID=2 GR=1-1 New firewall session
192.168.20.200 54023 -> 198.51.100.2 80 6 AS=0 ID=2 GR=1-1 allow action
...
!--- Authenticated binding persists across subsequent, unrelated destinations (no further redirects)
...
192.168.20.200 54024 -> 198.51.100.2 80 6 AS=0 ID=2 GR=1-1 found active binding for user_id 0 usernames azure-entra-saml\captive-portal-user@onmicrosoft.example.com in realm 2
192.168.20.200 54025 -> 198.51.100.1 443 6 AS=0 ID=1 GR=1-1 found active binding for user_id 0 usernames azure-entra-saml\captive-portal-user@onmicrosoft.example.com in realm 2
192.168.20.200 54026 -> 198.51.100.2 80 6 AS=0 ID=1 GR=1-1 found active binding for user_id 0 usernames azure-entra-saml\captive-portal-user@onmicrosoft.example.com in realm 2
192.168.20.200 54027 -> 198.51.100.3 443 6 AS=0 ID=1 GR=1-1 found active binding for user_id 0 usernames azure-entra-saml\captive-portal-user@onmicrosoft.example.com in realm 2
192.168.20.200 19935 -> 198.51.100.4 443 6 AS=0 ID=1 GR=1-1 found active binding for user_id 0 usernames azure-entra-saml\captive-portal-user@onmicrosoft.example.com in realm 2
...ユーザIDダンプ
- FTDで現在のユーザID状態データのスナップショットを取得するには、FTD CLIでsystem support firewall-engine-dump-user-identity-dataコマンドを実行します。
> system support firewall-engine-dump-user-identity-data
Successfully commanded snort.
>
- expertモードのCLIで、FTDデバイスのローカル管理者クレデンシャルでログインし、/ngfw/var/sf/user_enforcement/user_identity.dumpにあるダンプされたファイルの内容を表示します。
> expert
admin@ftd:~$ sudo su
Password:
root@ftd:/home/admin#
root@ftd:/home/admin# ls -lah /ngfw/var/sf/user_enforcement/user_identity.dump
-rw------- 1 root root 5.6K Oct 7 07:51 /ngfw/var/sf/user_enforcement/user_identity.dump
root@ftd:/home/admin#
root@ftd:/home/admin# less /ngfw/var/sf/user_enforcement/user_identity.dump
...
----------------
IP:USER
----------------
!--- Host IP is aligned with the user authenticated via Captive Portal/Active Authentication
----------------
Host ::ffff:192.168.20.200
----------------
::ffff:192.168.20.200:0 realm 2 type 8, username azure-entra-saml\captive-portal-user@onmicrosoft.example.com
::ffff:192.168.20.200: SXP initialized 0 sgt 0
ABP values: None
-------------------
SXP MAPPING:
-------------------
...
考えられる問題
キャプティブポータルの不明な認証局
問題：認証が試行されると、クライアントブラウザが「unknown issuer」エラーを返します。
原因：内部の証明機関がクライアントブラウザー内で信頼されていない。
解決策：ブラウザ内でCAが信頼できることを確認します。次の例は、内部CA証明書が信頼されていることを示しています。
キャプティブポータル「サーバが見つかりません
問題：クライアントブラウザがキャプティブポータルをロードしようとすると、ベースURLに到達しようとしているときに、ベースURLに「Server Not Found」が返されます または類似しています。
考えられる原因:DNS到達可能性またはDNSの設定ミス。
解決策：クライアントに、Aレコードを解決するように設定された適切なDNSサーバがあることを確認します。サーバにFQDNにマッピングされたAレコードがあること、およびサーバが到達可能で応答できることを確認します。
関連情報
- アクティブ認証用のMicrosoft Azure AD (SAML)レルムの作成（キャプティブポータル） - FMCデバイス構成ガイド10.x
- Azure Event Hubドキュメント
- テクニカル サポートとドキュメント – Cisco Systems
更新履歴
| 改定 | 発行日 | コメント |
|---|---|---|
1.0 |
15-Oct-2026
|
初版 |
フィードバック