Discussion :

[new_wave]

Bonjour,

Si j'ai bien compris, une connexion Windows ou SQL ne peut être mappée qu'un un seul USER SQL .

J'ai fait le test suivant

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
CREATE LOGIN C_4 WITH PASSWORD = 'C4'; 
 
 USE GESCOM 
  GO
-- création de 2utilisateurs associés à la connexion C_4
CREATE USER U_4 FOR LOGIN C_4; 
 
CREATE USER U_7 FOR LOGIN C_4;

Et obtiens une erreur à la creation du USER U_7.
Cependant je constate, à la connexion C_4, que l'utilisateur par défaut sur la base GESCOM reste dbo .
Pourquoi est ce qu'on n'est pas positionné automatiquement sur l'utilisateur U_4 mappé avec la connexion C_4?

Vous remerciant de votre réponse,

Bien cordialement.

new_wave

[SQLpro]

je dirais plus précisément :
Si j'ai bien compris, une connexion Windows ou SQL ne peut être mappée qu'a un un seul USER SQL dans chaque base.

dbo, comme public et guest sont des utilisateurs génériques. Vous ne pouvez ni les modifier ni les supprimer !

A +

[new_wave]

Bonjour,

Vous dites que les utilisateur dbo et guest sont des utilisateurs génériques. ok

Pourquoi cela impliquerait qu'on se connecte automatiquement à eux lors d'une connexion, quand celle ci est mappée à un utilisateur SQL.

C'est de "l'abus de pouvoir"

Je comprends quand une connexion n'est pas mappée à un utilisateur SQL mais quand elle ne l'est pas , je trouve çà un peu dur dur à concevoir...

Bien cordialement.

new_wave

[SQLpro]

Non, non, il n'y a aucun abus.... Bien au contraire !

Utilisateur SQL dbo : est l'utilisateur SQL par défaut UNIQUEMENT si le compte de connexion est du niveau maximum de privilège de serveur, à savoir :

• rôle sysadmin
• privilège CONTROL SERVER

guest : est l'utilisateur par défaut d'utilisateur. par défaut, guest n'a aucun privilège et ne peut donc rien faire dans aucune base de données.

public : est l'utilisateur SQL (norme) assimilé à un rôle (dans SQL Server), auquel certains privilèges sont attribué à minima pour pouvoir naviguer dans les objets, par exemple sur les tables systèmes gérants les privilèges.

Fonctionnement :

Lorsque vous créez un utilisateur SQL dans une base utilisateur (pas une base système), et que vous ne lui donnez aucune privilège ni aucun rôle, il est toujours inclus dans le rôle public.... Sinon vous ne pourriez pas accéder à la base dans le sens ou l'utilisateur ne pourrait pas connaître ses propres droit puisqu'il ne pourrait pas lire les tables systèmes pour savoir ce à quoi il a droit !

Si votre utilisateur SQL veut aller voir ce qu'il y a dans une autre base, il sera rejeté car il n'existe pas dans cet autre base, sauf si vous avez donné quelques privilèges à l'utilisateur SQL guest (qui veut dire "invité"). Dans ce cas il pourra naviguer dans cette base en "empruntant " l'identité "guest" et manipuler des informations dans la limite des privilèges de l'utilisateur guest.
Un exemple concret est lorsque l'on décide de créer une base de données référentielle auquel d'autres bases peuvent accéder. Par exemple, une base de données contenant la liste des tous les codes postaux, les communes, départements, régions de France, etc.

A +