ASA AnyConnect VPN met Microsoft Azure MFA configureren via SAML

Inleiding

Dit document beschrijft hoe u Security Assertion Markup Language (SAML) kunt configureren met de focus op ASA AnyConnect via Microsoft Azure MFA. 

Voorwaarden

Vereisten

Cisco raadt kennis van de volgende onderwerpen aan:

• Basiskennis van RA VPN-configuratie op adaptieve security applicatie (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:

• Een Microsoft Azure AD-abonnement.
• Cisco ASA 9.7+ en AnyConnect 4.6+
• 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 Azure MFA kan naadloos worden geïntegreerd met de Cisco ASA VPN-applicatie om extra security te bieden voor de aanmeldingen bij Cisco AnyConnect VPN.

SAML-componenten

Metagegevens: Het is een op XML gebaseerd document dat een veilige transactie tussen een IdP en een SP garandeert. 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 bevatten voor zowel een SP als een IdP. Onder het veld EntityDescriptor is een IDPSSODescriptor, als de informatie in het veld is voor een Single Sign-On IDP, of een SPSODescriptor als de informatie in het veld is voor een Single Sign-On SP. Dit is belangrijk omdat de juiste waarden uit de juiste secties moeten worden gehaald om SAML in te stellen.

Identiteitskaart van de entiteit: Dit veld is een unieke identificatiecode voor een SP of een ID. Eén apparaat kan meerdere diensten hebben en verschillende ID’s van entiteiten gebruiken om ze te onderscheiden. Een ASA heeft bijvoorbeeld verschillende entiteits-id's voor verschillende tunnelgroepen die moeten worden geverifieerd. Een IdP die elke tunnelgroep authenticeert, heeft een aparte entiteit-ID-vermeldingen voor elke tunnelgroep om deze diensten 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 door de SP of IDP wordt geleverd. 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. Zodra de IdP met succes de gebruiker uit de diensten heeft gelogd, wordt de gebruiker teruggestuurd naar de SP en gebruikt de URL van de DSL-dienst die binnen de metagegevens van de SP wordt gevonden.

SAML Bindingen voor Service URL's: Bindingen zijn de methode die de SP gebruikt om informatie over te dragen naar de IDp en vice versa voor services. 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:bindingen: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 wordt gebruikt om de gegevens te versleutelen en/of te ondertekenen kan worden opgenomen in de metagegevens, zodat het ontvangen einde het SAML-bericht kan verifiëren en ervoor kan zorgen dat het van de verwachte bron komt. De certificaten die worden gebruikt voor het ondertekenen en versleutelen kunnen worden gevonden binnen de metagegevens onder KeyDescriptor use=sign en KeyDescriptor use=encryptie, respectievelijk, dan 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 Azure Active Directory. 

Stap 2. Zoals in deze afbeelding wordt getoond, kiest u Enterprise Application. 

Stap 3. Kies nu Nieuwe toepassing, zoals in deze afbeelding.

Stap 4. In de sectie Toevoegen in de galerij typt u AnyConnect in het zoekvak, kiest u Cisco AnyConnect in het resultatenpaneel en voegt u de app toe. 

Stap 5. Kies de Single Sign-on menuoptie, zoals in deze afbeelding wordt getoond. 

Stap 6. Kies SAML, zoals in de afbeelding.

Stap 7. Bewerk sectie 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. Kies in het gedeelte SAML-ondertekeningscertificaat Downloaden om het certificaatbestand te downloaden en op uw computer op te slaan. 

Stap 9. Dit is vereist voor 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 deze sectie wordt Test1 ingeschakeld om eenmalige aanmelding van Azure te gebruiken wanneer u toegang tot de Cisco AnyConnect-app verleent.  

Stap 1. Kies op de overzichtspagina van de app Gebruikers en groepen en voeg gebruikers toe. 

Stap 2. Kies Gebruikers en groepen in het dialoogvenster Toewijzing toevoegen. 

Stap 3. Klik in het dialoogvenster Toewijzing toevoegen op de knop Toewijzen. 

ASA voor SAML configureren via CLI

Stap 1. Maak een Trustpoint en importeer uw SAML cert. 

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. Deze opdrachten voorzien uw 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 

Stap 3. SAML-verificatie toepassen 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 aanbrengt in de IDp-configuratie, moet u de kleine identiteit-provider-configuratie uit uw Tunnel-groep verwijderen en opnieuw toepassen op de wijzigingen om effectief te worden. 

Verifiëren

AnyConnect testen met SAML-verificatie

Stap 1. Maak verbinding met uw VPN-URL en voer uw login in Azure AD details.

Stap 2.  Keur de aanmeldingsaanvraag goed.

Stap 3.  AnyConnect is verbonden.

Veelvoorkomende problemen

Niet-overeenkomende entiteits-id

Voorbeeld van debug:  

 [SAML] consume_assertion: De identificator van een provider is onbekend bij #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: In het algemeen betekent dit dat kleine idp [entityID] opdracht onder de webvpn-configuratie van de ASA niet overeenkomt met de IDp Entity ID in de metadata van IdP. 

Oplossing: controleer de entiteit-ID van het metadata-bestand van IdP en wijzig de opdracht saml idp [entity id] om dit aan te passen.

Niet-overeenkomende tijd

Voorbeeld van debug:  

 [SAML] Niet voor:2017-09-05T23:59:01.896Z NietOpOfNa:2017-09-06T00:59:01.896Z time-out: 0 

 [SAML] consume_assertion: bewering is verlopen of ongeldig 

Probleem 1. ASA-tijd niet gesynchroniseerd met de tijd van IdP.

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

Probleem 2. De bewering is ongeldig tussen de opgegeven tijd.

Oplossing 2. Wijzig de timeout waarde die ingesteld is 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 geen handtekening verifiëren op het bericht 

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

Oplossing: Controleer of het op de ASA geïnstalleerde IDp-ondertekeningscertificaat overeenkomt met wat door de IdP wordt verzonden. Na bevestiging controleert u of de handtekening is opgenomen in de SAML-respons.  

  

Ongeldige doelgroep voor bewering

Voorbeeld van debug:  

[SAML] consume_assertion: het publiek van de bewering is ongeldig 

Probleem: IdP definieert het onjuiste publiek.

Oplossing: Corrigeer de Publiek configuratie op de IDp. Het moet overeenkomen met de entiteit-ID van de ASA. 

  

Onjuiste URL voor Assertion Consumer Service

Voorbeeld debug: kan geen debugs ontvangen nadat de eerste verificatieaanvraag is verzonden. De gebruiker kan gebruikersreferenties invoeren op de IdP, maar de IdP leidt niet om naar de ASA.  

Probleem: IDp is ingesteld op de verkeerde URL voor Assertion Consumer Service. 

Oplossing(s): Controleer de basis-URL in configuratie en zorg ervoor 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.

  

Wijzigingen in de SAML-configuratie die niet van kracht worden

Voorbeeld: Nadat een enkele aanmelding-URL is gewijzigd of aangepast, werkt het SP-certificaat nog steeds niet en verstuurt SAML vorige configuraties. 

Probleem: ASA moet zijn metagegevens regenereren wanneer er een configuratieverandering is die het beïnvloedt. Dit gebeurt niet automatisch.  

Oplossing: Nadat wijzigingen zijn aangebracht, onder de betreffende tunnelgroep het kleine idp [entity-id]-commando verwijderen en opnieuw toepassen. 

Problemen oplossen

De meeste SAML problemen oplossen impliceert een misconfiguratie die kan worden gevonden wanneer de SAML configuratie wordt gecontroleerd, of debugs worden uitgevoerd. debug webvpn saml 255 kan worden gebruikt om de meeste problemen op te lossen, echter, in scenario's waar dit debug geen nuttige informatie verstrekt, 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