Configurazione di ASA AnyConnect VPN con l'autenticazione a più fattori (MFA) di Microsoft Azure tramite SAML

Introduzione

In questo documento viene descritto come configurare Security Assertion Markup Language (SAML) con uno stato attivo su ASA AnyConnect tramite Microsoft Entra ID. 

Prerequisiti

Requisiti

Cisco raccomanda la conoscenza dei seguenti argomenti:

• Conoscenze base della configurazione di RMA VPN su ASA (Adaptive Security Appliance).
• Nozioni base sull'autenticazione SAML e su Microsoft Azure.
• Licenze AnyConnect abilitate (APEX o solo VPN).

Componenti usati

Le informazioni fornite in questo documento si basano sulle seguenti versioni software e hardware:

• Sottoscrizione di Microsoft Azure AD.
• Cisco ASA 9.17+ e Secure Client 5+
• Profilo VPN AnyConnect funzionante.

Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.

Premesse

SAML è un framework basato su XML per lo scambio dei dati di autenticazione e autorizzazione tra domini di sicurezza. Instaura una relazione di fiducia tra l'utente, un provider di servizi (SP) e un provider di identità (IdP) che consente all'utente di accedere contemporaneamente a più servizi. Microsoft Entra ID si integra perfettamente con l'appliance VPN Cisco ASA per fornire una maggiore sicurezza per gli accessi VPN AnyConnect di Cisco Secure Client.

Componenti SAML

Metadati: un documento basato su XML che garantisce una transazione sicura tra un provider di identità e un provider di servizi. Permette ai due provider di negoziare accordi.

Ruoli supportati dai dispositivi (IdP, SP)

Un dispositivo può supportare più ruoli e può contenere valori sia per un SP che per un IdP. Sotto il campo EntityDescriptor è presente un IDPSSODescriptor, se le informazioni contenute si riferiscono a un IdP Single Sign-On, o un SPSSODescriptor, se le informazioni contenute si riferiscono a un SP Single Sign-On. Questa distinzione è importante per configurare correttamente il processo SAML, in quanto occorre usare sempre i valori corretti a seconda del provider.

ID entità: identificativo univoco del provider di servizi o del provider di identità. Un singolo dispositivo può disporre di più servizi e utilizzare ID entità diversi per differenziarli. Ad esempio, l'appliance ASA usa ID entità diversi per i diversi tunnel-group che devono essere autenticati. Un IdP che autentica ogni gruppo di tunnel dispone di voci di ID entità separate per ogni gruppo di tunnel al fine di identificare con precisione tali servizi.

L'appliance ASA può supportare più provider di identità e ha un ID entità separato per ciascun provider per differenziarli. Se una delle due parti riceve un messaggio che non contiene un ID entità già configurato, è probabile che il dispositivo elimini il messaggio interrompendo il processo di autenticazione SAML. L'ID entità si trova nel campo EntityDescriptor accanto all'ID autorità (authorityID).

URL di servizio: definiscono l'URL di un servizio SAML fornito dal provider di servizi o dal provider di identità. Per i provider di identità, equivale in genere ai servizi Single Logout Service e Single Sign-On. Per i provider di servizi, equivale in genere ai servizi Assertion Consumer Service e Single Logout Service.

L'URL del servizio Single Sign-On specificato nei metadati del provider di identità viene usato dal provider di servizi per reindirizzare l'utente al provider di identità e procedere all'autenticazione. Se questo valore non è configurato correttamente, il provider di identità non riceve o non è in grado di elaborare correttamente la richiesta di autenticazione inviata dal provider di servizi.

L'URL del servizio Assertion Consumer Service specificato nei metadati del provider di servizi viene utilizzato dal provider di identità per reindirizzare l'utente al provider di servizi e fornire informazioni sul tentativo di autenticazione. Se non è configurato correttamente, il provider di servizi non riceve l'asserzione (risposta) o non è in grado di elaborarla correttamente.

L'URL del servizio Single Logout Service è disponibile sia sul provider di servizi sia sul provider di identità. Viene utilizzato per facilitare la disconnessione di tutti i servizi SSO dal provider di servizi ed è facoltativo sull'ASA. Quando l'URL del servizio SLO presente nei metadati del provider IdP è configurato sul provider SP, quando l'utente si disconnette dal servizio sul provider SP, il provider SP invia la richiesta al provider IdP. Una volta che l'IdP ha eseguito correttamente la disconnessione dell'utente dai servizi, reindirizza nuovamente l'utente all'SP e utilizza l'URL del servizio SLO trovato nei metadati dell'SP.

