Entité identityStore

Tableau Server a besoin d’un magasin d’identités pour stocker les informations sur les utilisateurs et les groupes. Consultez les rubriques Authentification et Magasin d’identités avant de configurer le magasin d’identités pour la première fois. Après avoir installé le magasin d’identités sur Tableau Server, vous ne pouvez pas la modifier sans réinstaller le serveur.

Important : toutes les options d’entité sont sensibles à la casse.

Avant de commencer

Vérifiez les informations suivantes :

  • Si vous ne comptez pas utiliser pas le magasin d’identités local, vous utiliserez une version de LDAP. Dans ce cas, adressez-vous à votre administrateur de répertoire/LDAP pour configurer Tableau Server en fonction des exigences de schéma et de liaison LDAP.

  • La configuration de Tableau Server est optimisée pour Active Directory. Si vous effectuez l’installation sur Active Directory, nous vous recommandons de configurer le magasin d’identités avec l’Configurer les paramètres du nœud initial.

  • La liaison LDAP est indépendante de l’authentification utilisateur. Par exemple, vous pouvez configurer Tableau Server de manière à utiliser la liaison simple pour l’authentification sur l’annuaire LDAP, puis configurer Tableau Server pour authentifier les utilisateurs sur Kerberos après l’installation.

  • Ne vous connectez pas à LDAP par liaison simple ou via une connexion non sécurisée. Par défaut, LDAP avec liaison simple envoie des données en texte clair. Utilisez LDAPS pour crypter le trafic avec une liaison simple. Consultez Configurer le canal crypté vers le magasin d’identités externe LDAP.

  • Pour utiliser l’authentification Kerberos pour la liaison LDAP avec le service Tableau Server, vous avez besoin d’un fichier keytab pour la liaison GSSAPI, comme décrit dans les sections ci-dessous. Consultez également Comprendre la configuration requise du fichier keytab. Dans le contexte de Kerberos, la liaison GSSAPI est la seule chose dont vous avez besoin lors de l’installation de base de Tableau Server. Après avoir installé le serveur, vous pouvez configurer Kerberos pour l’authentification utilisateur et la délégation Kerberos pour les sources de données.

  • Dans cette rubrique, nous faisons la distinction entre LDAP (le protocole de connexion aux services de répertoire) et un serveur LDAP (l’implémentation d’un service de répertoire). Par exemple, slapd est un serveur LDAP faisant partie d’un projet OpenLDAP.

  • Validez la configuration LDAP avant d’initialiser le serveur. Consultez Configurer les paramètres du nœud initial.

  • Importez des fichiers de configuration JSON uniquement 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 avec tsm configuration set. Consultez Référence de configuration du magasin d’identités externe.

Modèles de configuration

Les modèles JSON de cette section sont utilisés pour configurer Tableau Server avec différents scénarios de magasin d’identités. À moins que vous ne configuriez un magasin d’identités local, vous devrez sélectionner et modifier un modèle de fichier de configuration spécifique à votre environnement LDAP.

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 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é.

Sélectionnez un modèle de configuration de magasin d’identités à modifier :

  • Local
  • LDAP - Active Directory
  • OpenLDAP - Liaison GSSAPI
  • OpenLDAP - Liaison simple

Pour plus d’explications sur les fichiers de configuration, les entités et les clés, consultez Exemple de fichier de configuration.

Local

Configurez le type de magasin d’identités « local » si votre entreprise n’utilise pas déjà un serveur Active Directory ou LDAP pour l’authentification utilisateur. Lorsque vous sélectionnez un magasin d’identités local, vous utilisez Tableau Server pour créer et gérer des utilisateurs.

Une autre façon de configurer Tableau Server pour le magasin d’identités local est d’exécuter l’interface graphique d’installation et de sélectionner « Local » pendant le processus d’installation. Consultez Configurer les paramètres du nœud initial.

{
  "configEntities": {
    "identityStore": {
       "_type": "identityStoreType",
       "type": "local"
     }
   }
}			
		

Important

Les modèles de configuration LDAP que vous trouverez ci-dessous sont des exemples. Les modèles, tels qu’ils sont présentés, ne permettront pas de configurer la connectivité LDAP dans votre organisation. Vous devez vous adresser à votre administrateur de répertoires pour modifier les valeurs des modèles LDAP pour un déploiement réussi.

