Dépannage des problèmes courants avec SAML sur ASA et FTD

Introduction

Ce document décrit les problèmes les plus courants rencontrés lors du dépannage de SAML sur les appareils Cisco ASA et FTD.

Conditions préalables

Exigences

Cisco vous recommande de prendre connaissance des rubriques suivantes :

• Configuration du fournisseur d'identité (IdP) SAML
• Configuration d'un objet d'authentification unique Cisco Secure ASA Firewall ou Firepower Threat Defense (FTD)
• VPN AnyConnect Cisco Secure Client

Composants utilisés

Le guide des meilleures pratiques est basé sur les versions matérielles et logicielles suivantes :

• Cisco ASA 9.x
• Firepower Threat Defense 7.x / FMC 7.x

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.

Informations générales

SAML (Security Assertion Markup Language) est un cadre XML d'échange de données d'authentification et d'autorisation entre domaines de sécurité. Il crée un cercle de confiance entre l'utilisateur, un fournisseur de services (SP) et un fournisseur d'identité (IdP) qui permet à l'utilisateur de se connecter une seule fois pour plusieurs services. SAML peut être utilisé pour l'authentification VPN d'accès à distance pour les connexions du client sécurisé Cisco aux têtes de réseau VPN ASA et FTD, où ASA ou FTD est l'entité SP dans le cercle de confiance.

La plupart des problèmes SAML peuvent être résolus en vérifiant la configuration sur l'IdP et l'ASA/FTD utilisés. Dans les cas où la cause n'est pas claire, les débogages donnent plus de clarté et les exemples dans ce guide proviennent de la commande debug webvpn saml 255.

Le présent document a pour but de fournir une référence rapide sur les problèmes connus liés au SAML et sur les solutions possibles. 

Problèmes courants :

Problème 1 : Incompatibilité des ID d'entité

Explication

Cela signifie généralement que la commande saml idp [entityID] sous la configuration webvpn du pare-feu ne correspond pas à l'ID d'entité du fournisseur d'identité trouvé dans les métadonnées du fournisseur d'identité, comme indiqué dans l'exemple.

Exemple de débogage :

Sep 05 23:54:02 [SAML] consume_assertion: The identifier of a provider is unknown to #LassoServer. To register a provider in a #LassoServer object, you must use the methods lasso_server_add_provider() or lasso_server_add_provider_from_buffer().

De IDP :

<EntityDescriptor ID="_7e53f3f3-7c79-444a-b42d-d60ae13f0948" entityID="https://sts.example.net/69c69fff-03f6-4c9c-be73-9ed4f5f894c/">

À partir de ASA/FTD :

saml idp https://sts.example.net/69c69fff-03f6-4c9c-be73-9ed4f5f894   >>>> The entity ID is missing characters at the end

Solution

Vérifiez l'ID d'entité du fichier de métadonnées du fournisseur d'identités et modifiez la commande saml idp [entity id] pour qu'elle corresponde exactement à ceci, y compris les caractères de barre oblique inverse (/).

Problème 2 : Assertion non valide

Explication

Cela signifie que le pare-feu n'est pas en mesure de valider l'assertion fournie par le fournisseur d'identité, car l'horloge du pare-feu est en dehors de la validité de l'assertion.

Exemple de débogage :

[SAML] consume_assertion: assertion is expired or not valid

Exemple :

[SAML] NotBefore:2022-06-21T09:52:10.759Z NotOnOrAfter:2022-06-21T10:57:10.759Z timeout: 0    >>>>> Validity of the saml assertion provided by the IDP
Jun 21 15:20:46 [SAML] consume_assertion: assertion is expired or not valid

firepower# show clock
15:26:49.240 UTC Tue Jun 21 2022   >>>> Current time on the firewall

Dans l'exemple, nous pouvons voir que l'assertion n'est valide qu'entre 09:52:10.759 UTC à 10:57:10.759 UTC, et l'heure sur le pare-feu est en dehors de cette fenêtre de validité.

Remarque : Le temps de validité vu dans l'assertion est en UTC. Si l'horloge du pare-feu est configurée dans un fuseau horaire différent, elle convertit l'heure en UTC avant validation.

Solution

Configurez l'heure correcte sur le pare-feu manuellement ou à l'aide d'un serveur NTP et vérifiez que l'heure actuelle du pare-feu est dans la validité de l'assertion dans UTC. Si le pare-feu est configuré dans un fuseau horaire différent de UTC, assurez-vous que l'heure est convertie en UTC avant de vérifier la validité de l'assertion.

Problème 3 : la signature ne vérifie pas

Explication

Lorsque le pare-feu ne parvient pas à vérifier la signature de l'assertion SAML reçue du fournisseur d'identité en raison d'un certificat de fournisseur d'identité incorrect configuré sous la configuration webvpn du pare-feu avec la commande trustpoint idp <trustpoint>.

Exemple de débogage :

[Lasso] func=xmlSecOpenSSLEvpSignatureVerify:file=evp_signatures.c:line=372:obj=rsa-sha256:subj=unknown:error=18:data do not match:details=EVP_VerifyFinal: signature does not verify

Solution

Téléchargez et installez le certificat à partir du fournisseur d'identité sur le pare-feu et attribuez le nouveau point de confiance sous la configuration webvpn du pare-feu. Le certificat de signature du fournisseur d'identité se trouve généralement dans les métadonnées du fournisseur d'identité ou dans la réponse SAML décodée.

Problème 4 : URL incorrecte pour Assertion Consumer Service

Explication

