469,138 Members | 1,254 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,138 developers. It's quick & easy.

db_owners unable to see login list

Hi. We are using SQL Server 2005 64-bit on Windows Server 2003 R2 x64
Enterprise Edition. I have a really weird problem where I have people
out there who are placed in the db_owner, db_accessadmin, and
db_securityadmin roles in their database, and yet they are unable to
add new users to their databases, despite the fact that logins exist
for these users on the server. The reason is that when attempting to
add a new user in Management Studio, upon using the "Browse" option to
look at the logins, the complete list is not presented to them. In
fact, they only see a couple of logins or so (the server has hundreds
of logins). Also, if they try to type in the login name directly,
they get a "permission denied" error message. Since they cannot add
users to their databases, they have to call me and have me do it for
them.

I created a test, non-privileged, SQL-authenticated login to test
things for my own sake, and when logged in under the test account, I
saw the same behavior. I had db_owner role for a single test
database, and when I went to add users, the only server logins that
were displayed were my own (the test login in this case) and that of
sa. Further, when I queried the master.sys.syslogins view, I saw the
same thing, it only came back with the rows for myself and sa.

It appears that this is clearly a security problem, but I'm not sure
at what level to look. We never had this problem with SQL Server 2000
or earlier. Does anyone have any idea what I can do to allow my
db_owners to see all the server logins, and therefore be able to add
users to their databases as they see fit? I really do NOT want to
assign them to server-level security roles, for obvious reasons.

Thanks,
SkyGringo

Jul 18 '07 #1
1 3536
[posted and mailed]

You asked the same question yesterday. For your convenience, I repeat
my answer, and send a mail copy as well. Please reply in the newsgroup.

SkyGringo (do**@bu.edu) writes:
I'm using the 64-bit version of SQL Server 2005, SP2, on Windows
Server 2003 R2 X64 Enterprise Edition. I've got a bunch of users out
there who are the db_owner, db_accessadmin and db_securityadmin of
their different respective databases. I would expect that they would
be able to add users to their databases, given that a login exists on
the server. However, when they go to browse logins to add a user in
Management Studio, they are only shown a very short list (like,
themselves and sa, and that's it). We have hundreds of logins on the
server, and they should be able to add any one of them to their
databases if they wish. And if they try to type in the login name
directly, they get a permission denied error.
They need to have VIEW DEFINITION on the logins they need to add. There
is no permission VIEW ANY LOGIN, but there is a server-level VIEW ANY
DEFINITION you can grant to them, but I would think twice before you
did.
The only other thing I can add is it's not just occurring with the GUI
interface; the same thing happens when I do a direct query on the
master.sys.syslogins view: I only see the same two logins. So it
appears it's happening at that level and the result appears up in the
GUI.
It appears that you are of the old SQL 2000 school. :-)

Microsoft did a lot around security in SQL 2005, and one thing is
that objects are no longer visible to everyone. Essentially, you
can only see an object, if you have permission to it.

And the place to look for logins these days, is sys.server_principals.
While the old system tables are around for compatibility, they may not
show aspects that are new to SQL 2005.

--
Erland Sommarskog, SQL Server MVP, es****@sommarskog.se

Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pro...ads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodinf...ons/books.mspx
Jul 18 '07 #2

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

1 post views Thread by Brian Pittman | last post: by
reply views Thread by Dilip | last post: by
1 post views Thread by CARIGAR | last post: by
reply views Thread by zhoujie | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.