5. Security-Configuration Properties
The security-configuration properties, as shown in Table 4, control the security features of SQL Server.
Table 4 Security-Configuration Properties
The same security-configuration options
established during the installation are again presented in the Security
tab of the Server Properties page (see Figure 4), so the configuration may be adjusted after installation.
Server Authentication Mode
The server authentication modes are
exactly the same as presented during the SQL Server installation.
Following are two server authentication modes:
- Windows Authentication mode: This uses Windows Authentication to validate connections.
- SQL Server and Windows Authentication mode: This uses both SQL and Windows Authentication to validate connections.
Note
During installation, if you select SQL
Server and Windows Authentication mode, you are prompted for an sa
password. When you select Windows Authentication mode, the sa account
gets a random strong password, unknown to the user. When you change to
SQL Server and Windows Authentication mode, the sa account is disabled.
You need to enable the sa account and then change the sa password to
use the account (refer to Figure 4).
Security-Audit Level
The login auditing options configure
the level of user-login auditing performed by SQL Server. You can
choose one of the following four login auditing options (refer to Figure 4):
- None
- Failed logins only
- Successful logins only
- Both failed and successful logins
Based on the setting, SQL Server records every
successful or failed user login attempt to the Windows application log
and the SQL Server log. SQL Server service must be restarted for the
login auditing options to take effect.
C2 Audit Tracing
C2 auditing is a U.S. government
standard for monitoring database security. SQL Server supports C2
auditing. To configure SQL Server for C2 auditing, enable the c2 audit mode option. Enabling the c2 audit mode
option configures the SQL Server to all security related events. You
can find all the events by browsing through them in SQL Server Profiler.
Note
By default, a trace file (C2 audit log)
is stored in the default SQL Server data directory. The trace file
rolls over automatically when it reaches 200MB. This continues until
the data drive fills up or C2 auditing is turned off.
In Management Studio, the c2 audit mode option can be turned on by selecting the Enable C2 Audit Tracing box in the Server Properties Security tab (refer to Figure 4).
In code, to turn on the c2 audit mode option, do the following:
EXEC sp_configure ‘show advanced options', 1;
RECONFIGURE;
EXEC sp_configure ‘c2 audit mode', 1;
RECONFIGURE;
SQL Server service must be restarted for the c2 audit mode option to take effect.
The C2 auditing mode has been superseded by
Common Criteria Compliance. Common Criteria Compliance can be enabled
only by code using the sp_configure system stored procedure:
EXEC sp_configure ‘show advanced options', 1;
RECONFIGURE;
EXEC sp_configure ‘common criteria compliance enabled', 1;
RECONFIGURE;
SQL Server service must be restarted for the common criteria compliance enabled option to take effect.
Cross Database Ownership Chaining
By default, all database objects such
as table, view, and stored procedure have owners. When an object
references another object, an ownership chain is formed. When the same
user owns the source object and the target object, SQL Server checks
permission on the source objects and not on the target objects.
Cross-database ownership chaining occurs when the
source object depends on objects in another database. Cross-database
ownership chaining works in the same way as ownership chaining in a
database, except that an unbroken ownership chain is based on all the
object owners being mapped to the same login account. If your
application uses more than one database and it calls objects from one
database based on objects in another database, then cross database
chaining is used. If the source object in the source database and the
target object in the target database are owned by the same login, SQL
Server does not check permissions on the target objects.
The cross db ownership chaining option enables control of the cross database ownership chaining for all databases. By default, the cross db ownership chaining
option is turned off (0). This is good because it ensures maximum
security. If you turn this option on (1), database owners and members
of the db_ddladmin or the db_owners
database roles can create objects owned by other users. These objects
can potentially target objects in other databases. This means you must
fully trust these users with data in all databases.
Tip
In Management Studio, you can turn on
cross database ownership chaining by checking the Cross Database
Ownership Chaining option on the Server Properties Security tab (refer
to Figure 4).
In code, to turn on cross database ownership chaining, do the following:
EXEC sp_configure ‘cross db ownership chaining', 1;
RECONFIGURE;
When you turn off (0) the cross db ownership chaining option , you can control cross database ownership chaining at the database level with the SET DB_CHAINING option of the ALTER DATABASE command.
