ASA AnyConnect VPN met Microsoft Azure MFA configureren via SAML

Inleiding

In dit document wordt beschreven hoe u Security Assertion Markup Language (SAML) configureert met de nadruk op ASA AnyConnect via Microsoft Entra ID. 

Voorwaarden

Vereisten

Cisco raadt kennis van de volgende onderwerpen aan:

• Basiskennis van RA VPN-configuratie op Adaptive Security Appliance (ASA).
• Basiskennis van SAML en Microsoft Azure.
• AnyConnect-licenties ingeschakeld (APEX of VPN Only).

Gebruikte componenten

De informatie in dit document is gebaseerd op de volgende software- en hardware-versies:

• Microsoft Azure AD-abonnement.
• Cisco ASA 9.17+ en Secure Client 5+
• Een werkend AnyConnect VPN-profiel

De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk live is, moet u zorgen dat u de potentiële impact van elke opdracht begrijpt.

Achtergrondinformatie

SAML is een op XML gebaseerd framework voor het uitwisselen van verificatie- en autorisatiedata tussen security domeinen. Op deze manier wordt een vertrouwenscirkel tussen de gebruiker, een serviceprovider (SP) en een identiteitsprovider (IdP) tot stand gebracht, zodat de gebruiker zich in één keer voor meerdere services kan aanmelden. Microsoft Entra ID kan naadloos worden geïntegreerd met het Cisco ASA VPN-apparaat om extra beveiliging te bieden voor de aanmeldingen van Cisco Secure Client AnyConnect VPN.

SAML-componenten

Metagegevens: het is een op XML gebaseerd document dat een veilige transactie tussen een IdP en een SP waarborgt. Hiermee kunnen de IdP en SP over overeenkomsten onderhandelen.

Ondersteunde rollen door de apparaten (IdP, SP)

Een apparaat kan meer dan één rol ondersteunen en kan waarden voor zowel een SP als een IdP bevatten. Onder het veld EntityDescriptor bevindt zich een IDPSSODescriptor, als de informatie voor een Single Sign-On-IDp is, of een SPSSODescriptor als de informatie voor een Single Sign-On-SP is. Dit is belangrijk omdat de juiste waarden uit de juiste secties moeten worden gehaald om SAML in te stellen.

Entiteits-ID: dit veld is een unieke id voor een SP of een IdP. Eén apparaat kan verschillende services bevatten en kan verschillende entiteits-id's gebruiken om onderscheid te maken tussen deze services. Een ASA heeft bijvoorbeeld verschillende entiteits-id's voor verschillende tunnelgroepen die moeten worden geverifieerd. Een IdP die elke tunnelgroep verifieert, heeft een aparte entiteits-id voor elke tunnelgroep om die services nauwkeurig te identificeren.

Een ASA kan meerdere IdP's ondersteunen en heeft een aparte entiteits-id voor elke IdP om onderscheid te kunnen maken tussen deze IdP's. Als een van beide partijen een bericht ontvangt van een apparaat dat geen entiteits-id bevat die eerder is geconfigureerd, wordt dit bericht waarschijnlijk verwijderd en mislukt de SAML-verificatie. De entiteits-id vindt u in het veld EntityDescriptor naast entityID.

Service-URL's: deze definiëren de URL naar een SAML-service die is geleverd door de SP of IdP. Voor IdP's zijn dit meestal de SLO-service (eenmalige afmelding) en de SSO-service (eenmalige aanmelding). Voor SP's zijn dit meestal Assertion Consumer Service en de SLO-service.

De URL van de SSO-service in de IdP-metagegevens wordt gebruikt door de SP om de gebruiker om te leiden naar de IdP voor verificatie. Als deze waarde onjuist wordt geconfigureerd, kan de IdP de verificatieaanvraag die is verzonden door de SP niet ontvangen of niet goed verwerken.

De URL van Assertion Consumer Service in de SP-metagegevens wordt gebruikt door de IdP om de gebruiker weer terug te leiden naar de SP en informatie te geven over de verificatiepoging van de gebruiker. Als deze URL onjuist is geconfigureerd, ontvangt de SP de bewering (het antwoord) niet of kan deze bewering niet worden verwerkt.

De URL van de SLO-service (eenmalige afmelding) kan zowel op de SP als op de IdP worden gevonden. Deze service wordt gebruikt om het afmelden bij alle SSO-services (eenmalige aanmelding) vanaf de SP te vergemakkelijken en is optioneel op de ASA. Als de URL van de SLO-service uit de IdP-metagegevens is geconfigureerd op de SP, wordt de aanvraag naar de IdP verzonden als de gebruiker zich op de SP afmeldt bij de service. Wanneer de IdP de gebruiker heeft afgemeld bij de services, wordt de gebruiker teruggeleid naar de SP via de URL van de SLO-service die is opgenomen in de metagegevens van de SP.

