Public, Server Permissions, and Endpoints

Question

I am seeking a good discussion of how to handle the impact of revoking connect to endpoint permissions for the public role. Up to this point, I've encountered several resources, including the Microsoft documentation, that recommend removing all server
permissions from public. I find this amusing due to the fact that all other logins inherit their permissions on the various endpoints from public. Of course, if I revoke connect for the endpoints from public, only system administrators can connect.
None of the sources that I've found address handling this issue. This reminds me a bit of the old South Park episode with the Underpants Gnomes and their business plan: Step 1 - Underpants, Step 2 - ?, Step 3 - Profit! In this case, it is
Step 1 - Revoke rights from public, Step 2 - ?, Step 3 - Security!
There is a comment on the SQL Server 2008 on-line documentation that recommends granting connect to endpoint to specific logins, but it does not supply any detail. I understand that Step 2 is highly dependent on factors that vary from location to location,
and application to application.
My question is whether there is a resource that details the considerations for granting connect to endpoint for the various endpoints and logins? I am looking for answers to questions like:
Is there a case in which one would have a login that was not granted connect to any endpoint?
Do logins like ##MS_PolicyTsqlExecutionLogin## need these rights, and if so, to which endpoints specifically?
I have a number of others, but I was hoping someone could provide me with a resource from which I could draw this information without having to chase all over the documentation. Thanks in advance!

Answer 1

Rick,
First, thanks so much for the helpful reply! It validates what I was thinking.
For versions 2008, 2008 R2, and 2012, if you follow Administer Servers by Using Policy-Based Management -> Monitor and Enforce Best Practices by Using Policy-Based Management -> Server public Permissions, it advises, "Do not grant server permissions
to the server public role." The links below are for the 2012 version of this page:
http://technet.microsoft.com/en-us/library/cc645930.aspx
http://msdn.microsoft.com/en-us/library/cc645930(v=sql.110).aspx
You and "Quantum John" are listed as authors of a comment on the 2008 version of this page (http://technet.microsoft.com/en-us/library/cc645930(v=sql.100).aspx) that acknowledge
this problem. The last part of that comment is:
However, as mentioned in Harry Zheng's post on Dosql (http://dosql.com/cms/index.php?option=com_content&view=article&id=96:sql-server-best-practice-policy-public-not-granted-server-permissions&catid=40:microsoft-sql-server&Itemid=41),
executing the following command:
REVOKE CONNECT ON ENDPOINT::[TSQL Default TCP] FROM public
while best practice, is nevertheless liable to get you in deep trouble on a production server unless you also execute:
GRANT CONNECT ON ENDPOINT::[TSQL Default TCP] to [loginname]
for each of your logins, because without this, no-one except sysadmins will have permission to connect to your instance via TCP.
It refers to performing the revoke connect on endpoint as best practice, which we agree is arguable. Unfortunately, Harry Zheng's post is a dead link. None of the later editions of this page are commented on in any way.
Further, the policy referenced by this documentation, "Public Not Granted Server Permissions," is distributed with SQL Server and evaluates @PublicServerRoleIsGranted. It flags this policy as failed if any connect to endpoint is granted to public.
Fortunately, I'm one of those that insists on testing before moving forward with any change. I also cannot leave gaps in my knowledge unfilled, which is why I posted. Again, thanks for the assistance!