Many people who've played around with TDE seem to have had trouble with restoring a TDE database on an alternate server, and the confusion seems to stem primarily from the deep encryption heirarchy for TDE. It's not too hard, however, once you realize that you can ignore most of the stack. The lynchpin is the certificate that is just above the TDE database in the heirarchy. If you use the certificate backup option to export the certificate's private key and protect it by password, then you can restore the certificate to any instance of SQL Server of the same version or later. Once the certificate has been restored, you should also be able to restore the TDE database that was protected by that certificate.

I've attached a .zip with a detailed document and a T-SQL script to help you experiment with TDE. Here are the topics in the document:

• What is Transparent Database Encryption (TDE)?
• Limitations of TDE
• Costs of TDE
• Alternatives to TDE
• When to use TDE
• How to enable TDE
• How to backup a TDE database
• How to restore a TDE database to the same server
• How to restore a TDE database to an alternate server
• TDE/Encryption-Related System Tables
• TDE's Encryption Hierarchy

Before you invest a lot of time with TDE, consider my standard lecture #8: Since there are many good alternatives to using TDE and since there are costs imposed by using TDE, it shouldn't be used unless there are specific reasons for which the alternatives are inadequate and the costs are justifiable. In practice, this means that TDE should rarely be implemented.

See Also:
http://blogs.technet.com/b/fort_sql/archive/2012/02/23/does-the-dod-stig-require-transparent-database-encryption-tde.aspx
 

TDE overview and example script.zip

The Database STIG makes clear that any unnecessary network protocols should be disabled on the server hosting an instance of SQL Sever, but what I'm pointing out in this post is that network protocols on other servers may also need to be secured to provide maximum security for SQL Server.

If you have a web server or DNS server exposed to the Internet, as is very common, they normally don't need NetBIOS or SMB. If they're enabled and a cracker compromises one of them, they may be able to use them to find instances of SQL Server. The MSDN article "Security Considerations for a SQL Server Installation" (http://msdn.microsoft.com/en-us/library/ms144228(v=sql.105).aspx) covers this issue, among others.

If you want to harden your web servers and DNS servers, here are links to articles descibing how to disable NetBIOS and SMB. Note that in Device Manager, you may have an entry of "NETBT" instead of "NetBios over TCP/IP" (both represent netbt.sys).

How to Disable NetBIOS
(Netbt.sys)
http://msdn.microsoft.com/en-us/library/ms143696(v=SQL.90).aspx

How to Disable SMB
http://msdn.microsoft.com/en-US/library/ms143455(v=sql.90).aspx

====================================================================================

I've recently learned there's such as a thing as Managed Service Accounts (MSAs) in Active Directory if your domain controller is using Window Server 2008 R2 or Windows 7, and these accounts can significantly improve security. Why didn't I hear about this before? Probably because I'm a SQL Server specialist, not a Windows or Active Directory specialist. At any rate, I thought I'd pass this along in case I'm not the last person on the planet to get clued in.

For an MSA, Active Directory will assign a 120-random-character password, change the password every 30 days, and manage the Service Principal Names (SPNs). The account can't be locked out, and system administrators don't have to maintain it.

Security is improved because the passwords don't have to be maintained by humans and because an MSA can only be used by a service on one computer. It does take a little extra work in the beginning, though, as seen in this 4-step process:

1. Create an MSA in Active Directory.
2. Associate the MSA with a single computer.
3. Install the MSA on its computer.
4. Configure the service (e.g. SQL Server) to use the MSA.

This isn't in the Database STIG yet, but I expect it will show up there as a security best practice sooner or later.

For more information on MSAs, start here http://technet.microsoft.com/en-us/library/ff641729(v=ws.10) or here http://technet.microsoft.com/en-us/library/dd548356(v=WS.10).aspx.

Attached to this article is a WMI-PowerShell script that checks disk free space, including mount points. It's written to be used in a SQL Server Agent job, and send an email alert via SQL Server's Database Mail. You can run it against any number of servers from one script, and you'll need to replace several items in the script: Server name(s), the Database Mail profile name, the recipient email address(es), and optionally change the warning threshold. It works like any other Agent job except you choose a job step Type of "PowerShell". Detailed notes on how to tweak and use the script are included as in-line notes in the script file.

If you're not familiar with PowerShell and you'd like to view the code in color-coded formating, use the PowerShell ISE (Start menu/Accessories/Windows PowerShell/Windows PowerShell ISE). (ISE stands for Integrated Scripting Environment.)

Here's a security-related wrinkle to WMI calls via PowerShell that's run by SQL Server Agent... If the service account that SQL Server Agent runs under has local admin permissions/privileges and you only run the script against the local server, you probably won't have any access-denied problems. Under any other scenarios, such as the Agent having limited local permissions or you target the script against remote servers and the Agent service account doesn't have admin permissions on those servers, you'll have to grant a WMI "Remote Execute" persmission to the Agent account on each server. To assign Remote Execute, run wmimgmt.msc from the Start menu's Run box or from a command prompt, then right-click on Properties, then select the Security tab, then expand the Root node, then select the CIMV2 node, then click the Security button, then add the Agent account and scroll down to find and check the box for the "Remote Enable" permission. Simple, right? You were probably going to guess that anyway. ;)

Check disk free space including mount points.ps1

I'll point out a critical factor in the article is that you must be logged into the server with the SQL Server service account when you open the SQL Server Configuration Manager to select the certificate, if the SQL Server service account is a domain account (and it should be if you're complying with the DoD Database STIG).

Also, a community comment contains another critical element, that you have to edit the registry on each node. See the note for more info and links to the details.

Microsoft recommends non-default ports for maximum security.

Check ports in use: SELECT ServerProperty("ProcessID")
At a command prompt: "netstat -ano"

AlwaysOn Ports

• Each instance w an Availability Group (AG) must have a database mirroring endpoint, and they endpoints bust be started (query sys.database_mirroring_endpoints and sys.tcp_endpoints).
• Logins from a remote server must have CONNECT permission. Each instance must have access to ports on all partners.

Resources: Windows Firewall & SQL Server, Ports that DBAs Need to Know, and KB968872

Despite having all of the user configurable events selected, nothing will show up in the trace if you don't create custom events to feed the trace. The easiest way is to use sp_trace_generateevent in your T-SQL code, such as inside a trigger. Here's an example from inside a trigger:

EXEC sp_trace_generateevent 82, N'Trigger fired.'

You can use 82-91 as the first argument, which corresponds to UserConfigurable events 0-9, and then a unicode message (just put an N right before your single-quote delimited message).

When you use custom events like this, you'll often want to capture only the UserConfigurable events, thereby cutting out all the events you don't care about.

Recently some colleagues had failures while attempting to install SQL Server 2008 R2 on a VMware virtual Windows cluster, even though they had ensured their installation account had the 3 privileges I covered in the previous article. One of the difficulties with these types of failures is that you don't get an error saying something clear like "Sorry, you don't have the Debug Privileges permission," so it can be a little troublesome to figure out exactly which permissions are missing, if any. In this case, my colleagues were able to successfully install SQL Server after adding the "Act as part of the operating system" and "Logon as a service" permissions to the installation account. I'm going to repeat myself to emphasize they added these permissions to the installation account (the account they were logged in as while running the installer). That difference allowed their install to succeed, but if you use this remedy, remember to remove those permissions from the installation account after you finish the install.

Did they need both of those are just one of them? We don't know, they didn't uninstall and reinstall with just one of them to narrow it down. If you gain any insight on what security settings cause this problem, and whether or not only one of these permissions is needed to succeed, please let me know.