Bonjour,
Est-il possible de limiter l'option xp_cmdshell à une seule commande définie (par ex : dtexec) dans le but de respecter certaines contraintes de sécurité..
Merci.
Version imprimable
Bonjour,
Est-il possible de limiter l'option xp_cmdshell à une seule commande définie (par ex : dtexec) dans le but de respecter certaines contraintes de sécurité..
Merci.
Le problème est que je suis en partie obligé d'utiliser cette commande. Il faudrait donc que je puisse prouver à notre admin DB SQL Server qu'elle n'engendre aucun risque, afin qu'il l'active. Comment en être sûr, et comment la sécuriser au maximum?
Le besoin est d'exécuter un package SSIS distant, via une macro Excel.
Pour cela, l'idée est de faire appel en VBA à une procédure stockée (Serveur), qui exécute mon package (dispo dans le SSIS Package Store) grâce à la commande xp_cmdshell -> "dtexec /DTS ...".
Il peut configurer le compte exécutant cette commande...
http://msdn.microsoft.com/fr-fr/library/ms190359.aspx
Merci.
Cependant est-il possible de le limiter à l'exécution d'une seule commande, par ex la commande dtexec.
Est-il possible de lancer n'importe quelle commande shell avec xp_cmdshell ?
Merci
Il faut faire une proc qui appelle xp_cmdshell 'dtexec /...' et donner les droits sur cette proc seule au compte considéré.
Ah ouii bien vu :ccool:!
Je vais essayer d'implémenter ça dans la journée.
Merci !
Encore moi, est-il possible d'autoriser l'exécution de xp_cmdshell à un utilisateur non sysadmin, sans lui créer de proxy.
Le problème est qu'une dizaine de personnes doivent pouvoir exécuter xp_cmdshell via une procédure stockée, que j'ai aussi seulement autorisé en exécution pour ces utilisateurs..
Et devoir créer un proxy/Credential pour chacun serait embêtant, d'autant plus que les credentials ne supportent pas la synchronisation avec le LDAP (problème lors de changement de mot de passe windows) et leur mot de passe ne doit pas être visible par l'admin par sécurité (création credential)
Merci
Bonjour,
Un article intéressant dans votre cas.
@+
MON SAUVEUR ! Merci beaucoup.
Voici la solution donnée dans le lien :
La procédure stockée appellant la commande xp_cmdshell doit être créé dans la base de données système master, et non dans une base de données utilisateur.
Pourquoi ?
Avec cette solution, sql server ne contrôle pas le contenu de la procédure stockée et donc l'instruction exec xp_cmdshell... ne pose pas de problème.
Perso je trouve ca un peu deg comme solution.Citation:
Envoyé par HighSam
Deja creer des sp dans Master, je suis bof bof a l'idee, et de plus faire ca pour bypasser le fait d'utiliser xp_cmdshell...
Je vous recommanderai de creer un job SQL Server agent qui execute votre job SSIS avec un proxy application.
Et dans votre stored procedure de declencher ce job avec sp_start_job.
Ca vous evite de devoir activer xp_cmdshell sur votre instance.
Je comprends oui c'est pas faux..
L'avantage pour moi avec xp_cmdshell est qu'il est possible de donner un paramètre à la commande (variable user), chose impossible avec la procédure stockée sp_start_job.
C'est vrai que je peux toujours lui spécifier un fichier de configuration dans lequel j'indiquerai la valeur de ma variable...
Mais J'ai 2 questions vis à vis de ça :
Est-il possible que plusieurs utilisateurs SQL puissent exécuter un même job simultanément ?
Est-il possible que plusieurs personnes distinctes (avec le même compte SQL) puissent appeler une procédure stockée lancant la commande dtexec sur un même package (paramètres différents) simultanément, depuis la procédure stockée xp_cmdshell et ceci sur un serveur 64bit ? Ou faut-il leur créer chacun un autre compte SQL? Ou dans les 2 cas ce n'est pas possible ?
Merci.
NonCitation:
Envoyé par HighSam
Je sais pas, a tester.Citation:
Envoyé par HighSam
Autre piste:
Que fait ce package SSIS ?
Quid d'en sortir la logique ?
Au fait, pourquoi passer par des commandes SQL pour déclencher un package SSIS ?
Vous pouvez toujorus faire appel dans votre VBA, directement à l'éxecutable DTExec.exe... : C:\Program Files (x86)\Microsoft SQL Server\100\DTS\Binn\DTExec.exe
J'ai pense a ca aussi...Citation:
Envoyé par Jinroh77
Le probleme est si le fichier excel est ouvert en local et que dtexec n'existe pas sur la machine client.
Il faut aussi de la machine client executer le package SSIS qui se trouve ailleurs (possible via un share).
QUID alors de la configuration du package si celui-ci utilise une variable d'environnement... -> A definir sur tous les clients.
Il faudrait alors passer par l'execution en remote de dtexec (est ce possible ???)
Il faudrait effectivement executer avec le DtExec du serveur, amis ça implique certaines choses.
Pour les variables, on peut les passer via le dtsconfig ou dans la ligne de commande, par contre pour les droits sur des fichiers source par exemple, ça doit se paramétrer également.
Ce projet s'inscrit dans le cadre d'un reporting project (project : affaire interne à l'entreprise), effectué via un fichier excel rempli de feuilles et de macros.Citation:
Envoyé par Ptit_Dje
Ce fichier (le "MASTER") est toujours utilisé vu que les clients internes en sont satisfaits, mais était autrefois, en partie alimenté manuellement ! Ce processus a depuis changé et je suis en charge de l'automatiser/l'industrialiser.
Je précise que ce fichier est lancé par les contrôleurs de gestion.
J'ai terminé le développement du package, en local. J'effectue donc des tests (concluants) mais dans un environnement développeur (SSIS, BIDS)
Le processus est le suivant :
---- PACKAGE.DTSX ----------------------------------------------------
1-] Récupérer les données d'une BD SQL Server sur le réseau (ex: \\SERV)
2-] Traiter ces données
3-] Restituer ces données vers des "exports" excel présents sur un serveur de données (ex: S:\ )
---- MANUEL -----------------------------------------------------------
4-] Un fichier "Master" Excel doit ensuite être lancé manuellement, permettant de réaliser le reporting project, en vue de faire certaines analyses financières. Ses macros vont donc permettre d'alimenter ce fichier à l'aide des exports générés à l'étape 3-].
-> Ce package doit être administré sur serveur, et éventuellement planifiable (mode Batch); je l'ai ainsi déployé sur serveur, vers le SSIS Package Store et SQL Server (SQL Server Agent) -> FONCTIONNEL !
=> Puis l'idée est d'intégrer au final dans ce Master, un bouton permettant d'exécuter ce package (mode Interactif). Mais nous voulons alléger le plus possible l'environnement technique des contrôleurs de gestion, qu'ils puissent aboutir à cela sans qu'on soit amener à leur installer SSIS.
Ca m'aurait beaucoup simplifié la vie dès le départ, mais nous ne pouvons pas installer SSIS à tous les contrôleurs de gestion pour pouvoir rendre accessible à chacun la commande DTexec.exeCitation:
Envoyé par Jinroh77
Justement, dans le VBA, sur le poste client, vous pourriez directement faire appel à l'executable DTExec qui est placé sur le serveur.
Comment ? :lol:
A part ça, pour la commande xp_cmdshell, quand je crée le proxy avec la procédure sp_xp_cmdshell_proxy_account, qu'est-ce que cela signifie :
Est-ce que n'importe quel compte non sysadmin sera apte à exécuter xp_cmdshell, et ceci quelque soit le compte windows enregistré dans le credential ##xp_cmdshell_proxy_account## (sous réserve d'authentification réussie bien sur) ?
Merci.
Avec un executable dans ce genre :
Code:\\MonServeur\c$\progr..\SQL ..\..\DTExec.exe /DTS "\File System\MyPackage"