By default, SQL Server restricts the use of xp_cmdshell to members of the sysadmin fixed server role. This is a vital security guardrail because xp_cmdshell allows the execution of Windows operating system commands directly from the database engine.

However, in enterprise environments, there is often a legitimate business need to allow low-privileged service accounts or specific application users to execute command-line operations—such as monitoring disk space using EXEC master..sp_fixeddrives or checking system directory structures—without granting them full, dangerous administrative control over the entire SQL Server instance.

In this guide, we will walk through the secure architecture for granting xp_cmdshell access to non-sysadmin users, explain how SQL Server handles security delegation under the hood, and troubleshoot the most common credential-desync blocker: LogonUserW Error 1326.

📌 1. The Security Problem: Why Standard Users Cannot Run xp_cmdshell

When a non-sysadmin user attempts to execute xp_cmdshell or any system procedure that relies on it (such as sp_fixeddrives), SQL Server blocks the execution with the following security exception by default:

Msg 15121, Level 16, State 10, Procedure xp_cmdshell, Line 1
An error occurred during the execution of xp_cmdshell. A call to 'CreateProcess' failed with error code: '5' (Access is denied.).

The Security Delegation Layout

SQL Server enforces strict security delegation depending on who runs the command:

1. When run by a sysadmin: SQL Server executes the OS command under the security context of the SQL Server Database Engine Service Account (e.g., NT SERVICE\MSSQLSERVER or a highly privileged Domain Service Account).

2. When run by a non-sysadmin: It is a critical security risk to let standard users inherit the service account's OS permissions. To prevent this, SQL Server requires the configuration of an unprivileged Windows proxy account. This proxy account acts as a security sandbox.

🚀 2. Step-by-Step Guide: Granting Safe Access to Non-Sysadmins

To safely grant a standard database user access to xp_cmdshell, you must follow a three-step configuration process. These steps must be performed by a sysadmin account.

Step 1: Create a Low-Privileged Windows Account

First, work with your Windows Infrastructure / Active Directory team to create a dedicated local or domain user account.

• Account Name Example: YOURDOMAIN\sql_xp_proxy

• Security Principle: This account must be a standard user with highly restricted access. It should only have read/write access to the specific network paths or directories required for its tasks. It must not be an administrator.

Step 2: Grant Execution Permission in SQL Server

Next, grant your low-privileged SQL Server database login the permission to execute the xp_cmdshell extended stored procedure:

USE [master];
GO

-- Grant EXECUTE permission to your specific non-sysadmin SQL login
GRANT EXECUTE ON xp_cmdshell TO [YourNonSysadminUser];
GO

Additionally, you can add these commands to be more specific about what privilledge to be allowed.

CREATE ROLE [YourNewRoles];
GRANT EXECUTE ON xp_fileexist TO [YourNewRoles];
GRANT EXECUTE ON xp_cmdshell TO [YourNewRoles];
GRANT EXECUTE ON xp_create_subdir TO [YourNewRoles];
GRANT EXECUTE ON xp_fixeddrives TO [YourNewRoles];

ALTER ROLE [YourNewRoles]ADD MEMBER [YourNonSysadminUser]

Step 3: Configure the Credential Proxy Account

To prevent the "Access is Denied" error, you must register the unprivileged Windows account (created in Step 1) as the SQL Server command shell proxy. This is done by creating a credential named ##xp_cmdshell_proxy_account##:

USE [master];
GO

-- Establish the unprivileged proxy credentials

EXEC sp_xp_cmdshell_proxy_account NULL; -- Removes existing proxy account
EXEC sp_xp_cmdshell_proxy_account 'YOURDOMAIN\sql_xp_proxy', 'P@YourSecuredPassword123'; 

GO

Once this proxy credential is established, any non-sysadmin running xp_cmdshell will execute commands safely within the OS-level sandbox of YOURDOMAIN\sql_xp_proxy.;

🔍 3. Troubleshooting the Common Blocker: LogonUserW Error 1326

After setting up the permissions, your standard user might execute the query and receive this verbose authentication failure:

[ERROR] MESSAGE: [Microsoft][ODBC Driver 17 for SQL Server][SQL Server]An error occurred during the execution of xp_cmdshell. A call to 'LogonUserW' failed with error code: '1326'. Query: EXEC MASTER..sp_fixeddrives;

Technical Analysis of Error 1326

When the non-sysadmin user triggers xp_cmdshell, SQL Server calls the Windows API function LogonUserW to authenticate the proxy credentials stored in ##xp_cmdshell_proxy_account##.

In the Windows operating system, error code 1326 stands for ERROR_LOGON_FAILURE (Logon failure: unknown user name or bad password). This means SQL Server holds outdated credentials for the proxy account. This typically happens when:

• The Active Directory password for YOURDOMAIN\sql_xp_proxy was recently rotated or changed.

• The Windows account has been disabled, locked out, or set to expire.

Resolving the Credential Desync

To resolve Error 1326 and restore service access:

1. Verify Windows Status: Ensure the Windows account YOURDOMAIN\sql_xp_proxy is Enabled, not locked out, and has its password set to "Password never expires".

2. Update SQL Server Credentials: Run the update command using a sysadmin account to sync the new password:

USE [master];
GO

-- Re-sync the proxy credential with the actual current Windows password
EXEC sp_xp_cmdshell_proxy_by_credential 
    @credential_identity = 'YOURDOMAIN\sql_xp_proxy', 
    @credential_password = 'TheNewActiveDirectoryPassword!';
GO

Once updated, the standard user can execute EXEC master..sp_fixeddrives or xp_cmdshell seamlessly, running OS commands safely without compromising SQL Server administration.

💡 Key Takeaways for DBAs

• The Least Privilege Path: Never elevate a business user or monitoring account to sysadmin just to let them run OS scripts. Always use the GRANT EXECUTE + ##xp_cmdshell_proxy_account## configuration.

• Password Rotation Plans: Include SQL Server credentials in your Active Directory password rotation protocols to prevent unexpected 1326 operational failures.