SAML-bindingen voor service-URL's: bindingen worden door de SP gebruikt om gegevens voor services uit te wisselen met de IdP. Hierbij gaat het onder andere om HTTP Redirect, HTTP POST en Artifact. Elke methode heeft een andere manier om gegevens over te dragen. De ondersteunde bindingmethode door de service is opgenomen in de definitie van die service. Bijvoorbeeld: SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location= SSO Service >. De ASA biedt geen ondersteuning voor de binding Artifact. De ASA gebruikt altijd de methode HTTP Redirect voor SAML-verificatieaanvragen, dus het is belangrijk om de URL van de SSO-service te kiezen die de binding HTTP Redirect gebruikt, zodat de IdP dit verwacht.

Certificaten voor ondertekenings- en versleutelingsbewerkingen

Om de vertrouwelijkheid en integriteit van de verzonden berichten tussen de SP en de IdP te waarborgen, omvat SAML de mogelijkheid om de data te versleutelen en te ondertekenen. Het certificaat dat is gebruikt om de data te versleutelen en/of te ondertekenen, kan worden opgenomen in de metagegevens, zodat de ontvangende partij het SAML-bericht kan verifiëren en kan bepalen of het afkomstig is van de verwachte bron. De certificaten die worden gebruikt voor ondertekening en codering zijn te vinden in de metagegevens onder KeyDescriptor use=signing en KeyDescriptor use=encryption, respectievelijk, en vervolgens X509Certificate. De ASA biedt geen ondersteuning voor de versleuteling van SAML-berichten.

Netwerkdiagram

Configureren

Cisco AnyConnect toevoegen vanuit de galerie met apps van Microsoft

Stap 1. Meld u aan bij Azure Portal en kies Microsoft Entra ID. 

Stap 2. Selecteer Enterprise Applications, zoals weergegeven in deze afbeelding. 

Stap 3.  Selecteer nu New Applications, zoals weergegeven in deze afbeelding.

Stap 4. Typ in de sectie Bladeren door Microsoft Entra Gallery AnyConnect in het zoekvak, kies Cisco Secure Firewall - Secure Client (voorheen AnyConnect) -verificatie in het deelvenster Resultaten en kies vervolgens Create de app. 

Stap 5. Selecteer het menu-item Single Sign-on (Eenmalige aanmelding), zoals weergegeven in deze afbeelding. 

Stap 6. Selecteer SAML, zoals weergegeven in de afbeelding.

Stap 7. Bewerk Section 1 met deze details. 

 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 

Stap 8. Selecteer  Download in de sectie SAML Signing Certificate om het certificaatbestand te downloaden en klik op save  om het bestand op uw computer op te slaan. 

Stap 9. Dit is vereist voor de ASA-configuratie. 

• Azure AD-id: dit is de SAML-id in onze VPN-configuratie.
• Aanmeldings-URL: dit is de URL voor aanmelden.
• Afmeldings-URL: dit is de URL voor afmelden.

Azure AD-gebruiker toewijzen aan de app

In dit gedeelte is Test1 ingeschakeld voor het gebruik van Azure voor eenmalige aanmelding, omdat u toegang verleent tot de Cisco Secure Client AnyConnect-app. 

Stap 1. Kies op de overzichtspagina van de app de optie Gebruikers en groepen en vervolgens Gebruiker/groep toevoegen. 

Stap 2. Selecteer Users and groups (Gebruikers en groepen) in het dialoogvenster Add Assignment (Toewijzing toevoegen). 

Toewijzing toevoegen

Stap 3.  Klik in het dialoogvenster Add Assignment (Toewijzing toevoegen) op de knop Assign (Toewijzen). 

ASA voor SAML configureren via CLI

Stap 1. Maak een Trustpoint en importeer uw SAML-certificaat. 

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 

Stap 2.  Met deze opdrachten richt u uw SAML-IdP in. 

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 

Stap 3. Pas SAML-verificatie toe op een VPN-tunnelconfiguratie.

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

 

Opmerking: als u wijzigingen wilt aanbrengen in de IdP-configuratie, moet u de configuratie van de SAML-identiteitsprovider uit uw tunnelgroep verwijderen en opnieuw toepassen om de wijzigingen van kracht te laten worden. 

Verifiëren

AnyConnect testen met SAML-verificatie

Stap 1.  Maak verbinding met uw VPN-URL en voer uw aanmeldingsgegevens voor Azure AD in.

Stap 2.  Keur de aanmeldingsaanvraag goed.

