Implémentation d’une authentification LDAP dans SAS

Par défaut, le serveur de métadonnées exploite le système d’authentification de la machine l’hébergeant pour valider les utilisateurs. Ce système d’authentification peut être modifié et il est possible de configurer le serveur de métadonnées pour exploiter un annuaire LDAP ou Active directory. Dans ce cas, les utilisateurs se connecteront aux différentes applications clientes de l’architecture SAS® à l’aide de leur compte LDAP ou AD. Cet article présente la mise en place de ce mécanisme d’authentification. [nextpage title="Présentation"]  

Qu’est-ce qu’un annuaire ?

Un annuaire est avant tout une base de données. A la différence des bases de données relationnelles où les données sont stockées de manière tabulaire (ligne, colonne), l'annuaire classe les informations de manière hiérarchique. Toutes sortes de données peuvent figurer dans un annuaire électronique : répertoire téléphonique, liste des ressources matérielles de l'entreprise, identité du personnel,… Autre différence, le mode d'utilisation : comparé aux bases de données relationnelles, un annuaire a vocation à être plus souvent consulté que mis à jour.

Les intérêts d’un annuaire

D’une façon générale, l’utilisation d’un annuaire présente plusieurs intérêts : • Administration centralisée et simplifiée : la gestion des comptes utilisateurs est simplifiée. Tout est centralisé dans l’annuaire. • Authentification unifiée : un utilisateur authentifié sur une machine, sous condition d’avoir les autorisations nécessaires, peut accéder aux ressources stockées sur d’autres serveurs ou ordinateurs enregistrés dans l’annuaire. Un seul compte permet un accès à tout le système d’information. • Référencement de tous les utilisateurs : l’annuaire s’apparente à une énorme base de données qui référence les utilisateurs, les groupes et les ordinateurs d’une entreprise. Les applications et systèmes d’exploitation s’appuient sur cette base de données pour réaliser de nombreuses opérations : authentification, identification, stratégie de groupe, déploiement de logiciels…

Le protocole LDAP

LDAP (Lightweight Directory Access Protocol) est un protocole pour l’accès à des services d'annuaire. Ce protocole est une définition de la norme de communication client-serveur et propose un ensemble d’outils et de commandes pour de se connecter, rechercher et administrer les entrées dans un annuaire. Le schéma ci-dessous présente un exemple d’organisation logique d’un annuaire LDAP : [nextpage title="Implémentation dans SAS"]

Externaliser le processus d’authentification

Comme indiqué en introduction, le serveur de métadonnées exploite le système d’authentification de la machine qui l’héberge pour valider les utilisateurs. En fonction de votre environnement, plusieurs approches sont envisageables pour externaliser le processus d’authentification. Par externaliser, on entend réaliser la tâche d’authentification par un annuaire externe (LDAP/AD) au lieu d’être réalisé par le serveur de métadonnées. Dans ce cas, les utilisateurs se connecteront aux différentes applications clientes de l’architecture SAS à l’aide de leur compte LDAP. Nous verrons dans les chapitres suivants qu’il est possible de gérer plusieurs méthodes d’authentifications, LDAP, active directory, compte système, compte interne SAS, en simultané.

SAS et LDAP, quelles solutions ?

SAS supporte les méthodes suivantes pour l'intégration avec LDAP : host use of LDAP L'hôte du serveur SAS utilise un annuaire en tant que fournisseur d'authentification back-end. Du point de vue du serveur SAS, ceci est l'authentification de l'hôte. Ainsi, ce mode d’intégration avec annuaire est transparent et ne demande aucune configuration SAS. Par exemple, Active Directory est le fournisseur d'authentification back-end standard sur Windows. Certains hôtes UNIX reconnaissent les comptes LDAP ou Active Directory (ou peuvent être configurés pour le faire). sasauth use of LDAP (Unix uniquement) Cette méthode fournit une connexion directe entre sasauth (le module d'authentification de l'hôte UNIX) et une base de données LDAP pour l'authentification. Cette méthode fournit une identité d'hôte UNIX pour chaque utilisateur authentifié. metadata server use of LDAP Le serveur de métadonnées valide certains utilisateurs par l’intermédiaire d’un annuaire LDAP tiers. Cette méthode permet au serveur de métadonnées de reconnaître les comptes qui ne sont pas connus par son hôte.

