--- schema_version: "1" id: fbf6ee76cf5d812945867a5d31546f87f04b95e778a530798040b620781cef03 title: Configurer SAML avec l’IdP Azure AD sur Tableau Server collection: tableau version: current locale: fr-fr portal_url: https://docs.salesforce.com/tableau/current/fr-fr/server-linux/saml_config_azure_server.md canonical_url: https://help.tableau.com/current/server-linux/fr-fr/saml_config_azure_server.htm source_site: help.tableau.com content_type: documentation content_hash: 6f0e15546434e99917a914c1becfb9fa5b59b799098dbdd79148f519540979c5 description: Configure Azure AD as a SAML identity provider for Tableau Server. --- [Passer au contenu principal](#main-content) # Configurer SAML avec l’IdP Azure AD sur Tableau Server Vous pouvez configurer Azure AD en tant que fournisseur d’identités (IdP) SAML et ajouter Tableau Server à vos applications d’authentification unique (SSO) prises en charge. Lorsque vous intégrez Azure AD avec SAML et Tableau Server, vos utilisateurs peuvent se connecter à Tableau Server en utilisant leurs identifiants réseau standard. ## Avant de commencer : Prérequis Pour que vous puissiez configurer Tableau Server et SAML avec Azure AD, votre environnement doit se présenter ainsi : - Certificat SSL crypté à l’aide du cryptage SHA-2 (256 ou 512 bits) et répondant aux exigences supplémentaires énumérées dans les sections suivantes : - [Exigences relatives aux certificats SSL](https://help.tableau.com/current/server-linux/fr-fr/ssl_config.htm#cert-req) - [Conditions liées au certificat et au fournisseur d’identité (IdP)](https://help.tableau.com/current/server-linux/fr-fr/saml_requ.htm#Certific) SAML - Si vos utilisateurs se connectent à partir d’un domaine qui n’est pas le domaine par défaut, consultez les sections [Exigences en matière d’authentification SAML](https://help.tableau.com/current/server-linux/fr-fr/saml_requ.htm#multiple_domain) et [Gestion des utilisateurs dans les déploiements avec magasins d’identités externes](https://help.tableau.com/current/server-linux/fr-fr/users_manage_ad.htm#multiple_domain) pour vous assurer que la valeur de l’attribut de domaine est configurée et définie de manière à éviter tout problème de connexion ultérieurement. ## Étape 1 : Vérifier la connexion SSL à Azure AD Azure AD nécessite une connexion SSL. Si vous ne l’avez pas encore fait, effectuez les étapes décrites dans [Configurer SSL pour le trafic HTTP externe vers et depuis Tableau Server](https://help.tableau.com/current/server-linux/fr-fr/ssl_config.htm), en utilisant un certificat répondant aux exigences spécifiées ci-dessus. Alternativement, si Tableau Server est configuré pour fonctionner avec un proxy inverse ou un équilibreur de charge sur lequel SSL est terminé (communément appelé déchargement de SSL), alors vous n’avez pas besoin de configurer SSL externe. Si votre entreprise utilise le Proxy d’application Azure AD, consultez la section ci-dessous, [Proxy d’application Azure AD](#AzureAppProxy). ## Étape 2: Configurer SAML sur Tableau Server Effectuez les étapes décrites dans [Configurer SAML à l’échelle du serveur](https://help.tableau.com/current/server-linux/fr-fr/config_saml.htm) en téléchargeant les métadonnées Tableau Server dans un fichier XML. À ce stade, revenez ici et passez à la section suivante. ## Étape 3 : Configurer les règles de revendication Azure AD Le mappage est sensible à la casse et nécessite une orthographe exacte, vérifiez donc votre saisie par deux fois. Le tableau ci-dessous montre les attributs communs et les mappages de revendications. Il est conseillé de vérifier les attributs avec votre configuration Azure AD spécifique.
Attribut LDAPType de revendication envoyée
onpremisessamaccountnameusername
Prénom

Prénom

Remarque : paramètre facultatif.

Surnom

Nom

Remarque : paramètre facultatif.

netbiosname

domain

Remarque : paramètre requis uniquement si des utilisateurs se connectent depuis un domaine qui n’est pas le domaine par défaut.

