Category: Security

Deepthi Goguri covers the real value of gMSA accounts:

A Failover Cluster Instance (FCI) is a SQL Server high-availability solution where multiple servers share the same storage. If the active node fails, SQL Server automatically fails over to another node with minimal downtime.

You need to follow all the steps mentioned in the first blog post, which you can find here.

From there, Deepthi covers how to change the SQL Server service account to use a gMSA if you have FCI or other high availability setups for SQL Server.

Rebecca Lewis notes the slowdown:

You upgraded to SQL Server 2025. Your SQL auth logins are slower. This is not a bug. Microsoft did this on purpose — which is actually good news, but if you’re not using connection pooling, it’s not going to feel very good.

Read on for more details, as well as a recommendation for connection pooling. On the whole, this is a very good thing—PBKDF2 is a mature process that we’ve had available to use in applications for 15+ years, and what’s particularly neat about it is that the level of effort scales linearly. As computer hardware becomes more powerful, add more iterations of the hashing algorithm to keep a fairly consistent per-login delay.

Deepthi Goguri takes advantage of Group Managed Service Accounts in Windows:

A Service Account is something that applications like the SQL Server, IIS, or scheduled tasks need to run under using Microsoft Active Directory. These are the regular domain user accounts, where the passwords needs to be manually managed and rotated. As these needs to be manually updated, downtime to the services are required if the password needs to be changed. Not only that but syncing these passwords across multiple servers can be an issue. This problem is resolved by using the Standalone Managed Service Account as Windows can manage the password automatically.

Read on to learn more about single MSAs and group MSAs, and some tips and limitations.

Vibhor Kumar releases an extension:

This extension provides transparent column-level encryption using custom PostgreSQL datatypes so developers can read and write encrypted columns without changing their SQL queries.

And perhaps the most human part of this project is this:

the idea for this project started back in 2016.

It stayed with me for years as one of those engineering ideas that never quite leaves your mind — the thought that PostgreSQL itself could enforce encryption at the column level.

The diagram does look a bit like what you’d see for SQL Server’s Transparent Data Encryption, though the internal mechanics are a good bit different.

John Sterrett provides a reminder:

SQL Server Dynamic Data Masking (DDM) is one of those SQL Server features that is commonly misused as a primary security feature used in production. Since it landed in SQL Server 2016, I’ve seen teams throw it at compliance requirements and call it a day, only to find out later that their “masked” data was completely readable by anyone willing to spend 20 minutes in SSMS.

Let me show you some data masking limitations in SQL Server when used for security, and what you should be doing instead (or alongside it) if you’re serious about Zero Trust data security.

I think John is a bit kinder to the value of Dynamic Data Masking than I am. Even so, this article shows several major problems it brings to the fore.