Konfigurieren von ASA AnyConnect-VPN mit Microsoft Azure MFA über SAML

Einleitung

In diesem Dokument wird beschrieben, wie Sie Security Assertion Markup Language (SAML) mit Schwerpunkt auf ASA AnyConnect über Microsoft Entra ID konfigurieren. 

Voraussetzungen

Anforderungen

Cisco empfiehlt, dass Sie über Kenntnisse in folgenden Bereichen verfügen:

• Grundkenntnisse der RA VPN-Konfiguration auf der Adaptive Security Appliance (ASA)
• Grundkenntnisse in SAML und Microsoft Azure
• Aktivieren von AnyConnect-Lizenzen (APEX oder VPN-Only)

Verwendete Komponenten

Die Informationen in diesem Dokument basierend auf folgenden Software- und Hardware-Versionen:

• Microsoft Azure AD-Abonnement.
• Cisco ASA 9.17+ und Secure Client 5+
• Funktionierendes AnyConnect-VPN-Profil

Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen.

Hintergrundinformationen

SAML ist ein XML-basiertes Framework für den Austausch von Authentifizierungs- und Autorisierungsdaten zwischen Sicherheitsdomänen. Es schafft einen Vertrauenskreis zwischen dem Benutzer, einem Service-Provider (SP) und einem Identitätsanbieter (IdP), mit dem sich Benutzer für mehrere Services nur einmal anmelden müssen. Die Microsoft Entra ID lässt sich nahtlos in die Cisco ASA VPN-Appliance integrieren und bietet so zusätzliche Sicherheit für Cisco Secure Client AnyConnect VPN-Anmeldungen.

SAML-Komponenten

Metadaten: Es handelt sich um ein XML-basiertes Dokument, das eine sichere Transaktion zwischen einem IdP und einem SP gewährleistet und es ihnen ermöglicht, Vereinbarungen auszuhandeln.

Von den Geräten unterstützte Rollen (IdP, SP)

Ein Gerät kann mehr als eine Rolle unterstützen und Werte für einen SP und einen IdP enthalten. Unter dem EntityDescriptor-Feld befindet sich ein IDPSSODescriptor, wenn die enthaltenen Informationen eine Single Sign-On IdP betreffen, oder ein SPSSODescriptor, wenn die enthaltenen Informationen einen Single Sign-On SP betreffen. Dies ist wichtig, da die richtigen Werte aus den entsprechenden Abschnitten entnommen werden müssen, um SAML erfolgreich einzurichten.

Entitäts-ID: Dieses Feld ist eine eindeutige Kennung für einen SP oder einen IdP. Ein einzelnes Gerät kann über mehrere Services verfügen und verschiedene Entitäts-IDs verwenden, um sie zu unterscheiden. Die ASA hat beispielsweise verschiedene Entitäts-IDs für verschiedene Tunnelgruppen, die authentifiziert werden müssen. Ein IdP, der jede Tunnelgruppe authentifiziert, hat separate Entitäts-ID-Einträge für jede Tunnelgruppe, um diese Services genau zu identifizieren.

Die ASA kann mehrere IdPs unterstützen und hat eine separate Entitäts-ID für jeden IdP, um sie zu unterscheiden. Wenn eine Seite eine Meldung von einem Gerät empfängt, das keine zuvor konfigurierte Entitäts-ID enthält, verwirft das Gerät diese Meldung wahrscheinlich und die SAML-Authentifizierung schlägt fehl. Die Entitäts-ID befindet sich im Feld „EntityDescriptor“ neben „entityID“.

Service-URLs: Diese definieren die URL eines vom SP oder IdP bereitgestellten SAML-Dienstes. Bei IdPs sind dies meist der Single Logout- und der Single Sign-On-Dienst. Bei SPs sind es normalerweise der Assertion Consumer Service und der Single Logout-Dienst.

Die Single Sign-On Service-URL in den IdP-Metadaten wird vom SP verwendet, um den Benutzer zur Authentifizierung an den IdP weiterzuleiten. Wenn dieser Wert falsch konfiguriert ist, empfängt der IdP die vom SP gesendete Authentifizierungsanfrage nicht oder kann sie nicht erfolgreich verarbeiten.

Die Assertion Consumer Service-URL in den SP-Metadaten wird vom IdP verwendet, um den Benutzer zurück zum SP zu leiten und Informationen über den Authentifizierungsversuch des Benutzers bereitzustellen. Wenn dies falsch konfiguriert ist, erhält der SP die Zusicherung (die Antwort) nicht oder kann sie nicht erfolgreich verarbeiten.

Die Single Logout Service-URL befindet sich sowohl auf dem SP als auch auf dem IdP. Sie wird verwendet, um das Abmelden von allen SSO-Services vom SP zu erleichtern, und ist auf der ASA optional. Wenn die SLO-Service-URL aus den IdP-Metadaten auf dem SP konfiguriert ist und sich der Benutzer beim Service auf dem SP abmeldet, sendet der SP die Anfrage an den IdP. Sobald der IdP die Benutzer erfolgreich von den Services abgemeldet hat, leitet er die Benutzer mithilfe der SLO-Service-URL in den Metadaten des SP zurück zum SP.

