Discussion :

[Aldareis]

Bonjour,

Voilà, je me suis décidé à me faire une activité sur SQL server 2005 avec le BTS informatique de gestion, néanmoins je rencontre quelques difficultés vis à vis de la gestion des droits.

J'utilise un mode d'authentification windows donc uniquement avec Active Directory.

J'ai créé 3 utilisateurs :
- SQL-art (ce compte pourra lire et écrire uniquement des données sur la table articles de la base de données TEST)
- SQL-L (ce compte pourra lire toutes les données de la base de données TEST)
- SQL-E (ce compte pourra en plus modifier les données de la base de données TEST)

Dans le dossier sécurité, connexions, j'ai créé une nouvelle connexion pour chaque utilisateur. J'ai mappé l'utilisateur à la base de données TEST avec "db_reader" pour SQL-L et "db_writer" pour SQL-E.

Néanmoins, avec l'utilisateur SQL-L, j'arrive toujours à faire des delete, insert into. Savez vous pourquoi ?

Peut-on attribuer uniquement des droits sur une table d'une base de données ?

Merci d'avance

[ylarvor]

au niveau de tes logins, tu as bien creer des utilisateurs windows, car si tu te connectes comme administrateur, c'est normal de pouvoir inserer!

[Aldareis]

Bonjour,

C'est en me connectant avec l'utilisateur "SQL-L", donc droit en lecture que j'arrive à faire des insert to ou delete.

[ylarvor]

cet utilisateur sql-l, quel droit windows lui a tu donner ? administrateur ?

Peut-on attribuer uniquement des droits sur une table d'une base de données ?

oui, mais il ne faut pas donner des roles comme tu l'as fait... il faut attribuer des droits...

Pour en savoir plus : http://blog.developpez.com/ylarvor?t...n_de_la_Scurit

[Aldareis]

Les utilisateurs SQL-L et SQL-E sont des utilisateurs classiques, donc membre du groupe "Users"

En fait, ce qui n'est pas encore très clair, malgré le tutorial que j'ai lu, c'est que permet précisément le rôle de base de données DB-READER. J'ai compris que c'était des droits globaux. Il ne faut donc pas attribuer que des rôles mais systématiquement définir des autorisations d'instructions en plus ?

Désole, je suis encore un peu dans le flou, malgré ces explications.

[ylarvor]

j'avoue que je ne comprend pas qu'avec un utilisateur du groupe users, tu es des droits d'écriture...

db_datareader donne simplement le droit de lire les données... donc ce n'est pas normal que tu puisses modifier! il y a un probleme dans ta configuration de la sécurité. tu n'as aucun rôle serveur comme sysadmin ou serveradmin sur ton login ?

les roles, c'est pour te simplifier la vie, tu n'es pas oblige d'affecter des rôles, tu peux creer des droits sur tes objets et les affecter à ton utilisateur.

[Aldareis]

Voici le détail concernant l'utilisateur SQL-L
- Rôle du serveur : aucun
- utilisateur mappé à cette connexions : base de données TEST avec utilisateur SQL-L, shéma par défaut : dbo
- appartenance au rôle de base de donnée TEST : db-datareader, public
- element sécurisable : aucun
- état : autorisation de se connecter au moteur de base de donnéees : octroyer, connexion : activé

Sinon, je crois bien que je vais suivre votre conseil, c'est à dire ne pas utiliser les rôles et définir directement des autorisations spécifiques. (je comprends par là élément sécurisable)

A ce sujet d'ailleurs, savez vous où je peux trouver des infos à ce niveau là ? (par exemple savoir ce qui correspond à la possibilité de faire des SELECT et de l'autre côté des UPDATE)

Autre question que je me pose : la modification des droits sur un utilisateur (Active directory j'entends) oblige l'utilisateur à ouvrir une nouvelle session ou les modifications sont fait en temps réel ?

EDIT : après quelques tests, il n'y a que le drop database que je ne peux pas faire (UPDATE, INSERT INTO, DELETE fonctionne alors qu'il ne devrait pas...)

[ylarvor]

j'ai fait le test, j'ai créé un utilisateur, sur ma base test, avec le droit db_datareader, et je n'ai aucun droit en insertion!

essayes de passer en authentification Mixte, cela marchera peut etre mieux!

[Aldareis]

Bonsoir,

Alors je viens de passer en authentification mixte, j'ai donc dû redémarrer un service pour que cela soit pris en compte.

J'ai donc crée une nouvelle connexion TEST2 avec le même modèle d'authentification qu'avec l'utilisateur SQL-L, et j'ai toujours exactement le même problème....

UPDATE, INSERT INTO, DELETE fonctionne alors qu'il ne devrait pas

[SQLpro]

A quel utilisateur SQL est lié le compte de connexion TEST2 ?

Dans SQL Server il y a séparation entre connexion et utilisateurs. Ce sont des objets différents !

A +

[ylarvor]

le post est resolu, il avait mis des droits d'ecriture sur le compte public!

[Aldareis]

Voilà, c'est ça

La source venait du script de création de base de données.