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 chiffré à l’aide du chiffrement 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
- Conditions liées au certificat et au fournisseur d’identité (IdP) 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 et Gestion des utilisateurs dans les déploiements avec magasins d’identités externes 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, 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.

Étape 2 : Configurer SAML sur Tableau Server

Effectuez les étapes décrites dans Configurer SAML à l’échelle du serveur 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 LDAP	Type de revendication envoyée
onpremisessamaccountname	username
Prénom	Prénom Remarque : ceci est facultatif.
Surnom	Nom Remarque : ceci est 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 que fournisseur d’identités 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

Revenez à l’interface utilisateur Web TSM et accédez à l’onglet Configuration > Identité de l’utilisateur et accès > Méthode d’authentification.
À l’étape 4 du volet de configuration SAML, entrez l’emplacement du fichier XML que vous avez exporté depuis Azure AD, et sélectionnez Téléverser.
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. Enregistrez et appliquez les modifications.
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.

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(Le lien s’ouvre dans une nouvelle fenêtre).

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 pour plus d’informations.
Augmentez le paramètre maxAuthenticationAge de Tableau Server. Pour plus d’informations, consultez « a, --max-auth-age<max-auth-age> » dans la rubrique tsm authentication.

Non-concordance d’AppID

Lors de l’examen du fichier vizportal.log, vous pouvez voir l’erreur « 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

Retour en haut

Aide de Tableau Server sur Linux