Binding SAML degli URL dei servizi: I binding sono il metodo usato dal provider di servizi per scambiare le informazioni sui servizi con il provider di identità. Includono il reindirizzamento HTTP, il test POST HTTP e gli artefatti. Ogni metodo ha un modo diverso di trasferire i dati. Il metodo di binding supportato dal servizio è incluso nella definizione dei servizi. Ad esempio: SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location= Servizio SSO >. L'ASA non supporta il binding degli artefatti. L'ASA usa sempre il metodo di reindirizzamento HTTP per le richieste di autenticazione SAML, quindi è importante scegliere l'URL del servizio SSO che usa il binding di reindirizzamento HTTP in modo che il provider di identità ne sia informato.

Certificati per le operazioni di firma e crittografia

Per garantire la riservatezza e l'integrità dei messaggi scambiati tra il provider SP e il provider IdP, SAML offre la possibilità di criptare e firmare i dati. Il certificato utilizzato per crittografare e/o firmare i dati può essere incluso nei metadati in modo che l'estremità che riceve possa verificare il messaggio SAML e assicurarsi che provenga dall'origine prevista. I certificati utilizzati per la firma e la crittografia sono disponibili nei metadati in KeyDescriptor use=signature e KeyDescriptor use=encryption, rispettivamente, quindi in X509Certificate. L'ASA non supporta la crittografia dei messaggi SAML.

Esempio di rete

Configurazione

Aggiunta di Cisco AnyConnect da Microsoft App Gallery

Passaggio 1.  Accedere al portale di Azure e scegliere Microsoft Entra ID. 

Passaggio 2. Come mostrato in questa immagine, scegliere Applicazioni enterprise. 

Passaggio 3. Scegliere Nuova applicazione, come mostrato nell'immagine.

Passaggio 4. Nella sezione Esplora la Microsoft Entra Gallery, digitare AnyConnect nella casella di ricerca, scegliere Autenticazione Cisco Secure Firewall - Secure Client (in precedenza AnyConnect) dal pannello dei risultati, quindi Creare l'app. 

Passaggio 5. Scegliere la voce di menu Single Sign-on, come illustrato in questa immagine. 

Passaggio 6. Scegliere SAML, come mostrato nell'immagine.

Passaggio 7. Modificare la Sezione 1 con questi dettagli.  

 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 

Passaggio 8. Nella sezione Certificato di firma SAML, scegliere Scarica per scaricare il file del certificato e salvarlo sul computer. 

Passaggio 9. Questa operazione è obbligatoria per la configurazione dell'ASA. 

• Azure AD Identifier: l'identificativo di Azure AD, ossia, nella nostra configurazione VPN, il provider di identità SAML.
• Login URL: l'URL di accesso.
• Logout URL: l'URL di disconnessione.

Assegnazione di un utente Azure AD all'applicazione

In questa sezione, Test1 è abilitato per l'utilizzo di Azure Single Sign-On, poiché si concede l'accesso all'app AnyConnect per Cisco Secure Client. 

Passaggio 1. Nella pagina di panoramica dell'app, scegliere Utenti e gruppi, quindi Aggiungi utente/gruppo. 

Passaggio 2. Scegliere Utenti e gruppi nella finestra di dialogo Aggiungi assegnazione. 

Aggiungi assegnazione

Passaggio 3.  Nella finestra di dialogo Add Assignment (Aggiungi assegnazione), fare clic sul pulsante Assign (Assegna).  

Configurazione dell'ASA per l'autenticazione SAML dalla CLI

Passaggio 1. Creare un trust point e importare il certificato 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 

Passaggio 2. Questi comandi permettono di definire il provider di identità SAML.  

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 

Passaggio 3. Applicare l'autenticazione SAML a una configurazione tunnel VPN.

 
tunnel-group AnyConnectVPN-1 webvpn-attributes 
  saml identity-provider https://xxx.windows.net/xxxxxxxxxxxxx/ 
  authentication saml 
end 
 
write memory

 

Nota: Se si apportano modifiche alla configurazione IdP, è necessario rimuovere la configurazione del provider di identità saml dal gruppo di tunnel e riapplicarla per rendere effettive le modifiche. 

Verifica

Verifica di AnyConnect con l'autenticazione SAML

Passaggio 1. Connettersi all'URL della VPN e immettere il log nei dettagli di Azure AD.

Passaggio 2.  Approvare la richiesta di accesso.

Passaggio 3.  AnyConnect è connesso.

Problemi comuni

Mancata corrispondenza tra ID entità

Esempio di debug:  

 [SAML] consume_assertion: The identifier of a provider is unknown to #LassoServer. In order to register a provider in a #LassoServer object, you must use the methods lasso_server_add_provider() or lasso_server_add_provider_from_buffer(). [L'identificativo di un provider è sconosciuto a #LassoServer. Per registrare un provider in #LassoServer, usare i metodi lasso_server_add_provider() o lasso_server_add_provider_from_buffer()]   