L’authentification dans les environnements Linux/Unix

Lorsque les informations d'identification des utilisateurs sont validées, les systèmes Linux/Unix recherchent une base de données utilisateur pour une entrée qui contient le même nom d'utilisateur. Traditionnellement, la base de données utilisateur est un fichier simple dans le système de fichiers (/etc/passwd avec des mots de passe chiffrés stockés dans /etc/shadow) Rapidement, l’idée de centraliser le mécanisme d'authentification est apparu, pour, par exemple, éviter d’avoir à ré-implémenter les mêmes schémas d'authentification dans toutes les applications se connectant au système ou ne pas à recompiler toutes les applications lors du changement des méthodes d'authentification. Avec l’implémentation de PAM, l'authentification n'a plus forcément réalisé par les bibliothèques du système. Suivant les modules activés, c’est PAM sélectionne la façon de faire l'authentification : • Si le module est pam_unix.so, l'authentification sera toujours gérée par les bibliothèques système. • Si le module est pam_ldap.so l'authentification se fera via un serveur LDAP. • Si le module est am_krb5.so, l'authentification se fera via Kerberos. La figure ci-dessous montre les éventuels flux d'authentification :

Authentification ou Autorisation ?

Avant de poursuivre, il est important de faire la distinction entre l'authentification et l'autorisation pour comprendre le fonctionnement de SAS : • L'authentification consiste à vérifier les informations d'identification de la tentative de connexion. • L'autorisation consiste à vérifier que la tentative de connexion est légitime puis à affecter les droits à l’utilisateur. L'autorisation intervient après une authentification réussie.   Déléguer les taches d’authentification à un annuaire LDAP ou ACTIVE DIRECTORY n’empêche pas de devoir gérer les autorisations dans SAS. [nextpage title="Comment est determinée l'identité d'un utilisateur SAS ?"] Comme nous venons de le voir, lorsqu’un utilisateur se connecte à un serveur de métadonnées SAS, nous rentrons dans un processus d’authentification. Ce processus est composé de deux phases : - Vérification - Identification La phase de vérification veille à ce que l'utilisateur soit bien celui qu'il prétend être. Par exemple, avec une authentification basée sur l'hôte : 1. Le serveur demande un compte utilisateur et un mot de passe 2. L’utilisateur saisit son compte et son mot de passe. Ces deux informations sont connues par le serveur hôte, hébergeant le serveur de métadonnées SAS. 3. Le serveur de métadonnées SAS soumet ses deux informations au serveur hôte pour authentification. Le serveur de métadonnées SAS ne connait pas le mot de passe. 4. Si le serveur hôte valide le compte, une confirmation est retournée au serveur de métadonnées SAS. La seconde phase d’identification associe le compte utilisateur authentifié à une identité SAS. Dans cette phase, SAS examine ses utilisateurs et tente de trouver celui qui correspond au compte de l’utilisateur authentifié : • Si un utilisateur SAS est trouvé, une connexion est établie sous l’identité du propriétaire. Cette identité est un utilisateur ou un groupe SAS associé au compte avec laquelle la connexion a été effectuée. • Si aucun utilisateur SAS associé au compte utilisé lors de la connexion n’est trouvé, une connexion est faite avec une identité PUBLIC, ne disposant d’aucun droit par défaut. [nextpage title="Host use of LDAP"] Dans le cas du host use of LDAP, le serveur hôte peut se connecter à un annuaire LDAP ou Active Directory. Comme indiqué précédemment, dans ce mode de fonctionnement, la connexion à l’annuaire et le processus d’authentification sont transparents pour SAS. [nextpage title="Metadata sever use of LDAP"]

Connecter SAS à un annuaire LDAP

