Je débute sur SQL Server 2005 et j'ai quelques soucis avec la gestion
des droits :
Je souhaite donner à une équipe de développeurs un accès complet à une
base de données (modif/ajout/suppr de tables, de vues, procédures
stockées,...).
Les utilisateurs sont définis dans l'Active Directory (2003 R2) et j'ai
créé un groupe "Dev SQL Server" dans l'AD.
Si je crée une connexion en utilisant un nom d'utilisateur dans l'AD,
que je la mappe vers un utilisateur de la base avec les droits db_owner,
pas de pb, je me connecte sans pb à distance avec SQL Server Management
studio et je peux ajouter une table, par ex.
Par contre, si je crée une connexion identique en utilisant mon groupe
"SQL Server" que je mappe de la même façon, je peux me connecter,
modifier des données ou la structure des tables, mais pas créer de
nouvelles tables.
Le message d'erreur est le suivant : La propriété DefaultSchema n'est
pas disponible pour la base de données "mabdd". Cette propriété n'existe
peut-être pas pour cet objet ou ne peut pas être récupérée en raison de
droits d'accès insuffisants"
Quels droits minimum faut-il appliquer pour gérer une base de données ?
Comment faire pour donner les droits à un groupe ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Fred BROUARD
Fred a écrit :
Bonjour à tous,
Je débute sur SQL Server 2005 et j'ai quelques soucis avec la gestion des droits :
En matière de SGBDR la notion de "DROIT" n'existe pas. On parle de privilèges. Ce n'est pas la même chose : "le privilège d'exécuter la commande XXX sur l'objet YYYY"
Je souhaite donner à une équipe de développeurs un accès complet à une base de données (modif/ajout/suppr de tables, de vues, procédures stockées,...).
Vous mélangez la sécurité système et la sécurité applicative. A mon sens c'est une hérésie. En effet, ce ne sont pas les utilisateurs (personnes physique) qui se connecte à un SGBDR, mais une application. De ce fait vous devriez gérer cela avec des connexion SQL et non WIndows. Ce sera en sus plus portable car indépendant de votre AD, qui peut tomber en panne !
Les utilisateurs sont définis dans l'Active Directory (2003 R2) et j'ai créé un groupe "Dev SQL Server" dans l'AD.
Si je crée une connexion en utilisant un nom d'utilisateur dans l'AD, que je la mappe vers un utilisateur de la base avec les droits db_owner, pas de pb, je me connecte sans pb à distance avec SQL Server Management studio et je peux ajouter une table, par ex.
Par contre, si je crée une connexion identique en utilisant mon groupe "SQL Server" que je mappe de la même façon, je peux me connecter, modifier des données ou la structure des tables, mais pas créer de nouvelles tables.
Le message d'erreur est le suivant : La propriété DefaultSchema n'est pas disponible pour la base de données "mabdd". Cette propriété n'existe peut-être pas pour cet objet ou ne peut pas être récupérée en raison de droits d'accès insuffisants"
Quels droits minimum faut-il appliquer pour gérer une base de données ? Comment faire pour donner les droits à un groupe ?
Gérez les privilèges au niveau de SQL et non de l'OS. Ce sera plus simple !
Merci pour votre aide,
@+
Fred
-- Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Audit, conseil, expertise, formation, modélisation, tuning, optimisation *********************** http://www.sqlspot.com *************************
Fred a écrit :
Bonjour à tous,
Je débute sur SQL Server 2005 et j'ai quelques soucis avec la gestion
des droits :
En matière de SGBDR la notion de "DROIT" n'existe pas. On parle de
privilèges. Ce n'est pas la même chose :
"le privilège d'exécuter la commande XXX sur l'objet YYYY"
Je souhaite donner à une équipe de développeurs un accès complet à une
base de données (modif/ajout/suppr de tables, de vues, procédures
stockées,...).
Vous mélangez la sécurité système et la sécurité applicative. A mon sens
c'est une hérésie. En effet, ce ne sont pas les utilisateurs (personnes
physique) qui se connecte à un SGBDR, mais une application. De ce fait
vous devriez gérer cela avec des connexion SQL et non WIndows. Ce sera
en sus plus portable car indépendant de votre AD, qui peut tomber en panne !
Les utilisateurs sont définis dans l'Active Directory (2003 R2) et j'ai
créé un groupe "Dev SQL Server" dans l'AD.
Si je crée une connexion en utilisant un nom d'utilisateur dans l'AD,
que je la mappe vers un utilisateur de la base avec les droits db_owner,
pas de pb, je me connecte sans pb à distance avec SQL Server Management
studio et je peux ajouter une table, par ex.
Par contre, si je crée une connexion identique en utilisant mon groupe
"SQL Server" que je mappe de la même façon, je peux me connecter,
modifier des données ou la structure des tables, mais pas créer de
nouvelles tables.
Le message d'erreur est le suivant : La propriété DefaultSchema n'est
pas disponible pour la base de données "mabdd". Cette propriété n'existe
peut-être pas pour cet objet ou ne peut pas être récupérée en raison de
droits d'accès insuffisants"
Quels droits minimum faut-il appliquer pour gérer une base de données ?
Comment faire pour donner les droits à un groupe ?
Gérez les privilèges au niveau de SQL et non de l'OS. Ce sera plus simple !
Merci pour votre aide,
@+
Fred
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
*********************** http://www.sqlspot.com *************************
Je débute sur SQL Server 2005 et j'ai quelques soucis avec la gestion des droits :
En matière de SGBDR la notion de "DROIT" n'existe pas. On parle de privilèges. Ce n'est pas la même chose : "le privilège d'exécuter la commande XXX sur l'objet YYYY"
Je souhaite donner à une équipe de développeurs un accès complet à une base de données (modif/ajout/suppr de tables, de vues, procédures stockées,...).
Vous mélangez la sécurité système et la sécurité applicative. A mon sens c'est une hérésie. En effet, ce ne sont pas les utilisateurs (personnes physique) qui se connecte à un SGBDR, mais une application. De ce fait vous devriez gérer cela avec des connexion SQL et non WIndows. Ce sera en sus plus portable car indépendant de votre AD, qui peut tomber en panne !
Les utilisateurs sont définis dans l'Active Directory (2003 R2) et j'ai créé un groupe "Dev SQL Server" dans l'AD.
Si je crée une connexion en utilisant un nom d'utilisateur dans l'AD, que je la mappe vers un utilisateur de la base avec les droits db_owner, pas de pb, je me connecte sans pb à distance avec SQL Server Management studio et je peux ajouter une table, par ex.
Par contre, si je crée une connexion identique en utilisant mon groupe "SQL Server" que je mappe de la même façon, je peux me connecter, modifier des données ou la structure des tables, mais pas créer de nouvelles tables.
Le message d'erreur est le suivant : La propriété DefaultSchema n'est pas disponible pour la base de données "mabdd". Cette propriété n'existe peut-être pas pour cet objet ou ne peut pas être récupérée en raison de droits d'accès insuffisants"
Quels droits minimum faut-il appliquer pour gérer une base de données ? Comment faire pour donner les droits à un groupe ?
Gérez les privilèges au niveau de SQL et non de l'OS. Ce sera plus simple !
Merci pour votre aide,
@+
Fred
-- Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Audit, conseil, expertise, formation, modélisation, tuning, optimisation *********************** http://www.sqlspot.com *************************
Fred
Fred BROUARD a écrit :
Fred a écrit :
Bonjour à tous,
Je débute sur SQL Server 2005 et j'ai quelques soucis avec la gestion des droits :
En matière de SGBDR la notion de "DROIT" n'existe pas. On parle de privilèges. Ce n'est pas la même chose : "le privilège d'exécuter la commande XXX sur l'objet YYYY"
Je souhaite donner à une équipe de développeurs un accès complet à une base de données (modif/ajout/suppr de tables, de vues, procédures stockées,...).
Vous mélangez la sécurité système et la sécurité applicative. A mon sens c'est une hérésie. En effet, ce ne sont pas les utilisateurs (personnes physique) qui se connecte à un SGBDR, mais une application. De ce fait vous devriez gérer cela avec des connexion SQL et non WIndows. Ce sera en sus plus portable car indépendant de votre AD, qui peut tomber en panne !
Les utilisateurs sont définis dans l'Active Directory (2003 R2) et j'ai créé un groupe "Dev SQL Server" dans l'AD.
Si je crée une connexion en utilisant un nom d'utilisateur dans l'AD, que je la mappe vers un utilisateur de la base avec les droits db_owner, pas de pb, je me connecte sans pb à distance avec SQL Server Management studio et je peux ajouter une table, par ex.
Par contre, si je crée une connexion identique en utilisant mon groupe "SQL Server" que je mappe de la même façon, je peux me connecter, modifier des données ou la structure des tables, mais pas créer de nouvelles tables.
Le message d'erreur est le suivant : La propriété DefaultSchema n'est pas disponible pour la base de données "mabdd". Cette propriété n'existe peut-être pas pour cet objet ou ne peut pas être récupérée en raison de droits d'accès insuffisants"
Quels droits minimum faut-il appliquer pour gérer une base de données ? Comment faire pour donner les droits à un groupe ?
Gérez les privilèges au niveau de SQL et non de l'OS. Ce sera plus simple !
Merci pour votre aide,
@+
Fred
Merci pour vos remarques.
En fait, la base sera accessible par une application web. De ce côté, pas de problème, il y aura un utilisateur SQL Server.
Par contre, les développeurs doivent avoir un accès complet à cette base pour l'administrer et c'est là que le problème se pose.
@+
Fred
Fred BROUARD a écrit :
Fred a écrit :
Bonjour à tous,
Je débute sur SQL Server 2005 et j'ai quelques soucis avec la gestion
des droits :
En matière de SGBDR la notion de "DROIT" n'existe pas. On parle de
privilèges. Ce n'est pas la même chose :
"le privilège d'exécuter la commande XXX sur l'objet YYYY"
Je souhaite donner à une équipe de développeurs un accès complet à une
base de données (modif/ajout/suppr de tables, de vues, procédures
stockées,...).
Vous mélangez la sécurité système et la sécurité applicative. A mon sens
c'est une hérésie. En effet, ce ne sont pas les utilisateurs (personnes
physique) qui se connecte à un SGBDR, mais une application. De ce fait
vous devriez gérer cela avec des connexion SQL et non WIndows. Ce sera
en sus plus portable car indépendant de votre AD, qui peut tomber en
panne !
Les utilisateurs sont définis dans l'Active Directory (2003 R2) et
j'ai créé un groupe "Dev SQL Server" dans l'AD.
Si je crée une connexion en utilisant un nom d'utilisateur dans l'AD,
que je la mappe vers un utilisateur de la base avec les droits
db_owner, pas de pb, je me connecte sans pb à distance avec SQL Server
Management studio et je peux ajouter une table, par ex.
Par contre, si je crée une connexion identique en utilisant mon groupe
"SQL Server" que je mappe de la même façon, je peux me connecter,
modifier des données ou la structure des tables, mais pas créer de
nouvelles tables.
Le message d'erreur est le suivant : La propriété DefaultSchema n'est
pas disponible pour la base de données "mabdd". Cette propriété
n'existe peut-être pas pour cet objet ou ne peut pas être récupérée en
raison de droits d'accès insuffisants"
Quels droits minimum faut-il appliquer pour gérer une base de données ?
Comment faire pour donner les droits à un groupe ?
Gérez les privilèges au niveau de SQL et non de l'OS. Ce sera plus simple !
Merci pour votre aide,
@+
Fred
Merci pour vos remarques.
En fait, la base sera accessible par une application web. De ce côté,
pas de problème, il y aura un utilisateur SQL Server.
Par contre, les développeurs doivent avoir un accès complet à cette base
pour l'administrer et c'est là que le problème se pose.
Je débute sur SQL Server 2005 et j'ai quelques soucis avec la gestion des droits :
En matière de SGBDR la notion de "DROIT" n'existe pas. On parle de privilèges. Ce n'est pas la même chose : "le privilège d'exécuter la commande XXX sur l'objet YYYY"
Je souhaite donner à une équipe de développeurs un accès complet à une base de données (modif/ajout/suppr de tables, de vues, procédures stockées,...).
Vous mélangez la sécurité système et la sécurité applicative. A mon sens c'est une hérésie. En effet, ce ne sont pas les utilisateurs (personnes physique) qui se connecte à un SGBDR, mais une application. De ce fait vous devriez gérer cela avec des connexion SQL et non WIndows. Ce sera en sus plus portable car indépendant de votre AD, qui peut tomber en panne !
Les utilisateurs sont définis dans l'Active Directory (2003 R2) et j'ai créé un groupe "Dev SQL Server" dans l'AD.
Si je crée une connexion en utilisant un nom d'utilisateur dans l'AD, que je la mappe vers un utilisateur de la base avec les droits db_owner, pas de pb, je me connecte sans pb à distance avec SQL Server Management studio et je peux ajouter une table, par ex.
Par contre, si je crée une connexion identique en utilisant mon groupe "SQL Server" que je mappe de la même façon, je peux me connecter, modifier des données ou la structure des tables, mais pas créer de nouvelles tables.
Le message d'erreur est le suivant : La propriété DefaultSchema n'est pas disponible pour la base de données "mabdd". Cette propriété n'existe peut-être pas pour cet objet ou ne peut pas être récupérée en raison de droits d'accès insuffisants"
Quels droits minimum faut-il appliquer pour gérer une base de données ? Comment faire pour donner les droits à un groupe ?
Gérez les privilèges au niveau de SQL et non de l'OS. Ce sera plus simple !
Merci pour votre aide,
@+
Fred
Merci pour vos remarques.
En fait, la base sera accessible par une application web. De ce côté, pas de problème, il y aura un utilisateur SQL Server.
Par contre, les développeurs doivent avoir un accès complet à cette base pour l'administrer et c'est là que le problème se pose.