Exigences d’approbation de domaine pour les déploiements Active Directory
Lorsque vous exécutez Tableau Server dans un environnement Active Directory entre plusieurs domaines (soit dans la même forêt Active Directory soit dans des forêts différentes), certaines fonctionnalités de Tableau sont dépendantes de la relation de confiance entre les domaines. Par exemple, certains administrateurs gèrent les utilisateurs dans des domaines distincts d’où ils déploient des applications de serveur, comme Tableau Server. Dans d’autres structures, un déploiement de Tableau Server peut être partagé avec des partenaires externes ou avec différents partenaires au sein de l’entreprise. Enfin, les sources de données authentifiées par Windows, telles que SQL Server, MSAS ou Oracle, auxquelles Tableau Server se connecte peuvent aussi résider dans d’autres domaines.
Si possible, nous recommandons la configuration d’une relation de confiance bidirectionnelle entre tous les domaines qui interagissent avec Tableau Server. Sinon, Tableau Server peut être configuré de sorte à prendre en charge l’authentification des utilisateurs dans les cas où une relation de confiance unidirectionnelle a été configurée. Dans ce cas, la relation de confiance unidirectionnelle est prise en charge lorsque le domaine dans lequel Tableau Server est installé est configuré pour faire confiance au domaine où les comptes utilisateur résident.
L’illustration suivante représente une relation de confiance unidirectionnelle entre le domaine dans lequel Tableau Server est installé et celui où les comptes utilisateur résident :
Dans ce cas de figure, Tableau Server est installé dans le domaine dev.local et les utilisateurs du domaine Active Directory users.lan sont importés dans Tableau Server. Une relation unidirectionnelle est nécessaire ici. En particulier, le domaine dev.local est configuré pour faire confiance au domaine users.lan. Les utilisateurs du domaine users.lan peuvent accéder à Tableau Server dans le domaine dev.local au moyen de leurs informations d’identification Active Directory ordinaires. Toutefois, il vous faudra peut-être modifier le surnom du domaine dans Tableau Server pour que les utilisateurs puissent se connecter avec. Consultez Tableau Knowledge Base(Le lien s’ouvre dans une nouvelle fenêtre) pour plus d’informations.
Lorsque vous configurez Tableau Server pour ce scénario, spécifiez le domaine utilisateur principal durant l’installation. Consultez Configurer les paramètres du nœud initial. Pour être sûr que Tableau Server puisse se connecter à d’autres domaines Active Directory, vous devez également spécifier d’autres domaines auxquels Tableau Server se connecte en définissant l’option wgserver.domain.accept_list avec TSM. Pour plus d’informations, consultez wgserver.domain.accept_list.
Le compte Exécuter en tant que service doit également demander un accès (en lecture) à chaque domaine depuis lequel les utilisateurs seront importés.
L’authentification unique Kerberos est prise en charge avec cette relation de confiance unidirectionnelle.
Consultez la Gestion des utilisateurs dans les déploiements avec magasins d’identités externes pou comprendre comme le format des domaines multiples, des domaines, des noms de domaine, NetBIOS et du nom d’utilisateur Active Directory influence la gestion utilisateur de Tableau.
Connexion à des données en direct dans des relations de confiance unidirectionnelles.
Dans une relation de confiance unidirectionnelle, les utilisateurs qui se connectent à Tableau Server peuvent se connecter aux données en direct hébergées dans le nuage ou dans un autre source de données locale qui ne dépend pas de l’authentification Windows.
Les sources de données nécessitant une authentification Windows sont parfois associées à d’autres contraintes d’authentification qui compliquent le cas de figure ou empêchent même les utilisateurs Tableau Server de se connecter. La raison est que Tableau Server utilise