このドキュメントでは、Microsoft Entra IDを介したASA AnyConnectに焦点を当てて、Security Assertion Markup Language(SAML)を設定する方法について説明します。
次の項目に関する知識があることが推奨されます。
このドキュメントの情報は、次のソフトウェアとハードウェアのバージョンに基づいています。
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されたものです。このドキュメントで使用するすべてのデバイスは、クリアな(デフォルト)設定で作業を開始しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。
SAML は、セキュリティドメイン間で認証および許可データを交換するための XML ベースのフレームワークです。ユーザー、サービスプロバイダー(SP)、アイデンティティ プロバイダー(IdP)の間に信頼の輪が作成され、ユーザーは複数のサービスに 1 回でサインインできるようになります。Microsoft Entra IDはCisco ASA VPNアプライアンスとシームレスに統合され、Cisco Secure Client AnyConnect VPNログインのセキュリティを強化します。
メタデータ:これは、IdP と SP 間のセキュアなトランザクションを保証する XML ベースのドキュメントです。IdP と SP が契約をネゴシエートできるようにします。
デバイス(IdP、SP)でサポートされるロール
デバイスは複数のロールをサポートでき、SP と IdP の両方の値が含まれている場合があります。EntityDescriptor フィールドの下には、含まれている情報がシングルサインオン IdP の場合は IDPSSODescriptor、含まれている情報がシングルサインオン SP の場合は SPSSODescriptor があります。SAML を正常に設定するには、適切なセクションから正しい値を取得する必要があるため、これは重要です。
[エンティティID(Entity ID)]:このフィールドは、SP または IdP の一意の識別子です。単一のデバイスで複数のサービスを使用することができ、それらを区別するために異なるエンティティ ID を使用できます。たとえば、ASA では、認証が必要なトンネルグループごとに異なるエンティティ ID を使用します。これらのサービスを正確に識別するために、各トンネルグループを認証する IdP には、各トンネルグループの個別のエンティティ ID エントリがあります。
ASA は複数の IdP をサポートでき、各 IdP を区別するためにそれぞれに個別のエンティティ ID を設定できます。いずれかの側が、以前に設定済みのエンティティ ID が含まれないメッセージをデバイスから受信した場合、そのデバイスはこのメッセージをドロップした可能性が高く、SAML 認証は失敗します。エンティティ ID は、entityID の横にある EntityDescriptor フィールド内にあります。
[サービスURL(Service URLs)]:これらは SP または IdP によって提供される SAML サービスの URL を定義します。IdP の場合、シングル ログアウト サービスとシングル サインオン サービスが最も一般的です。SP の場合、通常はアサーション コンシューマ サービスとシングル ログアウト サービスです。
IdP メタデータで見つかったシングル サインオン サービス URL は、SP によって認証のためにユーザーを IdP にリダイレクトするために使用されます。この値が正しく設定されていないと、IdP は SP から送信された認証要求を受信しないか、正常に処理できません。
SP メタデータで見つかったアサーション コンシューマ サービスの URL は、IdP によって、ユーザーを SP にリダイレクトし、ユーザーの認証試行に関する情報を提供するために使用されます。これが正しく設定されていないと、SP はアサーション(応答)を受信しないか、正常に処理できません。
シングル ログアウト サービス URL は、SP と IdP の両方で検出できます。これは SP からのすべての SSO サービスのログアウトを容易にするために使用され、ASA ではオプションです。IdP メタデータからの SLO サービス URL が SP で設定されている場合、ユーザーが SP でサービスからログアウトすると、SP はリクエストを IdP に送信します。IdP がユーザーをサービスから正常にログアウトさせたら、ユーザーを SP にリダイレクトし、SP のメタデータ内で見つかった SLO サービス URL を使用します。
[サービスURLのSAMLバインディング(SAML Bindings for Service URLs)]:バインドは、SP が IdP にサービスに関する情報を転送する、およびその逆のために使用する手法です。これには、HTTP リダイレクト、HTTP POST、アーティファクトが含まれます。各手法で、データを転送する方法は異なります。サービスでサポートされているバインディング手法は、そのサービスの定義内に含まれています。例:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location= SSO Service >。ASA は、アーティファクト バインディングをサポートしていません。ASA は、SAML 認証要求に対して常に HTTP リダイレクト方式を使用するため、IdP がこれを想定できるように、HTTP リダイレクトバインディングを使用する SSO サービス URL を選択することが重要です。
SP と IdP との間で送信されるメッセージの機密性と完全性を提供するために、SAML にはデータの暗号化および署名機能が含まれています。データの暗号化や署名に使用される証明書をメタデータに含めることで、受信側が SAML メッセージを検証し、意図した送信元からのものであることを確認できるようにすることができます。署名および暗号化に使用される証明書はメタデータ内にあり、それぞれ KeyDescriptor use=signing および KeyDescriptor use=encryption、次に X509Certificate です。ASA は、SAML メッセージの暗号化をサポートしていません。

