Discussion :

[Hepil]

Bonjour
j'ai une application DOT.NET qui lors de son premier démarrage va créer la base de données dans SQL serveur pour l'utiliser ensuite

Pour cela je dois lui donner soit une authentification SQL server soit windows (le user courant)

Je ne sais pas si c'est mieux de partir sur le "user courant" en authentification windows, sachant que ce n'est pas ce user qui sera utilisé ensuite forcément (plutôt anonymous)

Donc je partirai volontiers sur un User interne à SQL server, mais lequel ?
En créer un nouveau plutôt que d'utiliser sa ?
(je n'ai pas testé avec "sa")

Le souci est que ce nouveau user n'est pas encore lié à la base de données que l'application va créée, vu qu'elle n'existe pas, donc ce nouveau user n'a pas les bons droits pour mon application.

J'ai donné sysadmin à ce user, et aussi dbcreator ... toujours un message d'erreur avec le user

Si je mets Authentification windows, ça marche, bien sûr

Question:

Y a t-il un user /role/droit qui permettrait de créer une base de données à une application, sans lui donner tous les droits ? ou est-ce "sa" qu'il me faut utiliser par défaut ?

[Hepil]

je viens de trouver :

Sécurité

Autorisations

Nécessite l'autorisation CREATE DATABASE sur la base de données master, ou l'autorisation ALTER ANY DATABASE ou VIEW ANY DEFINITION.

Pour garder le contrôle de l'utilisation du disque sur une instance de SQL Server, l'autorisation de création de bases de données est généralement limitée à quelques comptes de connexion.

sur le site Microsoft ici

je vais tester ce soir et je fermerai le sujet si cela est bon ... ou quelqu'un peut tester là maintenant ? Je n'ai pas SQL serveur sous la main ...

[elsuket]

Bonjour,

Dans tous les cas, n'utilisez pas le compte sa pour des connexions d'application. Je vous recommande même de désactiver cette connexion : tout le monde, les petits malins inclus, sait que la connexion sa donne tous les droits sur une instance SQL Server, comme par exemple supprimer toutes les bases de données, puisque cette connexion est membre du rôle fixe de serveur sysadmin.

Je ne sais pas si c'est mieux de partir sur le "user courant" en authentification windows, sachant que ce n'est pas ce user qui sera utilisé ensuite forcément (plutôt anonymous)

Vous devez faire la distinction entre un utilisateur qui se connecte à votre application, et le nom de connexion sous lequel votre application se connecte à l'instance SQL Server.

Le mieux est probablement d'installer l'instance SQL Server avec l'utilisateur courant, qui s'authentifie sous Windows, et qui crée les bases de données et leurs objets requis pour le bon fonctionnement de votre application.
Ensuite vous pouvez créer un utilisateur dédié pour votre application, à authentification "SQL", en ne lui donnant accès qu'aux bases de données dont celle-ci a besoin pour fonctionner.

De cette façon, l'utilisateur courant, en authentification Windows, vous permet de réaliser la maintenance (par exemple), et l'utilisateur SQL ne sert qu'à l'exécution de l'application.

En matière de sécurité, on n'octroie toujours que le minimum nécessaire

@++

[Hepil]

Merci pour tous ces éléments de réponse

Bonjour,

Dans tous les cas, n'utilisez pas le compte sa pour des connexions d'application. Je vous recommande même de désactiver cette connexion : ...cette connexion est membre du rôle fixe de serveur sysadmin.

C'est plus que clair !

Vous devez faire la distinction entre un utilisateur qui se connecte à votre application, et le nom de connexion sous lequel votre application se connecte à l'instance SQL Server.

Le mieux est probablement d'installer l'instance SQL Server avec l'utilisateur courant, qui s'authentifie sous Windows,...
Ensuite vous pouvez créer un utilisateur dédié pour votre application, à authentification "SQL", en ne lui donnant accès qu'aux bases de données dont celle-ci a besoin pour fonctionner...
... @++

Oui pour tout, mais dans mon cas, j'ai 2 besoins différents

sur mon réseau local, j'ai la base de données sur SQL serveur gérée avec un compte local (AD), sans souci!

Maintenant pour l'application, achetée d'ailleurs telle quelle, j'aurai 3 cas de figures:
1- la base de données existe déjà (dans ce cas je ne fais que des mises à jours de code et de files) : il me faut donner à l'application un droit pour UPDATE de files et creation de files et store proc et views ...

2 - la base de données n'existe pas, le user de l'appli doit pouvoir créer la base dans SQL serveur : donc d'après ce que je viens de lire, je peux créer un compte AppliUser1 qui aura les droits DbCreator (je crois) et lié à la base Master. Ça devrait suffire, mais je n'ai pas encore pu tester (voir lundi ou mardi prochain, pas avant )

3 - c'est un enduser (internaute) qui utilise la base de données (anonymous user via IIS 7.5 dans mon cas) : cas réglé (enfin selon moi)

Je dois faire les tests mais si tu as des observations à me soumettre je suis preneurs.
Dans tous les cas, je reviendrai ici pour compléter mes écrits avec les résultats des tests, bien volontiers

[elsuket]

Pour ma part, je créerai un utilisateur à authentification SQL pour que mon application se connecte à SQL Server, et je conserverai l'authentification Windows pour les comptes d'utilisateurs réels ou de service.

Dans le cas où la base de données existe déjà, qu'entendez-vous par UPDATE de files et creation de files ? En ce qui concerne les procédures stockées, vues, fonctions, tables, déclencheurs, vous pouvez tout à fait donner ce droit juste avant la liste des commandes du lot de modifications pour le schéma, et les révoquer une fois que tout est terminé. Pour faire simple, vous pouvez tout à fait faire un GRANT ALTER ON SCHEMA::dbo TO myUserSQL au tout début, et REVOKE ALTER ON SCHEMA::dbo TO myUserSQL à la fin

Dans le cas où la base de données n'existe pas, vous pouvez GRANT ALTER ANY DATABASE TO mySQLLogin, créer la base de données, lui ajouter des fichiers et groupes de fichiers. Une fois cela fait, vous changez de contexte de base de données pour vous connecter à celle nouvellement créée, et vous exécutez le lot de modifications comme je le décris au paragraphe précédent.

Dans le cas d'utilisation d'un internaute, je suppose que ces derniers se connectent à votre site web, qui lui même est l'interface d'un serveur applicatif, lequel se connecte sous authentification SQL aux serveurs de base de données : les internautes sont donc en totale abstraction de ce qui se passe au délà de leur navigateur, et tant mieux !

@++

[Hepil]

Merci de ces réponses

Pour ma part, je créerai un utilisateur à authentification SQL pour que mon application se connecte à SQL Server, et je conserverai l'authentification Windows pour les comptes d'utilisateurs réels ou de service.

Pile poil ce que j'ai fait ce weekend

Dans le cas où la base de données existe déjà, ... vous pouvez tout à fait donner ce droit juste avant la liste des commandes du lot de modifications pour le schéma, et les révoquer une fois que tout est terminé...

Je pense que la partie install de l'appli fait cela, et je ne souhaite pas modifier le code de l'appli, car il faudrait le faire à chaque release ...

Dans le cas où la base de données n'existe pas, vous pouvez ...créer la base de données, lui ajouter des fichiers et groupes de fichiers. Une fois cela fait, vous changez de contexte de base de données pour vous connecter à celle nouvellement créée....

OUI, l'appli fait cela, apparemment sans encombre aussi

Dans le cas d'utilisation d'un internaute, je suppose que ces derniers se connectent à votre site web, qui lui même est l'interface d'un serveur applicatif, lequel se connecte sous authentification SQL aux serveurs de base de données : les internautes sont donc en totale abstraction de ce qui se passe au délà de leur navigateur, et tant mieux !
@++

Exactement ce qui se passe à présent


mille merci et j'espère que cela peut aussi aider d'autres personnes
@ bientôt dans un autres post ...

[elsuket]

Parfait !

Je pense que la partie install de l'appli fait cela, et je ne souhaite pas modifier le code de l'appli, car il faudrait le faire à chaque release ...

Peut-être générez-vous un script SQL que vous passez en paramètre d'entrée à l'utilitaire en ligne de commande SQLCMD ? Si tel est le cas, c'est assez facile

@++

[Hepil]

Alors puisqu'on en parle, oui, il y a des scripts :

En fait l'application est à installer une première fois, et elle demande un compte SQL serveur pour créer la PREMIERE base de données; d'où mes questions précédentes.

Les fois d'après, ce ne sont que des scripts de mises à jours pour la base données et du code pour l'application web (build et deploy)

Ces scripts, je les exécute directement sur SLQ serveur dans la base de données (après sauvegardes bien sûr) avec un compte windows du réseau local.

Si les mise à jours de l'application ne fonctionnent pas du premier coup, ce qui vient de m'arriver, il se peut que je doive procéder à la REINSTALLTION de l'application complètement, et même la base de données peut être reconstruite en TOTALITE avec perte des données !!!

Pour éviter cela, il y a un procédé de réinstallation qui tient compte de l'existence de la base de données et des données éventuellement aussi

Mais tout ceci est inclus dans le package , même si j'en ai tout le code source; je ne tiens pas à modifier quoique ce soit, car ensuite, à la prochaine release, je devrai sans doute tout refaire...

Autant utiliser les fonctions correctement et attribuer les bond rôles à l'application et les accès aux folders

voilà la petite histoire

[SQLpro]

Alors puisqu'on en parle, oui, il y a des scripts :

En fait l'application est à installer une première fois, et elle demande un compte SQL serveur pour créer la PREMIERE base de données; d'où mes questions précédentes.

Ordinairement on ne proède pas du tout de la sorte :
1) à l'installation de l'application on lance consécutivement l’installation de SQL Server sauf si celui-ci est déjà installé.
2) après installe de l'appli et de SQL Server, on lance un script SQLCMD qui va créé la base de données et utilise un compte de connexion de niveau sysadmin. Ce script incorpore la création des utilisateurs et comptes de connexion spécifique à l'appli et la base
3) dans l'application on se connzecte avec le minimum de privilège.

