28

Es fällt uns schwer zu ermitteln, wie diese Berechtigungsnachweisobjekte funktionieren. In der Tat funktionieren sie möglicherweise nicht so, wie wir es von ihnen erwartet haben. Hier ist eine Erklärung des aktuellen Problems.Verwenden von DefaultCredentials und DefaultNetworkCredentials

Wir haben 2 Server, die über Webservices miteinander kommunizieren müssen. Der erste (wir nennen ihn Server01) hat einen Windows-Dienst, der als NetworkService-Konto ausgeführt wird. Die andere Server02 hat ReportingServices mit IIS 6.0 ausgeführt. Der Windows-Dienst unter Server01 versucht, den ReportingServices WebService 10 zu verwenden, um Berichte zu generieren und sie per E-Mail zu senden.

Also, hier ist, was wir bisher versucht haben.

die Anmeldeinformationen zur Laufzeit einstellen (Das funktioniert völlig in Ordnung):

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

Wenn wir nun einen generischen Benutzer verwenden könnten alles wäre in Ordnung, aber ... wir sind nicht erlaubt. Also, versuchen wir, die DefaultCredetials oder DefaultNetworkCredentials zu verwenden und an die RS Webservice übergeben:

rs.Credentials = System.Net.CredentialCache.DefaultNetworkCredentials 

Oder:

rs.Credentials = System.Net.CredentialCache.DefaultCredentials 

In beiden Fällen wird nicht funktionieren. Wir bekommen immer 401 Unautorrorized von IIS. Nun, was wir wissen, ist, dass, wenn wir Zugriff auf eine Ressource als Netzwerk angemeldet geben wollen, müssen wir es DOMAIN\MachineName$ (http://msdn.microsoft.com/en-us/library/ms998320.aspx) gewähren:

Gewähren von Zugriff auf einen Remote-SQL Server

Wenn Sie Wenn Sie auf eine Datenbank auf einem anderen Server in derselben Domäne (oder in einer vertrauenswürdigen Domäne) zugreifen, werden die Netzwerkanmeldeinformationen des Netzwerkdienstkontos zur Authentifizierung bei der Datenbank verwendet. Die Anmeldeinformationen des Netzwerkdienstkontos haben die Form Domänenname \ AspNetServer $, wobei Domänenname die Domäne des ASP.NET-Servers und AspNetServer der Name Ihres Webservers ist.

Wenn Ihre ASP.NET-Anwendung beispielsweise auf einem Server namens SVR1 in der Domäne CONTOSO ausgeführt wird, sieht der SQL Server eine Datenbankzugriffsanforderung von CONTOSO \ SVR1 $.

Wir gingen davon aus, dass das Gewähren von Zugriff auf dieselbe Weise mit IIS funktionieren würde. Allerdings nicht. Oder zumindest ist etwas nicht richtig eingestellt, um es richtig zu authentifizieren.

So, hier sind einige Fragen:

  1. Wir haben gelesen über "Impersonating Benutzer" irgendwo, tun wir das irgendwo in der Windows Service setzen müssen?

  2. Ist es möglich, einem Remote-IIS-Server Zugriff auf das integrierte NetworkService-Konto zu gewähren?

Danke fürs Lesen!

Antwort

8

Alle Details, die Sie brauchen, sind in dieser sehr alten Artikel enthalten,

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

Kurz gesagt, wenn Sie es verwirrend zu beheben Fragen wie diese finden, sollten Sie zunächst die technischen Details hinter ASP.NET überprüfen Identitätswechsel sorgfältig.

+0

Hervorragender Link: D – omglolbah

+1

Wäre schön gewesen, die tatsächliche Antwort auf die Frage in aller Kürze (wenn möglich) zu schreiben, anstatt den Link zum 2-Stunden-Artikel in der MSDN zu setzen, und anderen die Schuld nicht zu lesen es :) –

+0

@ d.popov Das ist wirklich eine Herausforderung für mich, die Kernpunkte zusammenzufassen. Sie können es selbst versuchen, wenn Sie daran interessiert sind. Ich muss sagen, die tatsächliche Antwort auf die Frage wird nicht kürzer sein als dieser Artikel. –

0

Hier sind einige Dinge, die Sie überprüfen können: - Legen Sie einen SPN (Service Principal Name) für den Reporting Service fest; Sie können gute Beispiele in Google finden; - Delegierung zulassen (ClientCredentials.Windows.AllowImpersonationLevel)

0

Ist das Problem, dass Sie sich bei IIS nicht authentifizieren können oder die Authentifizierung bei SSRS fehlgeschlagen ist? Dem Konto DOMAIN \ MachineName $ muss möglicherweise die Berechtigung in SSRS erteilt werden, um den Bericht auszuführen, den Sie zu automatisieren versuchen.

SSRS macht normalerweise eine ziemlich gute Arbeit, IIS richtig zu konfigurieren, also sollten Sie sich nicht mit diesen Einstellungen anlegen. Ich habe meine Installation doppelt überprüft (SSRS 2005, die Dinge haben in SSRS 2000 möglicherweise anders funktioniert und Sie haben nicht gesagt, welche Version Sie ausführen), und sie ist auf die Windows-Authentifizierung eingestellt und der Identitätswechsel ist aktiviert. Das bedeutet, dass IIS im Grunde nur Ihre Anmeldeinformationen authentifizieren sollte (Überprüfung eines korrekten Benutzernamens/Kennworts), nicht autorisiert (bestimmt, ob dieser Benutzer berechtigt ist, den fraglichen Bericht auszuführen). IIS übergibt dann die Anmeldeinformationen an SSRS, die über eigene Einstellungen verfügt, um festzulegen, welche Konten berechtigt sind, Berichte anzuzeigen.

Sie können Berichte auch automatisch in SSRS senden, sodass Sie den Windows-Dienst überhaupt nicht benötigen, wenn Ihre Planung ziemlich einfach ist (d. H. Täglich, wöchentlich usw.).

Verwandte Themen