Server Permissions
Before server permissions, if you wanted a login to be able to shut down the server, you needed to assign that login to the serveradmin role. Yet serveradmin
imparts a number of other capabilities that you may not want to give
that other user, such as the ability to change server-wide settings.
With server permissions, you can now grant just the SHUTDOWN permission to a specific login, as shown in the following code:
USE master
GO
GRANT SHUTDOWN TO <login>
GO
where <login> is the name of the SQL Server login that you want to grant the SHUTDOWN permission to. There are 30 permissions that can be granted at the server instance scope. Table 2 shows a complete list of these permissions.
Each one of these permissions applies to one or more securables. A securable is a resource to which SQL Server regulates access. In Table 2,
you can see that some securables are servers, some are logins, and some
are endpoints. By using these permissions, you be very granular in what
you allow other users to do.
Endpoints
An endpoint is a point of entry into SQL
Server. Prior to SQL Server 2005, if you had a valid SQL Server login,
you could connect via TCP/IP, shared memory, or any other protocol that
was enabled on the server. With endpoints, you can now restrict what
kinds of protocols a specific SQL Server login can connect by. Restricting available protocols reduces the area of attack for hackers. If you allow your sysadmin
accounts to connect via shared memory only, you won’t have to worry
that someone remote will try to connect as sysadmin over a network
connection. Shared memory clients can connect to only those server
instances that are on the local server, so you have to be physically
sitting at the machine or within a remote desktop session. As a best
practice (and if possible to do within your organization), consider
locking down access to sysadmin accounts.
In addition to the transport protocol, endpoints specify the payload. Payloads
define the type of traffic that is allowed. For example, if you can
create an HTTP endpoint that listens to SOAP traffic and assign the CONNECT
permission to a specific SQL Server login, that SQL Server login can
then submit SOAP queries via HTTP to SQL Server. Endpoints are highly
leveraged by two key components within SQL Server: Service Broker and
database mirroring. When you set up these features within SQL Server,
you may notice additional endpoints created.
The sys.server_endpoints catalog view displays both system and user endpoints. Since there are no user-defined endpoints on the queried server, Table 3 simply shows the system endpoints that are available out of the box.
SELECT Name,Protocol_desc from sys.endpoints
The previous SELECT statement yields the information represented in Table 3.
By default, all SQL Server logins are granted CONNECT permissions to all the system endpoints listed in Table 3
with the exception of the dedicated administrator connection (DAC). The
DAC is a special endpoint available only to members of the sysadmin
role. It’s a special single-user connection that is designed for an
administrator to connect if he or she cannot connect via the normal
connection method to SQL Server. The DAC is useful if a particular
process ID within SQL Server is consuming too many resources, which, in
turn, prevents additional user connections. With DAC, an administrator
can always connect and troubleshoot any issues.
To help illustrate the power of endpoints, let’s create a login, MyAppLogin, and allow it to connect only via shared memory. You do this by denying access to all the other protocols.
CREATE LOGIN MyAppLogin WITH PASSWORD='PaSsWoRd1'
GO
DENY CONNECT on ENDPOINT::[TSQL Default TCP] to MyAppLogin
GO
DENY CONNECT on ENDPOINT::[TSQL Default VIA] to MyAppLogin
GO
DENY CONNECT on ENDPOINT::[TSQL Named Pipes] to MyAppLogin
GO
You can test the ability to connect to SQL Server as MyAppLogin
through SQL Server Management Studio. When you make a connection in
SSMS, the connection dialog box has an Options button. Clicking that
will allow you to select the Connection Properties tab. On this tab is
a Network Protocol drop-down box. Here, you can force a certain
protocol to be used when SSMS makes the connection to SQL. If you run
the previous script and attempt to connect using TCP/IP with valid
credentials, your connection request will fail. However, if you specify
shared memory, the connection will succeed. This is illustrating the
fact that you denied access to these endpoints for the MyAppLogin account.
User-Defined Server Roles
SQL Server contains a plethora of permissions
that a database administrator can assign to a particular login. In
reality, once we have more than a few users managing permissions, this
way becomes cumbersome. To address this, administrators can create a
user-defined server role. These roles are defined at the SQL Server
instance level, and specific server-level permissions can be assigned
to a role. One scenario where user-defined server roles can be useful
is when you have a requirement to give users elevated capability (such
as the sysadmin role), but they only need a limited part
of that role for thier jobs. With user-defined server roles, a system
administrator can create a role that has specific elevated permissions
like CONTROL SERVER. CONTROL SERVER is almost the same level as a sysadmin except that it obeys a DENY
permission on an object. Given this, we can create user that has
sysadmin-like access without being in the sysadmin role. If we wanted
to prevent that user from modifying the server audits we can simply
apply the DENY ALTER ANY SERVER AUDIT permission to the user-defined server role.
To illustrate user-defined server roles, let’s
consider the scenario where we want to create a new user-defined role
that will contains logins who are database administrators. We want to
make sure this group cannot change any audits that are defined but can
perform all the other duties that a sysadmin can. First, we create the
server role by issuing the CREATE SERVER ROLE statement as follows:
CREATE SERVER ROLE [DBA Role]
Next, we define the permissions assigned to this new role and add the necessary DENY permissions to restrict the user from changing audits or impersonating the auditor.
GRANT CONTROL SERVER TO [DBA Role]
GO
DENY ALTER ANY SERVER AUDIT TO [DBA Role]
GO
DENY ALTER ANY LOGIN TO [DBA Role]
GO
DENY IMPERSONATE ON LOGIN::CorporateAuditor TO [DBA Role]
GO
To add a login to a user-defined server role we issue the ALTER SERVER ROLE statement as follows:
ALTER SERVER ROLE [DBA Role] ADD MEMBER [Julie]
Given these statements, if we assigned our database administrator, Julie, to the DBA Role
role, she could perform any administrative function except being able
to change the audit. Since we denied this role the ability to change
logins, she can’t simply modify permissions on the group to give
herself more privileges. Also, we denied the group the ability to
change the server audits. This protects against a repudiation attack
where the malicious user, or DBA Role member in this case, tried to cover up their tracks by tampering with the audit. Someone with CONTROL SERVER
permission also has the ability to impersonate user accounts, thus, we
want to ensure that this role doesn’t have the ability to change the
audit via the auditor’s credentials, so we use DENY IMPERSONATE
on the auditors login as well.