En outre, tous les fichiers référencés dans configEntities doivent se trouver sur l’ordinateur local. Ne spécifiez pas les chemins d’accès UNC.

LDAP - Active Directory

La configuration de Tableau Server est optimisée pour Active Directory. Si vous effectuez l’installation sur Active Directory, configurez le magasin d’identités avec l’Configurer les paramètres du nœud initial.

Une connexion cryptée à Active Directory est requise. Consultez Configurer le canal crypté vers le magasin d’identités externe LDAP.

Si, pour une raison quelconque, vous ne pouvez pas configurer le magasin d’identités de manière à ce qu’il communique avec Active Directory à l’aide de l’interface Web TSM, utilisez ce modèle JSON pour configurer Tableau Server de manière à ce qu’il se connecte à Active Directory. Ce modèle utilise la liaison GSSAPI (Kerberos) pour authentifier le service Tableau Server sur Active Directory. Tableau Server inclut la prise en charge du schéma Active Directory. De ce fait, si vous avez défini l’option "directoryServiceType" sur "activedirectory", vous n’avez pas besoin de fournir des informations de schéma dans l’option "identityStoreSchemaType".

Si vous installez Tableau Server pour Linux sur Active Directory, et que l’ordinateur sur lequel vous installez Tableau Server est déjà lié au domaine, il se peut que l’ordinateur dispose déjà d’un fichier de configuration Kerberos et d’un fichier keytab. À proprement parler, vous pouvez utiliser ces fichiers pour la liaison GSSAPI, mais nous déconseillons de les utiliser. Au lieu de cela, contactez votre administrateur Active Directory et demandez un fichier keytab spécifiquement pour le service Tableau Server.

{
  "configEntities":{
    "identityStore": {
		"_type": "identityStoreType",
		"type": "activedirectory",
		"domain": "your-domain.lan",
		"nickname": "YOUR-DOMAIN-NICKNAME",
		"directoryServiceType": "activedirectory",
		"bind": "gssapi",
		"kerberosKeytab": "<path to local key tab file>",
		"kerberosConfig": "/etc/krb5.conf",
		"kerberosPrincipal": "your-principal@YOUR.DOMAIN"
		}
	}
}			

Nous recommandons une liaison à Active Directory avec GSSAPI. Toutefois, vous pouvez vous connecter avec une liaison simple et LDAPS. Pour vous connecter avec la liaison simple, modifiez bind en simple, supprimez les trois entités Kerberos et ajoutez les options port/sslPort, username et password. L’exemple suivant présente Active Directory avec un fichier json liaison simple.

{
  "configEntities":{
	"identityStore": {
		"_type": "identityStoreType",
		"type": "activedirectory",
		"domain": "your-domain.lan",
		"nickname": "YOUR-DOMAIN-NICKNAME",
		"directoryServiceType": "activedirectory",
		"hostname": "optional-ldap-server", 
		"sslPort": "636",
		"bind": "simple",
		"username": "username",
		"password": "password"	
		}
	}
}			
		

OpenLDAP - Liaison GSSAPI

Utilisez le modèle ci-dessous pour configurer OpenLDAP avec la liaison GSSAPI. N’utilisez pas ce modèle si votre entreprise exécute Active Directory. Si vous effectuez l’installation sur Active Directory, utilisez le modèle ci-dessus, LDAP - Active Directory.

Dans la plupart des cas, les entreprises utilisant OpenLDAP avec GSSAPI (Kerberos) utiliseront un fichier keytab pour stocker les informations d’identification. Dans l’exemple suivant, un fichier keytab est utilisé pour les identifiants d’authentification.

Vous pouvez toutefois fournir des informations d’identification via les entités username et password.

Vous pouvez également spécifier un fichier keytab ainsi qu’une paire nom d’utilisateur/mot de passe. Dans ce cas, Tableau Server tente d’utiliser le fichier keytab, mais si l’authentification échoue pour une raison quelconque, il passe à l’option de secours et utilise les informations d’identification de nom d’utilisateur et mot de passe.

