使用DefaultCredentials和DefaultNetworkCredentials

Question

我們很難判斷這些憑證對象是如何工作的。事實上，他們可能無法工作，我們預計他們如何工作。這是對當前問題的解釋。

我們有2臺服務器需要通過webservices彼此交談。第一個（我們稱之爲Server01）具有作爲NetworkService帳戶運行的Windows服務。另一個Server02具有與IIS 6.0一起運行的ReportingServices。 Server01上的Windows服務試圖使用ReportingServices WebService生成報告並通過電子郵件發送。

所以，這是我們到目前爲止所嘗試的。

在運行時設置的憑據（這工作完全正常）：

rs.Credentials = new NetworkCredentials("user", "pass", "domain"); 

現在，如果我們可以使用一個通用的用戶都將被罰款，但是......我們不允許。所以，我們試圖利用DefaultCredetials或DefaultNetworkCredentials並把它傳遞到RS web服務：

rs.Credentials = System.Net.CredentialCache.DefaultNetworkCredentials 

或者：

rs.Credentials = System.Net.CredentialCache.DefaultCredentials 

無論哪種方式將無法正常工作。我們總是從IIS獲取401 Unautrorized。現在，我們知道的是，如果我們想給訪問記錄爲網絡服務資源，我們需要將它授予DOMAIN\MachineName$（http://msdn.microsoft.com/en-us/library/ms998320.aspx）：

授予訪問遠程SQL Server

如果您正在訪問同一域（或受信任域中）的另一臺服務器上的數據庫時，網絡服務帳戶的網絡憑據將用於向數據庫進行身份驗證。網絡服務帳戶的憑證格式爲DomainName \ AspNetServer $，其中DomainName是ASP.NET服務器的域，AspNetServer是您的Web服務器名稱。

例如，如果您的ASP.NET應用程序在域CONTOSO中名爲SVR1的服務器上運行，則SQL Server會看到來自CONTOSO \ SVR1 $的數據庫訪問請求。

我們假設以與IIS相同的方式授予訪問權限可行。但是，它沒有。或者至少，有些東西沒有正確設置以便正確認證。

因此，這裏有一些問題：

1. 我們讀過有關「冒充用戶」的地方，我們需要設置這個地方在Windows服務？

2. 是否可以將對NetworkService內置帳戶的訪問權授予遠程IIS服務器？

感謝您的閱讀！

Answer 1

你需要包含在本很舊的文章中所有的細節，

http://msdn.microsoft.com/en-us/library/ms998351.aspx

總之，當你找到它混淆解決這樣的問題，你應該首先查看ASP.NET背後的技術細節小心模仿。

Answer 2

以下是您可以檢查的一些事項： - 爲報告服務設置SPN（服務主體名稱）你可以在谷歌找到很好的例子; - 允許委派（ClientCredentials.Windows.AllowImpersonationLevel）

Answer 3

問題是您無法向IIS進行身份驗證或未能向SSRS進行身份驗證？ DOMAIN \ MachineName $帳戶可能需要在SSRS中授予權限才能運行您嘗試自動執行的報告。

SSRS通常在正確配置IIS方面做得非常好，所以你不需要搞砸那些設置。我仔細檢查了我的安裝（這是SSRS 2005，SSRS 2000中的工作可能有所不同，並且您沒有說明您正在運行的是哪個版本），並將其設置爲使用Windows身份驗證並啓用了模擬。這意味着IIS應該基本上只是驗證您的憑據（驗證正確的用戶名/密碼），而不是授權（確定該用戶是否有權運行相關報告）。然後，IIS將憑據傳遞給SSRS，SSRS具有自己的設置以確定哪些帳戶有權查看報告。

此外，您可以自動直接在SSRS中按計劃發送報告，因此如果您的日程安排相當基本（即每日，每週等），則根本不需要Windows服務。