Installing SQL Server presents us with two options for login
authentication: Windows Authentication Mode or SQL Server and Windows
Authentication Mode (commonly called Mixed Mode). Regardless of the
installation choice, you change this setting at any future point using sp_configure, or as shown in figure 1,
by right-clicking on a registered server instance in SQL Server
Management Studio, choosing Properties, and then clicking the Security
page in the Properties dialog.
In Windows Authentication mode, SQL Server will
only accept connections from sessions bearing a security token assigned
during a successful Windows login. Not only does this simplify SQL
Server login management (logins are already managed in Windows), Windows
logins can be the subject of powerful password complexity and
expiration policies, options that weren't available in SQL Server
authentication in versions prior to 2005.
In SQL Server 2005, Microsoft significantly
strengthened SQL Server authentication by providing a means to enforce
password complexity and expiration policies to match the host Windows
Server, as long as the server is running Windows Server 2003 or above.
Despite this addition, Windows authentication remains the best choice.
1. Windows Authentication mode
Windows Authentication mode offers many advantages:
It's the most secure. Passwords are
never sent across the network, and expiration and complexity policies
can be defined at a domain level.
Account creation and management is centralized, and usually handled by specialist IT groups.
Windows accounts can be placed into groups, with permissions assigned at a group level.
SQL Server, with its ability to accept Windows
authenticated logins, can leverage all of these benefits, providing both
a secure and simplified login and a permissions management environment.
|
Unfortunately, many application vendors rely on
SQL Server authentication, and in the worst examples, hard-code SA as
the username in the connection properties (some with a blank password!).
As DBAs, we should be exerting pressure on such vendors to ensure
there's at least an option to use something other than the SA account,
and ideally to use Windows Authentication mode.
|
If Windows Authentication mode is chosen during
installation, the setup process still creates the SA account but
disables it by default. Changing to Mixed Mode security, discussed next,
requires this account to be reenabled before it can be used. If the
authentication mode is changed, SQL Server will check for a blank SA
password and prompt for a new one if appropriate. Given that brute-force
attacks tend to target the SA account, having a nonblank, complex SA
password is crucial in preventing unauthorized access.
In some cases, connections may originate from
clients or applications unable to connect using Windows Authentication
mode. To enable such connections, SQL Server also supports the SQL
Server and Windows Authentication mode.
2. SQL Server and Windows Authentication mode (Mixed Mode)
Unlike Windows authentication, SQL Server
authentication works by validating a username and password supplied by
the connecting process. For example, in Windows Authentication mode, a
process connecting from the WIDGETINC\JSmith account would be
automatically accepted if the Windows account is defined as a SQL Server
login with access to the appropriate database. No password needs to be
supplied because Windows has already validated the login. In contrast, a
SQL Server authentication session supplies a username and password for
validation by SQL Server.
Despite welcome improvements to SQL Server authentication mode in 2005, some concerns with this login method remain:
For applications using SQL Server
authentication, SQL passwords are commonly included in connection
strings stored in clear text in configuration files or registry entries.
If you're using this authentication mode, store passwords in an
encrypted form before unencrypting them for use in establishing a
connection.
Despite the login credentials
being encrypted during the SQL Server login process, the encryption is
typically performed using a self-signed certificate. While such
encryption is better than nothing at all, it's susceptible to
man-in-the-middle or identity spoofing attacks. In Windows
authentication, passwords are never transmitted over the network as part
of the SQL Server login process.
While
password expiration and complexity policies are available in SQL Server
authentication, such policy enforcement isn't mandatory, and each SQL
Server's policies could potentially have varying degrees of strength,
compared to a policy defined and enforced at a domain level using
Windows authentication.
For these reasons, Windows authentication
remains the most secure choice for a SQL Server installation. If you do
choose the SQL Server Authentication mode—for example, to support
connections from non-Windows authenticated clients—ensure that passwords
are adequately complex and you have an appropriate expiration policy in
place.
|
Unlike SQL Server 2005, there's no Surface Area
Configuration tool in SQL Server 2008; a variety of tools are used in
its place, including policy-based management, sp_configure,
and Management Studio. Fortunately, the default installation and
configuration settings are secure, so unless configuration settings are
explicitly changed, the surface area of a SQL Server instance will
remain secure.
|
A strong login
authentication model is a crucial aspect of a secure SQL Server
environment, as is locking down network access, as you'll see next.
