Flush Authentication Cache: Who Can Run DBCC FLUSHAUTHCACHE

To flush authentication cache entries for one database, run DBCC FLUSHAUTHCACHE inside that database. The command empties the cache of logins and firewall rules that a database keeps. A local SQL Server accepts it, so the syntax and the permission check can be tested there. The cache effect cannot.

What the Command Does

In Azure SQL Database, each user database keeps a cache of authentication data. It holds login details, firewall rules and, for directory accounts, group memberships. In Azure SQL Database, resetting a password does not unauthenticate a connection that is already open. To flush authentication cache entries, run the command. The cache empties at once, and the next sign in reads fresh data.

The syntax takes no arguments. It works on the current user database only. Run it once in every database you care about. It does not apply to the logical master database in Azure. The first demo check confirms the no-argument rule on SQL Server 2025. A WITH option is rejected.

USE master;
GO
IF DB_ID(N'FlushAuthDemo') IS NULL CREATE DATABASE FlushAuthDemo;
GO
USE FlushAuthDemo;
GO
DBCC FLUSHAUTHCACHE;
GO
DBCC FLUSHAUTHCACHE WITH NO_INFOMSGS;

DBCC execution completed. If DBCC printed error messages, contact your system administrator.
Msg 2532, Level 16, State 1, Line 1
One or more WITH options specified are not valid for this command.

The plain command succeeds and prints the standard DBCC line. The version with an option fails with message 2532. Plan your scripts around the bare statement.

Who Can Run It

Few callers can flush authentication cache entries. Azure documents the permission as KILL DATABASE CONNECTION, or the admin account. A local SQL Server has no such database permission, and the demo shows what it says. Then it tries the command as three kinds of caller: a sysadmin, a plain database user and a database owner. The two users are tied to throwaway logins. The passwords are placeholders, and each login is disabled at once. The cleanup drops them.

USE master;
GO
CREATE LOGIN FlushAuthReader WITH PASSWORD = N'ReplaceWithYourOwnPassword1!', CHECK_POLICY = OFF;
ALTER LOGIN FlushAuthReader DISABLE;
CREATE LOGIN FlushAuthOwner WITH PASSWORD = N'ReplaceWithYourOwnPassword1!', CHECK_POLICY = OFF;
ALTER LOGIN FlushAuthOwner DISABLE;
GO
USE FlushAuthDemo;
GO
CREATE USER FlushAuthReader FOR LOGIN FlushAuthReader;
CREATE USER FlushAuthOwner FOR LOGIN FlushAuthOwner;
ALTER ROLE db_owner ADD MEMBER FlushAuthOwner;
GO
GRANT KILL DATABASE CONNECTION TO FlushAuthReader;

Msg 4630, Level 16, State 1, Line 1
The permission 'KILL DATABASE CONNECTION' is not supported in this version of SQL Server. Alternatively, use the server level 'ALTER ANY CONNECTION' permission.

Now the test. Each call sits in a TRY block, so the outcome lands in a small table. The two impersonated callers need REVERT afterward.

DECLARE @r TABLE (Caller nvarchar(30), Outcome nvarchar(60));
BEGIN TRY
    DBCC FLUSHAUTHCACHE;
    INSERT INTO @r VALUES (N'Sysadmin', N'ran');
END TRY
BEGIN CATCH
    INSERT INTO @r VALUES (N'Sysadmin', CONCAT(N'Msg ', ERROR_NUMBER()));
END CATCH;
EXECUTE AS USER = N'FlushAuthReader';
BEGIN TRY
    DBCC FLUSHAUTHCACHE;
    INSERT INTO @r VALUES (N'Plain user', N'ran');
END TRY
BEGIN CATCH
    INSERT INTO @r VALUES (N'Plain user', CONCAT(N'Msg ', ERROR_NUMBER()));
END CATCH;
REVERT;
EXECUTE AS USER = N'FlushAuthOwner';
BEGIN TRY
    DBCC FLUSHAUTHCACHE;
    INSERT INTO @r VALUES (N'Database owner', N'ran');
END TRY
BEGIN CATCH
    INSERT INTO @r VALUES (N'Database owner', CONCAT(N'Msg ', ERROR_NUMBER()));
END CATCH;
REVERT;
SELECT Caller, Outcome FROM @r;

Message 2571 says the user does not have permission to run the command. Even a member of db_owner is refused on SQL Server 2025. A login that held only the server permission ALTER ANY CONNECTION was refused too. So was a login with CONTROL SERVER and ALTER ANY CONNECTION. In these tests only a sysadmin succeeded. In Azure SQL Database, give the work to the admin account or to a user with the documented permission.

What It Does to Open Sessions

On SQL Server 2025 the command ran but ended no session. A session that waited 25 seconds in the demo database finished normally after a flush from a second window. Run the wait in window 1 and the flush in window 2.

-- Window 1
USE FlushAuthDemo;
WAITFOR DELAY '00:00:25';
SELECT N'finished normally' AS Result;

-- Window 2, during the wait
USE FlushAuthDemo;
DBCC FLUSHAUTHCACHE;

The session kept its session id and its login time, and its later statements ran. The same held for a session that signed in with a SQL Server login.

In Azure SQL Database the documented effect is that open connections check their credentials again against the emptied cache. A connection whose credentials are still valid carries on, and one whose credentials are gone fails at that check. This post did not run it on Azure.

So on SQL Server 2025 a flush alone does not log anyone out. To see who is connected to the database, list the user sessions. The list holds your own session in the demo, and every other open connection on a real server.

SELECT session_id, login_name, status FROM sys.dm_exec_sessions WHERE database_id = DB_ID() AND is_user_process = 1;

To end sessions at once, use KILL, as in DBCC FLUSHAUTHCACHE: Force Azure SQL to Re-authenticate. That post tests what a password change does to open sessions.

When to Use It in Azure

Reach for the command after a change that must apply to new sign-ins at once. A changed firewall rule, a removed user or a changed password are examples. In a database that uses directory accounts, the command also clears the cached group memberships. Run it in each affected user database. These steps are documented for Azure SQL Database and were not run there.

Use a safe order for a security change. Make the change first. Then flush in each affected user database. Then list the sessions of the affected login and end them with KILL. Finally, sign in again as that login to confirm. The order matters, because a flush before the change would only reload the old data.

You could argue that waiting is fine, because a change reaches every connection in the end. For a routine change that is true. For a leaked password it is too slow.

What to Remember

To flush authentication cache entries, run DBCC FLUSHAUTHCACHE with no options in the user database. It needs admin rights, and on SQL Server 2025 it does not end a session. Azure documents that it skips the logical master database. Pair it with KILL when open connections must go. Remove the demo objects when you finish.

USE master;
GO
DROP LOGIN FlushAuthReader;
DROP LOGIN FlushAuthOwner;
ALTER DATABASE FlushAuthDemo SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
DROP DATABASE FlushAuthDemo;

A flushed cache is not a closed door, it is a lock that rechecks the next key.

Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.