We have evaluated the Microsoft "best practice" policies (located at C:\Program Files (x86)\Microsoft SQL Server\number\Tools\Policies\DatabaseEngine\1033) on each of our SQL Server instances (example here). The following issue has been flagged up to us:

enter image description here

This provides a link to a Microsoft page which states the following as being best practice:

Do not grant server permissions to the server public role.

On reviewing the security, we can see that the public role has server permissions to view any database by default. We have run the following and re-evaluated the policy, but the issue is still flagged up.


The only other permissions attributed to this server role are endpoint permissions to be able to connect via TCP/VIA/Named Pipes/Local Machine. If we remove these, surely the role will be superfluous.

enter image description here


  • Should we be concerned about this? Is this something we really should look to address?
  • What else do we need to do to properly resolve this issue?
  • Are there any implications for doing this or not doing this?

2 Answers 2


Yes, you should fix this. If you have multiple DBs in the server, a legitimate user in one DB might have nothing to do in another DB and will not be a user in that and hence 'public'. Why would you give pubic user permission to view/access objects in a DB they are not entitled to?

Make sure to test the application after you fix these. Sometimes even a legitimate user might be missing appropriate grant permission and might have been working based on public Access, which won't work after you fix the 'public' role access. They needs to be granted explicit access through grant stmt to specific objects or via database roles or via user roles.

  • Thank you. It's amazing what defaults SQL Server ships with if this is best practice. Do you please have any thoughts on why the issue would still be highlighted by the policy evaluation after running the T-SQL given above? Have we missed anything? Oct 16, 2018 at 15:13

When revoking the "view any database" permission from the public server role, logins cannot see the databases any more by querying select * from sys.databases (except for master and tempdb), but they can easily circumvent this revocation by querying:

select db_name(5); 
select db_name(6);

So that "best practice" sounds nice, but is worth nothing.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.