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

Einleitung

Dieses Dokument beschreibt die Konfiguration der Security Assertion Markup Language (SAML). Der Schwerpunkt liegt auf Adaptive Security Appliance (ASA) AnyConnect über Microsoft Azure MFA. 

Voraussetzungen

Anforderungen

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

• Grundlegende Kenntnisse der RA-VPN-Konfiguration auf der 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:

• Ein Microsoft Azure AD-Abonnement
• Cisco ASA 9.7+ und AnyConnect 4.6+
• 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. Microsoft Azure MFA lässt sich nahtlos in die Cisco ASA VPN-Appliance integrieren, um zusätzliche Sicherheit für die Cisco AnyConnect-VPN-Anmeldungen zu bieten.

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 Feld „EntityDescriptor“ befindet sich ein IDPSSODescriptor, wenn die enthaltenen Informationen für einen Single Sign-On-IdP sind, oder ein SPSSODescriptor für einen Single Sign-On-SP sind. 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-Services. 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 welcher 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. Beispiel: SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location=https://saml.example.com/simplesaml/saml2/idp/SSOService.php/ >. 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"“ > „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 beim Azure Portal an und wählen Sie Azure Active Directory aus. 

Schritt 2: Wählen Sie, wie in dieser Abbildung gezeigt, Enterprise Applications (Unternehmensanwendungen) aus. 

Schritt 3:  Wählen Sie nun New Application (Neue Anwendung) aus, wie in dieser Abbildung gezeigt.

Schritt 4: Geben Sie im Abschnitt Add from the gallery (Hinzufügen aus der Galerie) AnyConnect in das Suchfeld ein, wählen Sie im Ergebnisbereich Cisco AnyConnect aus, und fügen Sie dann die App über die Schaltfläche Add hinzu. 

Schritt 5: Wählen Sie den Menüpunkt Single Sign-On aus, wie in dieser Abbildung gezeigt. 

Schritt 6: Wählen Sie SAML aus, wie in der Abbildung gezeigt.

Schritt 7. Bearbeiten Sie Abschnitt 1 mit folgenden 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 Signing Certificate (SAML-Signaturzertifikat) die Option Download (Herunterladen) aus, um die Zertifikatdatei 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 Verwendung des Single Sign-On von Azure aktiviert, wenn Sie Zugriff auf die Cisco AnyConnect-App gewähren. 

Schritt 1: Wählen Sie auf der Übersichtsseite der App Users and groups (Benutzer und Gruppen) und dann Add user (Benutzer hinzufügen) aus. 

Schritt 2: Wählen Sie im Dialogfeld „Add Assignment“ (Zuweisung hinzufügen) Users and groups aus. 

Schritt 3:  Klicken Sie im Dialogfeld Add Assignment (Zuweisung hinzufügen) auf die Schaltfläche Assign (Zuweisen). 

Konfigurieren der ASA für SAML über die CLI

Schritt 1: Erstellen Sie einen Trustpoint und importieren Sie unser 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 Ihren 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

 

Hinweis: Wenn Sie Änderungen an der IdP-Konfiguration vornehmen, müssen Sie die Konfiguration des SAML Identity-Providers aus Ihrer Tunnelgruppe entfernen und erneut anwenden, damit die Änderungen wirksam werden. 

Überprüfung

Testen von AnyConnect mit SAML-Authentifizierung

Schritt 1:  Stellen Sie eine Verbindung mit Ihrer VPN-URL her und geben Sie Ihre Anmeldeinformationen für Azure AD 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 webvpn-Konfiguration der ASA nicht mit der IdP-Entitäts-ID in den Metadaten des IdP übereinstimmt. 

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 ist abgelaufen oder ungültig 

Problem 1:  ASA-Zeit ist nicht mit der Uhrzeit des IdP synchronisiert.

Lösung 1. Konfigurieren Sie ASA mit demselben NTP-Server, der vom IdP verwendet wird.

Problem 2:  Die Assertion ist zwischen den angegebenen Zeitpunkten ungültig.

Lösung 2.  Ändern Sie den auf der 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: 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-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: Die ASA muss ihre Metadaten neu generieren, wenn sich eine Konfigurationsänderung darauf auswirkt. Dies geschieht nicht automatisch. 

Lösung: Nachdem Sie Änderungen vorgenommen haben, entfernen Sie unter der betroffenen Tunnelgruppe den Befehl „saml idp [entityID]“ und wenden Sie ihn erneut an. 

Fehlerbehebung

Die meisten SAML-Fehlerbehebungen beinhalten eine Fehlkonfiguration, die gefunden werden kann, wenn die SAML-Konfiguration überprüft oder Debugging ausgeführt wird. „debug webvpn saml 255“ kann zur Behebung der meisten Probleme verwendet werden. In Szenarien, in denen dieses Debugging keine nützlichen Informationen liefert, können jedoch weitere Debugging-Aktionen 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