patternsqlMajor
What does a RED X on a database user mean?
Viewed 0 times
whatuserredmeandatabasedoes
Problem
I created two new AD groups and added them as Users of a database, but their icons show with a red X.
What does this mean?
What does this mean?
Solution
It does not mean the user is disabled (you can only disable logins), it means the user does not have connect privileges to the database. I'm not sure exactly how your users were created, but the easiest way to demonstrate this is:
(You may need to refresh Object Explorer between
To fix it (assuming you actually want them to be able to connect to the database):
Surely you'll need to apply more permissions depending on what you need them to be able to do in the database.
There may be other, more obscure ways to get into this state (e.g. adding a domain group to a role in a database without actually adding a user, as described in MichaelK's answer). Though I'll be honest, when I tried to do what the OP did, the old way or the right way, I was not able to add the domain group to a role without a user present:
Msg 15410, Level 11, State 1, Procedure sp_addrolemember
User or role '[CAKE\MyGroup]' does not exist in this database.
Msg 15151, Level 16, State 1
Cannot add the principal 'CAKE\MyGroup', because it does not exist or you do not have permission.
Of course with this outcome I did not see any such user in
Then the user did show up in those views and did show up as a user in Object Explorer with the red x due to
In my case, when I granted connect to this user, it prevented me from running the
Msg 15023, Level 16, State 1, Line 16
User, group, or role 'CAKE\MyGroup' already exists in the current database.
This state will always be true for
From the
From the
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!(You may need to refresh Object Explorer between
GO commands because, well, caching.)To fix it (assuming you actually want them to be able to connect to the database):
GRANT CONNECT TO [DomainName\BI360Consultants];
GRANT CONNECT TO [DomainName\BI360Users];Surely you'll need to apply more permissions depending on what you need them to be able to do in the database.
There may be other, more obscure ways to get into this state (e.g. adding a domain group to a role in a database without actually adding a user, as described in MichaelK's answer). Though I'll be honest, when I tried to do what the OP did, the old way or the right way, I was not able to add the domain group to a role without a user present:
-- the old way
EXEC sys.sp_addrolemember N'db_datareader', N'[CAKE\MyGroup]';Msg 15410, Level 11, State 1, Procedure sp_addrolemember
User or role '[CAKE\MyGroup]' does not exist in this database.
-- the right way
ALTER ROLE db_datareader ADD MEMBER [CAKE\MyGroup];Msg 15151, Level 16, State 1
Cannot add the principal 'CAKE\MyGroup', because it does not exist or you do not have permission.
Of course with this outcome I did not see any such user in
sysusers (deprecated; stop using it) or sys.database_principals. However, if I did this (thanks to sepupic's answer):GRANT SELECT ON dbo.SomeTable TO [CAKE\MyGroup];Then the user did show up in those views and did show up as a user in Object Explorer with the red x due to
HAS_DBACCESS() = 0. Which still amounts to roughly the same thing: "can't access the database." So if the above GRANT CONNECT does not work (in my case, that did get rid of the red x, but I did not try to actually query the database as that account), also try the following, knowing that it might fail:CREATE USER [DOMAIN\Group] FROM LOGIN [DOMAIN\Group];In my case, when I granted connect to this user, it prevented me from running the
CREATE USER command:Msg 15023, Level 16, State 1, Line 16
User, group, or role 'CAKE\MyGroup' already exists in the current database.
This state will always be true for
guest/INFORMATION_SCHEMA/sys - with the exception of the guest account on certain system databases. Ignore that and leave them alone.From the
sp_addrolemember topic:From the
sys.sysusers topic:Code Snippets
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!GRANT CONNECT TO [DomainName\BI360Consultants];
GRANT CONNECT TO [DomainName\BI360Users];-- the old way
EXEC sys.sp_addrolemember N'db_datareader', N'[CAKE\MyGroup]';-- the right way
ALTER ROLE db_datareader ADD MEMBER [CAKE\MyGroup];GRANT SELECT ON dbo.SomeTable TO [CAKE\MyGroup];Context
StackExchange Database Administrators Q#213013, answer score: 36
Revisions (0)
No revisions yet.