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 ou false 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 uniquement true ou false, 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 native tsm 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

typeS.O.wgserver.authenticateAD, LDAP, LocalEmplacement où vous souhaitez enregistrer les informations d’identité de l’utilisateur. Valeurs : local ou activedirectory.

Si vous souhaitez vous connecter à un serveur LDAP, entrez activedirectory.

sslPortS.O.wgserver.domain.ssl_portAD, LDAPUtilisez 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.
portS.O.wgserver.domain.portAD, LDAPUtilisez cette option pour spécifier le port non sécurisé du serveur LDAP. Le texte simple est généralement 389.
domaindomainwgserver.domain.defaultADDans 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].

usernameldapusernamewgserver.domain.usernameAD, LDAPNom 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, "cn=jsmith,dc=example,dc=lan".

Commande tsm native : utilise la commande tsm user-identity-store set-connection [options].

passwordldappasswordwgserver.domain.passwordAD, LDAPMot 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].

directoryServiceTypeS.O.wgserver.domain.directoryservice.typeAD, LDAPType de service de répertoire LDAP auquel vous souhaitez vous connecter. Valeurs : activedirectory ou openldap.
kerberosPrincipalkerbprincipalwgserver.domain.ldap.principalAD, LDAPNom 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 un fichier keytab existant pour le système. 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.

Commande tsm native : utilise la commande tsm user-identity-store set-connection [options].

hostnamehostnamewgserver.domain.ldap.hostnameAD, LDAPNom 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].

membersRetrievalPageSizeS.O.wgserver.domain.ldap.members.retrieval.page.sizeAD, 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.enabledAD, LDAPLorsque 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_listADPermet 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 wgserver.domain.whitelist avec TSM. Pour plus d’informations, consultez wgserver.domain.whitelist.

kerberosConfig

kerbconfig

Aucun mappage directAD, 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].

kerberosKeytabkerbkeytabAucun mappage directAD, 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].

nicknameS.O.wgserver.domain.nicknameAD, LDAP

Surnom du domaine. Également appelé nom NetBIOS dans les environnements Windows/Active Directory. L’option nickname est requise pour toutes les entités LDAP. La valeur ne peut pas être null. Si votre organisation n’exige pas un surnom/nom NetBIOS, transmettez une clé vide, par exemple : "".

rootS.O.wgserver.domain.ldap.rootLDAPSi 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".
serverSideSortingS.O.wgserver.domain.ldap.server_side_sortingLDAPIndique 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.
rangeRetrievalS.O.wgserver.domain.ldap.range_retrievalLDAPIndique 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.
bindS.O.wgserver.domain.ldap.bindLDAPManiè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.domainLDAP

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 : FQDN1:port,FQDN2:port

Exemple : tsm configuration set -k wgserver.domain.ldap.domain_custom_ports -v childdomain1.lan:3269,childdomain2.lan:3269,childdomain3.lan:389

distinguishedNameAttributeS.O.wgserver.domain.ldap.dnAttributeLDAP

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

groupBaseDnS.O.wgserver.domain.ldap.group.baseDnLDAP

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 "o=groups".

S.O.classnameswgserver.domain.ldap.group.classnamesLDAP

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 groupOfNames, top, entrez "groupOfNames\, top".

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

groupBaseFilterbasefilterwgserver.domain.ldap.group.baseFilterLDAP

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 :

"(&(objectClass=groupofNames)(ou=Group))"

Si "(&(objectClass=inetOrgPerson)(ou=People))"ne fonctionne pas dans votre implémentation LDAP, spécifiez le filtre de base qui fonctionne pour votre base d’utilisateurs Tableau.

Cette clé est obligatoire. Elle ne peut pas être vide.

Commande tsm native : utilise la commande tsm user-identity-store set-group-mappings [options].

groupNamegroupnamewgserver.domain.ldap.group.nameLDAP

Attribut correspondant aux noms de groupes sur votre serveur LDAP.

Commande tsm native : utilise la commande tsm user-identity-store set-group-mappings [options].

groupEmailgroupemailwgserver.domain.ldap.group.emailLDAP

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

groupDescriptiondescriptionwgserver.domain.ldap.group.descriptionLDAP

Attribut correspondant aux descriptions de groupes sur votre serveur LDAP.

Commande tsm native : utilise la commande tsm user-identity-store set-group-mappings [options].

membermemberwgserver.domain.ldap.group.memberLDAP

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.memberURLLDAPSpécifiez le nom de l’attribut LDAP qui stocke la requête LDAP pour les groupes dynamiques.
userBaseDnS.O.wgserver.domain.ldap.user.baseDnLDAPUtilisez 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.classnameswgserver.domain.ldap.user.classnamesLDAP

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 : "userclass1, userclass2".

Si vos noms incluent des virgules, vous devez ajouter un échappement avec un trait oblique arrière (\). Par exemple, si vous avez un nom Names, top, entrez "Names\, top".

Commande tsm native : utilise la commande tsm user-identity-store set-user-mappings [options].

userBaseFilterbasefilterwgserver.domain.ldap.user.baseFilterLDAP

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 :

"(&(objectClass=inetOrgPerson)(ou=People))"

Commande tsm native : utilise la commande tsm user-identity-store set-user-mappings [options].

userUsernameldapusernamewgserver.domain.ldap.user.usernameLDAP

Attribut correspondant aux noms d’utilisateur sur votre serveur LDAP.

Commande tsm native : utilise la commande tsm user-identity-store set-user-mappings [options].

userDisplayNamedisplaynamewgserver.domain.ldap.user.displaynameLDAP

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

userEmailemailwgserver.domain.ldap.user.emailLDAP

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

userCertificatecertificatewgserver.domain.ldap.user.usercertificateLDAP

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.thumbnailwgserver.domain.ldap.user.thumbnailLDAP

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

userJpegPhotojpegphotowgserver.domain.ldap.user.jpegphotoLDAP

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

memberOfmemberofwgserver.domain.ldap.user.memberofLDAP

Groupe auquel l’utilisateur appartient.

Commande tsm native : utilise la commande tsm user-identity-store set-user-mappings [options].

groupClassNamesS.O.wgserver.domain.ldap.group.classnamesLDAP

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 : ["basegroup","othergroup"].

Pour configKey : Entrez chaque classe, en les séparant par une virgule (sans espace) et entre guillemets. Par exemple : "basegroup,othergroup”.

userClassNamesS.O.wgserver.domain.ldap.user.classnamesLDAP

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 : ["userclass1",userclass2”].

Pour configKey : Entrez chaque classe, en les séparant par une virgule (sans espace) et entre guillemets. Par exemple : "userclass1,userclass2”.

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éePour 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 kerbconfig de la commande tsm user-identity-store set-connection [options].

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.
Merci de vos commentaires!Votre commentaire s été envoyé avec succès. Merci!