SQL Server 2025 PBKDF2 login performance regression with Microsoft Access/ACE – supported mitigation?

Question

SQL Server 2025 PBKDF2 login performance regression with Microsoft Access/ACE – supported mitigation?

devswick 5

We have reproduced a significant SQL Authentication performance regression after migrating an on-premises Microsoft Access application from SQL Server 2022 to SQL Server 2025.

Environment

SQL Server 2025 Express CU9, 17.0.5005.3
Windows Server 2022
Compatibility level 170
Microsoft Access frontend with ODBC linked tables
Microsoft ODBC Driver 18 for SQL Server
SQL Authentication

The Access application was responsive on SQL Server 2022. After moving to SQL Server 2025, many operations showed a noticeable “warm-up” delay.

We traced the application with Extended Events and ODBC tracing. Microsoft Access/ACE creates multiple short-lived physical SQL connections for some linked-table operations. These connections were not effectively reused from the ODBC pool (is_cached = false, different ClientConnectionID values).

We then measured SQL login performance independently from Access.

With PasswordHashAlgorithm = 3 / SQL Server 2025 PBKDF2:

Average new non-pooled connection: ~202 ms
Minimum: ~192 ms
Maximum: ~248 ms

ODBC connection pooling itself works correctly:

First ODBC connection: ~249 ms
Subsequent pooled connections: ~0.03–0.10 ms

We then enabled: DBCC TRACEON (4671, -1) and reset the SQL login password.

On SQL Server 2025 CU9 the login then used: PasswordHashAlgorithm = 2

Connection performance changed to:

First connection: ~39 ms
Subsequent non-pooled connections: ~1.3–2.0 ms
Average over 20 connections: ~3.4 ms

The Microsoft Access application immediately returned to approximately the same responsiveness as it had on SQL Server 2022.

When TF 4671 was disabled again, the login returned to algorithm 3 and the performance regression returned. Re-enabling TF 4671 and resetting the password restored algorithm 2 and the former performance.

Microsoft documents PBKDF2 login overhead as a known SQL Server 2025 issue, especially without effective connection pooling. However, the official trace flag documentation describes TF 4671 only for SQL Server 2022, where it enables version 3 password verifiers.

My questions are:

Is the observed SQL Server 2025 behavior of TF 4671 intentional?
Is -T4671 supported as a production workaround to disable PBKDF2 on SQL Server 2025?
If not, is there any supported way to use version 2 SQL Authentication password verifiers on SQL Server 2025?
Is Microsoft planning a supported mitigation for applications such as Microsoft Access/ACE that create multiple short-lived SQL-authenticated connections?
Is this TF 4671 behavior expected to remain stable across future SQL Server 2025 cumulative updates?

0 comments

1 answer

Your answer

Answer 1

Erland Sommarskog 137.6K MVP Volunteer Moderator

TF4671 does indeed have the reverse behaviour on SQL 2025 than it has on SQL 2022. That is, on SQL 2022 it turns on the feature, and on SQL 2025 it turns off the feature. I really hope that Microsoft addresses this, and change the behaviour of the trace flag in SQL 2025. The current arrangement means that security-aware sites that upgrade from SQL 2022 to SQL 2025 get degraded security when they retain the trace flag. (Which they are likely to do if they perform an in-place upgrade.)

I don't know much about Access/ACE, but surely it must support Windows authentication for linked tables?

devswick 5 Reputation points

2026-09-23T21:57:04.1233333+00:00
Thanks for confirming the reversed behaviour of TF4671 on SQL Server 2025. I agree that this is rather concerning for in-place upgrades, especially if an existing -T4671 startup parameter is carried over unnoticed.

Yes, Access/ACE does support Windows Authentication for linked tables. However, it is not a viable solution for this particular application.

The application has its own login system, and the same Windows user must be able to log into the application using different application/SQL users. These SQL logins are also intentionally used as the SQL Server identity; server-side logic relies on SUSER_SNAME() for user-specific filtering and permissions.

With Windows Authentication, SQL Server would always see the Windows account running Access, regardless of which user logged into the application. Changing that architecture would require a substantial redesign, for example by introducing a separate application-user context on every SQL connection. With Access/ACE creating and managing multiple linked-table connections internally, that would be particularly difficult to guarantee reliably.

For that reason, SQL Authentication is a requirement for this application.

What makes the issue particularly noticeable is the measured difference:

Password hash algorithm 3: ~202 ms per new non-pooled SQL connection

Password hash algorithm 2: ~1–2 ms after the initial connection

With TF4671 enabled on SQL Server 2025 CU9 and the login password reset, the login changes to algorithm 2 and the Access application immediately returns to approximately the same responsiveness it had with SQL Server 2022.

So the main question for me remains: Is there any supported way on SQL Server 2025 to use SQL Authentication without the PBKDF2/version 3 verifier, or is TF4671 currently the only available workaround?

And if TF4671 is not intended as a supported SQL Server 2025 configuration, is Microsoft planning to provide a documented alternative for applications that create many short-lived SQL-authenticated connections?
Erland Sommarskog 137.6K Reputation points MVP Volunteer Moderator

2026-09-24T08:15:02.26+00:00

TF4671 is currently the only viable workaround. As I said, I hope that Microsoft will change the behaviour of that trace flag. I don't know if they have plans to introduce a new trace flag.

I would consider opening a support case with regards to Access, and ask why they don't use connection pooling.

Overall, making many connections for short requests is bad not only in this situation, but also where you have a big latency, for instance when connecting to the cloud.