{
  "configEntities":{
		"identityStore": {
			"_type": "identityStoreType",
			"type": "activedirectory",
			"domain": "your-domain.lan",
			"nickname": "YOUR-DOMAIN-NICKNAME",
			"directoryServiceType": "openldap",
			"bind": "gssapi",
			"kerberosKeytab": "<path to local key tab file>",
			"kerberosConfig": "/etc/krb5.conf",
			"kerberosPrincipal": "your-principal@YOUR.DOMAIN",
			"identityStoreSchemaType": {
			   "userBaseFilter": "(objectClass=inetOrgPerson)",
			   "userUsername": "user",
			   "userDisplayName": "displayname",
			   "userEmail": "email",
			   "userCertificate": "certificate",
			   "userThumbnail": "thumbnail",
			   "userJpegPhoto": "photo",
			   "groupBaseFilter": "(objectClass=groupofNames)",
			   "groupName": "groupname",
			   "groupEmail": "groupemail",
			   "groupDescription": "groupdescription",
			   "member": "member",
			   "distinguishedNameAttribute": "",
			   "serverSideSorting": "",
			   "rangeRetrieval": "",
			   "userClassNames": ["inetOrgPerson","someClass2"],
			   "groupClassNames": ["groupOfUniqueNames1","groupOfUniqueNames2"]
			   }
		   }			
	  }			
}
		

OpenLDAP - Liaison simple

{
  "configEntities":{
		"identityStore": {
			"_type": "identityStoreType",
			"type": "activedirectory",
			"domain": "my.root",
			"nickname": "",
			"hostname": "optional-ldap-server",
			"port": "389",
			"directoryServiceType": "openldap",
			"bind": "simple",
			"username": "cn=username,dc=your,dc=domain",
			"password": "password",
			"identityStoreSchemaType": {
			   "userBaseFilter": "(objectClass=inetOrgPerson)",
			   "userUsername": "user",
			   "userDisplayName": "displayname",
			   "userEmail": "email",
			   "userCertificate": "certificate",
			   "userThumbnail": "thumbnail",
			   "userJpegPhoto": "photo",
			   "groupBaseFilter": "(objectClass=groupofNames)",
			   "groupName": "groupname",
			   "groupEmail": "groupemail",
			   "groupDescription": "groupdescription",
			   "member": "member",
			   "distinguishedNameAttribute": "",
			   "serverSideSorting": "",
			   "rangeRetrieval": "",
			   "userClassNames": ["inetOrgPerson","someClass2"],
			   "groupClassNames": ["groupOfUniqueNames1","groupOfUniqueNames2"]
			   }
		 }
  }
}			
		

Référence du modèle de configuration

Options de magasin d’identités partagé

type
Emplacement où vous souhaitez enregistrer les informations d’identité de l’utilisateur. Soit local, soit activedirectory. (Si vous souhaitez vous connecter à un serveur LDAP, sélectionnez activedirectory.)
domain
Domaine de l’ordinateur où vous avez installé Tableau Server.
nickname
Surnom du domaine. Également appelé nom NetBIOS dans les environnements Windows.
L’option nickname est requise pour toutes les entités LDAP. Si votre organisation n’exige pas un surnom/nom NetBIOS, transmettez une clé vide, par exemple : "nickname": "".

Options de liaison GSSAPI LDAP

directoryservicetype
Type de service de répertoire auquel vous souhaitez vous connecter. Soit activedirectory, soit openldap.
kerberosConfig
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 lié au domaine. Consultez Magasin d’identités.
kerberosKeytab
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. Par exemple, sur Linux, vous pouvez placer le fichier keytab dans le répertoire /var/opt/tableau/keytab.
kerberosPrincipal
Nom SPN (Service Principal Name) pour Tableau Server sur l’ordinateur hôte. Le fichier keytab doit disposer d’autorisations pour ce nom SPN. N’utilisez pas le fichier keytab système existant sur /etc/krb5.keytab. Nous vous recommandons plutôt d’enregistrer un nouveau nom SPN (Service Principal Name). Pour voir les noms SPN dans un fichier keytab donné, exécutez la commande klist -k. Consultez Comprendre la configuration requise du fichier keytab.

Options de liaison simple LDAP

