Microsoft Azure MFA で SAML を利用した ASA AnyConnect VPN の設定

はじめに

このドキュメントでは、Microsoft Azure MFAを介したASA AnyConnectに重点を置いてSecurity Assertion Markup Language(SAML)を設定する方法について説明します。 

前提条件

要件

次の項目に関する知識があることが推奨されます。

• 適応型セキュリティアプライアンス(ASA)でのRA VPN設定に関する基本的な知識。
• SAMLおよびMicrosoft Azureの基礎知識。
• AnyConnectライセンス対応（APEXまたはVPNのみ）。

使用するコンポーネント

このドキュメントの情報は、次のソフトウェアとハードウェアのバージョンに基づいています。

• Microsoft Azure ADサブスクリプション。
• Cisco ASA 9.7以降およびAnyconnect 4.6以降
• AnyConnect VPNプロファイルの動作

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、クリアな（デフォルト）設定で作業を開始しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。

背景説明

SAMLは、セキュリティドメイン間で認証および許可データを交換するためのXMLベースのフレームワークです。これにより、ユーザ、サービスプロバイダー(SP)、およびユーザが複数のサービスに対して一度にサインインできるアイデンティティプロバイダー(IdP)の間に信頼の輪が作られます。Microsoft Azure MFAはCisco ASA VPNアプライアンスとシームレスに統合され、Cisco AnyConnect VPNログインのセキュリティを強化します。

SAMLコンポーネント

メタデータ：IdPとSP間の安全なトランザクションを保証するXMLベースのドキュメントです。IdPとSPが契約を交渉できる

デバイスでサポートされるロール(IdP、SP)

デバイスは複数のロールをサポートでき、SPとIdPの両方の値を含むことができます。EntityDescriptorフィールドの下には、IDPSSODescriptor（含まれている情報がシングルサインオンIdP用の場合）またはSPSSODescriptor（含まれている情報がシングルサインオンSP用の場合）が表示されます。SAMLを正常に設定するには、適切なセクションから正しい値を取得する必要があるため、これは重要です。

エンティティID：このフィールドは、SPまたはIdPの一意の識別子です。1つのデバイスに複数のサービスを設定し、異なるエンティティIDを使用してそれらを区別できます。たとえば、認証が必要なトンネルグループごとにASAのエンティティIDが異なる場合です。各トンネルグループを認証するIdPには、これらのサービスを正確に識別するために、各トンネルグループに対して個別のエンティティIDエントリがあります。

ASAは複数のIdPをサポートでき、IdPごとに個別のエンティティIDを割り当ててそれらを区別します。いずれかの側が、以前に設定されたエンティティIDを含まないデバイスからメッセージを受信した場合、デバイスによってこのメッセージがドロップされ、SAML認証が失敗する可能性があります。エンティティIDは、entityIDの横のEntityDescriptorフィールド内にあります。

サービスURL:SPまたはIdPによって提供されるSAMLサービスへのURLを定義します。IdPsの場合、これは通常、シングルログアウトサービスとシングルサインオンサービスです。SPの場合、これは通常、アサーションコンシューマサービスとシングルログアウトサービスです。

SPは、IdPメタデータ内のシングル・サインオン・サービスURLを使用して、認証のためにユーザーを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バインディング：バインディングは、SPが情報をIdPに転送したり、サービスをIdPに転送したりするために使用する方法です。これには、HTTPリダイレクト、HTTP POST、アーティファクトが含まれます。データを転送する方法は、方法ごとに異なります。サービスによってサポートされるバインド方式は、そのサービスの定義に含まれます。例：SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location= SSO Service >ASAはアーティファクトバインドをサポートしていません。ASAはSAML認証要求に常にHTTPリダイレクト方式を使用するため、HTTPリダイレクトバインディングを使用するSSOサービスURLを選択して、IdPがこれを予期するようにすることが重要です。

署名および暗号化操作の証明書

SPとIdPの間で送信されるメッセージの機密性と整合性を確保するために、SAMLではデータの暗号化と署名が可能です。データの暗号化や署名に使用する証明書をメタデータに含めることで、受信側はSAMLメッセージを検証し、そのメッセージが想定される送信元から送信されたものであることを確認できます。署名と暗号化に使用される証明書は、メタデータ内のKeyDescriptor use=signingおよびKeyDescriptor use=encryptionの下にあり、それぞれX509Certificateの下にあります。ASAはSAMLメッセージの暗号化をサポートしていません。

