在連接字元串中設置應用程序名稱時執行 xp_cmdshell 的問題

我在 10 台左右的伺服器上有一個應用程序，它針對 MSSQL 2008 執行一些 xp_cmdshell 語句。它在所有伺服器上都可以正常工作，除了一個。更糟糕的是，我可以在 SQL Management Studio 中執行所有命令，但在應用程序中，它們不起作用。我什至製作了一個臨時應用程序進行測試，它執行良好！但在部署的應用程序中，我收到一個簡單的 SQL 錯誤“拒絕訪問”。如果我包含應用程序名稱，我已將其範圍縮小到連接字元串

Data Source={0};Initial Catalog={1};Persist Security Info=True;User ID={2};Password={3};Application Name=TheGroovyApp

只有在呼叫 xp_cmdshell 時才會拋出拒絕訪問，正常的 SQL 語句可以正常工作。但是如果我刪除應用程序名稱

Data Source={0};Initial Catalog={1};Persist Security Info=True;User ID={2};Password={3}

它適用於普通 SQL 語句和對 xp_cmdshell 的呼叫。奇怪的是，它只發生在十台伺服器中的一台上。唯一的區別是伺服器有 SP1 而其他伺服器沒有。

@@VERSION 返回

Microsoft SQL Server 2008 R2 (RTM) - 10.50.1600.1 (X64)   Apr  2 2010 15:48:46   Copyright (c) Microsoft Corporation  Standard Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1) (VM) 

我在想可以授予應用程序某種身份驗證，但我似乎找不到任何東西。我可以通過添加在 SQL Management Studio 中複製它

Application Name=TheGroovyApp

創建新查詢或更改其連接時，轉到“連接到數據庫引擎”對話框上的“附加連接參數”選項卡。

我使用的簡單測試語句是

EXEC master..xp_cmdshell 'DIR F:\SomeDirectory'

如果有人能對正在發生的事情有所了解，將不勝感激。

編輯：

好的，經過更多調查，它更加令人困惑。

如果我將應用程序名稱設置為以下 .Net 連接的預設值，它可以正常工作。

Application Name=".Net SqlClient Data Provider"

無論我使用哪種設置，我都可以毫無問題地執行 xp_subdirs

EXEC master..xp_subdirs 'F:\SomeDirectory' 

現在這是變得非常奇怪的地方。前兩個失敗，但最後一個成功，應用程序名稱設置為我的應用程序名稱。但只有當它的 xp_cmdshell 被呼叫時，xp_subdirs 才能與所有三個一起工作。

在連接集中使用應用程序名稱

EXEC master..xp_cmdshell 'DIR F:\SomeDirectory' - Fails
master..xp_cmdshell 'DIR F:\SomeDirectory' - Fails
xp_cmdshell 'DIR F:\SomeDirectory' - Works
EXEC master..xp_subdirs 'F:\SomeDirectory' - Works
master..xp_subdirs 'F:\SomeDirectory' - Works
xp_subdirs 'F:\SomeDirectory' - Works

未在連接中設置應用程序名稱

EXEC master..xp_cmdshell 'DIR F:\SomeDirectory' - Works
master..xp_cmdshell 'DIR F:\SomeDirectory' - Works
xp_cmdshell 'DIR F:\SomeDirectory' - Works
EXEC master..xp_subdirs 'F:\SomeDirectory' - Works
master..xp_subdirs 'F:\SomeDirectory' - Works
xp_subdirs 'F:\SomeDirectory' - Works

SQLMS查詢消息區失敗時返回的錯誤

Msg 10011, Level 16, State 1, Line 1
Access denied.

此錯誤消息僅發生在一台伺服器上，我無法將其複製到任何其他伺服器上。

這是在黑暗中刺傷，但在我們在伺服器上安裝 SQL Server 2008 SP2 後，問題不再出現。

與應用程序關聯的數據庫應該是可信賴的，以便訪問機器的命令行。

嘗試

select name,is_trustworthy_on from sys.databases;

如果您的目標數據庫不可信，那麼：

alter database db_name set trustworthy on;

但要注意安全性的妥協

引用自：https://dba.stackexchange.com/questions/40284