ステップ1:Azure Portalにログインして、Microsoft Entra IDを選択します。

ステップ 2次の図に示すように、[エンタープライズ アプリケーション(Enterprise Applications)] を選択します。

ステップ 3 その後、次の図に示すように、[新しいアプリケーション(New Application)] を選択します。

ステップ 4Browse Microsoft Entra Galleryセクションで、検索ボックスにAnyConnectと入力し、結果パネルからCisco Secure Firewall - Secure Client(以前のAnyConnect)認証を選択し、アプリを作成します。

ステップ 5次の図に示すように、[シングルサインオン(Single Sign-on )] メニュー項目を選択します。

ステップ 6図に示すように、[SAML] を選択します。

ステップ 7次の詳細情報を使用して [セクション1(Section 1)] を編集します。
a. Identifier (Entity ID) - https://<VPN URL>/saml/sp/metadata/<TUNNEL-GROUP NAME> b. Reply URL (Assertion Consumer Service URL) - https://<VPN URL>/+CSCOE+/saml/sp/acs?tgname=<TUNNEL-GROUP NAME> Example: vpn url called asa.example.com and tunnel-group called AnyConnectVPN-1

ステップ 8[SAML署名証明書(SAML Signing Certificate)] セクションで、[ダウンロード(Download)] を選択して証明書ファイルをダウンロードし、コンピュータに保存します。

ステップ 9これは ASA 設定のために必要です。

このセクションでは、Cisco Secure Client AnyConnectアプリへのアクセスを許可するときに、Test1でAzureシングルサインオンを使用できるようにします。
ステップ 1:アプリケーションの概要ページで、Users and groups、Add user/groupの順に選択します。

ステップ 2[割り当ての追加(Add Assignment)] ダイアログで [ユーザーとグループ(Users and groups)] を選択します。
課題の追加
ステップ 3 [割り当ての追加(Add Assignment)] ダイアログで、[割り当て(Assign )] ボタンをクリックします。

ステップ 1: トラストポイントを作成し、SAML証明書をインポートします。
config t
crypto ca trustpoint AzureAD-AC-SAML revocation-check none no id-usage enrollment terminal no ca-check crypto ca authenticate AzureAD-AC-SAML -----BEGIN CERTIFICATE----- … PEM Certificate Text you downloaded goes here … -----END CERTIFICATE----- quit
ステップ 2 次のコマンドにより、SAML IdP がプロビジョニングされます。
webvpn saml idp https://xxx.windows.net/xxxxxxxxxxxxx/ - [Azure AD Identifier] url sign-in https://login.microsoftonline.com/xxxxxxxxxxxxxxxxxxxxxx/saml2 - [Login URL] url sign-out https://login.microsoftonline.com/common/wsfederation?wa=wsignout1.0 – Logout URL trustpoint idp AzureAD-AC-SAML - [IdP Trustpoint] trustpoint sp ASA-EXTERNAL-CERT - [SP Trustpoint] no force re-authentication no signature base-url https://asa.example.com
ステップ 3 VPN トンネル設定に SAML 認証を適用します。
tunnel-group AnyConnectVPN-1 webvpn-attributes saml identity-provider https://xxx.windows.net/xxxxxxxxxxxxx/ authentication saml end write memory
ステップ 1: VPN URL に接続し、[Azure ADの詳細(Azure AD details)] にログを入力します。
ステップ 2:サインイン要求を承認します。
ステップ 3:AnyConnect が接続されます。



