support clients /

Authentification Active Directory dans un environnement SAS 9.2 sur Unix/Linux

Cet article décrit les mécanismes à mettre en œuvre  pour permettre une authentification vers un serveur Active Directory (AD) dans un environnement SAS® 9.2 sur Unix/Linux comme nous l’avions fait en SAS® 9.1.3. Nous évoquerons la connexion avec SAS® Enterprise Guide® et SAS® Information Delivery Portal avec un compte défini sous Active Directory.

Description de l'architecture

Les utilisateurs travaillent depuis des postes Windows (SAS® Enterprise Guide®, SAS® Information Delivery Portal, SAS® Web Report Studio, SAS® Management Console) et veulent utiliser leur compte AD sans avoir à connaitre l'existence d'un compte Unix associé.

Nous nous trouvons dans ce type d’architecture :

Dans notre scénario, le serveur de métadonnées (sur Unix/Linux) se connecte au serveur Active Directory afin de vérifier l'identité de l'utilisateur.

Le compte dans les métadonnées aura un compte Unix associé ainsi que le compte Active Directory (nous pouvons aussi n'avoir qu'un seul compte Unix associé à un groupe dans les métadonnées).

Note 
Dans les exemples et copies d’écran qui suivent, l’environnement de test suivant a été utilisé :

- Le serveur Active Directory est sur une machine Windows 2003 server et le nom d’hôte (« hostname ») est CLVGED.

- Le nom du domaine Active Directory est mondomaine.com 

- Le serveur Unix/Linux, où SAS 9.2TS2M3 est installé, a le nom d'hôte LinuxAD  

Configuration du serveur de métadonnées 

Il est nécessaire de configurer le serveur de métadonnées afin qu'il se connecte au serveur AD pour pouvoir vérifier l'identité de l'utilisateur.

Nous avons deux possibilités :

1/ Ajouter des options dans le fichier de configuration sasv9_usermods.cfg. Ce fichier se trouve sous :  /…/…/Lev1/SASMeta/MetadataServer/
Les options sont les suivantes :

-set AD_HOST CLVGED
-authpd ADIR:mondomaine

AD_HOST
Il s'agit de la variable d'environnement qui indique au serveur SAS Unix le nom d'hôte du serveur Active Directory à contacter pour l'authentification (nous pouvons aussi renseigner une adresse IP).