directoryservicetype
Type de service de répertoire auquel vous souhaitez vous connecter. Soit activedirectory, soit openldap.
hostname
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 uniquement. Si les requêtes utilisateur/groupe se trouvent dans d’autres domaines (pas dans le domaine principal), Tableau Server n’utilisera pas cette valeur, mais interrogera plutôt DNS pour identifier le contrôleur de domaine approprié.
port
Utilisez cette option pour spécifier le port non sécurisé du serveur LDAP. Le texte simple est généralement 389.
sslPort
Utilisez cette option pour activer LDAPS. Spécifiez le port sécurisé du serveur LDAP. LDAPS est généralement le port 636. Pour utiliser LDAPS, vous devez également spécifier l’option de nom d’hôte. Consultez Configurer le canal crypté vers le magasin d’identités externe LDAP.
username
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, jsmith. Pour les serveurs LDAP, entrez le nom unique de l’utilisateur à utiliser pour la connexion. Par exemple, vous pouvez entrer cn=username,dc=your-local-domain,dc=lan.
password
Mot de passe de l’utilisateur que vous souhaitez utiliser pour vous connecter au serveur LDAP.

LDAPS et sous-domaines

Si vous activez LDAPS dans Active Directory et que vous vous connectez à des sous-domaines, vous devrez exécuter la commande TSM suivante pour configurer le port LDAPS (TCP 636) pour les sous-domaines. La commande prend des arguments qui spécifient subdomainFQDN:port .

Exemple : tsm configuration set -k wgserver.domain.ldap.domain_custom_ports -v subdomain1.lan:636,subdomain2.lan:636,subdomain3.lan:636

Consultez Options tsm configuration set pour plus d’informations.

Options LDAP partagées

Vous pouvez définir les options suivantes pour les implémentations génériques LDAP, OpenLDAP, ou Active Directory.

bind
Méthode de communication d’authentification souhaitée depuis le service Tableau Server vers le service d’annuaire LDAP. Entrez gssapi pour GSSAPI (Kerberos).
domain
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.

root

LDAP uniquement. Ne spécifiez pas cette option pour Active Directory.
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".
membersRetrievalPageSize
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 aussi élevé 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.

Options identityStoreSchemaType

Si vous configurez une connexion LDAP à un serveur LDAP, vous pouvez entrer les informations de schéma spécifiques à votre serveur LDAP dans l’objet identityStoreSchemaType.

Important Si vous vous connectez à Active Directory ("directoryServiceType": "activedirectory"), ne configurez pas ces options.

userBaseFilter
Filtre que vous souhaitez utiliser pour les utilisateurs de Tableau Server. Par exemple, vous pouvez spécifier un attribut de classe d’objet et un attribut d’unité organisationnelle.
userUsername
Attribut correspondant aux noms d’utilisateur sur votre serveur LDAP.
userDisplayName
Attribut correspondant aux noms d’affichage d’utilisateur sur votre serveur LDAP.
userEmail
Attribut correspondant aux adresses e-mail d’utilisateur sur votre serveur LDAP.
userCertificate
Attribut correspondant aux certificats d’utilisateur sur votre serveur LDAP.
userThumbnail
Attribut correspondant aux images miniatures d’utilisateur sur votre serveur LDAP.
userJpegPhoto
Attribut correspondant aux images de profil d’utilisateur sur votre serveur LDAP.
groupBaseFilter
Filtre que vous souhaitez utiliser pour les groupes d’utilisateurs de Tableau Server. Par exemple, vous pouvez spécifier un attribut de classe d’objet et un attribut d’unité organisationnelle.
groupName
Attribut correspondant aux noms de groupes sur votre serveur LDAP.
groupEmail
Attribut correspondant aux adresses e-mail de groupes sur votre serveur LDAP.
groupDescription
Attribut correspondant aux descriptions de groupes sur votre serveur LDAP.
member
Attribut décrivant la liste des utilisateurs d’un groupe.
distinguishedNameAttribute
Attribut stockant les noms uniques des utilisateurs. Cet attribut est facultatif, mais améliore considérablement les performances des requêtes LDAP.
serverSideSorting
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
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 n’êtes pas sûr que votre serveur LDAP prenne en charge la récupération par plages, entrez false, étant donné qu’une configuration incorrecte peut générer des erreurs.
groupClassNames
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. 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 : ["basegroup","othergroup"].
userClassNames
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. 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 : ["userclass1",userclass2”].

Importation du fichier JSON

Une fois que vous avez fini de modifier le fichier JSON, transmettez le fichier et appliquez les paramètres avec les commandes suivantes :

tsm settings import -f path-to-file.json

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.

Merci de vos commentaires !Avis correctement envoyé. Merci