There are two parts to SQL Server security, and both parts are required... They work together to determine security, and neither is useful without the other.
The database server has logins. Logins establish identity and grant access to the server. Logins come in two general flavors, Windows Authenticated and SQL Authenticated.
Windows Authenticated logins use trusted connections to convey information about the Windows Login that is making the connection. The user doesn't need to enter any information like username or password because these were entered and confirmed when the user signed on to Windows. Windows Authentication is normally only used in an Active Directory environment, although it is possible to use the Windows logins provided by the local machine too. Windows Authentication is more secure at the communication level (between the client and the server), and can be more secure end-to-end
if it is used properly, but applications that use only Windows Authentication are vulnerable to "drive by users" if a machine is left unsecured.
SQL Authenticated logins require passing the user name and password to SQL Server. The SQL engine then confirms the user exists and that the password is correct for the specified user. SQL Authenticated logins are especially good for use with very old applications and also for non-windows applications.
Once the user has logged in, their identity is established for SQL Server. Some logins have server administrative permissions, such as the sa login or the sysadmin role which can grant them access to everything on the server. Each login is logically mapped to at most one user in each database. If no user is mapped to a login, then that login has no access to that database.
Within their database, a user is granted permissions. Some permissions are database-wide, such as db_owner or db_datareader. Other permissions are specific to a given object such as a view, table, or stored procedure. Permissions control what actions a given user can perform. If permission is not granted (directly or indirectly), a user can do nothing within the database.
FAQ Index