What Every Accidental DBA Needs to Know Now: Basics of SQL Security

Author's Note

This is a continuation of a series I'm writing on those foundational topics every new DBA (accidental or otherwise) needs to have a grasp of the first day on the job. This series grows out of a session I present on the topic of " What Every Accidental DBA Needs to Know Now "that I'm delivering at IT/Dev Connections this year. If you're new to your DBA role, know someone in that situation, or just want a refresher on the basics of SQL Server Administration then please read this and the other articles in this series.

SQL Server Security v. Trusted Authentication

There are two branches of security schemes in Microsoft SQL Server: SQL Server Security and Trusted Authentication (also known as windows Authentication.) SQL Server Security is a standard login & password combination whereas Trusted Authentication assumes the device attempting to connect to the SQL instance has been vetted and proven through domain authentication and that authentication is then passed on to the SQL Server instance: in the truest senseSQL assumes the login's identity is trusted by the domainhosting theSQL Server instance - that authentication has passed previously.

Users and applications attempting to connect to SQL Server under SQL Server Security will need to supply a login and password that has be created on the target SQL Server. Connections utilizing Trusted Authentication will only need a flag set in the connection string that states that trusted authentication is being used and in that case the identity of the end user or application service account is what is passed through as the security token. If there is a valid login that matches on the SQL Server then access will be granted.

Logins v. Users

Speaking of access there are two levels of access into a SQL Server instance: server (aka instance) logins and database users. Server logins allow an outside user (and for the sake of the rest of this article we'll use "user" as the word to identify any application, service, api, etc. that is attempting to make a connection to SQL Server) to make an initial connection to the instance of SQL Server. For SQL-based security this involves a login and password. In the case of Trusted Authentication this is a domain login.

There are a couple ways to create these logins: either through Transact-SQL or through the GUI. Since the documentation around using T-SQL to create logins is substantial its best served through a link to Microsoft SQL Server's official documentation. That said let's look at the GUI path for login creation. To launch the dialog for new logins connect to a SQL instance in SQL Server Management Studio (SSMS) within the Object Explorer then expand Security\Logins. Right click Logins and select New Login...:

You'll then see the following dialog for creating a new login. Editing a login will display the same dialog:

This is the General tab for the create (and edit) login process. It's also the only one that will differ between the two security schemes previously outlined. The General tab allows you to set:

Login name - just as it sounds this is the name of the login and what will be used for authentication. If this is a Windows\Trusted Authentication-based login you'll need to name it in terms of DOMAIN\LOGIN where LOGIN is the login within the domain you'll be authenticating from which, if it is not within the same domain as the SQL Server instance needs to have trust between its domain and the SQL Server's domain. Password - If using SQL Server authentication the password text box is enabled and you'll supply both a login name and an associated password. PasswordPolicy and ExpirationSettings - The checkboxes for password policy enforcement and expiration will also be enabled under SQL Server authentication and those policies are enforced based upon whatever is in place within Active Directory in the domain which the SQL Server resides. If you're setting up a SQL Server login you can also decide whether to allow the user to change their password on their initial login. This prevents the DBA from having access to the end user's login. Certificates, Keys, Credentials - Since this is an introduction-level article we'll not expand into discussing certificates, keys, and credentials at this time. Default Database - When a connection to a SQL Server is made there are a couple steps that happen: authentication is verified (a login must exist for the user's domain credentials if Windows/Trusted authentication is being used or a valid login and password combination must have been passed to the instance of SQL Server. That's the first hurdle. The second is that the validated login also has an associated user object within the default database - the database that is initially set as the login's context after validating their identity. Even if the first hurdle is cleared, unless there is an associated database user for the login's default database a connection will not be established and an entry will be made in the SQL error log denoting this. There are exceptions though: if the login's server role is significant enough to state that by default the login has implicit rights into each database then the corresponding user in the default database is not necessary. Note however I got ahead of myself because we've yet to discuss database users or server roles. Those come later. Suffice to say that when you choose a default database through the GUI an associated database user is not created. You're just stating what the default database is supposed to be. You will use the User Mapping tab for the Create Login dialog to create an associated database user.

Let's move onto the next tab: Server Roles. This page will allow you to select any roles at the SQL Server (aka Instance) level for the new login. Server Roles are a collection of rights, also known as securables , that are packaged into a collection so you don't have to grant individual rights to eachsecurable. By default every login is a member of the public role which affords basic connection to the SQL instance. We will discuss each of the Server Roles that are shipped with Microsoft SQL Server later in this article.

The next page in the Create Login dialog in SQL Server Management Studio is for user mappings. Each login can have a user in one or more databases.On this page you're able to create database users associated with the new login. That requires providing the following information:

Database - click the checkbox next to the database you want to create an associated user in for the login. User Name -a user object's name does not have to match the login name and you'll see below how you can change that. Default Schema - each database user should also be assigned to a Default Schema. A schema is a collection of database objects, segregated logically (but not necessarily physically) from other objects in the database. It's possible to grant rights for a user or group of users to all objects in a given schema, for instance granting all users in the accounting department (or the accounting application's service account) certain rights to all the objects in the Billing schema, yet not granting access to those objects to other users. By settinga default schema for a database user it means that there is no need to include the schema name in any T-S