IdP est configuré avec une URL de réponse incorrecte (URL du service client d'assertion).

Exemples

Exemple de débogage :

Aucun débogage n'est affiché après l'envoi de la demande d'authentification initiale. L'utilisateur peut entrer des informations d'identification, mais après l'échec de cette connexion, aucun débogage n'est imprimé.

De IDP :

À partir des métadonnées FW ou SP :

<AssertionConsumerService index="0" isDefault="true" Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://ac-vpn.local/+CSCOE+/saml/sp/acs?tgname=acvpn" />

Dans l'exemple, on peut voir que l'« URL du service client d'assertion » sur le fournisseur d'identité ne correspond pas à l'emplacement sur les métadonnées du fournisseur de services.

Solution

Modifiez l'URL du service client d'assertion sur le fournisseur d'identité comme indiqué dans les métadonnées du fournisseur de services. Les métadonnées du SP peuvent être obtenues à l'aide de la commande show saml metadata <tunnel-group-name>.

Problème 5 : L'audience d'assertions est incorrecte

Explication

Lorsque le fournisseur d'identité envoie une destination incorrecte dans la réponse SAML, telle que le groupe de tunnels incorrect.

Exemple de débogage :

[SAML] consume_assertion: assertion audience is invalid

À partir de la trace SAML :

<samlp:Response ID="_36585f72-f813-471b-b4fd-3663fd24ffe8"
Version="2.0"
IssueInstant="2022-06-21T11:36:26.664Z" 
Destination="https://ac-vpn.local/+CSCOE+/saml/sp/acs?tgname=acvpn1"

Recipient="https://ac-vpn.local/+CSCOE+/saml/sp/acs?tgname=acvpn1"

<AudienceRestriction> <Audience>https://ac-vpn.local/saml/sp/metadata/acvpnAudience> AudienceRestriction>

À partir du pare-feu ou des métadonnées SP :

<AssertionConsumerService index="0" isDefault="true" Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://ac-vpn.local/+CSCOE+/saml/sp/acs?tgname=acvpn" />

Solution

Corrigez la configuration sur l'IDP car la destination et le destinataire dans la réponse SAML doivent correspondre à l'emplacement tel qu'indiqué dans les métadonnées du pare-feu/SP dans le résultat de la commande show saml metadata <tunnel-group-name>.

Problème 6 : Les modifications de configuration SAML ne prennent pas effet

Explication

Après toute modification avec la configuration SAML sous webvpn, il est suggéré de supprimer et de rajouter la commande saml identity-provider <IDP-Entity-ID> sous le tunnel-group.

Solution

Supprimez et ajoutez à nouveau la commande saml identity-provider <IDP-Entity-ID> sous le tunnel-group.

Problème 7 : Comment utiliser le même IDP sous plusieurs profils tunnel-group/connection

Explication

Afin de configurer l'authentification SAML pour utiliser la même application SSO IdP pour plusieurs groupes de tunnels, suivez les étapes de configuration ci-dessous.

Solutions

Option 1 pour ASA 9.16 et versions antérieures, FTD géré par FDM ou FMC/FTD 7.0 et versions antérieures :

• Créez des applications SSO distinctes sur l'IdP, une pour chaque groupe de tunnels/profil de connexion.
• Créez un CSR à l'aide du CN par défaut utilisé par l'IDP.
• Signez le CSR auprès d'une autorité de certification interne/externe.
• Installez le même certificat d'identité signé sur les applications à utiliser pour des groupes de tunnels ou des profils de connexion distincts.

Option 2 pour ASA 9.17.1 et versions ultérieures ou FTD/FMC 7.1 et versions ultérieures :

• Créez des applications SSO distinctes sur l'IdP, une pour chaque groupe de tunnels/profil de connexion.
• Téléchargez les certificats de chaque application et téléchargez-les sur l'ASA ou le FTD.
• Attribuez le point de confiance qui correspond à l'application IdP pour chaque groupe de tunnels/profil de connexion.

Problème 8 : échec de l'authentification en raison d'un problème lors de la récupération du cookie d'authentification unique

Explication

Ceci peut être vu sur le logiciel Secure Client sur le périphérique client pour plusieurs raisons, notamment, mais sans s'y limiter :

• La validité de l'assertion est en dehors de l'heure actuelle du FW.
• L'ID d'entité ou l'URL du service client d'assertion est incorrectement défini sur l'IDP.

Solution

• Exécutez des débogages sur le pare-feu et recherchez des erreurs spécifiques.
• Vérifiez l'ID d'entité et l'URL du service client d'assertion configurés sur l'IDP par rapport aux métadonnées obtenues du FW.

Problème 9 : Discordance de hachage d'état de relais

Explications

• Le paramètre RelayState a pour but de permettre au protocole d'identification de rediriger l'utilisateur vers la ressource d'origine demandée après une authentification SAML réussie. Les informations RelayState de l'assertion doivent correspondre aux informations RelayState à la fin de l'URL de la demande d'authentification.
• Cela peut être une indication d'une attaque MitM, mais peut également être provoqué par des modifications de l'état du relais du côté IdP.

Exemple de débogage :

[SAML] relay-state hash mismatch.

Solution

• Passez à une version fixe comme détaillé dans l'ID de bogue Cisco CSCwf85757
• Vérifiez que l'IdP ne modifie pas les informations RelayState.

Dépannage supplémentaire

Bien que la plupart des dépannages SAML puissent être effectués avec seulement la sortie du débogage saml webvpn, il y a des moments où des débogages supplémentaires peuvent être utiles pour identifier la cause d'un problème.

firepower# debug webvpn saml 255
firepower# debug webvpn 255
firepower# debug webvpn session 255
firepower# debug webvpn request 255

Informations connexes

• Assistance technique de Cisco et téléchargements
• Guides de configuration ASA
• Guides de configuration FMC/FDM