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.
Dupliquer des comptes de liaison pour l’approbation de domaine
Tableau Server sur Linux s’appuie sur l’implémentation LDAP de JDK qui utilise une liaison simple pour l’authentifier avec Active Directory. La liaison simple ne tient pas compte du domaine et, par conséquent, ne prend pas en charge une liaison inter-domaines. Lorsque vous configurez le magasin d’identité initial, vous devez fournir le compte de liaison que vous utiliserez pour vous authentifier dans Active Directory.
Pour activer l’approbation inter-domaines et les recherches dans les répertoires, vous devez dupliquer ce compte de liaison dans chaque domaine cible. Chaque compte de liaison dans chaque domaine doit utiliser le même nom d’utilisateur (sAMAccountName
ou dn
) et le même mot de passe.
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 cloud 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