Press "Enter" to skip to content

Category: Security

Kerberos Error: It’s Always SPNs

Mike Lynn shares a story:

We were setting up a brand-new SQL Server 2022 instance and couldn’t connect remotely using valid Windows credentials. Every attempt gave us the same error: “Login is from an untrusted domain and cannot be used with Windows authentication.” The client only has one domain. Permissions and firewalls checked out. Local connections with domain accounts worked fine. So why was the server rejecting us from every remote machine, no matter how we connected? The answer turned out to be a change in Windows Server 2025 that more and more DBAs are going to run into.

My advice for every DBA is as follows: make sure you have at least a rudimentary understanding of SPNs, including what they are, what can go wrong when they aren’t set correctly, what “set correctly” even means, and how to set them. You don’t need to be an expert on Kerberos, but I think you do need to be a technician who can note a specific error code and troubleshoot the issue from there.

If you ever had to deal with SSRS or SSIS double-hop issues, you’ve likely already dealt with SPNs in some fashion. Just bite the bullet and spend a few hours boning up on the topic.

Leave a Comment

Linked Servers in SQL Server 2025 and Strict TLS

Rebecca Lewis notes a common failure point:

If you upgrade to SQL Server 2025 and your linked servers stop working, you are not alone. This is the single most common post-upgrade failure I am seeing right now, and it hits almost every environment that has linked servers configured from an older version. SQLNCLI is gone. The replacement driver has different defaults. Your connections will fail unless you explicitly tell them how to encrypt.

Read on for the correct solution, the mostly-correct solution, and the solution that a lot of people will take but will probably burn them in a few years.

Leave a Comment

Tips on a Post-NTLM Future

Rebecca Lewis wants to save you later heartache:

‘Informational message’ and ‘Further action is only required if Kerberos authentication is required’… For years, we could ignore this, but not anymore. Microsoft published a three-phase roadmap on January 28, 2026 to disable NTLM by default in upcoming Windows releases — and phase one is already live. That ‘informational message’ is about to become an action-item.

In most environments I audit, somewhere between 40 and 60 percent of Windows Authentication connections to SQL Server are running on NTLM — and nobody knew until we looked. If you have not checked yours, now is the time.

Read on to learn how you can check this, the kinds of problems that can prevent Kerberos authentication, and how you can fix them.

Leave a Comment

Farewell, Purview Access Policies

Andreas Wolter gives us the behind-the-scenes view of things:

SQL Server 2025 was released at the end of last year. While most attention has gone to new features, this release also discontinued several existing ones—a notable first in recent SQL Server versions.

The full list is available here: Discontinued services and deprecated features

One item deserves particular attention: Purview access policies.

Read on to learn the intent behind this, the struggle that led to using Purview instead of Azure RBAC, and why there isn’t a solid alternative currently available.

Leave a Comment

Interoperability and OneLake Security

Aaron Merrill introduces a new whitepaper:

In our whitepaper, The future of data security is interoperability, we make the case for a different data foundation: interoperable security that’s defined once and enforced everywhere your data is used. Using OneLake security as the lens, it walks through the core concepts and architectural choices behind centralized policy definition with distributed, engine-level enforcement, and explores how fine-grained access controls and enterprise governance fit into a multi-engine world.   

Click through for Aaron’s summary and check out the link for the whitepaper itself, in PDF format.

Comments closed

Mirroring to OneLake without Public Internet Access

Paul Hernandez builds a (virtual) network:

Mirroring has been a transformative technology for data integrations tasks since the early Microsoft Fabric days. Moreover, this feature has been called “pain killer as a service” in community posts. In many projects, data sources to be mirrored are behind private networking and for security reasons they are not accessible using public internet. If you want to mirror, for example, an Azure SQL database, you’ll need a data gateway. According to the official docs: “If your Azure SQL Database is not publicly accessible and doesn’t allow Azure services to connect to it, you can set up virtual network data gateway or on-premises data gateway to mirror the data”.

In this post I’ll show you step-by-step how to set up connectivity to be able to use mirroring when Azure SQL allows only private access.

There are several steps involved, but the end result is worth it compared to not having the data at all or needing to make it accessible over the Internet.

Comments closed

SQL vs Azure Permissions

Rebecca Lewis continues a series on how Azure permissions and SQL Server (or Azure SQL Database) permissions are not the same thing:

Welcome to cloud permissions, where ‘Contributor’ doesn’t mean you can contribute and ‘Reader’ doesn’t mean you can read.

In my last post, I explained the management plane vs data plane split. This post is the promised follow-up for the minimum permission combinations for common DBA tasks. aka, what you need, how to verify it, and how to fix it when it fails.

I’m the guy pushing up my no-longer-existent glasses and saying “Well, actually…” to the first sentence, though stylistically, it’s a good one. But getting past the first sentence, there are some nice breakdowns of what it takes to do what you need to do on a cloud-hosted database.

2 Comments

SIDs and Distributed Availability Groups

Evan Corbett troubleshoots an issue:

After building a contained availability group in SQL Server, a customer was experiencing intermittent issues connecting to their primary database. Our investigation revealed that the SQL Authentication login being used had been created both within the context of the contained AG as well as directly on the primary node but had different SIDs in each location.  

This is a pretty common issue when using SQL authentication, and it always seems to bite at the least opportune times.

Comments closed

Local Admin and SQL Server

Rebecca Lewis follows Betteridge’s Law of Headlines:

“Does a DBA need local administrator membership to manage SQL Server?”

The answer is simple: Local admin group membership is not required. In fact, best practices dictate that Database Administrators (DBAs) and SQL service accounts should not have local administrator rights on the host server.  This change was introduced as far back as SQL Server 2008 with a ‘secure by design, secure by default, and secure in deployment’ strategy.

Read on for the caveat of what happens when you don’t provide local admin access to your DBAs.

Comments closed

Management Plane and Data Plane Permissions

Rebecca Lewis continues a series on cloud data platform security:

My last post ended with a promise to explain the management plane vs. data plane split in practical terms. The short story? There are two separate permission systems — one for managing resources, one for accessing data — and they don’t talk to each other. The good news: you already understand this model. You just don’t recognize it yet.

Click through for the explanation and a simile involving SQL Server’s security model.

Comments closed