Aide de Tableau Server sur Linux

Les conseils de résolution des problèmes proposés dans cette rubrique sont classés en deux catégories : les problèmes concernant l’authentification unique (SSO) sur le serveur et les problèmes relatifs aux sources de données déléguées.

Voir également la page wiki de la communauté Tableau, Tester la configuration Kerberos de la base de données sur Linux(Le lien s’ouvre dans une nouvelle fenêtre).

Authentification unique sur Tableau Server

Dans un environnement SSO Kerberos, un utilisateur se connectant à Tableau Server depuis un navigateur Web ou Tableau Desktop peut voir un message indiquant que Tableau Server ne peut pas le connecter automatiquement (à l’aide de l’authentification unique). Ce message lui suggère de fournir à la place un nom d’utilisateur et un mot de passe Tableau Server.

Résolution des erreurs de connexion sur l’ordinateur client

• Entrer le nom d’utilisateur et le mot de passe—Pour vérifier l’accès général de l’utilisateur à Tableau Server, connectez-vous en entrant le nom et le mot de passe de l’utilisateur.

  Si ces informations d’identification échouent, il se peut que l’utilisateur ne soit pas un utilisateur sur Tableau Server. Pour que l’authentification unique Kerberos fonctionne, l’utilisateur doit pouvoir accéder à Tableau Server, et se voir accorder un billet TGT (Ticket Granting Ticket) par Active Directory (comme décrit dans la section TGT plus loin dans cette liste).

• Vérifier les informations d’identification SSO d’autres utilisateurs—Essayez de vous connecter avec SSO à Tableau Server en utilisant d’autres comptes utilisateur. Si tous les utilisateurs sont affectés, il se peut que le problème provienne de la configuration Kerberos.

• Utiliser un ordinateur autre que l’ordinateur du serveur—L’authentification unique Kerberos ne fonctionne pas lorsque vous vous connectez à Tableau Server sur l’hôte local. Les clients doivent se connecter depuis un ordinateur autre que l’ordinateur Tableau Server.

• Utiliser un nom de serveur, et non une adresse IP—L’authentification unique Kerberos ne fonctionne pas si vous entrez une adresse IP comme nom Tableau Server. En outre, le nom de serveur que vous utilisez pour accéder à Tableau Server doit correspondre au nom utilisé dans la configuration Kerberos (voir Entrée dans la table de clés, plus loin).

• Vérifier que le client possède un billet TGT—L’ordinateur du client doit posséder un billet TGT (Ticket Granting Ticket) émis par le domaine Active Directory. La délégation contrainte, où le proxy accorde un billet, n’est pas prise en charge.

  Pour vérifier que l’ordinateur client possède un TGT, procédez comme suit :

  • Sur Windows, ouvrez une invite de commande et entrez la commande suivante : klist tgt

  • Sur un Mac, ouvrez une fenêtre de terminal et entrez ce qui suit : klist

  Le résultat doit indiquer un TGT pour l’utilisateur/le domaine qui tente de s’authentifier auprès de Tableau Server.

  L’ordinateur client peut ne pas avoir de TGT dans les cas suivants :

  • L’ordinateur client utilise une connexion VPN.

  • L’ordinateur client ne fait pas partie du domaine (il s’agit, par exemple, d’un ordinateur personnel utilisé au travail, mais n’appartenant pas à l’entreprise).

  • L’utilisateur s’est connecté à l’ordinateur avec un compte local (n’appartenant pas à un domaine).

  • L’ordinateur est un Mac n’utilisant pas Active Directory comme serveur de comptes réseau.

• Vérifier la version et les paramètres du navigateur—Pour la connexion au navigateur Web, assurez-vous que le navigateur est pris en charge pour Kerberos et, si nécessaire, est configuré correctement.

  • Internet Explorer (IE) et Chrome fonctionnent directement sous Windows.

  • Safari fonctionne directement sur le Mac.

  • Firefox requiert une configuration supplémentaire.

  Pour plus d’informations, consultez Prise en charge du client Tableau pour l’authentification unique Kerberos.

Résolution des erreurs de connexion sur le serve

Si vous ne parvenez pas à résoudre le problème à partir de l’ordinateur client, l’étape suivante consiste à dépanner l’ordinateur exécutant Tableau Server. L’administrateur peut utiliser l’ID de demande pour localiser la tentative de connexion dans les fichiers journaux Apache sur Tableau Server.

• Fichiers journaux : Dans le fichier journal d’erreurs Apache, recherchez l’erreur correspondant à la tentative d’ouverture de session qui a échoué avec la date et l’heure exactes.

