Bonjour,
Je voudrais comprendre la différence entre SQL Server authentification et Windows authentification . Est ce qu'il y'a une spécifique utilisation pour chacun des deux ?
Merci
Version imprimable
Bonjour,
Je voudrais comprendre la différence entre SQL Server authentification et Windows authentification . Est ce qu'il y'a une spécifique utilisation pour chacun des deux ?
Merci
La grosse différence entre ces deux modes de connexion ce que le type windows authentification permet le SSO et que le mode sql serveur non .
Je vois 2 cas d'utilisations principale du windows authentification :
- 1 lorsque l'on veux donner accès à des utilisateurs windows à une base de donnée de façon à pouvoir les identifier facillement
- 2 de donner accès à un compte de service à une base afin qu'il puisse y effectué des traitements ex : le compe de service SSAS pour l'acces a ces datasources lors du traitement du cube
Pour le mode sql serveur on s'en sert principalement pour les connexions applicatif : ex web service , client lourd ... dans le cas ou l'on ne souhaite pas sécurisé la connexion a la base de donnée au niveau utilisateurs
Pour les WebServices et autres applications "serveur", il est tout de même recommandé d'utiliser l'authentification intégrée.
En effet, dans IIS, chaque pool d'application peut tourner avec sa propre identité. Par conséquent, cela permet aisément de segmenter la sécurité d'un site web à un autre.
Et pour les services en tant que tel, à nouveau, chacun peu prendre une identité différente. A nouveau, il est intéressant de segmenter les autorisations d'un service à l'autre.
En fait, le mode d'authentification mixte est surtout là pour les serveurs distants qui ne sont pas localisés dans un domaine. Plutôt que de prendre le risque de faire circuler les identifiants Windows de la machine à travers le réseau, l'hébergeur préfère communiquer uniquement le compte utilisateur de SQL Server, cela réduit l'impact d'un éventuel piratage.
Sinon, ce mode d'authentification est globalement à éviter, et n'est pas recommandé, car bien moins sécurisé (obligation de stocker le login/password sur le poste client, envoi des identifiants à chaque connexion).
Ajout : Pour en revenir aux sites web, il n'est absolument pas recommandé de mapper l'utilisateur Windows à l'utilisateur de la base de données. Ceci en raison du pooling de connexion, qui est obligé d'établir un pool de connexion par identifiant : s'il y a 1000 utilisateurs différents, on se retrouve alors avec 1000 pools de connexion avec chacun au minium 4 (paramètre par défaut) connexion actives et persistantes sur SQL Server. On se rend vite compte qu'il y a un problème.
Lorsqu'on utilise l'authentification Windows pour s'identifier à IIS, cela ne dois pas impacter l'identité du pool d'application, ou alors il faut absolument passer par exemple par un web service qui passe par sa propre authentification, au risque de saturer rapidement SQL Server.
Si vraiment on veut mapper l'utilisateur à SQL Server, dans ce cas on remontera au groupe d'utilisateur (ADV, Vendeur, Comptabilité, etc. plutôt que le login utilisateur lui-même, afin de réduire le nombre de pools de connexions)
Ajout 2 : Je me rends compte que ce que je viens de dire pour un site web est vrai aussi pour un client lourd. Du moment qu'on opte pour du SSO, il faut utlisier dans SQL Server les groupes utilisateurs plutôt que les logins utilisateurs, sous risque d'avoir rapidement des problèmes.
Cette limitation n'est pas inhérente au mode d'authentification Windows, on a rigoureusement le même problème avec la démultiplication des logins SQL Server.
D'accord, merci pour ces éclaircissements, merci beaucoup
Je ne peut pas être d'accord avec toi et cela pour plusieurs raisons :Citation:
Envoyé par StringBuilder
1) les utilisateurs WINDOWS nécessitent une authentification WINDOWS donc un serveur de domaine, voire un LDAP... C'est lourd, surtout dans le cas d'un PRA, car il faudra remonter le serveur de domaine et LDAP avant de faire fonctionner ton serveur SQL !!!! Que de temps perdu si Dassault voulait te commander 3456775434556 avions ?
2) il y a des moyens de chiffrer les deux côtés de la connexion afin que les mots de passe ne passent pas en claire
3) avec un seul compte de connexion commun à tous les utilisateur, traçabilité impossible !
4) avec le mode WINDOWS tu es ferré au monde Microsoft... Si tu veut passer ton application sur PG ou Oracle, faudra récire beaucoup de chose
Personnellement et depuis de nombreuses années, j'incite mes clients à utiliser :
- l’authentification Windows pour tout ce ui est admin
- l'authentification sa pour ce qui est du créateur des bases et des objets des bases (afin d'éviter l'orphelinage des propriétaire...)
- l'authentification SQL en créant autant d'utilisateurs SQL qu'il y a de gens connecter (les tables système étant mieux faites que des tables utilisateurs spécifiques à une appli lambda) et surtout pour avoir une traçabilité maximale, obligatoire notamment dans le domaines de la finance (Bâle II, SOX...) ou dans le domaine de la santé...
Pour de l'anonyme OK. Mais une fois l'utilisateur identifié, le problème n'a aucune importance car il sera toujours au moins géré quelque part... Par exemple l'idée d'ajouter l'identifiant de l'utilisateur dans chaque procédure complexifie et alourdit les codes et les performances sont à la baisse !Citation:
Ajout : Pour en revenir aux sites web, il n'est absolument pas recommandé de mapper l'utilisateur Windows à l'utilisateur de la base de données. Ceci en raison du pooling de connexion, qui est obligé d'établir un pool de connexion par identifiant : s'il y a 1000 utilisateurs différents, on se retrouve alors avec 1000 pools de connexion avec chacun au minium 4 (paramètre par défaut) connexion actives et persistantes sur SQL Server. On se rend vite compte qu'il y a un problème.
Possible dans certains casCitation:
Lorsqu'on utilise l'authentification Windows pour s'identifier à IIS, cela ne dois pas impacter l'identité du pool d'application, ou alors il faut absolument passer par exemple par un web service qui passe par sa propre authentification, au risque de saturer rapidement SQL Server.
Si vraiment on veut mapper l'utilisateur à SQL Server, dans ce cas on remontera au groupe d'utilisateur (ADV, Vendeur, Comptabilité, etc. plutôt que le login utilisateur lui-même, afin de réduire le nombre de pools de connexions)
Pas aussi simple qu'il n'y parait !!!!Citation:
Ajout 2 : Je me rends compte que ce que je viens de dire pour un site web est vrai aussi pour un client lourd. Du moment qu'on opte pour du SSO, il faut utlisier dans SQL Server les groupes utilisateurs plutôt que les logins utilisateurs, sous risque d'avoir rapidement des problèmes.
Cette limitation n'est pas inhérente au mode d'authentification Windows, on a rigoureusement le même problème avec la démultiplication des logins SQL Server.
A +