authpd ADIR : mondomaine
L'option 'authpd ADIR’ aura pour résultat de rediriger toute demande d'authentification du type nom_d_utilisateur@mondomaine vers Active Directory. La chaîne de caractère mondomaine correspond au domaine d'authentification SAS et au domaine Active Directory (il est possible de mettre une autre valeur que le nom du domaine, mais il faudrait alors aussi spécifier le nom du domaine dans le login. Ce cas est plus compliqué et ne sera pas traité dans le cadre de l'article).

Le nom de domaine peut être aisément vérifié en utilisant l'utilitaire 'Active Directory Users And Computers’ se trouvant dans les Outils d’administration : 

 

2/ Modifier le script de démarrage du serveur de métadonnées MetadataServer.sh. Ce fichier se trouve également sous /…/…/Lev1/SASMeta/MetadataServer/
Voici un extrait du fichier /…/…/Lev1/SASMeta/MetadataServer/MetadataServer.sh (sur le serveur Unix/Linux). Les parties en gras et rouge représentent les ajouts apportés au fichier (rien n’est modifié ni supprimé, seuls des ajouts sont effectués) :

….
CONFIGDIR=$LEVEL_ROOT/SASMeta/MetadataServer
LOGSDIR=/disk2/configEBI92/Lev1/SASMeta/MetadataServer/Logs
CMD_OPTIONS=" -authpd ADIR:mondomaine "
COMMAND="$SAS_COMMAND"
SCRIPT=`basename $0`
SERVERUSER=sas
AD_HOST=CLVGED
export AD_HOST


# Set config file path
…. 

Il est nécessaire de redémarrer le serveur de métadonnées après avoir apporté les modifications.

Configuration des comptes utilisateurs

Chaque utilisateur devra avoir 2 comptes :

  • Un compte Unix, indispensable pour pouvoir exécuter des sessions SAS sur le serveur de traitement (dans notre cas : pdupont).
  • Un compte Active Directory correspondant à son compte Windows (il s'agit le plus souvent du compte utilisé par l'utilisateur sur son poste de travail). Dans notre cas, il s'agit de PierreDupont

Note : il est possible de simplifier la mise en place en utilisant des groupes d’utilisateurs au niveau des métadonnées. Nous ne traiterons pas ce cas ici.

Les 2 comptes systèmes (Unix et Active Directory) seront liés entre eux par un compte créé dans les métadonnées.

Prenons l’exemple de l’utilisateur Pierre Dupont défini au niveau des métadonnées. Il est associé au compte pdupont  (compte Unix) et au compte PierreDupont (compte du domaine Active Directory).

En regardant les propriétés de Pierre Dupont au niveau des métadonnées, nous avons les informations suivantes :

Pour obtenir cet écran il est nécessaire d’ouvrir SAS® Management Console et d’aller sur Gestionnaire d’utilisateurs, puis  de sélectionner l’utilisateur souhaité. Cette modification doit être faite pas l’administrateur des métadonnées (généralement il s’agit de sasadm).   

Nous remarquons dans la copie d'écran, la présence de @mondomaine qui suit le compte Active Directory et l'absence de domaine d'authentification pour le compte Active Directory (en rouge).
Lors de l'ajout du compte Active Directory, le mot de passe n'est pas à renseigner dans les métadonnées.

Vérifications depuis la SAS® Management Console

Afin de vérifier que la connexion fonctionne avec le compte AD, il est utile de se connecter à SAS® Management Console avec le compte Windows Active Directory : PierreDupont@mondomaine (le mot de passe Windows utilisé pour le compte sera alors à spécifier).

Au bas de la console d'administration, la ligne 'PierreDupont@mondomaine connecté en tant que Pierre Dupont' indique clairement que le lien est fait entre le compte Active Directory et le compte des métadonnées.

Test de connexion à partir de SAS® Enterprise Guide® 4.2

Avec Enterprise Guide® 4.2, il est nécessaire de configurer l'application cliente (une seule fois) afin que cette dernière se connecte avec le compte Windows. Pour cela, nous irons dans le menu Outils -> Explorateur de SAS Entreprise Guide -> Fichier -> Gérer les profils, afin de définir les paramètres du compte PierreDupont@mondomaine comme le montre l’image suivante :

 

Une fois authentifié sous Enterprise Guide 4.2, nous verrons dans la ligne du bas que la connexion est établie avec l’utilisateur Active Directory (lié à l’utilisateur des métadonnées), comme c’est le cas sur l’image suivante :

Si le lien entre les 2 comptes ne s'effectue pas, le message suivant apparaîtrait:

Dans ce cas, il faudra vérifier les propriétés du compte Pierre Dupont dans les métadonnées.

Il est ensuite indispensable de vérifier que l’association est réalisée avec le compte Unix permettant d’exécuter une session SAS sur le serveur Unix/Linux (connexion au « Workspace Server »). Pour ce faire on clique sur Serveurs -> SASApp -> Bibliothèques -> et sur une des bibliothèques présentes (SASHELP dans notre exemple). La session SAS doit démarrer sur le serveur.
L’image suivante illustre ce type de vérification :

Nous visualisons donc bien le contenu de la bibliothèque SASHELP. En sélectionnant la table AIR, nous voyons le contenu de cette table. 

Test de connexion à partir de SAS® Web Report Studio 4.2

Il est intéressant de tester aussi la connexion aux applications telles que SAS® Web Report Studio (WRS), SAS® Information Delivery Portal etc. avec le compte Active Directory.

Par exemple, dans le cas de WRS 4.2, il suffit de saisir le compte comme le montre l’image suivante (le mot de passe est toujours le mot de passe Windows)

Une fois authentifié sur le portail SAS, en haut à droite de la fenêtre Internet Explorer, nous pouvons valider que la connexion s'est correctement effectuée avec le compte Active Directory Pierre Dupont.

La gestion des mots de passe

En général, les utilisateurs finaux n'ont pas connaissance de l'existence d'un compte Unix associé (le lien est fait par l'administrateur au niveau de SAS® Management Console). Pour eux, seuls le compte Windows/Active Directory et le mot de passe sont à saisir.