• Entrée dans la table de clés : Si l’entrée error.log inclut le message « No key table entry matching HTTP/<servername>.<domain>.<org>@ » (Aucune entrée de table de clés correspondant à HTTP/<nom_serveur>.<domaine>.<org>@), par exemple :

  [Fri Oct 24 10:58:46.087683 2014] [:error] [pid 2104:tid 4776] [client 10.10.1.62:56789] gss_acquire_cred() failed: Unspecified GSS failure. Minor code may provide more information (, No key table entry found matching HTTP/servername.domain.com@)

  Cette erreur résulte d’une discordance parmi les éléments suivants :

  • URL de Tableau Server - URL utilisée par l’ordinateur client pour accéder au serveur.

    Il s’agit du nom que vous saisissez dans Tableau Desktop ou dans la barre d’adresse d’un navigateur. Il s’agit d’un nom abrégé (http://servername) ou d’un nom de domaine qualifié complet (http://servername.domain.com)

    

  • Recherche inverse DNS de l’adresse IP du serveur.

    Cela permet de rechercher un nom DNS à l’aide d’une adresse IP.

    À l’invite de commande, entrez :

    ping servername

    avec l’adresse IP renvoyée par le ping au serveur, effectuez une recherche DNS inverse en tapant :

    nslookup <ip address>

    La commande nslookup renvoie des informations réseau pour l’adresse IP. Dans la partie Réponse ne faisant pas autorité de la réponse, vérifiez que le nom de domaine qualifié complet correspond aux valeurs configurées suivantes : 

    • Fichier .keytab Kerberos

    • SPN (Service Principal Name) pour le serveur

    Pour plus d’informations sur la configuration de ces valeurs, consultez Comprendre la configuration requise du fichier keytab.

Vérifier le script de configuration Kerberos

Vous serez peut-être amené à modifier la commande ktpass qui vous a servi à générer le fichier keytab pour les variables d’environnement. Consultez les étapes de dépannage dans l’article de la Base de connaissances Unable to Generate Kerberos Script Configuration for Tableau Server(Le lien s’ouvre dans une nouvelle fenêtre) (Impossible de générer la configuration de script Kerberos pour Tableau Server).

Signature unique pour les sources de données

Échecs des accès délégués aux sources de données

Dans les fichiers journaux vizqlserver, recherchez « workgroup-auth-mode ».

Recherchez "workgroup-auth-mode"dans les fichiers journaux. Il devrait être indiqué "kerberos-impersonate" et non pas "as-is".

Configuration multi-domaines de la délégation Kerberos

Tableau Server peut déléguer des utilisateurs depuis d’autres domaines Active Directory. Si votre base de données utilise MIT Kerberos, vous devrez peut-être ajuster votre nom Kerberos principal au mappage utilisateur de la base de données. Plus spécifiquement, vous devrez mettre à jour krb5.conf avec des règles pour chaque domaine Kerberos depuis lequel les utilisateurs se connecteront. Utilisez la balise auth_to_local dans la section [realms] pour associer les noms principaux aux noms d’utilisateurs locaux.

Par exemple, prenons un utilisateur, EXAMPLE\jsmith, dont le nom principal Kerberos est jsmith@EXAMPLE.LAN. Dans ce cas, Tableau Server spécifie un utilisateur délégué, jsmith@EXAMPLE. Tableau Server utilise l’alias de l’ancien domaine Active Directory comme domaine Kerberos.

Il se peut que la base de données cible utilise déjà une règle du type suivant pour mapper l’utilisateur jsmith@EXAMPLE.LAN à l’utilisateur de la base de données, jsmith.

EXAMPLE.LAN = {
   RULE:[1:$1@$0](.*@EXAMPLE.LAN)s/@.*//
   DEFAULT
}

Pour prendre en charge la délégation, vous devez ajouter une autre règle pour mapper jsmith@EXAMPLE à un utilisateur de base de données :

EXAMPLE.LAN = {
   RULE:[1:$1@$0](.*@EXAMPLE.LAN)s/@.*//
   RULE:[1:$1@$0](.*@EXAMPLE)s/@.*//
   DEFAULT
}

Consultez la rubrique krb5.conf(Le lien s’ouvre dans une nouvelle fenêtre) dans la documentation MIT Kerberos pour plus d’informations.

Délégation contrainte inter-domaines

Dans certains scénarios inter-domaines où le KDC fonctionne sur un serveur Windows antérieur à Windows 2012, la délégation peut échouer. Voici les erreurs qui peuvent s’afficher :

• Interfaces de réseau SQL Server : le système ne peut pas contacter un contrôleur de domaine pour répondre à la demande d’authentification. Veuillez réessayer ultérieurement.
• Client natif SQL Server : ne peut pas générer un contexte SSPI.
• Le contrôleur de domaine renvoie : KRB-ERR-POLICY error with a status STATUS_CROSSREALM_DELEGATION_FAILURE (0xc000040b).

« Inter-domaines » désigne un scénario où Tableau Server s’exécute sur un domaine différent de celui de la source de données avec des comptes de service différents. Par exemple :

• Tableau Server s’exécute sur DomaineA avec le compte de service DomaineA.
• SQL Server s’exécute sur DomaineB avec le compte de service DomaineB.

La délégation contrainte classique ne fonctionne que si les deux serveurs sont sur le même domaine. L’utilisateur peut venir d’autres domaines.

Si vous voyez les erreurs susmentionnées, pour activer ce scénario, vos administrateurs Active Directory doivent supprimer toute délégation contrainte classique configurée sur le compte de délégation. La suppression de la délégation peut être obtenue à l’aide d’outils de gestion Active Directory ou en supprimant les valeurs associées à la propriété Active Directory, msDS-AllowedToDelegateTo.

Si vous souhaitez conserver une délégation existante de domaine unique en même temps que la délégation inter-domaines, vous devez configurer les deux en utilisant la délégation contrainte basée sur des ressources.

Pour plus d’informations sur Kerberos et la délégation contrainte, consultez la rubrique Microsoft, Présentation de la délégation contrainte Kerberos(Le lien s’ouvre dans une nouvelle fenêtre).