Pour utiliser l’annuaire LDAP pour l’authentification, vous devez modifier les scripts de démarrage du serveur de métadonnées en ajoutant des variables d’environnement spécifiques pour LDAP. Le fichier à modifier, sasv9_usermods.cfg, se trouve dans /LevX/SASMeta/MetadataServer/ Ajoutez les variables suivantes : Voici une description des principales variables nécessaires à une connexion LDAP : Dans notre exemple, nous avons indiqué au serveur de métadonnées comment se connecter à l’annuaire LDAP et le chemin pour trouver les identités dans l’organisation, via LDAP_BASE. Maintenant, nous devons ajouter de nouvelles variables afin de préciser le domaine d’authentification. En effet, par défaut, le serveur de métadonnées supporte deux types de compte : - Les comptes internes, portant le suffixe @saspw - Les comptes physiques, sans suffixe. Pour router correctement l’authentification, nous devons donc créer un domaine d’authentification qui indiquera aux métadonnées si l’authentification doit se faire en interne, sur le host ou au niveau LDAP. Nous allons donc définir la variable AUTHPROVIDERDOMAIN : Grâce à cette variable (toujours dans sasv9_usermods.cfg) , nous pouvons spécifier au serveur de métadonnées où diriger l’authentification. Notez que vous pouvez nommer ce domaine comme vous le souhaitez. Une fois la configuration faite, vous devez simplement redémarrer le serveur de métadonnées pour prendre en compte ces nouveaux paramètres.

Comprendre le routage de l’authentification en fonction du domaine d’authentification

Comprendre le routage de l’authentification en fonction du domaine d’authentificationPour comprendre le routage d’un utilisateur, utilisons un exemple. Dans notre cas, l’utilisateur Nicolas dispose d’un compte local « nhousset » et d’un compte sur LDAP. Il peut également se connecter en tant qu’administrateur SAS. C’est grâce à ce domaine d’authentification, précisé à la connexion, que le serveur de métadonnées sera en mesure d’authentifier l’utilisateur : Cas 1 - L’utilisateur utilise le compte « nhousset » pour se connecter aux métadonnées SAS :   Cas 2 - L’utilisateur utilise son compte LDAP pour se connecter aux métadonnées SAS : Cas 3 - L’utilisateur utilise le compte d’administration pour se connecter aux métadonnées SAS :  

Utiliser LDAP comme authentification par défaut

Comme nous l’avons vu dans le chapitre « Routage de l’authentification en fonction du domaine d’authentification », si un utilisateur souhaite se connecter en utilisant son compte LDAP, il doit ajouter un suffixe (@DOMAINEFRANCE, dans nos exemples) afin d’indiquer au serveur de métadonnées que l’authentification doit être effectuée au niveau de l’annuaire.   Il est possible de configurer son serveur de métadonnées pour rendre l’authentification LDAP transparente pour l’utilisateur, c’est-à-dire qu’aucun suffixe n’est nécessaire pour router l’authentification vers LDAP.   La valeur de PRIMARYPROVIDERDOMAIN correspond à la valeur définie dans la variable AUTHPROVIDERDOMAIN : Pour cela, positionner la variable PRIMARYPROVIDERDOMAIN : Ainsi, avec cette configuration, il n’est plus nécessaire de préciser @DOMAINEFRANCE pour que l’authentification soit réalisée par LDAP. Avant de positionner un domaine d’authentification par défaut, il est important d’avoir une bonne connaissance des utilisateurs devant se connecter à l’environnement SAS. En effet, si dans votre entreprise,  les utilisateurs SAS peuvent être  identifiés soit via un annuaire, soit via un compte local, positionner le domaine de l’annuaire par défaut entraîne la nécessité d’utiliser un suffixe spécifique (@host) pour orienter l’authentification au niveau local, plutôt qu’au niveau du l’annuaire par défaut. [nextpage title="Configuration des utilisateurs dans SAS pour un usage dans SAS Enterprise Guide"] La configuration de vos utilisateurs dans les métadonnées dépend de la façon dont vous souhaitez que vos utilisateurs se connectent à SAS. Tous les utilisateurs de SAS doivent y être référencés. Un utilisateur peut avoir plusieurs comptes différents. Il peut y avoir une déclaration de compte pour une authentification avec LDAP, et une autre pour une authentification machine. Reprenons le contexte de l’exemple et examinons en détail la configuration de l’utilisateur « nhousset » dans les métadonnées. Pour bien comprendre la façon dont vous devez configurer vos métadonnées, nous allons partir de la fenêtre d’authentification de SAS Enterprise Guide et, à partir de là, présenter la configuration dans les métadonnées. 1) Dans notre premier cas de test, l’utilisateur souhaite se connecter, par défaut à son compte local, sans passer par l’authentification LDAP : Dans les métadonnées, l’utilisateur doit être configuré de cette manière : 2) Deuxième cas, l’utilisateur souhaite se connecter à SAS en utilisant son identité LDAP, la configuration dans SAS Enterprise Guide donnera donc : Dans les métadonnées (via la SAS^® Management Console), l’utilisateur doit être configuré de cette manière :     La valeur du suffixe @DOMAINEFRANCE est la même que celle définie dans la variable AUTHPROVIDERDOMAIN du fichier sasv9.cfg. Si aucun compte n’est créé avec cette identité @DOMAINEFRANCE, et comme nous l’avons vu au chapitre 2.3, l’utilisateur sera associé au profil PUBLIC.  

