DENY Server Permissions (Transact-SQL)

Applies to: SQL Server Azure SQL Managed Instance

Denies permissions on a server.

Transact-SQL syntax conventions

Syntax

DENY permission [ ,...n ]
    TO <grantee_principal> [ ,...n ]
    [ CASCADE ]
    [ AS <grantor_principal> ]

<grantee_principal> ::= SQL_Server_login
    | SQL_Server_login_mapped_to_Windows_login
    | SQL_Server_login_mapped_to_Windows_group
    | SQL_Server_login_mapped_to_certificate
    | SQL_Server_login_mapped_to_asymmetric_key
    | server_role

<grantor_principal> ::= SQL_Server_login
    | SQL_Server_login_mapped_to_Windows_login
    | SQL_Server_login_mapped_to_Windows_group
    | SQL_Server_login_mapped_to_certificate
    | SQL_Server_login_mapped_to_asymmetric_key
    | server_role

Arguments

permission

Specifies a permission that can be denied on a server. For a list of the permissions, see Remarks.

CASCADE

Indicates that the permission is denied to the specified principal and to all other principals to which the principal granted the permission. Required when the principal has the permission with GRANT OPTION.

TO <server_principal>

Specifies the principal to which the permission is denied.

AS <grantor_principal>

Specifies the principal from which the principal executing this query derives its right to deny the permission.

Use the AS principal clause to indicate that the principal recorded as the denier of the permission should be a principal other than the person executing the statement. For example, presume that user Mary is principal_id 12 and user Raul is principal 15. Mary executes DENY SELECT ON OBJECT::X TO Steven WITH GRANT OPTION AS Raul; Now the sys.database_permissions table will indicate that the grantor_principal_id of the deny statement was 15 (Raul) even though the statement was actually executed by user 13 (Mary).

SQL_Server_login

Specifies a SQL Server login.

SQL_Server_login_mapped_to_Windows_login

Specifies a SQL Server login mapped to a Windows login.

SQL_Server_login_mapped_to_Windows_group

Specifies a SQL Server login mapped to a Windows group.

SQL_Server_login_mapped_to_certificate

Specifies a SQL Server login mapped to a certificate.

SQL_Server_login_mapped_to_asymmetric_key

Specifies a SQL Server login mapped to an asymmetric key.

server_role

Specifies a server role.

Remarks

Permissions at the server scope can be denied only when the current database is master.

Information about server permissions can be viewed in the sys.server_permissions catalog view, and information about server principals can be viewed in the sys.server_principals catalog view. Information about membership of server roles can be viewed in the sys.server_role_members catalog view.

In Azure SQL Database, GRANT, REVOKE, and DENY of server level permissions aren't supported.

A server is the highest level of the permissions hierarchy. The most specific and limited permissions that can be denies on a server are listed in the following table.

The following three server permissions were added in SQL Server 2014 (12.x).

• CONNECT ANY DATABASE permission

  • Grant CONNECT ANY DATABASE to a login that must connect to all databases that currently exist and to any new databases that might be created in future. Does not grant any permission in any database beyond connect. Combine with SELECT ALL USER SECURABLES or VIEW SERVER STATE to allow an auditing process to view all data or all database states on the instance of SQL Server.

• IMPERSONATE ANY LOGIN permission

  • When granted, allows a middle-tier process to impersonate the account of clients connecting to it, as it connects to databases. When denied, a high privileged login can be blocked from impersonating other logins. For example, a login with CONTROL SERVER permission can be blocked from impersonating other logins.

• SELECT ALL USER SECURABLES permission

  • When granted, a login such as an auditor can view data in all databases that the user can connect to. When denied, prevents access to objects unless they are in the sys schema.

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.

Examples

A. Deny CONNECT SQL permission to a SQL Server login and principals to which the login has regranted it

The following example denies CONNECT SQL permission to the SQL Server login Test and to the principals to which she has granted the permission.

USE master;  
DENY CONNECT SQL TO Test CASCADE;  
GO  

B. Deny CREATE ENDPOINT permission to a SQL Server login using the AS option

The following example denies CREATE ENDPOINT permission to the user Test1. The example uses the AS option to specify Test2 as the principal from which the executing principal derives the authority to do so.

USE master;  
DENY CREATE ENDPOINT TO Test1 AS Test2;  
GO  

Related content

• GRANT (Transact-SQL)
• DENY (Transact-SQL)
• DENY Server Permissions (Transact-SQL)
• REVOKE Server Permissions (Transact-SQL)
• Permissions Hierarchy (Database Engine)
• sys.fn_builtin_permissions (Transact-SQL)
• sys.fn_my_permissions (Transact-SQL)
• HAS_PERMS_BY_NAME (Transact-SQL)