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 SAML (Security Assertion Markup Language) con particolare attenzione alle appliance ASA AnyConnect tramite Microsoft Azure MFA. 

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:

• Abbonamento a Microsoft Azure AD.
• Cisco ASA 9.7+ e AnyConnect 4.6+.
• 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 Azure MFA si integra perfettamente con l'appliance Cisco ASA VPN per fornire ulteriore sicurezza agli accessi a Cisco AnyConnect VPN.

Componenti SAML

Metadati: si tratta di un documento basato su XML che garantisce una transazione sicura tra IdP e SP. 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à: questo campo è un identificatore univoco per un SP o un IdP. 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 servizio: definiscono l'URL di un servizio SAML fornito dall'SP o dall'IdP. 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.

Associazioni SAML per URL servizio: le associazioni sono il metodo utilizzato dall'SP per trasferire le informazioni all'IdP e viceversa per i servizi. 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 Azure Active Directory. 

Passaggio 2. Come illustrato in questa immagine, scegliere Applicazioni aziendali. 

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

Passaggio 4. Nella sezione Aggiungi dalla raccolta, digitare AnyConnect nella casella di ricerca, scegliere Cisco AnyConnect dal pannello dei risultati, quindi aggiungere l'app. 

Passaggio 5. Scegliere la voce di menu Accesso singolo, come illustrato nell'immagine. 

Passaggio 6. Selezionate 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 nel 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 in modo da usare l'accesso Single-Sign-On Azure e permettere di accedere all'applicazione Cisco AnyConnect.  

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

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

Passaggio 3. Nella finestra di dialogo Aggiungi assegnazione fare clic sul pulsante 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 eseguono il provisioning del 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. Applica 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: l'identificatore di un provider è sconosciuto a #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: verificare l'ID entità del file di metadati dell'IdP e modificare il comando saml idp [entity id] in modo che corrisponda a questo.

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: asserzione scaduta o non valida 

Problema 1. Ora ASA non sincronizzata con l'ora dell'IdP.

Soluzione 1. Configurare l'ASA con lo stesso server NTP usato da IdP.

Problema 2. Asserzione non valida tra l'ora specificata.

Soluzione 2. Modificare il valore di timeout configurato sull'appliance 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: il profilo non è in grado di verificare una firma sul messaggio 

Problema: l'ASA non è in grado di verificare il messaggio firmato dall'IdP o non è presente alcuna firma da verificare per l'ASA. 

Soluzione: controllare il certificato di firma IdP installato sull'appliance ASA per verificare che corrisponda a quanto inviato dall'IdP. Se confermato, verificare che la firma sia inclusa nella risposta SAML.  

  

Destinatario dell'asserzione non valido

Esempio di debug:  

[SAML] consume_assertion: il gruppo di destinatari dell'asserzione non è valido 

Problema: il gruppo di destinatari definito dall'IdP non è corretto.

Soluzione: correggere la configurazione del gruppo di destinatari nel provider di identità. Deve corrispondere all'ID entità dell'ASA. 

  

URL errato del servizio ACS (Assertion Consumer Service)

Esempio di debug: impossibile ricevere alcun debug dopo l'invio della richiesta di autenticazione iniziale. 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 per l'URL del servizio consumer di asserzione errato. 

Soluzione/i: verificare l'URL di base nella configurazione e accertarsi 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 la modifica o la modifica di un URL Single Sign-On, il certificato dell'SP, SAML non funziona e invia le configurazioni precedenti. 

Problema: l'appliance ASA deve rigenerare i metadati quando viene modificata una configurazione. 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 si eseguono 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