• L’utilisateur souhaite se connecter à SAS via son identité LDAP, mais sans avoir à spécifier le suffixe @DOMAINEFRANCE:

  Dans les métadonnées, l’utilisateur doit être configuré de cette manière Mais pour que ce routage vers LDAP fonctionne par défaut, il faut avoir spécifié la variable PRIMARYPROVIDERDOMAIN (chapitre 2.3.3). Dans notre exemple, la variable est à positionner à DOMAINEFRANCE.  

• Dernier cas de figure, l’utilisateur souhaite se connecter via son compte local alors que l’authentification LDAP par défaut est activée. Dans ce cas, il faut indiquer au serveur de métadonnées de ne pas router l’authentification vers LDAP, c’est-à-dire contourner l’authentification par défaut. Pour cela, l’utilisateur « nhousset » doit suffixer avec @HOST:

En ajoutant le suffixe @HOST, nous indiquons au serveur de métadonnées de ne pas tenir compte des directives LDAP et d’effectuer l’authentification via l’hôte, et donc d’utiliser un compte local. Tableau récapitulatif [nextpage title="Lier une identité externe à un compte physique"] Metadata server use of LDAP Comme nous l’avons vu au début de cet article, déléguer le mécanisme d’authentification à un service d’annuaire distant présente des avantages. Il n’est plus nécessaire de gérer les utilisateurs au niveau du serveur. Il n’y a donc plus besoin de créer un compte local pour chaque utilisateur. Mais cela pose des problèmes dans le fonctionnement de SAS . En effet, l’utilisation de SAS Enterprise Guide nécessite l’utilisation d’un compte machine pour pouvoir démarrer et exécuter des sessions SAS. Vous n’êtes pas sans savoir que lorsqu’un utilisateur exécute du code SAS, un processus (Workspace Server) est exécuté. Ce processus est exécuté par l’utilisateur associé à l’identité dans les métadonnées : Avec une authentification LDAP, il n’y a pas d’utilisateur local. Il est impossible de lancer le Workspace Server et donc d’exécuter du code SAS. Vous serez confronté au problème suivant : une fois authentifié via LDAP et connecté au serveur de métadonnées, il vous sera impossible d’exécuter du code SAS sur le serveur : Pour résoudre cette situation, plusieurs solutions sont envisageables, nécessitant des étapes de configurations supplémentaires afin d’associer un compte système aux identités LDAP. Dans les chapitres suivants nous vous présentons deux méthodes possibles.

L’authentification de jeton pour le Workspace Server.

Avec l’authentification de jeton (SAS Token authentication), le serveur de métadonnées génère et valide un jeton d’identité à usage unique pour chaque évènement d’authentification. Ainsi, aucun compte système individuel n’est nécessaire, et aucun mot de passe utilisateur n’est stocké dans les métadonnées. A noter également, qu’avec ce mécanisme, les informations d'identification transmis au serveur ne sont pas réutilisables dans une autre session. Configuration de l’authentification de jeton