ネットワーク図

設定

Microsoft App GalleryからのCisco AnyConnectの追加

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

ステップ 2：次の図に示すように、Enterprise Applicationsの順に選択します。 

ステップ 3： ここで、次の図に示すようにNew Applicationを選択します。

ステップ 4：Add from the galleryセクションで、検索ボックスにAnyConnectと入力し、結果パネルからCisco AnyConnectを選択して、アプリケーションを追加します。 

ステップ 5：次の図に示すように、シングルサインオンメニュー項目を選択します。 

手順 6：図に示すように、SAMLを選択します。

手順 7：次の詳細を使用してセクション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 Signing Certificateセクションで、Downloadを選択して証明書ファイルをダウンロードし、コンピュータに保存します。 

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

• Azure AD Identifier – これはVPN構成のsaml idpです。
• ログインURL：これはURLサインインです。
• Logout URL：これはURLのサインアウトです。

Azure ADユーザーのアプリへの割り当て

このセクションでは、Cisco AnyConnectアプリへのアクセス権を付与する際に、Test1でAzureシングルサインオンの使用が有効になります。 

ステップ 1：アプリの概要ページで、Users and groups、Add userの順に選択します。 

ステップ 2：割り当ての追加ダイアログでユーザとグループを選択します。 

ステップ 3： Add Assignmentダイアログで、Assignボタンをクリックします。 

CLIによるSAML用のASAの設定

ステップ 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

 

注:IdP設定を変更した場合は、トンネルグループからsaml identity-provider設定を削除し、再度適用して変更を有効にする必要があります。 

確認

SAML認証によるAnyConnectのテスト

ステップ 1： VPN URLに接続し、Azure ADの詳細にログインします。

ステップ2：サインイン要求を承認します。

ステップ3:AnyConnectが接続されます。

一般的な問題

エンティティIDの不一致

デバッグ例： 

 [SAML] consume_assertion：プロバイダーの識別子が不明#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タイムアウト： 0 

 [SAML] consume_assertion：アサーションが期限切れか、無効です 

問題 1. ASA時刻がIdPの時刻と同期されていません。

解決策 1.IdPで使用されるのと同じNTPサーバでASAを設定します。

問題 2. アサーションは指定された時間の間は無効です。

解決策 2. ASAで設定されているタイムアウト値を変更します。

  

誤ったIdP署名証明書が使用されています

デバッグ例： 

[ラッソ] func=xmlSecOpenSSLEvpSignatureVerify:file=signatures.c:line=493:obj=rsa-sha1:subj=EVP_VerifyFinal:error=18:data do not match:signature do not match 

[SAML] consume_assertion：プロファイルはメッセージの署名を検証できません 

問題：ASAがIdPによって署名されたメッセージを確認できないか、確認するASAの署名がありません。 

解決策:ASAにインストールされているIdP署名証明書を調べ、IdPによって送信された証明書と一致することを確認します。これが確認された場合、署名がSAML応答に含まれていることを確認します。 

  

無効なアサーションオーディエンス

デバッグ例： 

[SAML] consume_assertion：アサーションオーディエンスが無効です 

問題：IdPが正しくない対象者を定義している。

解決方法： IdPの対象ユーザー構成を修正します。ASAのエンティティIDと一致している必要があります。 

  

アサーションコンシューマサービスのURLが正しくありません

デバッグ例：初期認証要求の送信後にデバッグを受信できない。ユーザはIdPでクレデンシャルを入力できますが、IdPはASAにリダイレクトしません。 

問題：アサーションコンシューマサービスのURLに対してIdPが正しく設定されていません。 

解決方法：構成のベースURLを確認し、正しいことを確認してください。showを使用してASAメタデータをチェックし、Assertion Consumer Service(ASSUMER)URLが正しいことを確認します。これをテストするには、これを参照します。ASA上の両方が正しい場合は、IdPをチェックしてURLが正しいことを確認します。

  

SAML設定の変更が有効にならない

例：シングルサインオンURLの変更または変更後、SP証明書、SAMLはまだ機能せず、以前の設定を送信します。 

問題：設定が変更されて影響を受けた場合、ASAはメタデータを再生成する必要があります。これは自動的には行われません。 

解決策：変更が行われた後、影響を受けるtunnel-groupで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 

関連情報

• アプリケーションプロキシを使用するオンプレミスアプリケーション向けSAMLシングルサインオン