Dans certaines entreprises, Azure AD en tant qu’IdP SAML est utilisé avec Active Directory comme magasin d’identités pour Tableau Server. Dans ce cas, `username` est généralement le nom sAMAccountName. Consultez la documentation de Microsoft pour identifier l’attribut sAMAccountName dans Azure AD afin de mapper l’attribut `username`. ## Étape 4 : Fournir les métadonnées Azure AD à Tableau Server 1. Revenez à l’interface utilisateur Web TSM et accédez à l’onglet Configuration > Identité de l’utilisateur et accès > Méthode d’authentification. 2. À l’étape 4 du volet de configuration SAML, entrez l’emplacement du fichier XML que vous avez exporté depuis Azure AD, et sélectionnez Charger. ![](/tableau/current/fr-fr/server-linux/fr-fr/Img/saml_config_upload_idp_metadata_linux.png) 3. Effectuez les étapes restantes (faire correspondre les assertions et spécifier le type d’accès au client) comme indiqué dans [Configurer SAML à l’échelle du serveur](https://help.tableau.com/current/server-linux/fr-fr/config_saml.htm). Enregistrez et appliquez les modifications. 4. Effectuez les étapes suivantes si ce n’est pas la première fois que vous configurez SAML : 1. Arrêtez Tableau Server, ouvrez l’interface en ligne de commande TSM et exécutez les commandes suivantes. `tsm configuration set -k wgserver.saml.sha256 -v true` `tsm authentication saml configure -a -1` 2. Appliquez les modifications : `tsm pending-changes apply` Si les modifications en attente nécessitent un redémarrage du serveur, la commande `pending-changes apply` affichera une invite pour vous informer qu’un redémarrage va avoir lieu. Cette invite s’affiche même si le serveur est arrêté, mais dans ce cas, il n’y a pas de redémarrage. Vous pouvez supprimer l’invite à l’aide de l’option `--ignore-prompt`, mais cela ne modifiera pas le comportement de redémarrage. Si les modifications ne nécessitent pas de redémarrage, les modifications sont appliquées sans invite. Pour plus d’informations, consultez [tsm pending-changes apply](https://help.tableau.com/current/server-linux/fr-fr/cli_pending-changes.htm#pending-changes-apply). ## Proxy d’application Azure AD Si vous exécutez le proxy d’application Azure AD devant Tableau Server et que SAML est activé, vous devrez effectuer une configuration supplémentaire sur le proxy d’application Azure AD. Tableau Server ne peut accepter le trafic qu’à partir d’une seule URL lorsque SAML est activé. Par défaut toutefois, le Proxy d’application Azure AD définit une URL externe et une URL interne. Vous devez définir ces deux valeurs sur la même URL dans votre domaine personnalisé. Pour plus d’informations, consultez la documentation Microsoft, [Configurer des domaines personnalisés avec le Proxy d’application Azure AD](https://docs.microsoft.com/fr-fr/azure/active-directory/manage-apps/application-proxy-configure-custom-domain). ## Résolution des problèmes **Proxy d’application Azure AD** Dans certains cas, les liens vers les vues génèrent un rendu en interne mais échouent en externe lorsque le trafic traverse un proxy d’application Azure AD. Le problème se pose lorsque l’URL contient un signe dièse (#) et que les utilisateurs accèdent au lien avec un navigateur. L’application Tableau Mobile est capable d’accéder aux URL avec un signe dièse. **Les délais d’expiration des sessions utilisateur semblent être ignorés** Lorsque Tableau Server est configuré pour SAML, les utilisateurs peuvent rencontrer des erreurs de connexion car le paramètre d’âge d’authentification maximum de l’IdP est défini sur une valeur supérieure au paramètre d’âge d’authentification maximum de Tableau. Pour résoudre ce problème, vous pouvez utiliser l’option tsm configuration set `wgserver.saml.forceauthn` pour demander à l’IdP de ré-authentifier l’utilisateur chaque fois que Tableau redirige la demande d’authentification, même si la session IdP de l’utilisateur est toujours active. Par exemple, lorsque le paramètre Azure AD `maxInactiveTime` est supérieur au paramètre de Tableau Server `maxAuthenticationAge`, Tableau redirige la demande d’authentification vers l’IdP qui envoie ensuite à Tableau une assertion indiquant que l’utilisateur est déjà authentifié. Cependant, étant donné que l’utilisateur a été authentifié en dehors du paramètre `maxAuthenticationAge` de Tableau Server, Tableau rejette l’authentification de l’utilisateur. Dans un tel cas, vous pouvez effectuer l’une des procédures suivantes : - Activer l’option `wgserver.saml.forceauthn` pour demander à l’IdP de ré-authentifier l’utilisateur chaque fois que Tableau redirige la demande d’authentification. Consultez [wgserver.saml.forceauthn](https://help.tableau.com/current/server-linux/fr-fr/cli_configuration-set_tsm.htm#wgserver-saml-forceauthn) pour plus d’informations. - Augmentez le paramètre `maxAuthenticationAge` de Tableau Server. Pour plus d’informations, consultez « a, --max-auth-age » dans la rubrique [tsm authentication](https://help.tableau.com/current/server-linux/fr-fr/cli_authentication_tsm.htm#tsm-authentication-saml-configure). **Non-concordance d’AppID** Lors de l’examen du fichier vizportal.log, vous pouvez voir le message d’erreur suivant : « _The intended audience doesn’t match the recipient_ » (Le public visé ne correspond pas au destinataire). Pour résoudre ce problème, assurez-vous que l’appID correspond à ce qui est envoyé. Azure ajoutera automatiquement « SPN » à l’appID lors de l’utilisation de l’ID d’application avec l’application utilisée. Vous pouvez modifier la valeur dans les paramètres Tableau SAML en ajoutant le préfixe « SPN: » à l’ID d’application, par exemple SPN:myazureappid1234