Discussion :

[cscerim3]

Bonjour,

Après une migration depuis un SAS en local vers un serveur SAS, je tente de reproduire le comportement de l'ancienne installation.

J'ai un poste (P), un serveur sur lequel SAS est installé (S) et un serveur de fichiers (R).


Voici ce que je voudrais faire :

Sur P, avec Guide écrire un fichier (par exemple avec l'ods html) et le stocker sur R, sachant donc que c'est S qui exécute le code SAS.

Au niveau des droits :

- J'utilise l'IWA pour me connecter à S depuis P.
- mon user a le droit d'écrire sur R

Lorsque je crée un fichier sur S celui-ci a bien comme propriétaire mon user windows. c'est donc le user windows qui 'écrit' ?
Lorsque j'essaie de créer le même fichier sur R, j'ai une erreur de droit d'accès.

Est il possible d'utiliser les droits du user pour écrire des fichiers sur d'autres serveurs?
Sinon quel user doit être autorisé à écrire sur R pour que ça fonctionne?

J'espère avoir été assez clair . merci d'avance pour vos réponses.

[cscerim3]

Début de réponse ici :

c'est possible mais il faut modifier les paramètres dans l'AD pour autoriser la délégation :
source

[datametric]

Sur S c'est le user du workspace server qui est utilisé. Si tu vois R depuis S (fichier > Ouvrir par ex).
Si tu exécutes ton traitement sur S, quel utilisateur est derrière ?
Il se peut (fortement) que ce ne soit pas le tien. Si par exemple tu as un annuaire LDAP ou AD c'est que le user d'exécution sur le workspace est différent de ton identité. Soit c'est sassrv ou un user du groupe d'identité auquel tu es rattaché.

[cscerim3]

Je débute avec cet univers alors j'ai un peu de mal

lorsque j'exécute un ods html, le fichier est crée avec comme propriétaire mon user. si c'est sassrv alors c'est un user interne à S, il ne sera pas possible d'utiliser les droits du user pour accéder à R ?
En plus clair :
Les deux opérations suivantes vont elles produire un résultat différent ?
- se logguer sur P avec mon user, lancer un script sas (depuis guide connecté sur S) qui crée un fichier sur S
- se logguer sur S avec mon user, lancer un script sas qui crée un fichier sur S
(je ne suis pas en mesure de le vérifier)

Merci pour la réponse en tout cas

[xav2229]

(je ne suis pas en mesure de le vérifier)

Tu devrais pouvoir le faire en utilisant la commande CACLS (Windows)

X

[datametric]

Avec EG :
1. je me connecte aux métadonnées avec le profil. c'est l'identité de l'utilisateur qui est vérifié. on peut avoir une connexion à l'annuaire.
2. je soumets un traitement. il faut un compte système comme sassrv. Ce sont ses droits qui doivent être vérifié.

Le "user interne" est un terme important en 9.2 donc je ne l'emploierais pas. il correspond à tout compte blabla@saspw.
sassrv est un compte d'exécution avec les droits pour cela (LOG ON AS BATCH JOB sur Windows).

Donc tes deux phrases me semblent équivalentes : je me loggue avec EG sur les métadonnées puis j'exécute sur S avec un compte d'exécution. C'est lui qu'il faut déterminer pour connaître ses droits sur les répertoires.

[cscerim3]

Je suis entrain de voir avec les administrateurs, je mtterai à jour le sujet dès que possible

[cscerim3]

En attendant, j'ai trouvé un moyen détourné :

j'exécute depuis EG sur les postes utilisateurs :

Code :

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

1
2
 
x "net use R: \\mon\partage\reseau /user:DOMAINE\&SYSUSERID. &_PASSWORD.";

Deux problèmes majeurs avec cette méthode :
- Obligé d'activer l'option Allow XCMD
- Il faut saisir un mot de passe en clair, je pensais à le récupérer dans une procédure stockée avec l'invite qui va bien mais dans ce cas, le partage n'est apparemment valide que pour la session de la procédure et pas pour du code exécuté ensuite dans guide.

[xav2229]

Donc tu as des problèmes de droits.

Comme je te l'indiquais pour diagnostiquer les droits appliqués tu fais un CACLS.

Tu verras dans quel groupe ton user doit être.

Lance ceci :

Code :

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

1
2
3
4
5
6
7
8
filename inP pipe'CACLS R:\';
data _NULL_;
   infile inP pad;
   input;
   varlen = length(_infile_);
   put _infile_ $varying256. varlen;
run;
filename inP clear;

et donne nous la log.

X

[cscerim3]

Avec CACLS, j'obtiens effectivement la liste des groupes et de leurs droits sur ce partage (je ne peux pas les poster ici par contre).
Mes users clients (qui se log sur le serveur avec l'IWA) appartiennent bien à un de ces groupes, c'est le user sassrv qui est local au serveur et donc qui n'y appartient pas.

Lorsque je regarde les noms d'utilisateurs dans les processus, c'est pas sassrv qui exécute sas.exe mais bien les utilisateurs client.

En fait, je ne comprends pas à quel moment va intervenir le user sassrv ?

Je tente de faire la modification décrite ici :
http://platformadmin.com/blogs/paul/...or-delegation/
sur l'AD. En espérant que ça fonctionne.

[cscerim3]

=> résolu

Le problème venait bien de l'AD.

Corrigé en appliquant la modification au dessus.