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 mehrere Rollen 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.

Element-ID: Dieses Feld ist eine eindeutige Kennung für einen SP oder einen IdP. Ein einzelnes Gerät kann mehrere Services umfassen und unterschiedliche Objektkennungen verwenden, um diese zu differenzieren. Die ASA hat beispielsweise verschiedene Entitäts-IDs für verschiedene Tunnelgruppen, die authentifiziert werden müssen. Ein IdP, der jede Tunnelgruppe authentifiziert, verfügt für jede Tunnelgruppe über separate Entity-ID-Einträge, 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 (Dienst-URLs): Diese definieren die URL zu einem vom SP oder vom IdP bereitgestellten SAML-Dienst. 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 Benutzer vom IdP erfolgreich bei den Services abgemeldet wurde, leitet er den Benutzer zurück zum SP und verwendet die SLO-Dienst-URL, die in den Metadaten des SP enthalten ist.

SAML-Bindungen für Dienst-URLs: Bindungen sind die Methode, die der SP verwendet, um Informationen an den IdP zu übertragen und umgekehrt. Dazu gehören HTTP-Umleitung, HTTP-POST und Artefakt. Jede Methode hat eine andere Möglichkeit, Daten zu übertragen. 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 zur Verschlüsselung und/oder Signierung der Daten verwendete Zertifikat kann in die Metadaten aufgenommen werden, sodass das empfangende Ende die SAML-Nachricht ü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 diesem Bild dargestellt, die Option Enterprise Applications aus. 

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

Schritt 4: Geben Sie im Abschnitt Aus Galerie hinzufügen im Suchfeld AnyConnect ein, wählen Sie Cisco AnyConnect aus dem Ergebnisfenster, und fügen Sie dann die App hinzu. 

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

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

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-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 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 Benutzer und Gruppen aus, und klicken Sie dann auf Benutzer hinzufügen. 

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

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 Identitätsanbieters 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 mit Ihrer VPN-URL her, und geben Sie die Azure AD-Details ein.

Schritt 2: Genehmigen der Anmeldeanforderung

Schritt 3: AnyConnect ist verbunden.

Häufige Probleme

Entitäts-ID stimmt nicht überein

Debug-Beispiel: 

 [SAML] consume_assertion: Die ID eines Anbieters ist #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-Element-ID übereinstimmt, die in den Metadaten der IDp gefunden wurde. 

Lösung: Überprüfen Sie die Entitäts-ID der Metadatendatei der IdP, und ändern Sie den Befehl saml idp [entity id] 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 für die Nachricht nicht überprüfen. 

Problem: Die ASA konnte die von der IdP signierte Nachricht nicht überprüfen, oder es ist keine Signatur vorhanden, die von der ASA überprüft werden muss. 

Lösung: Überprüfen Sie das auf dem ASA installierte IdP-Signaturzertifikat, um sicherzustellen, dass es mit dem übereinstimmt, was vom IdP gesendet wird. 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: Assertionszielgruppe ist ungültig 

Problem: IdP definiert die falsche Zielgruppe.

Lösung: Korrigieren Sie die Zielgruppenkonfiguration für die IdP. Sie muss mit der Objektkennung der ASA übereinstimmen. 

  

Falsche URL für Assertion Consumer Service

Beispiel-Debugging: Nach dem Senden der ursprünglichen Authentifizierungsanforderung konnten keine Debugging-Meldungen 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: Nach der Änderung oder Änderung einer einmaligen Anmelde-URL funktioniert das SP-Zertifikat 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 Ä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 gefunden werden kann. 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 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