Référence de configuration du magasin d’identités externe
Tableau Server prend en charge la connexion à un répertoire externe à l’aide de LDAP. Dans ce scénario, Tableau Server importe des utilisateurs du répertoire LDAP externe dans le référentiel Tableau Server en tant qu’utilisateurs système.
Cette rubrique décrit toutes les options de configuration associées à LDAP et prises en charge par Tableau Server. Si vous vous connectez à Active Directory, nous vous recommandons vivement de configurer automatiquement la connexion LDAP avec Tableau Server dans le cadre de l’installation, plutôt que de configurer la connexion manuellement. Consultez Configurer les paramètres du nœud initial.
Les options répertoriées dans cette référence peuvent être utilisées pour n’importe quel répertoire compatible LDAP. Si vous n’avez pas d’expérience dans la configuration de LDAP, travaillez avec votre administrateur de répertoires ou avec un expert LDAP.
Il s’agit d’une rubrique de référence. Pour plus d’informations sur la façon dont Tableau Server stocke et gère les utilisateurs, commencez par Magasin d’identités.
Méthodes de configuration
Les paramètres de configuration qui permettent à Tableau Server de se connecter à votre répertoire LDAP sont stockés dans des fichiers .yml. Ces fichiers sont gérés et synchronisés par différents services dans Tableau Server. La mise à jour des fichiers .yml doit se faire à l’aide d’une interface Tableau Services Manager (TSM).
N’essayez pas de mettre à jour les fichiers .yml directement avec un éditeur de texte. TSM doit gérer toutes les mises à jour pour un bon fonctionnement.
Les fichiers de configuration .yml sont composés de paires de valeurs/clés. Par exemple, la clé wgserver.domain.username
prend un nom d’utilisateur comme une valeur. Cette clé définit le nom d’utilisateur qui sera utilisé pour l’authentifier sur le répertoire LDAP pendant l’opération de liaison.
Il existe quatre méthodes TSM différentes de définition des valeurs de clé yml. Les quatre méthodes sont décrites ici, en utilisant la clé wgserver.domain.username
comme exemple d’illustration des différentes méthodes :
Paires de clé-valeur configKey — Vous pouvez mettre à jour une clé de fichier de configuration .yml en mettant à jour la clé
wgserver.domain.username
exécutant Options tsm configuration set, ou en incluant la clé dans un fichier de configuration JSON sous une entité configKey. Consultez Exemple de fichier de configuration.Les paires de clé-valeur configKey dans un fichier de configuration JSON sont les mêmes que celles utilisées pour
tsm configuration set
, mais elles sont définies différemment. Cette rubrique fait référence à ces deux méthodes en tant que configKey.À la différence de configEntities et des commandes tsm natives décrites ci-dessous, l’entrée configKey n’est pas validée. Lorsque vous définissez une option avec une configKey, la valeur que vous entrez est copiée en tant que chaîne littérale dans les fichiers de configuration .yml sous-jacents. Par exemple, pour une clé où
true
oufalse
sont les entrées valides, lorsque vous configurez la clé à l’aide d’une paire de clé-valeur configKey, vous pouvez saisir une chaîne arbitraire, qui sera enregistrée pour la clé. Dans de tels cas, les valeurs non valides entraîneront sans aucun doute des erreurs de configuration LDAP.Nous vous recommandons d’utiliser des configKeys uniquement lorsqu’il n’existe pas d’option pour définir la configuration avec les trois autres options énumérées ci-dessous (configEntities, une commande tsm native ou l’interface utilisateur Web TSM). Lorsque vous utilisez des configKeys, assurez-vous de vérifier vos valeurs et faites attention à respecter la casse.
Fichier JSON configEntities — Vous pouvez mettre à jour un fichier de configuration .yml en transmettant l’option
username
dans un fichier JSON configEntities.Lorsque vous configurez une valeur à l’aide d’options configEntities dans un fichier JSON, les valeurs sont validées avant d’être enregistrées. Les valeurs sont sensibles à la casse. Pour plus de détails sur la façon de configurer une valeur à l’aide de configEntities, consultez l’exemple Entité identityStore. Le fichier JSON est importé avec la commande tsm settings import. Les options disponibles pour configEntities sont un sous-ensemble de toutes les paires de clé-valeur .yml.
La validation signifie que la commande d’importation ne réussira que si toutes les valeurs du fichier JSON sont des types de données valides. Par exemple, si vous entrez
no
pour une valeur qui accepte uniquementtrue
oufalse
, une erreur s’affichera et la configuration ne sera pas importée.Vous ne pouvez importer des fichiers de configuration JSON que dans le cadre de la configuration initiale. Si vous devez effectuer des modifications LDAP après avoir importé le fichier de configuration JSON et initialisé Tableau Server, n’essayez pas de ré-importer le fichier JSON. Apportez plutôt des modifications aux clés individuelles avec des commandes tsm natives, ou en utilisant configKeys et
tsm configuration set
.Commandes tsm natives — Vous pouvez mettre à jour un fichier de configuration .yml en transmettant l’option
ldapuser
avec la commande tsm nativetsm user-identity-store
. Comme avec configEntities, les valeurs que vous entrez à l’aide de la commande tsm native sont validées avant d’être enregistrées.Les paires de clé-valeur d’un fichier .yml ne peuvent pas toutes être définies à l’aide de commandes tsm natives.
TSM GUI — Vous pouvez définir des valeurs de configuration pendant l’installation, à l’aide de l’interface graphique utilisateur TSM. Si vous vous connectez à Active Directory et que vous configurez le magasin d’identités Tableau pendant l’installation à l’aide de l’interface utilisateur, un compte avec accès en lecture AD vous sera demandé. La clé
wgserver.domain.username
est définie lorsque vous entrez des identifiants.Ce scénario ne fonctionne que si vous vous connectez à Active Directory. Tableau Server ne prend pas en charge la configuration LDAP arbitraire dans le cadre du processus d’installation de l’interface graphique.
Envisagez d’utiliser l’Outil de configuration du magasin d’identités Tableau(Le lien s’ouvre dans une nouvelle fenêtre) pour générer votre fichier de configuration LDAP json. L’Outil de configuration du magasin d’identités Tableau génère également une liste de paires de clé/valeur que vous pouvez configurer en exécutant Options tsm configuration set. L’outil lui-même n’est pas pris en charge par Tableau. Par contre, si vous utilisez un fichier JSON créé par l’outil au lieu de créer un fichier manuellement, l’état de prise en charge de votre serveur n’est pas modifié.
Configuration d’Active Directory
Si vous configurez Tableau Server pour utiliser Active Directory, nous vous recommandons d’utiliser l’interface utilisateur Web TSM pendant l’installation. L’interface utilisateur Web TSM est optimisée pour la configuration de Tableau Server pour Active Directory en minimisant la saisie. Consultez Configurer les paramètres du nœud initial.
Table de référence de la configuration
Option configEntities (Vous devez respecter la casse des options) | Commande tsm native | configKey (Utilisé avec la commande tsm configuration set ou dans la section configKeys d’un fichier JSON) | Scénario | Remarques |
---|---|---|---|---|
type | S.O. | wgserver.authenticate | AD, LDAP, Local | Emplacement où vous souhaitez enregistrer les informations d’identité de l’utilisateur. Valeurs : local ou activedirectory .Si vous souhaitez vous connecter à un serveur LDAP, entrez |
sslPort | S.O. | wgserver.domain.ssl_port | AD, LDAP | Utilisez cette option pour spécifier le port sécurisé du serveur LDAP. Nous recommandons LDAP sécurisé pour la liaison simple. LDAPS est généralement le port 636. |
port | S.O. | wgserver.domain.port | AD, LDAP | Utilisez cette option pour spécifier le port non sécurisé du serveur LDAP. Le texte simple est généralement 389. |
domain | domain | wgserver.domain.default | AD | Dans des environnements Active Directory, spécifiez le domaine sur lequel Tableau Server est installé, par exemple « example.lan ». Pour l’authentification LDAP non-AD : la chaîne que vous entrez pour cette valeur s’affiche dans la colonne « Domaine » des outils de gestion des utilisateurs. Vous pouvez entrer une chaîne arbitraire, mais la clé ne peut pas être vide. Cette clé est redondante avec wgserver.domain.fqdn. Les valeurs des deux clés doivent être identiques. Commande tsm native : utilise la commande tsm user-identity-store set-connection [options]. |
username | ldapusername | wgserver.domain.username | AD, LDAP | Nom d’utilisateur que vous souhaitez utiliser pour vous connecter au service de répertoire. Le compte que vous spécifiez doit être autorisé à interroger le service de répertoire. Pour Active Directory, entrez le nom d’utilisateur, par exemple, Pour les serveurs LDAP, entrez le nom unique de l’utilisateur à utiliser pour la connexion. Par exemple, Commande tsm native : utilise la commande tsm user-identity-store set-connection [options]. |
password | ldappassword | wgserver.domain.password | AD, LDAP | Mot de passe du compte utilisateur que vous souhaitez utiliser pour vous connecter au serveur LDAP. Commande tsm native : utilise la commande tsm user-identity-store set-connection [options]. |
directoryServiceType | S.O. | wgserver.domain.directoryservice.type | AD, LDAP | Type de service de répertoire LDAP auquel vous souhaitez vous connecter. Valeurs : activedirectory ou openldap . |
kerberosPrincipal | kerbprincipal | wgserver.domain.ldap.principal | AD, LDAP | Nom SPN (Service Principal Name) pour Tableau Server sur l’ordinateur hôte. Le fichier keytab doit disposer d’autorisations pour ce nom SPN. klist -k . Consultez Comprendre la configuration requise du fichier keytab.Commande tsm native : utilise la commande tsm user-identity-store set-connection [options]. |
hostname | hostname | wgserver.domain.ldap.hostname | AD, LDAP | Nom d’hôte du serveur LDAP. Vous pouvez entrer un nom d’hôte ou une adresse IP pour cette valeur. L’hôte que vous indiquez ici sera utilisé pour les requêtes des utilisateurs/groupes sur le domaine principal. Dans le cas où les requêtes des utilisateurs/groupes se font dans d’autres domaines, Tableau Server interrogera le DNS pour identifier le contrôleur de domaine approprié. Commande tsm native : utilise la commande tsm user-identity-store set-connection [options]. |
membersRetrievalPageSize | S.O. | wgserver.domain.ldap.members.retrieval.page.size | AD, LDAP | Cette option détermine le nombre maximum de résultats renvoyés par une requête LDAP. Par exemple, envisagez un scénario où Tableau Server importe un groupe LDAP contenant 50 000 utilisateurs. Il est déconseillé de tenter d’importer un nombre si important d’utilisateurs en une seule opération. Lorsque cette option est définie sur 1500, Tableau Server importe les 1500 premiers utilisateurs dans la première réponse. Une fois que ces utilisateurs ont été traités, Tableau Server demande les 1500 utilisateurs suivants auprès du serveur LDAP, et ainsi de suite. Nous vous recommandons de modifier cette option uniquement de manière à répondre aux exigences de votre serveur LDAP. |
S.O. | S.O. | wgserver.domain.ldap.connectionpool.enabled | AD, LDAP | Lorsque cette option est définie sur true , Tableau Server tente de réutiliser la même connexion pour l’envoi de requêtes au serveur LDAP. Ce comportement diminue la charge de de devoir se réauthentifier auprès du serveur LDAP pour chaque nouvelle demande. La mise en commun des connexions fonctionne uniquement avec les connexions de liaison simple et liaison TSL/SSL. La mise en commun des connexions n’est pas prise en charge pour les connexions avec liaison GSSAPI. |
S.O. | S.O. | wgserver.domain.accept_list | AD | Permet la connexion depuis Tableau Server aux domaines Active Directory : secondaires. Un domaine secondaire est celui auquel Tableau Server se connecte pour la synchronisation utilisateur, mais est un domaine où Tableau Server n’est pas installé. Pour vous assurer que Tableau Server peut se connecter à d’autres domaines Active Directory, vous devez spécifier les domaines de confiance en définissant l’option wgserver.domain.accept_list avec TSM. Pour plus d’informations, consultez wgserver.domain.accept_list. |
S.O. | S.O. | wgserver.domain.whitelist | AD | Important : obsolète depuis la version 2020.4.0. Utilisez wgserver.domain.accept_list à la place. Permet la connexion depuis Tableau Server aux domaines Active Directory : secondaires. Un domaine secondaire est celui auquel Tableau Server se connecte pour la synchronisation utilisateur, mais est un domaine où Tableau Server n’est pas installé. Pour vous assurer que Tableau Server peut se connecter à d’autres domaines Active Directory, vous devez spécifier les domaines de confiance en définissant l’option |
kerberosConfig | kerbconfig | Aucun mappage direct | AD, LDAP | Chemin d’accès du fichier de configuration Kerberos sur l’ordinateur local. Si vous effectuez l’installation sur Active Directory, nous déconseillons d’utiliser le fichier de configuration Kerberos ou le fichier keytab existant qui se trouve peut-être déjà sur l’ordinateur personnel lié au domaine. Consultez Magasin d’identités Commande tsm native : utilise la commande tsm user-identity-store set-connection [options]. |
kerberosKeytab | kerbkeytab | Aucun mappage direct | AD, LDAP | Chemin d’accès du fichier keytab Kerberos sur l’ordinateur local. Il est recommandé de créer un fichier keytab avec des clés spécifiquement pour le service Tableau Server et de ne pas partager le fichier keytab avec d’autres applications sur l’ordinateur. Commande tsm native : utilise la commande tsm user-identity-store set-connection [options]. |
nickname | S.O. | wgserver.domain.nickname | AD, LDAP | Surnom du domaine. Également appelé nom NetBIOS dans les environnements Windows/Active Directory. L’option |
root | S.O. | wgserver.domain.ldap.root | LDAP | Si vous n’utilisez pas un composant dc dans la racine LDAP ou si vous souhaitez spécifier une racine plus complexe, vous devez définir la racine LDAP. Utilisez le format « o=my,u=root ». Par exemple, pour le domaine, example.lan , la racine serait "o=example,u=lan" . |
serverSideSorting | S.O. | wgserver.domain.ldap.server_side_sorting | LDAP | Indique si le serveur LDAP est configuré pour le tri des résultats de la requête côté serveur. Si votre serveur LDAP prend en charge le tri côté serveur, définissez cette option sur true . Si vous n’êtes pas sûr que votre serveur LDAP prenne en charge cette option, entrez false , étant donné qu’une erreur de configuration peut générer des erreurs. |
rangeRetrieval | S.O. | wgserver.domain.ldap.range_retrieval | LDAP | Indique si le serveur LDAP est configuré pour retourner une plage de résultats de requête pour une demande. Cela signifie que les groupes comportant de nombreux utilisateurs seront demandés par ensembles de petite taille plutôt que tous à la fois. Les serveurs LDAP prenant en charge la récupération par plages seront plus performants pour les requêtes volumineuses. Si votre serveur LDAP prend en charge la récupération par plages, définissez cette option sur true . Si vous ignorez si votre serveur LDAP prend en charge la récupération par plages, entrez false , étant donné qu’une erreur de configuration peut provoquer des erreurs. |
bind | S.O. | wgserver.domain.ldap.bind | LDAP | Manière dont vous souhaitez sécuriser la communication avec le service de répertoire. Entrez simple pour LDAP à moins que vous ne vous connectiez à un serveur LDAP avec Kerberos. Pour Kerberos, entrez gssapi . |
S.O. | S.O. | wgserver.domain.ldap.domain_custom_ports.domain | LDAP | Remarque : cette clé n’est prise en charge que pour Tableau Server sous Linux. Permet de mapper les domaines enfants et leurs ports LDAP. Le domaine et le port sont séparés par deux points ( :) et chaque paire domaine :port est séparée par une virgule (,) en utilisant ce format : Exemple : |
distinguishedNameAttribute | S.O. | wgserver.domain.ldap.dnAttribute | LDAP | Attribut stockant les noms uniques des utilisateurs. Cet attribut est facultatif, mais améliore considérablement les performances des requêtes LDAP. Important : ne définissez pas cette option dans le cadre de la configuration initiale. Définissez-la uniquement une fois que vous avez validé la fonctionnalité LDAP globale. Vous devez disposer d’un ensemble dnAttribute dans votre entreprise avant de définir cette clé. |
groupBaseDn | S.O. | wgserver.domain.ldap.group.baseDn | LDAP | Utilisez cette option pour spécifier une racine alternative pour les groupes. Par exemple, si tous vos groupes sont stockés dans l’organisation de base appelée « groups », entrez |
S.O. | classnames | wgserver.domain.ldap.group.classnames | LDAP | Par défaut, Tableau Server recherche les classes d’objet de groupe LDAP contenant la chaîne « group ». Si vos objets de groupe LDAP ne correspondent pas au nom de classe par défaut, remplacez la valeur par défaut en définissant cette valeur. Vous pouvez fournir plusieurs noms de classe en les séparant par des virgules. Si les noms de vos groupes incluent des virgules, vous devez ajouter un échappement avec un trait oblique arrière (\). Par exemple, si vous avez un nom de groupe L’implémentation LDAP de Tableau interprète les objets LDAP soit comme utilisateur, soit comme groupe. Par conséquent, veillez à saisir le nom de classe le plus spécifique. Le chevauchement des noms de classe entre les utilisateurs et les groupes peut provoquer des conflits. Commande tsm native : utilise la commande tsm user-identity-store set-group-mappings [options]. |
groupBaseFilter | basefilter | wgserver.domain.ldap.group.baseFilter | LDAP | Filtre que vous souhaitez utiliser pour les groupes d’utilisateurs de Tableau Server. Vous pouvez spécifier un attribut de classe d’objet et un attribut d’unité organisationnelle. Par exemple :
Si Cette clé est obligatoire. Elle ne peut pas être vide. Commande tsm native : utilise la commande tsm user-identity-store set-group-mappings [options]. |
groupName | groupname | wgserver.domain.ldap.group.name | LDAP | Attribut correspondant aux noms de groupes sur votre serveur LDAP. Commande tsm native : utilise la commande tsm user-identity-store set-group-mappings [options]. |
groupEmail | groupemail | wgserver.domain.ldap.group.email | LDAP | Attribut correspondant aux adresses de courriel de groupes sur votre serveur LDAP. Commande tsm native : utilise la commande tsm user-identity-store set-group-mappings [options]. |
groupDescription | description | wgserver.domain.ldap.group.description | LDAP | Attribut correspondant aux descriptions de groupes sur votre serveur LDAP. Commande tsm native : utilise la commande tsm user-identity-store set-group-mappings [options]. |
member | member | wgserver.domain.ldap.group.member | LDAP | Spécifiez l’attribut LDAP contenant une liste des noms distinctifs des utilisateurs appartenant à ce groupe. Commande tsm native : utilise la commande tsm user-identity-store set-group-mappings [options]. |
S.O. | S.O. | wgserver.domain.ldap.group.memberURL | LDAP | Spécifiez le nom de l’attribut LDAP qui stocke la requête LDAP pour les groupes dynamiques. |
userBaseDn | S.O. | wgserver.domain.ldap.user.baseDn | LDAP | Utilisez cette option pour spécifier une racine alternative pour les utilisateurs. Par exemple, si tous vos utilisateurs sont stockés dans l’organisation de base appelée « users », entrez "o=users" . |
S.O. | classnames | wgserver.domain.ldap.user.classnames | LDAP | Par défaut, Tableau Server recherche les classes d’objet de groupe LDAP contenant la chaîne « user » et « inetOrgPerson ». Si vos objets d’utilisateur LDAP n’utilisent pas ces noms de classe par défaut, remplacez la valeur par défaut en définissant cette valeur. Vous pouvez fournir plusieurs noms de classe en les séparant par des virgules. Par exemple : Si vos noms incluent des virgules, vous devez ajouter un échappement avec un trait oblique arrière (\). Par exemple, si vous avez un nom Commande tsm native : utilise la commande tsm user-identity-store set-user-mappings [options]. |
userBaseFilter | basefilter | wgserver.domain.ldap.user.baseFilter | LDAP | Filtre que vous souhaitez utiliser pour les utilisateurs de Tableau Server. Vous pouvez spécifier un attribut de classe d’objet et un attribut d’unité organisationnelle. Par exemple :
Commande tsm native : utilise la commande tsm user-identity-store set-user-mappings [options]. |
userUsername | ldapusername | wgserver.domain.ldap.user.username | LDAP | Attribut correspondant aux noms d’utilisateur sur votre serveur LDAP. Commande tsm native : utilise la commande tsm user-identity-store set-user-mappings [options]. |
userDisplayName | displayname | wgserver.domain.ldap.user.displayname | LDAP | Attribut correspondant aux noms d’affichage d’utilisateur sur votre serveur LDAP. Commande tsm native : utilise la commande tsm user-identity-store set-user-mappings [options]. |
userEmail | wgserver.domain.ldap.user.email | LDAP | Attribut correspondant aux adresses de courriel d’utilisateur sur votre serveur LDAP. Commande tsm native : utilise la commande tsm user-identity-store set-user-mappings [options]. | |
userCertificate | certificate | wgserver.domain.ldap.user.usercertificate | LDAP | Attribut correspondant aux certificats d’utilisateur sur votre serveur LDAP. Commande tsm native : utilise la commande tsm user-identity-store set-user-mappings [options]. |
S.O. | thumbnail | wgserver.domain.ldap.user.thumbnail | LDAP | Attribut correspondant aux images miniatures d’utilisateur sur votre serveur LDAP. Commande tsm native : utilise la commande tsm user-identity-store set-user-mappings [options]. |
userJpegPhoto | jpegphoto | wgserver.domain.ldap.user.jpegphoto | LDAP | Attribut correspondant aux images de profil d’utilisateur sur votre serveur LDAP. Commande tsm native : utilise la commande tsm user-identity-store set-user-mappings [options]. |
memberOf | memberof | wgserver.domain.ldap.user.memberof | LDAP | Groupe auquel l’utilisateur appartient. Commande tsm native : utilise la commande tsm user-identity-store set-user-mappings [options]. |
groupClassNames | S.O. | wgserver.domain.ldap.group.classnames | LDAP | Par défaut, Tableau Server recherche les classes d’objet de groupe LDAP contenant la chaîne « group ». Si vos objets de groupe LDAP ne correspondent pas au nom de classe par défaut, remplacez la valeur par défaut en définissant cette valeur. Pour configEntity : cette option prend une liste de chaînes, ce qui nécessite de transmettre chaque classe entre guillemets, en les séparant par une virgule (sans espace) et entre parenthèses. Par exemple : Pour configKey : Entrez chaque classe, en les séparant par une virgule (sans espace) et entre guillemets. Par exemple : |
userClassNames | S.O. | wgserver.domain.ldap.user.classnames | LDAP | Par défaut, Tableau Server recherche les classes d’objet de groupe LDAP contenant la chaîne « user » et « inetOrgPerson ». Si vos objets d’utilisateur LDAP n’utilisent pas ces noms de classe par défaut, remplacez la valeur par défaut en définissant cette valeur. Pour configEntity : cette option prend une liste de chaînes, ce qui nécessite de transmettre chaque classe entre guillemets, en les séparant par une virgule (sans espace) et entre parenthèses. Par exemple : Pour configKey : Entrez chaque classe, en les séparant par une virgule (sans espace) et entre guillemets. Par exemple : |
Clés configKey calculées
Les clés configKey suivantes associées à Kerberos sont calculées et définies en fonction de plusieurs entrées liées à l’environnement. En tant que telles, elles doivent être définies par la commande tsm native ou configEntities. Ne tentez pas de définir manuellement ces clés configKey.
Clé configKey calculée | Pour utiliser la commande TSM native : | Pour utiliser configEntity json : |
---|---|---|
wgserver.domain.ldap.kerberos.conf, cfs.ldap.kerberos.conf | Définissez l’emplacement du fichier de configuration Kerberos avec l’option | Définissez l’emplacement du fichier de configuration Kerberos à l’aide de l’option configEntity kerberosConfig . |
wgserver.domain.ldap.kerberos.keytab, cfs.ldap.kerberos.keytab | Définissez l’emplacement du fichier keytab Kerberos à l’aide de l’option kerbkeytab de la commande tsm user-identity-store set-connection [options]. | Définissez l’emplacement du fichier keytab Kerberos à l’aide de l’option configEntity kerberosKeytab . |
Clés configKey non prises en charge
Certaines clés configKey non prises en charge sont présentes dans les fichiers de configuration .yml sous-jacents. Les clés suivantes ne sont pas conçues pour les déploiements standard. Ne configurez pas ces clés :
- wgserver.domain.ldap.kerberos.login
- wgserver.domain.ldap.guid
- wgserver.domain.fqdn : cette clé est redondante avec wgserver.domain.default. Les valeurs des deux clés doivent être identiques. Mettez à jour wgserver.domain.fqdn uniquement si la valeur ne correspond pas à wgserver.domain.default.