J'ai un petit problème avec SQL Server 2008 et l'authentification par
compte Active Directory (Win 2003 R2) :
Je crée une connexion avec un compte AD, ce compte AD se connecte sans
problème sur mon instance (via Management Studio), mais il dispose par
défaut des droits complets (création de bases,...).
Et quelque soit les droits/restrictions que je lui affecte (mappage sur
une db,...), ça ne change rien.
Par contre, si je crée cet utilisateur en tant que compte SQL Server,
pas de pb, il n'a par défaut aucun droit et je peux lui octroyer sans
problème les droits que je veux.
Au début, je pensais que ça pouvait venir du fait que je créais une
connexion sur un groupe de sécurité AD, mais même en créant la connexion
directement sur l'utilisateur ça ne change rien.
Mes utilisateurs AD n'ont rien de particulier (à part être admin de leur
poste).
Y'a-til un paramétrage spécifique à appliquer pour prendre en compte les
droits sur les utilisateurs de mon AD ?
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
TedIF
Fred a formulé la demande :
Bonjour à tous,
J'ai un petit problème avec SQL Server 2008 et l'authentification par compte Active Directory (Win 2003 R2) :
Je crée une connexion avec un compte AD, ce compte AD se connecte sans problème sur mon instance (via Management Studio), mais il dispose par défaut des droits complets (création de bases,...). Et quelque soit les droits/restrictions que je lui affecte (mappage sur une db,...), ça ne change rien.
Par contre, si je crée cet utilisateur en tant que compte SQL Server, pas de pb, il n'a par défaut aucun droit et je peux lui octroyer sans problème les droits que je veux.
Au début, je pensais que ça pouvait venir du fait que je créais une connexion sur un groupe de sécurité AD, mais même en créant la connexion directement sur l'utilisateur ça ne change rien.
Mes utilisateurs AD n'ont rien de particulier (à part être admin de leur poste).
Y'a-til un paramétrage spécifique à appliquer pour prendre en compte les droits sur les utilisateurs de mon AD ?
Quelles sont les "rôles du serveur" de la connexion ? Quelles sont les "Appartenance au rôle de base de donnée" du mappage de l'utilisateur ?
--
Dominique
Fred a formulé la demande :
Bonjour à tous,
J'ai un petit problème avec SQL Server 2008 et l'authentification par compte
Active Directory (Win 2003 R2) :
Je crée une connexion avec un compte AD, ce compte AD se connecte sans
problème sur mon instance (via Management Studio), mais il dispose par défaut
des droits complets (création de bases,...).
Et quelque soit les droits/restrictions que je lui affecte (mappage sur une
db,...), ça ne change rien.
Par contre, si je crée cet utilisateur en tant que compte SQL Server, pas de
pb, il n'a par défaut aucun droit et je peux lui octroyer sans problème les
droits que je veux.
Au début, je pensais que ça pouvait venir du fait que je créais une connexion
sur un groupe de sécurité AD, mais même en créant la connexion directement
sur l'utilisateur ça ne change rien.
Mes utilisateurs AD n'ont rien de particulier (à part être admin de leur
poste).
Y'a-til un paramétrage spécifique à appliquer pour prendre en compte les
droits sur les utilisateurs de mon AD ?
Quelles sont les "rôles du serveur" de la connexion ?
Quelles sont les "Appartenance au rôle de base de donnée" du mappage de
l'utilisateur ?
J'ai un petit problème avec SQL Server 2008 et l'authentification par compte Active Directory (Win 2003 R2) :
Je crée une connexion avec un compte AD, ce compte AD se connecte sans problème sur mon instance (via Management Studio), mais il dispose par défaut des droits complets (création de bases,...). Et quelque soit les droits/restrictions que je lui affecte (mappage sur une db,...), ça ne change rien.
Par contre, si je crée cet utilisateur en tant que compte SQL Server, pas de pb, il n'a par défaut aucun droit et je peux lui octroyer sans problème les droits que je veux.
Au début, je pensais que ça pouvait venir du fait que je créais une connexion sur un groupe de sécurité AD, mais même en créant la connexion directement sur l'utilisateur ça ne change rien.
Mes utilisateurs AD n'ont rien de particulier (à part être admin de leur poste).
Y'a-til un paramétrage spécifique à appliquer pour prendre en compte les droits sur les utilisateurs de mon AD ?
Quelles sont les "rôles du serveur" de la connexion ? Quelles sont les "Appartenance au rôle de base de donnée" du mappage de l'utilisateur ?
--
Dominique
Fred
Le 26/05/2010 11:52, TedIF a écrit :
Fred a formulé la demande :
Bonjour à tous,
Je crée une connexion avec un compte AD, ce compte AD se connecte sans problème sur mon instance (via Management Studio), mais il dispose par défaut des droits complets (création de bases,...). Et quelque soit les droits/restrictions que je lui affecte (mappage sur une db,...), ça ne change rien.
Par contre, si je crée cet utilisateur en tant que compte SQL Server, pas de pb, il n'a par défaut aucun droit et je peux lui octroyer sans problème les droits que je veux.
Y'a-til un paramétrage spécifique à appliquer pour prendre en compte les droits sur les utilisateurs de mon AD ?
Quelles sont les "rôles du serveur" de la connexion ? Quelles sont les "Appartenance au rôle de base de donnée" du mappage de l'utilisateur ?
Les rôles sont les rôles par défaut, pour les 2 utilisateurs (AD et compte SQL Server) : public.
Sauf que pour l'utilisateur SQL Serveur je n'ai aucun droit (ce qui est normal) et pour le compte AD, il a l'air d'avoir les rôles sysadmin.
Le 26/05/2010 11:52, TedIF a écrit :
Fred a formulé la demande :
Bonjour à tous,
Je crée une connexion avec un compte AD, ce compte AD se connecte sans
problème sur mon instance (via Management Studio), mais il dispose par
défaut des droits complets (création de bases,...).
Et quelque soit les droits/restrictions que je lui affecte (mappage
sur une db,...), ça ne change rien.
Par contre, si je crée cet utilisateur en tant que compte SQL Server,
pas de pb, il n'a par défaut aucun droit et je peux lui octroyer sans
problème les droits que je veux.
Y'a-til un paramétrage spécifique à appliquer pour prendre en compte
les droits sur les utilisateurs de mon AD ?
Quelles sont les "rôles du serveur" de la connexion ?
Quelles sont les "Appartenance au rôle de base de donnée" du mappage de
l'utilisateur ?
Les rôles sont les rôles par défaut, pour les 2 utilisateurs (AD et
compte SQL Server) : public.
Sauf que pour l'utilisateur SQL Serveur je n'ai aucun droit (ce qui est
normal) et pour le compte AD, il a l'air d'avoir les rôles sysadmin.
Je crée une connexion avec un compte AD, ce compte AD se connecte sans problème sur mon instance (via Management Studio), mais il dispose par défaut des droits complets (création de bases,...). Et quelque soit les droits/restrictions que je lui affecte (mappage sur une db,...), ça ne change rien.
Par contre, si je crée cet utilisateur en tant que compte SQL Server, pas de pb, il n'a par défaut aucun droit et je peux lui octroyer sans problème les droits que je veux.
Y'a-til un paramétrage spécifique à appliquer pour prendre en compte les droits sur les utilisateurs de mon AD ?
Quelles sont les "rôles du serveur" de la connexion ? Quelles sont les "Appartenance au rôle de base de donnée" du mappage de l'utilisateur ?
Les rôles sont les rôles par défaut, pour les 2 utilisateurs (AD et compte SQL Server) : public.
Sauf que pour l'utilisateur SQL Serveur je n'ai aucun droit (ce qui est normal) et pour le compte AD, il a l'air d'avoir les rôles sysadmin.
Fred
Apparemment, ce problème ne date pas d'hier ;-) :
2007 : Sql Server 2005 : http://www.bigresource.com/Tracker/Track-ms_sql-BqNUTDhy/ 2002 : SQL Server 2000 : http://forums.sqlwire.com/showthread.php?t824
Apparemment, ce problème ne date pas d'hier ;-) :
2007 : Sql Server 2005 :
http://www.bigresource.com/Tracker/Track-ms_sql-BqNUTDhy/
2002 : SQL Server 2000 : http://forums.sqlwire.com/showthread.php?t824
2007 : Sql Server 2005 : http://www.bigresource.com/Tracker/Track-ms_sql-BqNUTDhy/ 2002 : SQL Server 2000 : http://forums.sqlwire.com/showthread.php?t824
Fred
Le 26/05/2010 17:34, Fred a écrit :
Apparemment, ce problème ne date pas d'hier ;-) :
2007 : Sql Server 2005 : http://www.bigresource.com/Tracker/Track-ms_sql-BqNUTDhy/ 2002 : SQL Server 2000 : http://forums.sqlwire.com/showthread.php?t824
Je viens finalement de trouver : c'est parce que mon utilisateur est admin local de son poste (mais pas du serveur sur lequel est installé SQL Server) et que le compte BUILTINAdministrateurs a le rôle sysadmin.
J'ai simplement supprimer ce rôle et tout est rentré dans l'ordre.
j'ai trouvé cette info ici : http://www.developpez.net/forums/d181489/bases-donnees/ms-sql-server/explication-quelques-login-sql-server-2k/
@+
Fred
Le 26/05/2010 17:34, Fred a écrit :
Apparemment, ce problème ne date pas d'hier ;-) :
2007 : Sql Server 2005 :
http://www.bigresource.com/Tracker/Track-ms_sql-BqNUTDhy/
2002 : SQL Server 2000 : http://forums.sqlwire.com/showthread.php?t824
Je viens finalement de trouver : c'est parce que mon utilisateur est
admin local de son poste (mais pas du serveur sur lequel est installé
SQL Server) et que le compte BUILTINAdministrateurs a le rôle sysadmin.
J'ai simplement supprimer ce rôle et tout est rentré dans l'ordre.
j'ai trouvé cette info ici :
http://www.developpez.net/forums/d181489/bases-donnees/ms-sql-server/explication-quelques-login-sql-server-2k/
2007 : Sql Server 2005 : http://www.bigresource.com/Tracker/Track-ms_sql-BqNUTDhy/ 2002 : SQL Server 2000 : http://forums.sqlwire.com/showthread.php?t824
Je viens finalement de trouver : c'est parce que mon utilisateur est admin local de son poste (mais pas du serveur sur lequel est installé SQL Server) et que le compte BUILTINAdministrateurs a le rôle sysadmin.
J'ai simplement supprimer ce rôle et tout est rentré dans l'ordre.
j'ai trouvé cette info ici : http://www.developpez.net/forums/d181489/bases-donnees/ms-sql-server/explication-quelques-login-sql-server-2k/
@+
Fred
Fred BROUARD
bonjour,
Fred a écrit :
Bonjour à tous,
J'ai un petit problème avec SQL Server 2008 et l'authentification par compte Active Directory (Win 2003 R2) :
Je crée une connexion avec un compte AD, ce compte AD se connecte sans problème sur mon instance (via Management Studio), mais il dispose par défaut des droits complets (création de bases,...). Et quelque soit les droits/restrictions que je lui affecte (mappage sur une db,...), ça ne change rien.
Par contre, si je crée cet utilisateur en tant que compte SQL Server, pas de pb, il n'a par défaut aucun droit et je peux lui octroyer sans problème les droits que je veux.
Au début, je pensais que ça pouvait venir du fait que je créais une connexion sur un groupe de sécurité AD, mais même en créant la connexion directement sur l'utilisateur ça ne change rien.
Mes utilisateurs AD n'ont rien de particulier (à part être admin de leur poste).
s'il sont admin de leur poste (ce qui est stupide en matière de droits user lambda) alors sil seront admin de SQL Server du fait du groupe BUILTIN qui récupère tous les admin et les passent en syadmin SQL.
Y'a-til un paramétrage spécifique à appliquer pour prendre en compte les droits sur les utilisateurs de mon AD ?
Soit vous restreignez les droit système convenablement, soit vous utilisez la sécurité Windows pour les apllications
Merci pour votre aide,
@+
Fred
A +
-- Frédéric BROUARD - expert SGBDR et SQL - MVP SQL Server - 06 11 86 40 66 Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Enseignant Arts & Métiers PACA, ISEN Toulon et CESI/EXIA Aix en Provence Audit, conseil, expertise, formation, modélisation, tuning, optimisation *********************** http://www.sqlspot.com *************************
bonjour,
Fred a écrit :
Bonjour à tous,
J'ai un petit problème avec SQL Server 2008 et l'authentification par
compte Active Directory (Win 2003 R2) :
Je crée une connexion avec un compte AD, ce compte AD se connecte sans
problème sur mon instance (via Management Studio), mais il dispose par
défaut des droits complets (création de bases,...).
Et quelque soit les droits/restrictions que je lui affecte (mappage sur
une db,...), ça ne change rien.
Par contre, si je crée cet utilisateur en tant que compte SQL Server,
pas de pb, il n'a par défaut aucun droit et je peux lui octroyer sans
problème les droits que je veux.
Au début, je pensais que ça pouvait venir du fait que je créais une
connexion sur un groupe de sécurité AD, mais même en créant la connexion
directement sur l'utilisateur ça ne change rien.
Mes utilisateurs AD n'ont rien de particulier (à part être admin de leur
poste).
s'il sont admin de leur poste (ce qui est stupide en matière de droits
user lambda) alors sil seront admin de SQL Server du fait du groupe
BUILTIN qui récupère tous les admin et les passent en syadmin SQL.
Y'a-til un paramétrage spécifique à appliquer pour prendre en compte les
droits sur les utilisateurs de mon AD ?
Soit vous restreignez les droit système convenablement, soit vous
utilisez la sécurité Windows pour les apllications
Merci pour votre aide,
@+
Fred
A +
--
Frédéric BROUARD - expert SGBDR et SQL - MVP SQL Server - 06 11 86 40 66
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Enseignant Arts & Métiers PACA, ISEN Toulon et CESI/EXIA Aix en Provence
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
*********************** http://www.sqlspot.com *************************
J'ai un petit problème avec SQL Server 2008 et l'authentification par compte Active Directory (Win 2003 R2) :
Je crée une connexion avec un compte AD, ce compte AD se connecte sans problème sur mon instance (via Management Studio), mais il dispose par défaut des droits complets (création de bases,...). Et quelque soit les droits/restrictions que je lui affecte (mappage sur une db,...), ça ne change rien.
Par contre, si je crée cet utilisateur en tant que compte SQL Server, pas de pb, il n'a par défaut aucun droit et je peux lui octroyer sans problème les droits que je veux.
Au début, je pensais que ça pouvait venir du fait que je créais une connexion sur un groupe de sécurité AD, mais même en créant la connexion directement sur l'utilisateur ça ne change rien.
Mes utilisateurs AD n'ont rien de particulier (à part être admin de leur poste).
s'il sont admin de leur poste (ce qui est stupide en matière de droits user lambda) alors sil seront admin de SQL Server du fait du groupe BUILTIN qui récupère tous les admin et les passent en syadmin SQL.
Y'a-til un paramétrage spécifique à appliquer pour prendre en compte les droits sur les utilisateurs de mon AD ?
Soit vous restreignez les droit système convenablement, soit vous utilisez la sécurité Windows pour les apllications
Merci pour votre aide,
@+
Fred
A +
-- Frédéric BROUARD - expert SGBDR et SQL - MVP SQL Server - 06 11 86 40 66 Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Enseignant Arts & Métiers PACA, ISEN Toulon et CESI/EXIA Aix en Provence Audit, conseil, expertise, formation, modélisation, tuning, optimisation *********************** http://www.sqlspot.com *************************
Fred
Le 29/05/2010 11:06, Fred BROUARD a écrit :
s'il sont admin de leur poste (ce qui est stupide en matière de droits user lambda) alors sil seront admin de SQL Server du fait du groupe BUILTIN qui récupère tous les admin et les passent en syadmin SQL.
Merci pour ces précisions. C'est effectivement la conclusion a laquelle j'étais arrivé, j'ai donc supprimé les droits sysadmin des BUILTINAdministrators.
Mes utilisateurs sont en effet admins de leur poste mais j'avoue ne pas voir le rapport entre être admin de sa machine en local et avoir les droits sysadmin sur une base de données hébergée sur un autre serveur ;-).
@+
Fred
Le 29/05/2010 11:06, Fred BROUARD a écrit :
s'il sont admin de leur poste (ce qui est stupide en matière de droits
user lambda) alors sil seront admin de SQL Server du fait du groupe
BUILTIN qui récupère tous les admin et les passent en syadmin SQL.
Merci pour ces précisions.
C'est effectivement la conclusion a laquelle j'étais arrivé, j'ai donc
supprimé les droits sysadmin des BUILTINAdministrators.
Mes utilisateurs sont en effet admins de leur poste mais j'avoue ne pas
voir le rapport entre être admin de sa machine en local et avoir les
droits sysadmin sur une base de données hébergée sur un autre serveur ;-).
s'il sont admin de leur poste (ce qui est stupide en matière de droits user lambda) alors sil seront admin de SQL Server du fait du groupe BUILTIN qui récupère tous les admin et les passent en syadmin SQL.
Merci pour ces précisions. C'est effectivement la conclusion a laquelle j'étais arrivé, j'ai donc supprimé les droits sysadmin des BUILTINAdministrators.
Mes utilisateurs sont en effet admins de leur poste mais j'avoue ne pas voir le rapport entre être admin de sa machine en local et avoir les droits sysadmin sur une base de données hébergée sur un autre serveur ;-).