Les fois d'après, ce ne sont que des scripts de mises à jours pour la base données et du code pour l'application web (build et deploy)

Ces scripts, je les exécute directement sur SLQ serveur dans la base de données (après sauvegardes bien sûr) avec un compte windows du réseau local.

Si les mise à jours de l'application ne fonctionnent pas du premier coup, ce qui vient de m'arriver, il se peut que je doive procéder à la REINSTALLTION de l'application complètement, et même la base de données peut être reconstruite en TOTALITE avec perte des données !!!

Le plus simple est de faire une sauvegarde et restaurer la base ou encore de faire une grande transaction qui n'est validée que si l'application a réussit à s'installer !

Pour éviter cela, il y a un procédé de réinstallation qui tient compte de l'existence de la base de données et des données éventuellement aussi

Mais tout ceci est inclus dans le package , même si j'en ai tout le code source; je ne tiens pas à modifier quoique ce soit, car ensuite, à la prochaine release, je devrai sans doute tout refaire...

Autant utiliser les fonctions correctement et attribuer les bond rôles à l'application et les accès aux folders

voilà la petite histoire

A +

[Hepil]

Merci de ces compléments

Ordinairement on ne proède pas du tout de la sorte :
1)...
2) après installe de l'appli et de SQL Server, on lance un script SQLCMD qui va créé la base de données et utilise un compte de connexion de niveau sysadmin. Ce script incorpore la création des utilisateurs et comptes de connexion spécifique à l'appli et la base
3) ...

SQL serveur est déjà installé, effectivement, et j'ai créé des users spéciaux dans SQL et aussi dans AD pour cette application.
Il y a un script de création qui utilise sans doute SQLcmd mais avec le user que je lui fournis (précédemment créé) l'appli n'aura pas accès à SQL serveur sans cela ni d'elle-même !!!
Le script existant ne crée pas les users; l'appli n'en a pas le droit ici ! Je pense que c'est plus sécurisé comme cela et je ne comprends pas trop l'intérêt de ta procédure au niveau sécurité surtout.

Le plus simple est de faire une sauvegarde et restaurer la base ou encore de faire une grande transaction qui n'est validée que si l'application a réussit à s'installer !
A +

Oui, cela est effectivement préconisé

merci @+