Lync Server 2013 uses SQL Server as a repository for key information such as the Central Management Store (CMS), which contains our Lync topology. Lync Standard Edition uses a collocated SQL Server Express backend database that we are not able to move on a different server. Although this configuration reduces the number of machines required for the Lync Server setup, this also limits the options we have to protect our databases. The suggestions in the There's more... and See also sections are usable for both the Standard Edition and Enterprise Edition of Lync Server. The steps in the How to do it... section are applicable only to Lync Server 2013 Enterprise Edition, which has a configuration based on SQL Server that runs on a separate server (with cluster and mirroring supported as a continuity solution).
There are different ways to protect a SQL server, including security measures for the filesystem and best practices, which we will see after the How to do it… section. The steps we will see now are meant to make it more difficult to attack our SQL database from the network. SQL server uses a standard port (TCP 1433 ) for the default database instance, and TCP 1434 for the SQL Browser Service, which allows for connections to named instances of SQL Server that use dynamic ports. Using SQL Browser Service allows us to connect to a database without knowing what port each named instance is using. We will modify the default port for an instance, and disable the SQL Browser Service so that the only way for an attacker to find the TCP port used by our SQL instances is to perform port scanning (which is easier to detect).
Note
There is a TechNet post that talks about a similar solution, Deploying a SQL Server nonstandard port and alias in Lync Server 2013, at http://technet.microsoft.com/en-us/library/dn776290.aspx. However, if we have more than a single instance on the same SQL Server, it makes sense also to disable the SQL Browser Service. If the service is running, discovering its TCP port will also give information about the ports used by the various instances.
On the machine that hosts our SQL server, open SQL Server Configuration Manager and go to SQL Server Network Configuration. Select Protocol for "name of our SQL instance".
Right-click on TCP/IP and select Properties:
Click on the IP Addresses tab, select the various IP addresses available for our SQL server, and set TCP Dynamic Ports as empty. Set TCP Port to the port value we want to use:
Go to the start screen and type
Services. Open the services MMC and right-click on the SQL Server Browser service. Select Properties, and from the drop-down menu, set Startup Type as Disabled:
On one of the Lync Servers that require access to the database, go to the start screen and type
cliconfg.exe.Click on the Alias tab and select Add, as shown in the following screenshot:
In the Server alias field, type a name for the SQL alias. In Network libraries, select TCP/IP. The Connection parameter option is the Fully Qualified Domain Name (FQDN) of the SQL server\name of the instance. If we have configured a static port for SQL, deselect Dynamically determine port and add the port number, as shown in the following screenshot:
Now, go to the start screen and type
regedit. Navigate toHKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\Client\ConnectToand then right-click and select Export:
Now, we are able to use the
.regfile to import the same server alias settings on all the Lync Servers that require a connection to the database.
Customizing and limiting the TCP/IP service ports used by SQL server will make it easier to protect the database, especially when we are using a firewall to protect the server. The SQL Server Browser service answers to requests for SQL resources and redirects the caller to the port where SQL server is listening. If this service is disabled, an external attack will be more complex. Aliases will be used in the Lync Topology to connect our deployment to the databases that we have secured.
As we mentioned before, there are other ways to protect our database, for example, at the single file level, using a SQL server feature known as Transparent Data Encryption (TDE). TDE performs real-time encryption and decryption of the data and logfiles. It is supported in Lync Server 2013 as stated in the Lync Server 2013 supports TDE in SQL Server 2008 or a later version on a backend server post found at http://support.microsoft.com/kb/2912342.
On the TechNet wiki, there are a couple of interesting posts such as Database Engine Security Checklist: Enhance the Security of Database Engine Connections at http://social.technet.microsoft.com/wiki/contents/articles/1257.database-engine-security-checklist-enhance-the-security-of-database-engine-connections.aspx and Database Engine Security Checklist: Database Engine Security Configuration at http://social.technet.microsoft.com/wiki/contents/articles/1256.database-engine-security-checklist-database-engine-security-configuration.aspx full of hints to enhance SQL server security
The Microsoft site also contains documentation regarding SQL Server 2008 R2 Security Best Practices (http://download.microsoft.com/download/1/2/A/12ABE102-4427-4335-B989-5DA579A4D29D/SQL_Server_2008_R2_Security_Best_Practice_Whitepaper.docx) and SQL Server 2012 Security Best Practices (http://download.microsoft.com/download/8/F/A/8FABACD7-803E-40FC-ADF8-355E7D218F4C/SQL_Server_2012_Security_Best_Practice_Whitepaper_Apr2012.docx)