Category: Security

Scott Klein takes us through the process of enabling Always Encrypted:

Always Encrypted provides a separation between those who own the data and can view it, and those who manage the data but should have no access. Always Encrypted does this by allowing clients to encrypt sensitive data inside client applications while never revealing the encryption key to the database engine. 

One of our clients utilizes Always Encrypted to protect sensitive data. In our work for this client, we realized that a walkthrough documenting the end-to-end process of enabling Always Encrypted would be helpful for everyone.  

Click through for a walkthrough of the process.

Daniel Hutmacher shows three methods for connecting to a remote SQL Server instance on a different domain:

A jump box is a virtual desktop on the client’s domain that you can connect to using Remote Desktop. You’d obviously have to ask somebody for access to one, and you’d have to set up your development environment from scratch. This may not be a big issue if you’re in SSMS all of the time, but when you need the Power BI Desktop, Excel or even Visual Studio, this setup can take some time (not to mention asking for local admin credentials on the jump box).

A fourth option is to run the executable with runas and /netonly, like:

runas /user:domain\username ssms.exe /netonly

Kenneth Fisher answers a question:

One of the most powerful permissions available in SQL Server is control. But what exactly is it?

It’s essentially one step shy of db_owner, but that one step’s a doozy.

Jack Vamvas contrasts Kerberos and NTLM:

There is a message found in SQL Server Error Logs similar to 

The SQL Server Network Interface library could not register the Service Principal Name (SPN) [ MSSQLSvc/myserver.net:60000 ] for the SQL Server service. Windows return code: 0x200b, state: 15. Failure to register a SPN might cause integrated authentication to use NTLM instead of Kerberos. This is an informational message. Further action is only required if Kerberos authentication is required by authentication policies and if the SPN has not been manually registered.

The line I’m interested in reviewing is Failure to register a SPN might cause integrated authentication to use NTLM instead of Kerberos.   It’s good to first understand the differences between Kerberos & NTLM – both supported by SQL Server during AD authentication

Read the whole thing. It’s easy to fall into the trap of “Windows authentication = Kerberos”—I do that myself far too often.