Problema: In genere, indica che il comando saml idp [entityID] nella configurazione webvpn dell'ASA non corrisponde all'ID entità IdP trovato nei metadati dell'IdP. 

Soluzione: Controllare l'ID entità specificato nel file dei metadati del provider IdP e modificare di conseguenza il valore di questo parametro nel comando saml idp [entity id].

Mancata sincronizzazione temporale

Esempio di debug:  

 [SAML] NotBefore:2017-09-05T23:59:01.896Z NotOnOrAfter:2017-09-06T00:59:01.896Z timeout: 0 

 [SAML] consume_assertion: assertion is expired or not valid (l'asserzione è scaduta o non è valida) 

Problema 1.  La data e ora dell'ASA non sono sincronizzate con la data e l'ora del provider di identità.

Soluzione 1. Configurare l'ASA in modo che usi lo stesso server NTP usato dal provider di identità.

Problema 2.  L'asserzione arrivata nel tempo specificato non è valida.

Soluzione 2.  Modificare il valore di timeout configurato sull'ASA.

  

Certificato di firma del provider di identità errato

Esempio di debug:  

[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] consume_assertion: The profile cannot verify a signature on the message (Il profilo non può verificare una firma del messaggio) 

Problema: L'ASA non è in grado di verificare il messaggio firmato dal provider di identità oppure non c'è alcuna firma da verificare.  

Soluzione: Controllare il certificato di firma del provider di identità installato sull'ASA per accertarsi che corrisponda a quello effettivamente inviato dal provider IdP. Se confermato, verificare che la firma sia inclusa nella risposta SAML.  

  

Destinatario dell'asserzione non valido

Esempio di debug:  

[SAML] consume_assertion: assertion audience is invalid (Il destinatario dell'asserzione non è valido) 

Problema: IdP definisce il gruppo di destinatari non corretto.

Soluzione: Correggere la configurazione del destinatario sul provider di identità Deve corrispondere all'ID entità dell'ASA. 

  

URL errato del servizio ACS (Assertion Consumer Service)

Esempio di debug: Unable to receive any debugs after the initial authentication request is sent. The user is able to enter credentials at IdP but IdP does not redirect to ASA. (Impossibile ricevere i debug dopo aver inviato la richiesta di autenticazione iniziale. L'utente può immettere le credenziali sul provider di identità, ma il provider di identità non lo reindirizza all'ASA.)  

Problema: Il provider di identità è configurato su un URL errato del servizio Assertion Consumer Service.  

Soluzioni. Controllare l'URL base nella configurazione e verificare che sia corretto. Controllare i metadati dell'ASA con il comando show per accertarsi che l'URL del servizio Assertion Consumer Service sia corretto. Verificare che entrambi i parametri siano corretti sull'ASA, quindi controllare che l'URL del provider di identità sia corretto.

  

Modifiche alla configurazione SAML che non hanno effetto

Esempio: Dopo aver modificato un URL per Single Sign-On o aver cambiato il certificato del provider di servizi, il processo di autenticazione SAML ancora non funziona e invia le configurazioni precedenti.  

Problema: L'appliance ASA deve rigenerare i metadati quando una modifica alla configurazione influisce su di essa. Questa operazione non è automatica.  

Soluzione: Dopo aver apportato le modifiche, nel gruppo di tunnel interessato rimuovere e riapplicare il comando saml idp [entity-id]. 

Risoluzione dei problemi

La maggior parte delle procedure di risoluzione dei problemi SAML implica una configurazione errata che può essere rilevata quando si controlla la configurazione SAML o quando vengono eseguiti i debug. debug webvpn saml 255 può essere utilizzato per risolvere la maggior parte dei problemi. tuttavia, negli scenari in cui questo debug non fornisce informazioni utili, è possibile eseguire altri debug: 

debug webvpn saml 255 
debug webvpn 255  
debug webvpn session 255 
debug webvpn request 255 

Informazioni correlate

• Autenticazione SAML con Single Sign-On per applicazioni on-premises con Application Proxy

Cronologia delle revisioni

Revisione	Data di pubblicazione	Commenti
5.0	22-Apr-2026	Testo alternativo e formattazione aggiornati.
4.0	28-Aug-2024	Traduzione automatica e formattazione aggiornate.
3.0	11-Aug-2023	PII rimossa. SEO, Alt Text, Style Requirements, Machine Translation and Formatting aggiornati.
1.0	19-Aug-2020	Versione iniziale