Stap 3.  AnyConnect is verbonden.

Veelvoorkomende problemen

Niet-overeenkomende entiteits-id

Voorbeeld van debug:  

 [SAML] consume_assertion: de identificatie van een provider is onbekend voor #LassoServer. Als u een provider in een #LassoServer-object wilt registreren, moet u de methode lasso_server_add_provider() of lasso_server_add_provider_from_buffer() gebruiken.  

Probleem: dit betekent over het algemeen dat de opdracht saml idp [entityID] onder de webvpn-configuratie van de ASA niet overeenkomt met de entiteits-ID van de IdP die is opgenomen in de metagegevens van de IdP. 

Oplossing: controleer de entiteits-ID van het metagegevensbestand van de IdP en pas de opdracht saml idp [entity id] hieraan aan.

Niet-overeenkomende tijd

Voorbeeld van debug:  

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

 [SAML] consume_assertion: bewering is verlopen of ongeldig 

Probleem 1.  ASA-tijd is niet gesynchroniseerd met IdP-tijd.

Oplossing 1. Configureer de ASA met de NTP-server die wordt gebruikt door de IdP.

Probleem 2.  De bewering is ongeldig in de opgegeven periode.

Oplossing 2.  Wijzig de geconfigureerde time-outwaarde op de ASA.

  

Onjuist handtekeningcertificaat voor IdP gebruikt

Voorbeeld van 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: het profiel kan een handtekening voor het bericht niet verifiëren 

Probleem: de ASA kan het bericht ondertekend door de IdP niet verifiëren of er is geen handtekening om te verifiëren voor de ASA. 

Oplossing:controleer het IdP-handtekeningcertificaat dat op de ASA is geïnstalleerd om er zeker van te zijn dat dit overeenkomt met wat door de IdP is verzonden. Na bevestiging controleert u of de handtekening is opgenomen in de SAML-respons.  

  

Ongeldige doelgroep voor bewering

Voorbeeld van debug:  

[SAML] consume_assertion: doelgroep voor bewering is ongeldig 

Problem: IdP definieert de verkeerde doelgroep.

Oplossing: corrigeer de doelgroepconfiguratie op de IdP. Deze moet overeenkomen met de entiteits-id van de ASA. 

  

Onjuiste URL voor Assertion Consumer Service

Voorbeeld van debug: kan geen debug-opdrachten ontvangen nadat de initiële verificatieaanvraag is verzonden. De gebruiker kan gebruikersreferenties invoeren op de IdP, maar de IdP leidt niet om naar de ASA.  

Probleem: IdP is niet voor de juiste Assertion Consumer Service-URL geconfigureerd. 

Oplossing(en): controleer de basis-URL in de configuratie en zorg dat deze correct is. Controleer de ASA-metagegevens met de opdracht show om er zeker van te zijn dat de URL voor Assertion Consumer Service correct is. Test de URL door deze te bezoeken en uit te proberen. Als beide URL's correct zijn op de ASA, controleert u de IdP om er zeker van te zijn dat de URL klopt.

  

SAML-configuratiewijzigingen die niet van kracht worden

Voorbeeld: nadat een URL  voor eenmalige aanmelding is gewijzigd, werkt de SAML van het SP-certificaat nog steeds niet en worden eerdere configuraties verzonden. 

Probleem: ASA moet zijn metagegevens opnieuw genereren als er een configuratiewijziging is die dit beïnvloedt. Dit gebeurt niet automatisch.  

Oplossing: wanneer u wijzigingen hebt aangebracht, moet u de opdracht saml idp [entity-id] onder de betreffende tunnelgroep verwijderen en opnieuw toepassen. 

Problemen oplossen

Bij de meeste SAML-problemen gaat het om een foutieve configuratie die kan worden opgespoord wanneer de SAML-configuratie gecontroleerd wordt of wanneer debugs worden uitgevoerd. debug webvpn saml 255 kan worden gebruikt om de meeste problemen op te lossen, maar in scenario's waar deze debug geen nuttige informatie geeft kunnen extra debugs worden uitgevoerd: 

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

Gerelateerde informatie

• Eenmalige aanmelding op basis van SAML voor on-premises toepassingen via toepassingsproxy

Revisiegeschiedenis

Revisie	Publicatiedatum	Opmerkingen
5.0	22-Apr-2026	Bijgewerkte Alt-tekst en -opmaak.
4.0	28-Aug-2024	Bijgewerkte machinevertaling en opmaak.
3.0	11-Aug-2023	Verwijderde PII. Bijgewerkte SEO, alt-tekst, stijlvereisten, machinevertaling en opmaak.
1.0	19-Aug-2020	Eerste vrijgave