Step 4. Accounts

Follow the principle of least privilege for the accounts used to run and connect to SQL Server to restrict the capabilities of an attacker who manages to execute SQL commands on the database server. Also apply strong password policies to counter the threat of dictionary attacks.

In this step, you:

• Secure the SQL Server service account .

• Delete or disable unused accounts .

• Disable the Windows guest account .

• Rename the administrator account .

• Enforce strong password policy .

• Restrict remote logins .

• Disable null sessions (anonymous logons ) .

Secure the SQL Server Service Account

Run the SQL Server service using a least privileged account to minimize the damage that can be done by an attacker who manages to execute operating system commands from SQL Server. The SQL Server service account should not be granted elevated privileges such as membership to the Administrators group .

 Task   To create a new account to run the SQL Server service

1. Start the Computer Management tool, and then expand Local Users and Groups .

2. Right-click the Users folder, and then click New User .

3. Create a new user making sure you use a strong password.

   In the New User dialog box, clear the User must change password at next logon check box, and then select the User cannot change password and Password never expires check boxes.

4. Remove the new account from the Users group because this group is granted liberal access across the computer.

You can now configure SQL Server to run using this new account. For more information, see "Step 10: SQL Server Security."

Accessing the Network from SQL Server

If you need to access network resources from SQL Server, for example to perform network backups , for replication or log shipping, the SQL Server service account must be capable of being authenticated across the network. You have two choices. Either create a duplicate local account with the same name and password on the remote server, or use a least privileged domain account.

Delete or Disable Unused Accounts

Unused accounts and their privileges may be a haven for an attacker who has gained access to a server. Audit local accounts on the server and delete those that are unused. The recommendation is to first disable an account to see if this causes any problems before deleting the account, because deleted accounts cannot be recovered. Note that the administrator account and guest account cannot be deleted.

Note  

During SQL Server 200 SP3 installation, Sqldbreg2.exe creates the SQL Debugger account. Visual Studio .NET uses this account when debugging stored procedures from managed .NET code. Because this account is only used to support debugging, you can delete it from production database servers.

Disable the Windows Guest Account

The Windows guest account is the account used when an anonymous connection is made to the computer. To restrict anonymous connections to your database server, keep this account disabled. By default, the guest account in Windows 2000 is disabled. To see if it is enabled, display the Users folder in the Computer Management tool. It is represented by a cross icon. If it isn't disabled, display its Properties dialog box and select the Account is disabled check box.

Rename the Administrator Account

The default local administrator account is a target for malicious use because of its high privileges on the computer. To improve security, rename the default administrator account and assign it a strong password.

Enforce Strong Password Policy

To counter password guessing and brute force dictionary attacks, apply strong password policies by configuring security policy. The keys to strong account and password policies are:

• Set password length and complexity . Enforcing strong passwords reduces the chance of successful password guessing or dictionary attacks.

• Set password expiration . Regularly expiring passwords reduces the chance that an old password will be used for unauthorized access. The expiration period is typically guided by a company's security policy.

Table 18.3 shows the default and recommended password policy settings.

Table 18.3: Password Policy Default and Recommended Settings

Password Policy	Default Setting	Recommended Minimum Setting
Enforce password history	1 password remembered	24 passwords remembered
Maximum password age	42 days	42 days
Minimum password age	0 days	2 days
Minimum password length	characters	8 characters
Passwords must meet complexity requirement	Disabled	Enabled
Strong password using reversible encryption for all users in the domain	Disabled	Disabled

Additionally, log failed login attempts to detect and trace malicious behavior. For more information, see "Step 9: Auditing and Logging."

For more information about password policies, see password "Best Practices" on the Microsoft TechNet Web site at http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/windowsserver2003/proddocs/entserver/ windows_password_protect.asp .

Restrict Remote Logons

Use the Local Security Policy tool to remove the "Access this computer from the network" user right from the Everyone group to restrict who can log on to the server remotely.

Disable Null Sessions (Anonymous Logons)

To prevent anonymous access, disable null sessions. These are unauthenticated or anonymous sessions established between two computers. Unless null sessions are disabled, an attacker can connect to your server anonymously, that is, without requiring authentication.

As soon as an attacker establishes a null session, a variety of attacks can be performed, including enumeration used to obtain system- related information from the target computer. The type of information that can be returned over a null session includes domain and trust details, shares, user information including groups and user rights, registry keys, and more. Disable them because they represent a significant security threat.

Restrict null sessions by setting RestrictAnonymous=1 in the registry at the following location.

 HKLM\System\CurrentControlSet\Control\LSA\RestrictAnonymous=1 

For more information, see Microsoft Knowledge Base article 246261, "How To: Use the RestrictAnonymous Registry Value in Windows 2000."

Additional Considerations

Consider the following steps to improve security for your database server:

• Require approval for account delegation . Do not mark domain accounts as trusted for delegation in Active Directory without special approval.

• Do not use shared accounts . Do not create shared account for use by multiple individuals. Give authorized individuals their own accounts. The activities of individuals can be audited separately and group membership and privileges appropriately assigned.

• Restrict the local Administrators group membership . Ideally, have no more than two administration accounts. This helps provide accountability. Also, do not share passwords, again to provide accountability.

• Limit the administrator account to interactive logins . If you perform only local administration, you can restrict your administrator account to interactive logons by removing the "Access this computer from the network" user right to deny network logon rights. This prevents users (well intentioned or otherwise ) from remotely logging on to the server using the administrator account. If a policy of local administration is too inflexible , implement secure remote administration.

  For more information about remote administration, see "Remote Administration" later in this chapter.

• Enable NTLMv2 authentication . If client computers connect to your database server by using Windows authentication, you should configure your database server to use the strongest version of Windows authentication, which is NTLMv2.

  Note  

  To support NTLMV2, clients must be running Windows 2000, Windows Server 2003, or Windows NT ⁽ operating system version 4.0 with Service Pack 4.

 Task   To enable NTLMv2 authentication from the Local Security Policy Tool

1. Expand Local Policies, select Security Options, and then double-click LAN Manager Authentication Level.

2. Select Send NTLMv2 response only\ refuse LM & NTLM.

This is the most secure setting.

Note  

This is equivalent to setting the HKLM\System\CurrentControlSet\Control\Lsa\LMCompatibilityLevel DWORD value to 5.