Do not install SQL Server on an Active Directory Domain
In a multitier environment, run Web logic and business logic on
Install the latest applicable SQL Server service pack and security
updates. Refer to the
Hardware & System Software Specification (Bill of Materials) for Cisco Unified ICM/Contact Center Enterprise & Hosted, Release 9.0(1) for the compatible service pack for your product.
Always install SQL Server service to run using a least privilege
account. Never install SQL Server to run using the built-in Local System
account. Follow the steps below to modify the SQL Server service account.
The following assumes the SQL Server has been installed
previously with the service configured to run as the
"LocalSystem" Account. It is possible that these steps can be
shortened if the SQL Server is installed initially to run using a least
privileged account. Refer to the
Staging Guide for Cisco Unified ICM/Contact Center Enterprise & Hosted, Release 9.x(y) for more information about how to properly install SQL
Server using a Domain User Account to run the MSSQL Server service.
Create a Windows domain user account (for example,
<domain>\SQLServiceAcct>). (Refer to the
Staging Guide for Cisco Unified ICM/Contact Center Enterprise & Hosted, Release 9.x(y) for details.) Appropriate file
system permissions (Modify) must be given to this user account for the
\mssql\data directory to be able to create, expand or delete databases as
needed by the
Configure Security Account Delegation in Active Directory
(Users folder) for this account:
Account property page, select
Account is trusted for delegation.
Account is sensitive and cannot be
delegated is not selected.
Configure Security Account Delegation in Active Directory
(Computers folder) for each machine that has SQL (or MSDE) installed:
Trust computer for delegation on the
General property page.
Have a Domain Administrator configure Security Account
Delegation using the SetSPN utility from the Windows Server 2008 R2 resource kit
to set a Service Principal Name as follows:
List the existing SPN for the machine by typing the following
at a command prompt:
setspn -L <machine>
Delete any existing SPN for the MSSQLSvc entry by typing the
following at a command prompt:
setspn -D "MSSQLSvc/<machine:port>
Create a new SPN entry for the MSSQLSvc entry by typing the
following at a command prompt:
setspn -A "MSSQLSvc/<machine:port>
Add the domain user account created in Step a. to the NTFS
permissions for the Operating System and data partitions at the root level (For
example, C:\). Allow all permissions, except Full Control.
The SQL Server 2008 R2 automated hardening utility, and the
ICMDBA tool, will automatically ensure this permission is appropriately
Finally, add this domain user account created in Step a. to
the Registry permissions for the HKEY_LOCAL_MACHINE\Software,
HKEY_LOCAL_MACHINE\System and HKEY_USERS hives, giving it Full Control.
From the SQL Server Configuration Manager (for SQL Server
2008 R2), configure the SQL Server service to run as the domain user account
created in Step a. (for example, <domain>\SQLServiceAcct>).
SQL Server Agent Service
must be enabled and set to Automatic for database
maintenance functioning in
Applying SQL Server security updates or hotfixes may require
that the SQL Server Agent service be disabled. It is recommended that this
service be reset to
"disabled" before performing the update. When the update has
completed, stop the service and set it back to
In all releases before 7.5, the Distributed Transaction
Coordinator, MSDTC, is disabled (this is done by default by the automated
server hardening in the Cisco
Unified ICM Security Template Settings shipped with 7.0, 7.1, and 7.2).
However, from ICM 7.5 onwards, MSDTC services must be set to
manual (done by default by the automated server hardening in the Cisco
Unified ICM Security Template shipped with ICM 7.5 and 8.0).
The SQLServerAgent and MSDTC services may be used for
Third-Party Backup solutions; therefore we recommend checking the Backup Agents
system requirements before disabling these services.
Use NTFS directory security with EFS for SQL Server data
directories. EFS must be set while logged in under the account credentials that
the SQL service will run under (for example,
<domain>\SQLServiceAcct>). From the Local Policy editor, temporarily
"logon locally" privileges to this account to enable EFS then
remove this right after logging off.
Only enable EFS if there is a
concern with data theft; there will be a performance impact.
In order to copy and send the data to other parties, it will be
necessary to back up the database to a different directory that is not
encrypted to ensure that the receiving party is able to read the data in the
backup. This can be accomplished by backing up the database from the SQL Server
Disable the SQL guest account.
Restrict sysadmin membership to your
Unified ICM administrators.
Block TCP port 1433 and UDP port 1434 at the firewall except for
when the Administration & Data Server is not in the same security zone as
Provide protection with good housekeeping:
Run the KillPwd utility to remove password data from setup
files. Detailed instructions on how to run this utility can be found in the
Delete or secure old setup files: Delete or archive the
following files after installation: sqlstp.log, sqlsp.log, and setup.iss in the
<systemdrive>:\Program Files\Microsoft SQL Server\MSSQL\Install
folder for a default installation, and the <systemdrive>:\Program
Files\Microsoft SQL Server\ MSSQL$<Instance Name>\Install folder for
If the current system is an upgrade from SQL Server 7.0,
delete the following files: setup.iss in the %Windir% folder, and sqlsp.log in
the Windows Temp folder.
Change the recovery actions of the Microsoft SQL Server service to
restart after a failure.
Remove all sample databases, for example, Pubs and Northwind.
Enable auditing for failed logins.
SQL Server users and authentication
When creating a user for the SQL Server account, create Windows
accounts with the lowest possible privileges for running SQL Server services.
It is preferable that this be done during the installation of SQL Server.
During installation, SQL Server Database Engine is set to either
Windows Authentication mode or SQL Server and Windows Authentication mode. If
Windows Authentication mode is selected during installation, the sa login is
disabled. If you later change authentication mode to SQL Server and Windows
Authentication mode, the sa login remains disabled. To enable the sa login, use
the ALTER LOGIN statement. For additional details see: http://msdn.microsoft.com/en-us/library/ms188670.aspx.
The local user or the domain user account that is created to function
as the SQL Server service account follows the Windows or domain password policy
respectively. It is imperative that a strict password policy is applied on this
account. However, do not set the password to expire, because SQL Server service
will cease to function and that in turn will cause the Administration &
Data Server to fail.
The password and account settings may be governed by the site
requirements. At the least, the following settings are recommended:
Table 1 Password and account settings
Enforce Password History
24 passwords remembered
Minimum Password Length
Minimum Password Age
Account Lockout Duration
Account Lockout Threshold
3 invalid logon attempts
Reset Account Lockout Counter After
The service account password must
explicitly be set to Not expire.
Mixed mode authentication is enforced through SQL Server 2008 R2 automated hardening.
During web setup, if the sa password is found to be blank, a randomly
generated strong password is generated and used to secure the sa account.
This randomly generated sa password is displayed only once during
the install. Make note of the password because it is not presented again.
Resetting of the sa account password may be done after installation by logging
on to the SQL Server using a Windows Local Administrator account.
SQL Server 2008 R2 security considerations
Server 2008 R2 is far more secure by design, default, and deployment than
prior versions. Microsoft SQL Server 2008 R2 provides a much more
granular access control and a new utility to manage attack surface, and runs
with lower privileges. To make the best of the security features provided by
Microsoft SQL Server 2008 R2, the database administrator must follow the best
practices as described below in the "Automated SQL 2008 R2 Hardening" section.
Forces SQL server user 'sa' password if found blank.
SQL Server Security Hardening utility
The SQL Server Security Hardening utility allows you to harden or roll
back the SQL Server security on Logger and Administration & Data Server/HDS
components. The Harden option disables unwanted services and features, as
explained in the
"Automated SQL 2008 R2 Hardening" section above. If the latest
version of the security settings are already applied, then the Harden option
does not change anything. The Rollback option allows you to return to the state
of SQL services and features that existed prior to your applying the last
The SQL Server Security Hardening utility is launched via Setup, by
default, to harden the SQL Server security. However, you can run it manually,
as described below.
By default, SQL
Server 2008 R2 disables VIA endpoint and limits the Dedicated Administrator
Connection (DAC) to local access. Also, by default, all logins have GRANT
permission for CONNECT using Shared Memory, Named Pipes, TCP/IP and VIA
endpoints. Unified ICM requires only Named Pipes and TCP/IP endpoints.
Enable both Named Pipes and TCP/IP endpoints during SQL Server 2008 R2
setup. Make sure Named Pipes has a higher order of priority than TCP/IP.
The SQL Server Security Hardening utility will check for the availability
and order of these endpoints.
Disable access to all
endpoints that are not required. For instance: Deny connect permission to VIA
endpoint for all users/groups who have access to the
1 The string inside
quotes must match exactly what is seen in the List command:: setspn -L