デバッグ例:
[SAML] consume_assertion:プロバイダーの ID が #LassoServer で認識されません。#LassoServer オブジェクトでプロバイダーを登録するには、lasso_server_add_provider() または lasso_server_add_provider_from_buffer() のメソッドを使用する必要があります。
問題:一般には、ASA の webvpn 設定の saml idp [entityID] コマンドが、IdP のメタデータで見つかった IdP エンティティ ID と一致しないことを意味します。
解決策:IdP のメタデータファイルのエンティティ ID を確認し、これと一致するように saml idp [entity id] コマンドを変更します。
デバッグ例:
[SAML] NotBefore:2017-09-05T23:59:01.896Z NotOnOrAfter:2017-09-06T00:59:01.896Z timeout: 0
[SAML] consume_assertion:アサーションが期限切れまたは有効でない
問題 1. ASA の時間が IdP の時間と同期していません。
解決策 1.IdP が使用するものと同じ NTP サーバーで ASA を設定します。
問題 2. 指定された時間内ではアサーションが無効です。
解決策 2. ASA で設定されているタイムアウト値を変更します。
デバッグ例:
[Lasso] func=xmlSecOpenSSLEvpSignatureVerify:file=signatures.c:line=493:obj=rsa-sha1:subj=EVP_VerifyFinal:error=18:data do not match:signature do not match
[SAML] consumer_assertion:プロファイルがメッセージの署名を確認できない
問題:ASA が IdP によって署名されたメッセージを検証できないか、ASA で検証する署名がありません。
解決策:ASA にインストールされている IdP 署名証明書を確認して、IdP が送信した証明書と一致していることを確認します。確認できた場合は、SAML 応答に署名が含まれていることを確認してください。
デバッグ例:
[SAML] consume_assertion:アサーションの対象者が無効です
問題:IdP が誤った対象者を定義しています。
解決策:IdP の対象者の設定を修正します。これは ASA のエンティティ ID と一致している必要があります。
デバッグ例:最初の認証要求が送信された後、デバッグを受信できません。ユーザーは IdP でクレデンシャルを入力できますが、IdP は ASA にリダイレクトしません。
問題:IdP が誤ったアサーション コンシューマ サービス URL に対して設定されています。
解決策:設定のベース URL が正しいことを確認します。アサーション コンシューマ サービス URL が正しいことを確認するには、show を使用して ASA メタデータをチェックします。テストするため、参照して ASA で両方が正しい場合は IdP を調べ、URL が正しいことを確認します。
例:シングルサインオン URL が変更され、SP 証明書が変更された後も、SAML は機能せず、以前の設定を送信します。
問題:ASA に影響を与える設定変更がある場合、ASA はそのメタデータを再生成する必要があります。これは自動的には行われません。
解決策:変更した後、影響を受けるトンネルグループで saml idp [entity-id] コマンドを削除して再適用します。
ほとんどの SAML のトラブルシューティングには、SAML 設定を確認したりデバッグを実行したときに見つかる設定ミスが含まれます。debug webvpn saml 255 を使用するとほとんどの問題をトラブルシューティングできますが、このデバッグで有用な情報が得られない場合は、次のような追加のデバッグを実行できます。
debug webvpn saml 255 debug webvpn 255 debug webvpn session 255 debug webvpn request 255
| 改定 | 発行日 | コメント |
|---|---|---|
5.0 |
22-Apr-2026
|
代替テキストとフォーマットを更新。 |
4.0 |
28-Aug-2024
|
機械翻訳と書式設定を更新。 |
3.0 |
11-Aug-2023
|
PIIを削除。
SEO、代替テキスト、スタイル要件、機械翻訳、フォーマットを更新。 |
1.0 |
19-Aug-2020
|
初版 |