[SEG] Impossible de se connecter à SASApp

**foxrol** · 02/04/2012, 19h23

Bonjour,
J'ai crée un utilisateur avec un compte interne toto@saspw avec un mot de passe, jsuqye la tout va bien.

Je me connectes dons sous Guide pour exécuter une requête toute simple

Code sas :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
proc print data=sashelp.prdsane;
run;

Mais à ma grande surprise j'ai une fenêtre (cf. fig1 ci-dessous) et lorsque je rentres les identifiants respectifs j'ai le message Impossible d'établir la connexion au serveur "SASApp" (cf. fig 2).
Alors j'aimerais savoir comment résoudre ce problème.

Merci

**datametric** · 02/04/2012, 20h49

Tu as oublié l'étape qui dit que toute identité doit être lié à un compte d'exécution. Sur Windows, un compte utilisateur avec le droit LOG ON AS BATCH JOB.
Si tu crées une identité avec un compte interne, tu seras identifié dans les MD et tu feras partie de SASUSERS.
Mais ensuite ? il te faut le lier un compte sur le serveur d'exécution.

Soit tu dis que chaque identité est lié à un compte
Soit elle est liée à un compte générique comme tu le fais avec SASSRV.
Soit le groupe utilisateur est lié à un compte Windows.

**yassine.ziad** · 09/04/2014, 16h05

Bonjour,

J'ai le même problème décrit ci-dessus, impossible de se connecter à la SASApp à moins de déclarer l'utilisateur en question autant qu'administrateurs du serveur SAS.

Voici les étapes par lesquelles je suis passé :

- création de l'utilisateur au niveau du SMC
- ajout de l'utilisateur au niveau du groupe sasusers (windows)

Sachant que le groupe sasusers est déclaré au niveau groupe "agir autant que partie du système d'exploitation" au même titre que sassrv
pouvez vous svp m'aider car je suis bloqué depuis plus d'une semaine.

Cordialement.

**Stackware** · 27/08/2014, 17h23

Il faut ajouter aux pré-requis le fait que le dossier WORK doit être accessible au groupe des sasusers en lecture ET écriture. Le workspace server ne pourra pas démarrer s'il ne peut pas créer son dossier dans la WORK. Il faut donc ajouter le groupe dans la sécurité du dossier en question.

**xav2229** · 03/09/2014, 11h52

Créer un user "toto@saspw" permet de se connecter aux métadata, rien ne dit que ce compote pourra ensuite obtenir une connexion de type WorkSpace.

Il y a beaucoup de choses à vérifier...

Un test possible est d'ajouter les droits d'affichage des plugins dans la SMC pour toto
Se connecter a la SMC en tant que toto
Effectuer un test "Validate" sur le WorkSpace que l'on veut
Regarder les logs ObjectSpawner/Metadata
Si l'on a un message qui demande un login/mdp lors du validate c'est que toto ne connait pas/n'a pas accès à un compte systeme (sassrv ou autre) qui lui lancera la commande WorkSpace

bonne chance!

**Stackware** · 03/09/2014, 14h56

Salut,

En fait on peut lancer la SMC avec sasadm@saspw, et entrer les login/pass que l'on veut tester avec le validate workspace (il demandera à les entrer vu que sasadm est interne).
Si on veut tester plusieurs identités, il faudra aller dans le premier menu de la SMC, en haut à gauche et cliquer "effacer les informations d'identification" parce que la SMC enregistre ces informations le temps de la session.
Si l'on a créé en local sur le serveur un compte sasdemo par exemple, on peut s'en servir pour faire fonctionner tous les utilisateurs, mais ce n'est pas très recommandé.

La meilleure solution est de créer un groupe AD (si l'on est en Active Directory) que l'on appellera SASUSERS par exemple, de déclarer dans les local policies le droit "logon as a batch job" (ou "ouvrir une session en tant que tâche" pour les Windows en Français) pour ce groupe sur le serveur (ou bien le gérer dans l'AD dans les group policies), puis de déclarer sur le serveur les droits de lecture et d'écriture (si nécessaire) sur les répertoires de données, les répertoires d'installation, la WORK etc. pour ce groupe. Il faut enfin déclarer les utilisateurs dans la SMC en y ajoutant dans l'onglet comptes leur identifiant AD sous la forme DOMAINE\IDENTIFIANT.

Pour finir les utilisateurs doivent se connecter en utilisant DOMAINE\IDENTIFIANT comme user, et leur mot de passe de session Windows. S'il n'y a pas d'Active Directory, "DOMAINE\" est à enlever de la déclaration dans la SMC et dans le nom d'utilisateur pour se connecter. Le groupe et les utilisateurs seront à créer localement sur le serveur SAS (le groupe ne servira alors que pour gérer les droits sur les répertoires, et aucune déclaration dans les local policies ne sera à faire, vu qu'un utilisateur local a toujours le droit de se connecter).

Pour finir, les comptes interne ne peuvent être utilisés que pour certaines applications Web (comme Web Report Studio ou le Stored Process web) et pour des fonctions d'administration dans la SMC. Si l'on utilise Guide ou Studio, il faut un compte physique sur le serveur (local ou AD) pour lancer le workspace server. Quand on est sur Unix ou Linux, c'est pareil, sauf que les utilisateurs doivent faire partie du groupe du compte d'installation de SAS pour pouvoir l'exécuter (et donc exister sur le serveur, que ce soit en local ou pas).

**vnr66** · 04/09/2018, 13h44

Bonjour,

Je déterre ce fil car j'ai le même problème, ces info m'ont bien aidé à identifier le problème. Mais comment créer un compte utilisateur externe ? A partir de la SMC ou dans Windows ?
J'ai créé un utilisateur test et la même boite de dialogue demandant id/mot de passe apparaît et le compte est y est inopérant. Je suppose que mon compte test n'est pas "externe".

Merci d'avance