[SQL 2k5] xp_cmdshell - mapped drive - permission erreur

Version imprimable

31/01/2007, 00h09
mksql

[SQL 2k5] xp_cmdshell - mapped drive - permission erreur

Hi,

Mon problème est le suivant :

je souhais copier un fichier d'une destination A (mapped drive) vers une destination B (mapped drive) via la commande xp_cmdshell ceci dans une procédure stockée. J'utilise un path UNC pour les deux chemins d'accès.

Lorsque je lance la commande via le QueryAnalyzer rien ne se fait.

Je suis loggé sur l'EnterpriseManager via mon compte de domain Win qui est également sysadmin du serveur SQL. Apparemment j ai les permissions pour écrire dans le dossier de destination car sous Win j'y copie ce que je veux dans ce même dossier.

Ma commande fonctionne si je la modifie pour avoir comme destination un dossier en local.

Apparemment cela ne peut être qu'un problème de permission entre le compte utilisé qui lance la commande cmdshell et les comptes ayant les droits sur le dossier de destination. Est-ce vraiment mon compte Win qui est utilisé? (même étant logé sur le serveur SQL via une authentification Win)

NB: Mon path de destination contient des dossiers avec espaces, cela peut-il être la cause?

Avez vous une idée?
31/01/2007, 10h14
Invité

Quelle édition de SQL Server ?

Si c'est du 2005, il faut activer xp_cmdshell (voir Surface Area).

De plus, vous pouvez (devez?) utiliser la procédure sp_xp_cmdshell_proxy_account pour spécifier le compte Windows que xp_cmdshell doit utiliser pour son exécution (ce compte doit donc avoir les droits sur vos partages).
31/01/2007, 20h39
mksql

Citation:

Envoyé par kuzco

Quelle édition de SQL Server ?

Si c'est du 2005, il faut activer xp_cmdshell (voir Surface Area).

De plus, vous pouvez (devez?) utiliser la procédure sp_xp_cmdshell_proxy_account pour spécifier le compte Windows que xp_cmdshell doit utiliser pour son exécution (ce compte doit donc avoir les droits sur vos partages).

oui SQL 2k5, la commande cmdshell est activée vue qu'elle marche si je lance une cmd de copie vers un dossier local.

Par contre pour ce sp_xp_cmdshell_proxy_account je ne connaissais pas je vais voir cela. En espérant que la solution soit à ce niveau. Merci pour la réponse.
06/02/2007, 18h18
mksql

rebonjour,

j'ai testé cette commande en donnant le monDomain\loginWindow + le pass mais apparemment cela n'a pas changé grand chose. Faut-il faire qqchose d'autres? Pour info j'appelle tjrs la commande ainsi : exec master..xp_cmdshell 'ma commande...'

En lancant un "dir" avec un xp_cmdshell sur un dossier local cela marche,
sur le UNC path 1 j'ai la 1ere partie avec les infos sur le volume puis le message comme quoi il n'y a aucune donnée n'a été trouvé,
sur le UNC path 2 j'ai le message comme quoi mon accès est refusé.

(les 3 dir via cmd.exe marchent)
07/02/2007, 10h13
Invité

Avec quel compte démarrent vos services MSSQLSERVER et SQLSERVERAGENT ?

Si localsystem, ce n'est pas bon, il faudrait les démarrer avec un compte qui a des droits d'accès aux chemins UNC.
07/02/2007, 18h58
mksql

Citation:

Envoyé par kuzco

Avec quel compte démarrent vos services MSSQLSERVER et SQLSERVERAGENT ?

Si localsystem, ce n'est pas bon, il faudrait les démarrer avec un compte qui a des droits d'accès aux chemins UNC.

Je me logue via l'authentification win sur le serveur SQL.
Sinon au niveau du SQLAgent je ne vois pas où configurer le démarrant. Mais je suis owner des jobs autrement.
07/02/2007, 23h45
SQLpro

Vous n'avez pas compris la question qui vous était posé :
QUEL SONT LES COMPTES SYSTEMES SOUS LESQUELS LES SERVICES SQL SERVER ET AGENT TOURNENT-ILS ?
Ces comptes là peuvent-ils accéder à d'autres ressources ?
En efet si vous faîtes tourner SQL Server avec un compte d'administrateur local vous ne pourrez accéder à aucune ressources réseau.

A +
08/02/2007, 15h35
mksql

Citation:

Envoyé par SQLpro

Vous n'avez pas compris la question qui vous était posé :
QUEL SONT LES COMPTES SYSTEMES SOUS LESQUELS LES SERVICES SQL SERVER ET AGENT TOURNENT-ILS ?
Ces comptes là peuvent-ils accéder à d'autres ressources ?
En efet si vous faîtes tourner SQL Server avec un compte d'administrateur local vous ne pourrez accéder à aucune ressources réseau.

A +

Hello,

hum ok j'ai compris, j'ai modifié le compte avec lequel le service démarre (en mettant mon compte de domain au lieu du système locale) et effectivement j'arrive maintenant à utiliser le cmdshell sur les ressources mappées. Merci pour cette aide.

Cependant la finalité de ce code est d'être exécuté sur une machine sur laquelle diverses personnes se loggent et utilises le service SQL.
Je ne pense pas qu'il soit possible d'attribuer mon compte en tant que démarreur du service SQL dans ces conditions. Comment alors faire en sort que mon code utilise toujours les droits de mon compte de domaine? Est-il possible que le compte local système de ce serveur puisse hériter des droits de mon compte de domain win?
08/02/2007, 15h58
Invité

Oubliez le compte localsystem. Demandez à l'administrateur de créer un compte de service qui sera dédié à SQL Server (et uniquement à lui). Les droits sur les ressources partagées devront être donnés à ce compte.
08/02/2007, 16h18
mksql

Citation:

Envoyé par kuzco

Oubliez le compte localsystem. Demandez à l'administrateur de créer un compte de service qui sera dédié à SQL Server (et uniquement à lui). Les droits sur les ressources partagées devront être donnés à ce compte.

Ok, merci pour vos réponses le cas est résolu.