SAML-Bindungen für Service-URLs: Bindungen sind die Methode, mit der der SP Informationen vom und an den IdP für Services überträgt. Dazu gehören HTTP-Umleitung, HTTP-POST und Artefakt. Jede Methode nutzt eine andere Art der Datenübertragung. Die vom Dienst unterstützte Bindungsmethode ist in der Definition dieser Dienste enthalten. Beispiele: SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location= SSO-Dienst >. Die ASA unterstützt die Artefaktbindung nicht, sondern verwendet immer die HTTP-Umleitungsmethode für SAML-Authentifizierungsanforderungen. Daher ist es wichtig, die SSO-Service-URL auszuwählen, die die HTTP-Umleitungsbindung verwendet, damit der IdP dies erwartet.

Zertifikate für Signatur- und Verschlüsselungsvorgänge

Um die Vertraulichkeit und Integrität der zwischen SP und IdP gesendeten Meldungen zu gewährleisten, beinhaltet SAML die Möglichkeit, die Daten zu verschlüsseln und zu signieren. Das Zertifikat, das zum Verschlüsseln und/oder Signieren der Daten verwendet wird, kann in den Metadaten enthalten sein, damit der Empfänger die SAML-Meldung überprüfen und sicherstellen kann, dass sie von der erwarteten Quelle stammt. Die für die Signierung und Verschlüsselung verwendeten Zertifikate finden Sie in den Metadaten unter KeyDescriptor use=signing bzw. KeyDescriptor use=encryption und dann unter X509Certificate. Die ASA unterstützt keine Verschlüsselung von SAML-Meldungen.

Netzwerkdiagramm

Konfigurieren

Hinzufügen von Cisco AnyConnect aus der Microsoft App-Galerie

Schritt 1:  Melden Sie sich bei Azure Portal an, und wählen Sie Microsoft Entra ID aus. 

Schritt 2: Wählen Sie, wie in dieser Abbildung dargestellt, Enterprise Applications aus. 

Schritt 3. Wählen Sie nun Neue Anwendung, wie in diesem Bild dargestellt.

Schritt 4. Geben Sie im Abschnitt Microsoft Entra Gallery durchsuchen im Suchfeld AnyConnect ein, wählen Sie Cisco Secure Firewall - Secure Client (ehemals AnyConnect)-Authentifizierung im Ergebnisfenster aus, und erstellen Sie dann die App. 

Schritt 5. Wählen Sie den Menüpunkt Single Sign-on (einmalige Anmeldung), wie in diesem Bild dargestellt. 

Schritt 6. Wählen Sie SAML, wie im Bild dargestellt.

Schritt 7: Bearbeiten Sie Abschnitt 1 mit diesen 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 

Schritt 8. Wählen Sie im Abschnitt SAML-Signaturzertifikat die Option Herunterladen aus, um die Zertifikatsdatei herunterzuladen und auf Ihrem Computer zu speichern. 

Schritt 9: Dies ist für die ASA-Konfiguration erforderlich. 

• Azure AD Identifier: Dies ist der SAML-IdP in unserer VPN-Konfiguration.
• Login URL: Dies ist die URL-Anmeldung.
• Logout URL: Dies ist die URL-Abmeldung.

Zuweisen von Azure AD-Benutzern zur App

In diesem Abschnitt ist Test1 für die einmalige Anmeldung bei Azure aktiviert, wenn Sie Zugriff auf die Cisco Secure Client AnyConnect-App gewähren. 

Schritt 1: Wählen Sie auf der Übersichtsseite der App Benutzer und Gruppen aus, und klicken Sie dann auf Benutzer/Gruppe hinzufügen. 

Schritt 2: Wählen Sie im Dialogfeld "Zuweisung hinzufügen" Benutzer und Gruppen. 

Zuweisung hinzufügen

Schritt 3: Klicken Sie im Dialogfeld Zuweisung hinzufügen auf die Schaltfläche Zuweisen. 

Konfigurieren der ASA für SAML über die CLI

Schritt 1: Erstellen Sie einen Vertrauenspunkt, und importieren Sie Ihr SAML-Zertifikat. 

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 

Schritt 2: Diese Befehle stellen Ihre SAML-IDp bereit. 

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 

Schritt 3: Anwenden der SAML-Authentifizierung auf eine VPN-Tunnelkonfiguration.

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

 

Anmerkung: Wenn Sie Änderungen an der IdP-Konfiguration vornehmen, müssen Sie die gleiche Identitätsanbieter-Konfiguration aus der Tunnelgruppe entfernen und erneut anwenden, damit die Änderungen wirksam werden. 

Überprüfung

Testen von AnyConnect mit SAML-Authentifizierung

Schritt 1: Stellen Sie eine Verbindung zu Ihrer VPN-URL her, und geben Sie die Azure AD-Details für die Anmeldung ein.

Schritt 2.  Genehmigen Sie die Anmeldeanfrage.

