Que signifie un RED X sur un utilisateur de base de données?


16

entrez la description de l'image ici

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:


21

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 GOcommandes 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 CONNECTne 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 USERcommande:

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.


De la sp_addrolememberquestion :

entrez la description de l'image ici

De la sys.sysusersquestion :

entrez la description de l'image ici


Cela m'a arrangé. Mais il doit y avoir un autre problème sous-jacent - mes utilisateurs sont créés via des scripts et ont accès à plusieurs bases de données. Un seul utilisateur sur une seule base de données avait besoin de l'autorisation explicite "CONNECT" pour être accordée.
Morvael

5

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 Windowsprincipaux que de la manière suivante:

WindowsLa 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/ denyune 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/ denysera écrite sys.database_permissions. Cela ne donnera aucun accès à cette base de données car l'utilisateur nouvellement créé manque toujours l' connectautorisation, et vous la verrez dans OE avec la flèche rouge.


Merci, mais nous parlons d'un «x» ROUGE, pas d'une flèche.
Michael Kirkpatrick

C'est une question de visualisation en Studio, mais c'est la même chose
Seppic

0

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.

entrez la description de l'image ici

L'utilisateur n'est PAS mappé à la base de données: entrez la description de l'image ici

Si je crée maintenant l'utilisateur:

USE TempDB
GO
CREATE USER [Domain\BI360Users] FOR LOGIN [DOMAIN\BI360Users]
GO

Le «x» ROUGE disparaît: entrez la description de l'image ici

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.

Voici les informations des sysusers: entrez la description de l'image ici


C'est ce dont je parlais, mais vous vous trompez en pensant que "L'utilisateur n'est PAS mappé à la base de données" après avoir correctement ajouté le groupe Win à un rôle de base de données. À ce même moment, l'utilisateur et le schéma correspondants sont créés.
2018

1
Vous devez avoir fait autre chose que l'ajout du groupe de domaines à un rôle de base de données, car cela ne fonctionne pas (sauf si vous utilisez une ancienne version de SQL Server). Et même dans ce scénario GRANT CONNECT, comme ma réponse originale le suggérait, aurait dû résoudre le problème.
Aaron Bertrand

0

J'ai eu le même problème. Je l'ai corrigé en changeant le statut 'Login' en 'Enabled' dans la section Status de la propriété utilisateur dans 'Security / Login'section de ma base de données SQL Server entrez la description de l'image ici

la marque rouge a disparu après avoir changé ce statut.


-3

X rouge signifie que les connexions sont désactivées avec SQL Server


Merci. Mais ils sont activés.
Michael Kirkpatrick

Les utilisateurs ne peuvent pas être désactivés.
Aaron Bertrand

Le compte existe-t-il dans le dossier Logins au niveau de l'instance? s'il exécute la commande "Créer un utilisateur [YourLogin] pour la connexion [YourLogin]" avec la base de données en question. Le Red X devrait disparaître.
Goforebroke
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.