J'ai créé deux nouveaux groupes AD et les ai ajoutés en tant qu'utilisateurs d'une base de données, mais ils apparaissent avec un RED X. Qu'est-ce que cela signifie? Merci.
J'ai créé deux nouveaux groupes AD et les ai ajoutés en tant qu'utilisateurs d'une base de données, mais ils apparaissent avec un RED X. Qu'est-ce que cela signifie? Merci.
Réponses:
Cela ne signifie pas que l'utilisateur est désactivé (vous ne pouvez désactiver que les connexions ), cela signifie que l'utilisateur n'a pas de privilèges de connexion à la base de données. Je ne sais pas exactement comment vos utilisateurs ont été créés, mais la façon la plus simple de le démontrer est:
CREATE LOGIN u1 WITH PASSWORD = 'x', CHECK_POLICY = OFF;
GO
USE tempdb;
GO
CREATE USER u1 FROM LOGIN u1;
GO
ALTER LOGIN u1 DISABLE;
GO
-- u1 has no red x even though the login has been disabled
CREATE USER u2 WITHOUT LOGIN;
GO
-- check Object Explorer, u2 has no red x
DENY CONNECT TO u2;
GO
-- check Object Explorer, u2 now has a red x!
CREATE USER u3 WITHOUT LOGIN;
GO
-- check Object Explorer, u3 has no red x
REVOKE CONNECT FROM u3;
GO
-- check Object Explorer, u3 now has a red x!
(Vous devrez peut-être actualiser l'Explorateur d'objets entre les GO
commandes car, enfin, la mise en cache.)
Pour y remédier (en supposant que vous souhaitiez réellement qu'ils puissent se connecter à la base de données):
GRANT CONNECT TO [DomainName\BI360Consultants];
GRANT CONNECT TO [DomainName\BI360Users];
Vous aurez sûrement besoin d'appliquer plus d'autorisations en fonction de ce dont vous avez besoin pour pouvoir faire dans la base de données.
Il peut y avoir d'autres façons plus obscures d'entrer dans cet état (par exemple, ajouter un groupe de domaine à un rôle dans une base de données sans ajouter réellement un utilisateur, comme décrit dans la réponse de MichaelK ). Bien que je sois honnête, quand j'ai essayé de faire ce que l'OP a fait, à l'ancienne ou à la bonne façon, je n'ai pas pu ajouter le groupe de domaine à un rôle sans qu'un utilisateur soit présent:
-- the old way
EXEC sys.sp_addrolemember N'db_datareader', N'[CAKE\MyGroup]';
Msg 15410, niveau 11, état 1, procédure sp_addrolemember L'
utilisateur ou le rôle «[CAKE \ MyGroup]» n'existe pas dans cette base de données.
-- the right way
ALTER ROLE db_datareader ADD MEMBER [CAKE\MyGroup];
Msg 15151, niveau 16, état 1
Impossible d'ajouter le principal «CAKE \ MyGroup», car il n'existe pas ou vous n'avez pas l'autorisation.
Bien sûr, avec ce résultat, je n'ai vu aucun utilisateur de ce type dans sysusers
(obsolète; arrêtez de l'utiliser) ou sys.database_principals
. Cependant, si je l'ai fait (grâce à la réponse de Seppic ):
GRANT SELECT ON dbo.SomeTable TO [CAKE\MyGroup];
Ensuite, l'utilisateur est apparu dans ces vues et s'est présenté comme un utilisateur dans l'Explorateur d'objets avec le x rouge en raison de HAS_DBACCESS() = 0
. Ce qui revient à peu près à la même chose: "ne peut pas accéder à la base de données." Donc, si ce qui précède GRANT CONNECT
ne fonctionne pas (dans mon cas, cela s'est débarrassé du x rouge, mais je n'ai pas essayé d'interroger réellement la base de données en tant que compte), essayez également ce qui suit, sachant qu'il pourrait échouer:
CREATE USER [DOMAIN\Group] FROM LOGIN [DOMAIN\Group];
Dans mon cas, lorsque j'ai accordé la connexion à cet utilisateur, cela m'a empêché d'exécuter la CREATE USER
commande:
Msg 15023, niveau 16, état 1, ligne 16 L'
utilisateur, le groupe ou le rôle «CAKE \ MyGroup» existe déjà dans la base de données actuelle.
Cet état sera toujours vrai pour guest
/ INFORMATION_SCHEMA
/ sys
- à l'exception du compte invité sur certaines bases de données système. Ignorez cela et laissez-les tranquilles.
Je veux seulement faire un ajout à la réponse d'Aaron Bertrand en ce qui concerne celle-ci:
Cela signifie que l'utilisateur n'a pas de privilèges de connexion à la base de données (vous ne pouvez pas désactiver les utilisateurs, uniquement les connexions). Je ne sais pas exactement comment vos utilisateurs ont été créés ...
Cela ne peut se produire avec les Windows
principaux que de la manière suivante:
Windows
La connexion existe au niveau du serveur mais n'est pas mappée à la base de données en question, quelqu'un décide de grant
/ deny
une autorisation pour ce principal Windows au niveau de la base de données. Dans ce cas, l'utilisateur / le schéma correspondant sera créé dans la base de données et la ligne contenant ce grant
/ deny
sera écrite sys.database_permissions
. Cela ne donnera aucun accès à cette base de données car l'utilisateur nouvellement créé manque toujours l' connect
autorisation, et vous la verrez dans OE avec la flèche rouge.
Je pense que j'ai compris pourquoi cela s'est produit.
Scénario:
Domain \ BI360Users est un groupe AD
Domain \ BI360Users est ajouté en tant que connexion au serveur (il dispose des autorisations de connexion)
Domain \ BI360Users n'existe PAS en tant qu'utilisateur d'une base de données
Je fais ce qui suit:
USE TEMPDB
GO
EXEC sp_addrolemember N'db_datareader', N'Doamin\BI360users'
GO
Se termine avec succès.
Actualiser: le «x» ROUGE apparaît.
L'utilisateur n'est PAS mappé à la base de données:
Si je crée maintenant l'utilisateur:
USE TempDB
GO
CREATE USER [Domain\BI360Users] FOR LOGIN [DOMAIN\BI360Users]
GO
Donc, il semble qu'il n'y ait pas eu d'utilisateur même si le spectacle d'écran l'a clairement montré ci-dessus.
GRANT CONNECT
, comme ma réponse originale le suggérait, aurait dû résoudre le problème.
X rouge signifie que les connexions sont désactivées avec SQL Server