Schritt 3.AnyConnect ist verbunden.

Häufige Probleme

Entitäts-ID stimmt nicht überein

Debug-Beispiel: 

 [SAML] consume_assertion: Die ID eines Provider ist dem #LassoServer unbekannt. Um einen Provider in einem #LassoServer-Objekt zu registrieren, müssen Sie die Methoden lasso_server_add_provider () oder lasso_server_add_provider_from_buffer () verwenden. 

Problem: Im Allgemeinen bedeutet dies, dass der Befehl saml idp [entityID] in der Web-VPN-Konfiguration der ASA nicht mit der IdP-Objektkennung übereinstimmt, die in den Metadaten der IdP gefunden wurde. 

Lösung: Überprüfen Sie die Entitäts-ID der Metadatendatei des IdP und ändern Sie den Befehl saml idp [entityID] entsprechend.

Zeit stimmt nicht überein

Debug-Beispiel: 

 [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 (Assertion ist abgelaufen oder ungültig) 

Problem 1. ASA-Zeit nicht mit IDp-Zeit synchronisiert

Lösung 1. Konfigurieren Sie ASA mit demselben von IdP verwendeten NTP-Server.

Problem 2. Die Assertion ist zwischen dem angegebenen Zeitpunkt nicht gültig.

Lösung 2. Ändern Sie den auf dem ASA konfigurierten Timeout-Wert.

  

Falsches IdP-Signaturzertifikat verwendet

Debug-Beispiel: 

[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 (Das Profil kann eine Signatur der Meldung nicht überprüfen) 

Problem: Die ASA kann die vom IdP signierte Meldung nicht überprüfen, oder es gibt keine Signatur, die von der ASA überprüft werden kann. 

Lösung: Überprüfen Sie das auf der ASA installierte IdP-Signaturzertifikat, um sicherzustellen, dass es mit dem vom IdP gesendeten Zertifikat übereinstimmt. Wenn dies bestätigt wird, stellen Sie sicher, dass die Signatur in der SAML-Antwort enthalten ist. 

  

Ungültige Assertion-Zielgruppe

Debug-Beispiel: 

[SAML] consume_assertion: assertion audience is invalid (Assertion-Zielgruppe ist ungültig) 

Problem: IdP definiert die falsche Zielgruppe.

Lösung: Korrigieren Sie die Zielgruppenkonfiguration auf dem IdP. Sie muss mit der Entitäts-ID der ASA übereinstimmen. 

  

Falsche URL für Assertion Consumer Service

Debug-Beispiel: Nach dem Senden der ersten Authentifizierungsanfrage können keine Debugs empfangen werden. Der Benutzer kann Anmeldeinformationen bei IdP eingeben, aber IdP leitet nicht an die ASA weiter. 

Problem: IdP ist für die falsche Assertion Consumer Service-URL konfiguriert. 

Lösung(en): Überprüfen Sie die Basis-URL in der Konfiguration und stellen Sie sicher, dass sie korrekt ist. Überprüfen Sie die ASA-Metadaten mit „show“, um sicherzustellen, dass die Assertion Consumer Service-URL korrekt ist. Um sie zu testen, durchsuchen Sie sie. Wenn beide auf der ASA korrekt sind, überprüfen Sie den IdP, um sicherzustellen, dass die URL korrekt ist.

  

SAML-Konfigurationsänderungen, die nicht wirksam werden

Beispiel: Nachdem eine Single Sign-On-URL geändert wurde, funktioniert das SP-Zertifikat, SAML jedoch immer noch nicht und sendet vorherige Konfigurationen. 

Problem: ASA muss seine Metadaten neu generieren, wenn eine Konfigurationsänderung vorliegt, die sich auf sie auswirkt. Dies geschieht nicht automatisch. 

Lösung: Nachdem die Änderungen vorgenommen wurden, entfernen Sie unter der betroffenen Tunnelgruppe den Befehl saml idp [entity-id], und wenden Sie ihn erneut an. 

Fehlerbehebung

Bei den meisten SAML-Fehlerbehebungen handelt es sich um eine Fehlkonfiguration, die beim Überprüfen der SAML-Konfiguration oder beim Ausführen von Debugs festgestellt werden kann. debug webvpn saml 255 kann zur Fehlerbehebung bei den meisten Problemen verwendet werden. In Szenarien, in denen dieses Debugging keine nützlichen Informationen bereitstellt, können jedoch zusätzliche Debugs ausgeführt werden: 

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

Zugehörige Informationen

• SAML Single Sign-On für lokale Anwendungen mit Anwendungsproxy

Revisionsverlauf

Überarbeitung	Veröffentlichungsdatum	Kommentare
5.0	22-Apr-2026	Aktualisierter Alternativer Text und Formatierung.
4.0	28-Aug-2024	Aktualisierte maschinelle Übersetzung und Formatierung.
3.0	11-Aug-2023	PII entfernt. Aktualisiert SEO, Alt Text, Stilanforderungen, maschinelle Übersetzung und Formatierung.
1.0	19-Aug-2020	Erstveröffentlichung