Version imprimable
salut a tous,
je suis au tout debut avec entity framework et je suis confronté a un problème, lors que la recherche de la base de données visual c# n'affiche deux option, parmi lesquel fichier de base de donnée, base de données compact et pas microsoft sql serveur.
je me plante a ce niveau. s'il vous plait aidé moi a comprendre pourquoi il ne voit pas mon sql serveur et ce qu'il faut faire.
merci
Si tu as un SQL Server sur ta machine, il suffit de taper l'adresse locale
localhost\"nom de l instance"
Si tu as un serveur SQL Server Express ca devrait etre
localhost\SQLExpress
Si tu as un serveur SQL Server Developer ou autre version payante
localhost\MSSQLServer
normalement je m'attendais a voir afficher mon serveur sql dans cette fenetre.
Il me semble que ça soit lié à ta version de Visual Studio, c'est une version Express 2008 ?
Ce que tu peux faire c'est de sélectionné un ficher de base de donnée et modifié ensuite le connexion string.
stp soit plus explicite,
je suis un débutant en programmation.
:cry:
Bonsoir.
Voici la petite astuce pour accéder à une base de données SQL Server.
Modifie ton fichier app.config en y ajoutant la section suivante :
Ensuite quand vous ajoutez un nouvel élément du type ADO.Net Entity Data Model vous verrez votre connexion dans la fenêtre de connexion.Code:
2
3
4
5<connectionStrings> <add name="MaConnectionString" connectionString="Data Source=NOM_DU_PC\SQLEXPRESS;Initial Catalog=MaBase;Integrated Security=True" providerName="System.Data.SqlClient" /> </connectionStrings>
Integrated Security=True signifie que tu vas utiliser le compte local de la machine pour accéder au serveur de la BDD. Je parle bien de 2 choses différentes ici l'accès à la BDD et l'accès au serveur où se trouve la BDD.
Personnellement je ne le mets jamais pour ne pas avoir de problèmes de droits d'accès au serveur.
Code:
2
3
4<connectionStrings> <add name="NomDeLaConnexion" connectionString="metadata=res://*;provider=System.Data.SqlClient;provider connection string="Data Source=NomServeur;Initial Catalog=NomBDD;User ID=NomUserBDD;pwd=MotDePasse;MultipleActiveResultSets=True"" providerName="System.Data.EntityClient" /> </connectionStrings>
je suis tout a fait d'accord avec toi mais la j'ai fait au plus simple puisqu'il est débutant, inutile pour le moment de s'embarrasser avec la sécurité des comptes.
A+
Justement je me rappelle qu'une de mes 1er blocage ça été ça.
Visual Studio m'a généré la même connexionString que toi et ...
ça marchait en débug mais dès que je déployais ça marchait plus ...
J'ai mis un petit moment pour comprendre
Dès fois le plus simple et la solution qui évite certains problèmes (à mon avis)
Et je pourrai savoir pourquoi, j'ai reçu un -1 sur le poste d'avant, si ma réponse ne plaît pas, je voudrait au moins savoir pourquoi :cry:
Citation:
Personnellement je ne le mets jamais pour ne pas avoir de problèmes de droits d'accès au serveur.
Je ne suis pas à l'origine du -1 mais cette allégation n'a aucun sens...
En quoi laisser un compte WINDOWS se connecter à SQL SERVER est un problème de sécurité?
Il est par exemple classique de dédier un compte WINDOWS sur le domaine à un POOL d'application d'une application WEB et de gérer les droits SQL de cette application via ce compte...
Une base de données (a part SQL COMPACT) n'est pas un simple fichier sur lequel on pointe...Citation:
Visual Studio m'a généré la même connexionString que toi et ...
ça marchait en débug mais dès que je déployais ça marchait plus ...
Je suis l'auteur du -1 parce que ton affirmation à propos des problèmes de droits est sans fondement et dangeureuse.Citation:
Envoyé par BROWNY
L'authentification par compte Windows est plus sécurisée, la configuration par défaut de SQL Server désactive le mode d'authentification par user/password.
Le mode Windows simplifie la gestion en utilisant les groupes AD et évite d'introduire une faille de sécurité potentielle si tu ne chiffres pas tes chaînes de connexion dans les fichiers de config. Il y a encore un paquet d'autres raisons, mais ce n'est pas le débat ici.
Certes je ne suis peut être pas expert dans le domaine, mais au moins j'ai une réponse, c'est toujours mieux que de ce prendre un skud sans savoir pourquoi.
Je ne dis pas que c'est un problème mais que si tu ne configure pas comme il faut tes machines ... tout débutant risque de chercher longtemps.
Le "sans fondement", je ne suis pas d'accord, puisque le problème s'est posé ici. A cause de règle de FireWall et de sécu sur les serveurs ont a pas trouvé d'autre solution :cry:
Peut-on expliquer alors comment on fait pour avoir une connexion string criptée et évité le problème d'authentification entre machines
D'un autre côté, pour protéger ton web.config, c'est de la sécutité sur le serveur. Si le gas ne peut pas accéder à ton config.web, tu t'en moques que ta chaîne soit criptée, non?
Je pose quand même la question car le response sécu nous a expliqué le problème comme ça, donc si c'est une grave erreur autant le savoir et que ça serve aux autres :ccool:
Tu as des exemple sur le MSDN:
http://msdn.microsoft.com/fr-fr/library/dtkwfdky.aspx
Dans mon domaine, on n'applique pas la notion de "trusted sub-system", ça veut dire que de bout en bout la connexion doit être attachée à une identité utilisateur. ça implique de passer par de l'impersonation pour certaines opérations. L'utilisation de l'authentification par l'AD permet de limiter les possibilités de récupération d'une identité SQL Server par la lecture d'une chaine de configuration non cryptée. Une faille de sécurité sur ASP.NET/IIS/Windows est plus accessible sur un front-end Web que sur un AD. Le risque est donc un peu moins élevé.Citation:
Envoyé par BROWNY
La seule fois où je passe par l'authentification SQL Server est lorsque mes serveurs sont en DMZ sans domaine. Mais là, ma surface d'exposition est bien moindre et le risque est mitigé par les procédure/équipement de sécurité.
Merci beaucoup pous vos 2 explications, c'est plus clairs.
Avec ses explication, je vais pouvoir argumenter et essayer de trouver une solution plus propre que ce qui est mis en place.
Personnellemnt, au début, je n'étais pas pour la suppression de l'identification Windows, mais n'ayant rien trouvé de mieux dans le délai imparti ...
Aller +1 avous 2
En faite la moitié de notre infra est sur un réseau secondaire sans accès à l'AD. De plus, certaines appli ne sont pas chez nous, donc pas d'accès à l'AD non plus. Or on souhaite avoir une méthode commune. Donc la solution la plus probable sera de crypter la connexion string.
Le seul truc, c'est qu'il faut faire la manip sur chaque machine. Un peu lourd, mais si ça protège mieux.
Il y a plusieurs personnes qui ne sont pas d'accords avec cette affirmation, pour l'exposition est identique même si tu est en DMZ sans domaine, peux-tu expliquer ce qui t'amène à cette conclusion?Citation:
La seule fois où je passe par l'authentification SQL Server est lorsque mes serveurs sont en DMZ sans domaine. Mais là, ma surface d'exposition est bien moindre et le risque est mitigé par les procédure/équipement de sécurité.
Dans ce cas, ne pourrais tu pas tout simplement créer un compte local sur la machine est utiliser ce compte comme s'il venait de l'AD?
Cette affirmation est plus en rapport avec le fait qu'il n'y a qu'en DMZ que j'utilise l'authentification SQL Server.Citation:
Envoyé par BROWNY
Pour deux serveurs SQL dans un domaine (sans tenir compte des autres éléments), la surface est pratiquement identique sur le serveur SQL quelque soit le mode d'authentification. La surface d'exposition s'agrandit pour le mode SQL du fait de la manière dont se connectent les autres acteurs (user+password). J'espère que c'est plus clair.
Mon exposition est différente car la base en DMZ ne contient que le subset minimum de données pour faire fonctionner le front end. Cette base est synchronisée avec la base principale grâce à un process différent.
De fait, je ne m'expose pas au même risque de sécurité.
Si le serveur est compromis d'une manière ou d'une autre, les dommages potentiels sont bien plus limités par le reste des équiments réseaux (mais ça c'est simplement le rôle d'une DMZ)
J'utilise des fois cela aussi sur cerains sites, ouj'ai mis un webService avant d'attaquer la base.
Sinon, j'ai oublié de dire que je paramètre mes "users Web" dans SQLServer qu'à certaines tâches.
Par exemple je leur interdit de créer des tables. En fait ils n'ont le droits que d'utiliser les procédures stockées mises à disposition. C'était l'astuce que j'utilise pour limiter toute agression.
Penses-tu que cela est suffisant? ou alors le criptage de la connexion string serait un vrai PLUS.
Parce que mettre en place de nouvelles procédures , c'est bien, mais si l'impact est minime, ça devient de la perte de temps et la mon Boss ne va pas être d'accord (même si personnellement la sécu est importante, pour les responsables, il la voit en chiffre).
Chiffrer une connexion est toujours un plus. En plus, ça ne prend pas longtemps et ce n'est finalement qu'un petite étape en plus dans ton process de déploiement. Après à toi de voir quel niveau de sécurité tu souhaites atteindre au final. Si ton responsable sécurité accepte le risque associé à une chaîne de connexion en clair, c'est sa responsabilité.