委派：從 SSRS 數據集執行批量插入失敗，但從 SSMS 成功
我已經為 SQL 伺服器引擎和 SSRS 配置了委派，它工作正常。
SQL Server (2017) 引擎和 SSRS 安裝在同一台機器上。我們稱它為 SqlSrv1。
我們應該達到的目標：使用者打開帶有數據集的報表，該數據集通過模擬連接數據庫數據和外部共享文件（帶有敏感數據）。如果使用者無權訪問共享文件，報告應向他顯示一個空的敏感列。
- 當我
BULK INSERT通過 SSMS 執行時，類似BULK INSERT #t1 FROM '\\FS1\common\anyfile.txt'它工作正常。電腦管理在“共享文件夾\會話”中將我的姓名（而不是 sqlengine 服務帳戶）顯示為使用者，將 SqlSrv1 顯示為電腦。
- 現在，當我
BULK INSERT針對本地文件（儲存在 SqlSrv1 上C:\anyfile.txt）從 SSRS 報告數據集執行時，它可以工作並且 ProcMon 在 Detail 列中顯示我的名字，而不是 ssrs 服務帳戶。- 最後，我從 SSRS 報告數據集中對共享文件執行 BULK INSERT
\\FS1\common\anyfile.txt並收到錯誤Operating system error 5(Access is denied.)，但 ProcMon 在 Detail 列中將我的名字顯示為 Impersonating。我發現了一個奇怪的東西：當我將數據集的連接字元串中的數據源更改為 時
FQDN，BULK INSERT開始從 SSRS 工作。之後，我將數據源改回NetBIOS但BULK INSERT繼續工作。到底是怎麼回事？一切都很好，但是在重新啟動 SSRS 服務後，我
Operating system error 5(Access is denied.)再次遇到錯誤。當我從步驟 1 執行查詢時，ProcMon 向我顯示路徑
\\FS1\common\\anyfile.txt（共享文件夾名稱後帶有雙斜杠！什麼？！！）而不是\\FS1\common\anyfile.txt當我收到錯誤 5 時，ProcMon 顯示
\\FS1\common\anyfile.txt（沒有雙斜杠）但是當第 3 步開始起作用時（在
FQDN操作之後），天哪！ProcMon 向我顯示\\FS1\common\\anyfile.txt（帶有雙斜杠），並且在 SSRS 服務重新啟動後，我在 ProcMon 中看到\\FS1\common\anyfile.txt（沒有雙斜杠）我嘗試將雙斜杠添加到BULK INSERT，但沒有運氣，SQL 引擎將其刪除（如預期的那樣）。你有什麼想法嗎？
預設情況下，Chrome 瀏覽器不請求帶有委託標誌的 kerberos 票證。因此，當通過 Chrome 查看報告時，我得到
作業系統錯誤 5（訪問被拒絕。）
例外，因為它就像端點的匿名使用者，而 IE 請求帶有委託標誌的 kerberos 票證。之前在 IE 中打開的報告在 Chrome 中執行良好。
請參閱Chrome 的AuthNegotiateDelegateWhitelist
我發現
klist實用程序的問題PS。路徑中的雙斜杠或單斜杠與此問題無關
我很高興我問你的最終目標是什麼。我打算在評論中回复，但它變成了太長的回复。
您最好的選擇是誠實地結束這個問題並提出一個關於“跨多個數據庫實施數據加密和混淆的最佳方法？”的新問題。包含您正在使用的每種數據系統的詳細資訊。有多種方法可以利用 SQL Server 的開箱即用功能實現客戶的需求，而無需將迂迴的解決方案組合在一起。
其中之一是Encryption另一個是Dynamic Data Masking，最後了解 SQL Server 中的正確權限都是隱藏客戶數據的標準和潛在方法，甚至對開發人員也是如此。
前面提到的所有三個以及許多其他功能都適用於您提到的系統使用的數據庫（取決於 SQL Server 版本）。