• Ouvrez une session sur SAS^® Management Console avec un utilisateur possédant les droits d’administration des utilisateurs.

 

• Dans l'onglet Plug-ins, développez le Gestionnaire de serveurs et le serveur de votre choix (par exemple, SASApp). Puis, cliquez sur le serveur logique (par exemple, SASApp - Logical Workspace Server) et sélectionnez Propriétés:

• Dans l'onglet Options, sélectionnez SAS authentification par jeton. Cliquez sur OK pour enregistrer ce paramètre :
• Une fois validé, retournez dans l'onglet Plug-ins, sélectionnez le SASAPP – Workspace Server et cliquez sur Propriétés:

• Dans l'onglet Options, dans la liste déroulante Informations d’identification de lancement, sélectionnez une connexion, puis validez en cliquant sur OK.

• Pour que les modifications prennent effet, actualisez l’Objet Spawner :

Création d’un groupe d’utilisateurs L’implémentation de l’authentification par jeton est une solution pour lier, rapidement et facilement, les comptes utilisateur avec un compte système. Toutefois, cette solution est limitée. En effet, tous les utilisateurs utilisent le même compte, il n’est donc pas possible de définir des droits spécifiques au niveau système pour interdire l’accès à certaines ressources. Une seconde solution consiste à créer des groupes d’utilisateurs et, pour chaque groupe, associer un compte système qui sera utilisable par les utilisateurs LDAP définis préalablement : La définition du groupe d’utilisateurs devra contenir les informations suivantes : 1 – Spécifiez un nom pour votre groupe. Ici, Utilisateur LDAP 2 – Puis cliquez sur l’onglet « Comptes » Cliquez ensuite sur le bouton « Nouveau » pour saisir les propriétés du nouveau compte. Puis : 1 – Indiquez l’identifiant de connexion d’un compte local au serveur. 2 – Indiquez le mot de passe lié à cet utilisateur. Ce mot de passe sera stocké dans les métadonnées 3 – Créez un nouveau domaine de connexion appelé, par exemple, « win_local » pour identifier les comptes utilisateurs locaux au serveur hébergeant le serveur SAS. Suite à cette saisie, vous obtenez le résultat suivant : Puis, attachez vos utilisateurs LDAP à ce groupe : Modification de la configuration du Workspace Server Nous avons maintenant deux domaines d’authentification :  

• DefaultAuth
• win_local

  Le domaine DefaultAuth contient les identités LDAP et le domaine win_local contient les informations d’authentification d’un compte physique local au serveur SAS.   Comme je l’ai déjà indiqué, lorsque le Spawner va initialiser un Workspace Server, il va s’authentifier au serveur en utilisant le compte utilisateur défini dans DefaultAuth puis lancer un processus SAS avec ce compte utilisateur. Puis dans la fenêtre de droite, rendez-vous dans les propriétés : Dans l’onglet « Options » nous allons modifier le « Domaine d’authentification » : En choisissant « win_local », on indique à l’object Spawner d’utiliser un compte défini sur le domaine d’authentification SAS « win_local » plutôt que sur le domaine « DefaultAuth » pour lancer le Worspace Server. [nextpage title="sasauth use of LDAP"] La méthode d'authentification « sasauth us of ldap » ("méthode = ldap" dans le fichier de configuration) fournit une connexion directe de sasauth vers un annuaire LDAP pour l'authentification :

• Le module sasauth interroge les attributs utilisateur de la base de données puis authentifie l'utilisateur en fonction des attributs retournés.
• Le module interroge également la base de données LDAP pour déterminer les attributs de groupe pour l'utilisateur authentifié.
• La connexion vers un serveur chiffré est supportée. Sasauth utilise alors les bibliothèques standards du système d’exploitation.
• L’annuaire LDAP utilisés doit inclure des attributs utilisateur UNIX/Posix (tels que UID) dans la base de données. Sans cette information, le LDAP  ne peut pas être utilisée avec UNIX.
• L’annuaire LDAP doit être conforme à la norme RFC 2307.

