Grantor does not have GRANT permission - issue

Question

I am having a problem with granting proper privileges to a server level role that I created. Whenever a user from the role tries to grant permition to other user I am getting an error like in the title. I did some research and add with grant option when I grant role priveleges but that not helped. I want to keep my role priveleges as low as it must be to perform the given script.

Here is how I create my role

CREATE SERVER ROLE [My_Server_Role]
go

GRANT    ALTER ANY LOGIN
        ,ALTER ANY SERVER ROLE
        ,CONNECT SQL
TO [My_Server_Role] 
WITH GRANT OPTION
go

now I have a user created like this (and a second one the same way)

CREATE  LOGIN   JohnSmith
    WITH    PASSWORD = 'MyPassword'

CREATE  USER JohnSmith
FOR     LOGIN JohnSmith

EXEC sp_addsrvrolemember [My_Server_Role], [JohnSmith] 

Now, my problem is that whenever JohmSmith tries to execute

DENY CONNECT SQL TO [ThatOtherUser] 

I have read to add WITH GRANT OPTIONS to CREATE ROLES statements but it didn't help. I can add CONTROL SERVER to MyServerRole but then users are getting too high privileges and are able co control other databases

Can anyone help? Perhaps i am messing something up with the idea. My point is to grant user (roles) priveleges to one database only plus I do not want to use build in server and database roles

Answer 1

You have two solutions for this:

1) Define the AUTHORIZATION for the role (See here)

CREATE SERVER ROLE role_name [ AUTHORIZATION server_principal ]

role_name
Is the name of the server role to be created.

AUTHORIZATION server_principal
Is the login that will own the new server role. If no login is specified, the server role will be owned by the login that executes CREATE SERVER ROLE.

The server principal will be able to grant the role.

2) Use CONTROL ON ROLE

You can add it within the list of the GRANTed permissions. Look at the Database role permissions section in this document:

Answer 2

From DENY server permissions:

Requires CONTROL SERVER permission or ownership of the securable. If you use the AS clause, the specified principal must own the securable on which permissions are being denied.

So, it would seem that because your server role doesn't have CONTROL SERVER, they can't deny connect themselves.