Dans le cas d'utilisateurs avertis ou si les administrateurs n'ont pas accès aux mots de passe (souvent pour des raisons de sécurité), il peut être utile d'installer 'SAS® Personal Login Manager’ sur les postes de travail. Cet  outil permet aux utilisateurs finaux de gérer leurs différents mots de passe et comptes (liés aux domaines d’authentification) sans toutefois leur permettre d’accéder aux autres objets et ‘plugins’ des métadonnées. Il se trouve dans le dépôt des packages SAS® BI Server et SAS® Data Integration Server et figure dans les plans fournis par défaut.

Voici une copie d'écran qui montre l'interface 'SAS® Personal Login Manager', toujours avec le compte utilisé précédemment.

La procédure PERMTEST

La procédure PERMTEST disponible uniquement sur Unix permet de tester l’authentification au niveau système ainsi que les droits des utilisateurs sur les fichiers. Elle a donc deux fonctions :

  • Appel du module sasauth pour tester l'authentification Système
  • Vérification des droits utilisateurs.

Afin d’utiliser  cette procédure, il est nécessaire d’activer des logs. Les actions pour ce faire sont :

  • Editer le fichier SASFoundation/9.2/utilities/bin/sasauth.conf
  • Supprimer les commentaires des quatre lignes suivantes :

debugLog=/tmp/sasauth-debug.log
accessLog=/tmp/sasauth-access.log
errorLog=/tmp/sasauth-error.log
logOwner=0

  • Ajouter pour logOwner l’uid de l’utilisateur ayant installé SAS® 9.2. Pour connaitre cet uid, il est possible d’exécuter la commande : id install_user où install_user est le compte utilisé pour l’installation. 

Par exemple :

[sas@localhost ~]$ id sas
uid=501(sas) gid=501(sas) groups=501(sas) context=root:system_r:unconfined_t:SystemLow-SystemHigh

La valeur uid de l'utilisateur ayant procédé à l'installation est 501.

Il est donc nécessaire d’avoir dans le fichier sasauth.conf les informations suivantes :

debugLog=/tmp/sasauth-debug.log
accessLog=/tmp/sasauth-access.log
errorLog=/tmp/sasauth-error.log
logOwner=501

  • Sauvegarder le fichier sasauth.conf.

Ces modifications effectuées, vous pouvez démarrer SAS avec la commande :

[sas@localhost 9.2]$ ./sas -path ./utilities/src/auth/ -nodms

Il est ensuite possible d'utiliser la procédure PERMTEST.

Dans l'exemple suivant, nous pouvons voir un problème d'authentification. En effet le mot de passe renseigné pour le compte pdupont n'était pas le bon.

   2? proc permtest;run;
Authentication Test
Enter userid:
pdupont
Enter password:

ERROR: Access denied.Authentication failed.

Dans l’exemple ci-dessus, la vérification de l’authentification s’est faite avec succès, il est donc ensuite possible de vérifier les droits sur un fichier. 

  3? proc permtest; run;
Authentication Test
Enter userid:
pdupont
Enter password:
Authentication successful.

Permissions Test
Enter a scratch filename:
/tmp/testfile
Test file written successfully.

   Pour plus d’information sur le sujet, il est possible de consulter les documentations suivantes :

Clarisse AUDOUCET
Consultant Support Clients - SAS France