Le module sasauth, lorsqu’il se connecte à un annuaire  nécessite, notamment, les attributs utilisateur suivants, (répertoriés à l'aide de leurs noms RFC 2307) :  

• uid – le nom de l’utilisateur,
• uidnumber – ID numerique de l’utilisateur,
• gidnumber – ID numerique du groupe principal de l’utilisateur,
• userpassword – Le mot de passe de l’utilisateur, chiffré.

  La liste des attributs complets est disponible dans la documentation Configuration Guide for SAS® 9.4 Foundation for UNIX Environments [nextpage title="Utilisation de PAM"] La méthode d'authentification PAM ("méthode = pam" dans le fichier de configuration) fournit une connexion directe de sasauth vers PAM pour l'authentification :

La module sasauth supporte de manière native l'authentification système, les annuaires LDAP et l'authentification PAM. Le module utilise un fichier e configuration sasauth.conf, stocké dans !SASROOT/utilities/bin/. [nextpage title="Configuration du module sasauth"]  Configurer sasauth pour une connexion à un annuaire LDAP La configuration du module sasauth pour ldap s’effectue en plusieurs étapes D’abord, dans le fichier SASHOME/SASFoundation/9.4/utilities/bin/sasauth.conf, vous devez specifier « ldap » comme méthode d’authentification : Une fois que la méthode LDAP est ajoutée à la liste des méthodes d'authentification pour sasauth. Des paramètres supplémentaires doivent être configurés pour LDAP dans sasauth.conf. Voici quelqu’une des propriétés à renseigner : Exemple de configuration : Pour plus de détails, vous pouvez consulter la documentation Configuration Guide forSAS® 9.4 Foundation for UNIX Environments et notamment le chapitre Configuring the sasauth LDAP Authentication Method »  Configurer sasauth pour utiliser de pam La configuration du module sasauth pour pam s’effectue en plusieurs étapes D’abord, dans le fichier SASHOME/SASFoundation/9.4/utilities/bin/sasauth.conf, vous devez specifier « pam » comme méthode d’authentification : Puis, il faut configurer de l'authentification PAM pour une utilisation avec sasauth. En effet, PAM est conçu de telle sorte que les applications doivent être enregistrées afin d'utiliser l'authentification prestations de service. Le fichier de configuration de PAM est /etc/pam.conf.  Ce fichier contient toutes les politiques de PAM pour votre système. A noter que sur certain système linux, le répertoire /etc/pam.d contient un fichier pour chaque programme autorisé à utiliser PAM. Le nom du fichier de configuration correspond au nom du processus effectuant les demandes d’autorisation. Dans le cas de sasauth, le fichier est donc /etc/pam.d/sasauth. Ajoutez les entrées suivantes dans le fichier : Pour plus de détails, vous pouvez consulter la documentation Configuration Guide forSAS® 9.4 Foundation for UNIX Environments et notamment le chapitre « Configuring PAM Authentication for Use with sasauth » [nextpage title="Tester et valider sa connexion"] La validation de la configuration est une étape importante, si ce n’est primordiale, lors de la mise en place de l’authentification. Dans le chapitre suivant nous allons aborder plusieurs méthodes pour valider sa connexion et vérifier le bon fonctionnement de l’authentification. Notez que ces différents protocoles de tests s’appliquent si vous utilisez une authentification via un annuaire ou via un autre mécanisme (hôte ou compte internet SAS). Aussi, nous vous proposons 4 approches différentes pour valider l’authentification :  

• Une validation, en dehors de SAS,
• L’utilisation de la PROC METAOPERATE,
• L’utilisation de la PROC PERMTEST,
• L’utilisation de l’outil SASUMGMT.

  Enfin, à la fin de ce chapitre, nous expliquons comment activer les traces, étape utile pour une investigation efficace.  

Valider la connexion au serveur LDAP, en dehors de SAS

La première étape consiste à valider la connexion en dehors de SAS, soit en utilisant un outil tiers permettant de vous connecter à un serveur LDAP à distance, soit en soumettant du code SAS pour simuler et valider la connexion au serveur LDAP, sans passer par la couche Métadonnées.

Utilisation de la procédure METAOPERATE

En cas de problème de connexion, la première chose à faire est de valider la connexion en dehors de SAS afin de s’assurer que « tout fonctionne correctement ». Puis, nous pouvons tenter une validation « dans » SAS. Pour tester l’authentification simplement, nous allons utiliser la PROC METAOPERATE. Cette procédure permet d’effectuer toute sorte de tâches administratives associées à un serveur de métadonnées SAS (ou un cluster de serveur de métadonnées). Globalement, la syntaxe est la suivante : Dans notre cas, nous allons utiliser l’action “STATUS”. La PROC METAOPERATE ACTION=status renvoie des informations sur les propriétés et l’état du serveur de métadonnées. Pour exécuter cette action, il est nécessaire de se connecter au serveur en positionnant des options de connexion, telles que le login ou le mot de passe. Cette procédure SAS est donc un moyen simple de valider ses identifiants de connexion. Voici un exemple de syntaxe, à exécuter dans une session SAS : L’exécution doit retourner, dans le journal SAS, les informations suivantes : Il est possible de valider la connexion avec un compte LDAP, par exemple : Le résultat vous permet de valider ou non les identifiants. Si vous obtenez un message d’erreur, celui-ci vous permettra d’effectuer un premier diagnostic sur l’origine de l’erreur. Par exemple :

 Validation de son authentification via la proc permtest

Lorsque vous utilisez SAS dans un environnement de type UNIX, vous pouvez utiliser la PROC PERMTEST. La PROC PERMTEST est un outil que nous pouvons qualifier de  « bas niveau » pour tester l'authentification. Vous pouvez l'utiliser pour déterminer l’origine de vos problèmes d’authentification. Ce qui donne :

Utilisation de l’outil SASUMGMT

Utilisez l'utilitaire SASUMGMT pour valider que le nom d'un utilisateur et son mot de passe sont bien valides et peuvent être utilisés pour l'authentification SAS. L'utilitaire SASUMGMT est stocké dans le répertoire SASROOT d'une installation SAS standard. Voici un exemple d’utilisation : Ce qui affiche : Si vous indiquez un mauvais mot de passe, le message suivant s’affiche : Pour plus d’informations concernant le fonctionnement de cet outil ainsi que la liste de messages d’erreurs, la documentation est disponible sur le site du support SAS (SASUMGMT Utility). [nextpage title="Activation des traces SAS Enterprise Guide"] A partir de la version 7.1 de SAS Enterprise Guide, il est possible d’activer les traces via les options de l’application. Voici les étapes à suivre : 1 – Cliquez sur « outils » dans la barre de menu. 2 - Cliquer sur « Options » Dans la fenêtre d’options :

• Cliquez sur « Journalisation de l’application»
• Puis cochez « Activer la journalisation»

Vous obtenez alors la cause de l’erreur de connexion ainsi que la « stack java » complète. [nextpage title="Activer les traces SAS Metadataserver"] Pour activer les traces côté serveur, soumettez le code suivant dans une session SAS (en ayant remplacé les variables host-name, port-number,user-ID et password) : Pour lister les logger activés, vous pouvez soumettre le code ci-dessous : Maintenant que vous avez soumis ce code, des traces détaillées sont visibles dans le fichier journal du serveur de métadonnées. En utilisant cette méthode, les SAS loggers activés ne le seront plus au redémarrage du serveur de métadonnées. [nextpage title="Visualiser les identités associées à votre compte"] Dans la phase de résolution de problème, il peut s’avérer nécessaire de visualiser les différentes identités associées à son compte SAS. Une fois connecté au serveur de métadonnées, via SAS Enterprise guide, vous disposez d’une fonctionnalité permettant de lister les identités et profils de connexion : Vous pouvez alors visualiser les informations du compte connecté au serveur de métadonnées :