System.Security.SecurityException beim Schreiben in das Ereignisprotokoll

Ich arbeite daran, eine ASP.NET-App von Server 2003 (und IIS6) auf Server 2008 (IIS7) zu portieren.

Wenn ich versuche, die Seite im Browser zu besuchen, erhalte ich Folgendes:

Serverfehler in '/' Anwendung.

Sicherheitsaußnahme

Beschreibung: Die Anwendung hat versucht, einen Vorgang auszuführen, der von der Sicherheitsrichtlinie nicht zugelassen wird. Um dieser Anwendung die erforderliche Berechtigung zu erteilen, wenden Sie sich bitte an Ihren Systemadministrator oder ändern Sie die Vertrauensstufe der Anwendung in der Konfigurationsdatei.

Ausnahmedetails: System.Security.SecurityException: Die Quelle wurde nicht gefunden, aber einige oder alle Ereignisprotokolle konnten nicht durchsucht werden. Unzugängliche Protokolle: Sicherheit

Quellfehler:

Während der Ausführung der aktuellen Webanforderung wurde eine nicht behandelte Ausnahme generiert. Informationen bezüglich des Ursprungs und des Ortes der Ausnahme können mithilfe des Ausnahmestapel-Trace unten identifiziert werden.

Stapelverfolgung:

[SecurityException: Die Quelle wurde nicht gefunden, aber einige oder alle Ereignisprotokolle konnten nicht durchsucht werden. Unzugängliche Protokolle: Sicherheit.]

System.Diagnostics.EventLog.FindSourceRegistration (String-Quelle, String-Maschinenname, Boolean readOnly) +562 System.Diagnostics.EventLog.SourceExists (String-Quelle, String-Maschinenname) +251

[snip]

Dies sind die Dinge, die ich getan habe, um es zu lösen:

1. Geben Sie "Jeder" die Vollzugriffsberechtigung für den Schlüssel HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog\Security. Das hat funktioniert. Aber natürlich kann ich das in der Produktion nicht machen. Nachdem ich die App einige Minuten lang ausgeführt hatte, löschte ich die Berechtigung "Jeder" und der Fehler trat erneut auf.

2. Ich habe die Quelle im Anwendungsprotokoll und im Sicherheitsprotokoll (und ich habe überprüft, ob sie über regedit vorhanden ist) während der Installation mit erhöhten Berechtigungen erstellt, aber der Fehler blieb bestehen.

3. Ich habe der App eine vollständige Vertrauensstufe in die web.configDatei gegeben (und verwendet appcmd.exe), aber ohne Erfolg.

Hat jemand einen Einblick, was hier getan werden könnte?

PS: Dies ist eine Fortsetzung dieser Frage . Ich folgte den gegebenen Antworten, aber ohne Erfolg (siehe # 2 oben).

Befolgen Sie die Anweisungen unter http://geekswithblogs.net/timh/archive/2005/10/05/56029.aspx, um die Network ServiceLeseberechtigung für den EventLog/SecuritySchlüssel zu erteilen (wie von Firenzi und royrules22 vorgeschlagen)

1. Öffnen Sie den Registrierungseditor:
   1. Wählen Sie StartdannRun
   2. Geben Sie regedt32oder einregedit

2. Navigieren Sie zu der folgenden Taste / erweitern Sie sie:

   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog\Security

3. Klicken Sie mit der rechten Maustaste auf diesen Eintrag und wählen Sie Berechtigungen

4. Fügen Sie den Network ServiceBenutzer hinzu

5. Gib ihm Leseberechtigung

UPDATE: Die obigen Schritte sind auf Entwicklercomputern in Ordnung, auf denen Sie den Bereitstellungsprozess nicht zum Installieren der Anwendung verwenden.
Wenn Sie Ihre Anwendung jedoch auf anderen Computern bereitstellen, sollten Sie während der Installation Ereignisprotokollquellen registrieren, wie in den Antworten von SailAvid und Nicole Calinoiu vorgeschlagen .

Ich verwende die PowerShell-Funktion (Aufruf von Octopus Deploy.ps1).

function Create-EventSources() {
    $eventSources = @("MySource1","MySource2" )
    foreach ($source in $eventSources) {
            if ([System.Diagnostics.EventLog]::SourceExists($source) -eq $false) {
                [System.Diagnostics.EventLog]::CreateEventSource($source, "Application")
            }
    }
}

Das Problem ist, dass EventLog.SourceExistsversucht wird, auf den EventLog\SecuritySchlüssel zuzugreifen, der nur einem Administrator gestattet ist.

Ein häufiges Beispiel für die Anmeldung eines C # -Programms EventLogist:

string sSource;
string sLog;
string sEvent;

sSource = "dotNET Sample App";
sLog = "Application";
sEvent = "Sample Event";

if (!EventLog.SourceExists(sSource))
    EventLog.CreateEventSource(sSource, sLog);

EventLog.WriteEntry(sSource, sEvent);
EventLog.WriteEntry(sSource, sEvent, EventLogEntryType.Warning, 234);

Die folgenden Zeilen schlagen jedoch fehl, wenn das Programm keine Administratorrechte besitzt und der Schlüssel nicht unter gefunden wird, EventLog\Applicationda EventLog.SourceExistsdann versucht wird, darauf zuzugreifen EventLog\Security.

if (!EventLog.SourceExists(sSource))
    EventLog.CreateEventSource(sSource, sLog);

Daher wird empfohlen, ein Installationsskript zu erstellen, das den entsprechenden Schlüssel erstellt, nämlich:

HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ EventLog \ Application \ dotNET-Beispielanwendung

Man kann dann diese beiden Zeilen entfernen.

Sie können auch eine .regDatei erstellen, um den Registrierungsschlüssel zu erstellen. Speichern Sie einfach den folgenden Text in einer Datei create.reg:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog\Application\dotNET Sample App]

Die Lösung bestand darin, dem Konto "Netzwerkdienst" die Leseberechtigung für den EventLog / Sicherheitsschlüssel zu erteilen.

Für mich hat es nur funktioniert, dem gesamten 'EventLog'- Zweig ' Lese'-Berechtigungen für 'NetworkService' zu erteilen .

Ich hatte ein sehr ähnliches Problem mit einem Konsolenprogramm, das ich unter VS2010 entwickelt habe (Upgrade von VS2008 unter XP). Mein Prog verwendet EnLib, um einige Protokollierungen durchzuführen. Der Fehler wurde ausgelöst, weil EntLib nicht berechtigt war, eine neue Ereignisquelle zu registrieren.

Also habe ich einmal meinen kompilierten Prog als Administrator gestartet : Er hat die Ereignisquelle registriert. Dann ging ich zurück und entwickelte und debuggte problemlos aus VS heraus.

(Sie können auch auf http://www.blackwasp.co.uk/EventLog_3.aspx verweisen , es hat mir geholfen

Diese Ausnahme trat bei einer .NET-Konsolen-App auf, die als geplante Aufgabe ausgeführt wurde, und ich habe versucht, im Grunde das Gleiche zu tun: eine neue Ereignisquelle erstellen und in das Ereignisprotokoll schreiben.

Am Ende hat das Festlegen der vollständigen Berechtigungen für den Benutzer, unter dem die Aufgabe ausgeführt wurde, mit den folgenden Schlüsseln den Trick für mich getan:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\eventlog\Application
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\eventlog\Security
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\eventlog

Ich versuche hier fast alles, um dieses Problem zu lösen ... Ich teile hier die Antwort, die mir hilft:

Eine andere Möglichkeit, das Problem zu beheben:

• Wechseln Sie in der IIS-Konsole zum Anwendungspool, der Ihre Site verwaltet, und notieren Sie sich die Identität, auf der sie ausgeführt wird (normalerweise Netzwerkdienst).
• Stellen Sie sicher, dass diese Identität KEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ Eventlog lesen kann (Rechtsklick, Berechtigungen).
• Ändern Sie nun die Identität dieses Anwendungspools in Lokales System, bewerben Sie sich und wechseln Sie zurück zum Netzwerkdienst

Die Anmeldeinformationen werden neu geladen und EventLog ist erreichbar

in http://geekswithblogs.net/timh/archive/2005/10/05/56029.aspx , danke Michael Freidgeim

Ich bin auf dasselbe Problem gestoßen, musste aber eine Ebene höher gehen und allen den vollständigen Zugriff auf den Schlüssel HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ EventLog \ gewähren, anstatt zur Sicherheit zu gehen, wodurch das Problem für mich behoben wurde.

Gleiches Problem unter Windows 7 64-Bit. Als Administrator ausführen hat das Problem behoben.

Ein neuer Schlüssel mit dem verwendeten Quellennamen muss unter HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ services \ eventlog \ Application in regEdit erstellt werden, wenn Sie System.Diagnostics.EventLog.WriteEntry verwenden ("SourceName", "ErrorMessage", EventLogEntryType.Error).

Grundsätzlich hat Ihr Benutzer keine Berechtigung zum Erstellen des Schlüssels. Je nach verwendetem Benutzer können Sie anhand des Identitätswerts in den erweiterten Einstellungen des Anwendungspools Folgendes tun:

1. Führen Sie RegEdit aus und wechseln Sie zu HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ services \ eventlog

2. Klicken Sie mit der rechten Maustaste in den EventLog-Schlüssel und wählen Sie die Option Berechtigungen ... aus. 3. Fügen Sie Ihrem Benutzer den vollständigen Kontrollzugriff hinzu.

   -Wenn Sie "NetworkService" verwenden, fügen Sie den Benutzer NETWORK SERVICE hinzu

   -Wenn Sie usinf "ApplicationPoolIdentity" verwenden fügen Sie IIS APPPOL {Name Ihres App-Pools} hinzu (verwenden Sie den lokalen Computerstandort, wenn Sie den Benutzer suchen).

   -Wenn Sie "LocalSystem" verwenden, stellen Sie sicher, dass der Benutzer über Administratorrechte verfügt. Es wird nicht für Sicherheitslücken empfohlen.

3. Wiederholen Sie die Schritte 1 bis 3 für HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ services \ eventlog \ Security

Zum Debuggen mit Visual Studio verwende ich "NetworkService" (es ist ein ASP.NET-Benutzer) und beim Veröffentlichen der Site "AppicationPoolIdentity".

Zu Ihrer Information ... mein Problem war, dass versehentlich "Lokaler Dienst" als Konto für Eigenschaften des ProcessInstaller anstelle von "Lokales System" ausgewählt wurde. Ich erwähne nur für alle anderen, die dem MSDN-Tutorial gefolgt sind, wie die Auswahl des lokalen Dienstes zuerst zeigt, und ich habe nicht genau aufgepasst ...

Es scheint eine offensichtliche Lösung dafür zu geben, dass ich noch keinen großen Nachteil gesehen habe, zumindest dort, wo es nicht praktikabel ist, Administratorrechte zu erhalten, um eine eigene Ereignisquelle zu erstellen: Verwenden Sie eine, die bereits vorhanden ist.

Die beiden, von denen ich angefangen habe, sie zu verwenden, sind ".Net Runtime" und "Application Error", die beide auf den meisten Computern vorhanden zu sein scheinen.

Die Hauptnachteile sind die Unfähigkeit, nach diesem Ereignis zu gruppieren, und dass Ihnen wahrscheinlich keine Ereignis-ID zugeordnet ist. Dies bedeutet, dass dem Protokolleintrag möglicherweise ein Präfix mit dem Effekt "Die Beschreibung für Ereignis-ID 0 aus Quelle .Net" vorangestellt wird Die Laufzeit kann nicht gefunden werden ... ", wenn Sie sie weglassen, aber das Protokoll eingeht und die Ausgabe im Großen und Ganzen sinnvoll erscheint.

Der resultierende Code sieht am Ende folgendermaßen aus:

EventLog.WriteEntry(
    ".Net Runtime", 
    "Some message text here, maybe an exception you want to log",
    EventLogEntryType.Error
    );

Da es immer die Möglichkeit gibt, dass Sie sich auf einem Computer befinden, auf dem diese Ereignisquellen aus irgendeinem Grund nicht vorhanden sind, möchten Sie sie wahrscheinlich try {} catch{}einpacken, falls sie fehlschlägt und die Situation verschlimmert, aber Ereignisse können jetzt gespeichert werden.

Ich arbeite nicht an IIS, aber ich habe eine Anwendung, die denselben Fehler auf einer 2K8-Box auslöst. Es funktioniert gut auf einer 2K3-Box.

Mein Vorsatz war "Als Administrator ausführen", um der Anwendung erhöhte Rechte zu gewähren, und alles funktioniert problemlos. Ich hoffe, das hilft Ihnen, in die richtige Richtung zu führen.

Windows 2008 ist Rechte / Berechtigungen / Erhöhung ist wirklich anders als Windows 2003, gar.

Hallo, ich bin auf dasselbe Problem gestoßen, als ich eine Anwendung entwickelt habe und sie auf einem Remote-PC installieren wollte. Ich habe es wie folgt behoben:

1) Gehen Sie zu Ihrer Registrierung und suchen Sie: HKLM \ System \ CurrentControlSet \ Services \ EventLog \ Application (??? YOUR_SERVICE_OR_APP_NAME ???)

Beachten Sie, dass "(??? YOUR_SERVICE_OR_APP_NAME ???)" der Name Ihres Anwendungsdienstes ist, wie Sie ihn beim Erstellen Ihrer .NET-Bereitstellung definiert haben. Wenn Sie beispielsweise Ihre neue Anwendung "Meine neue App" genannt haben, lautet der Schlüssel: HKLM \ System \ CurrentControlSet \ Services \ EventLog \ Application \ Meine neue App

Hinweis 2: Je nachdem, in welches eventLog Sie schreiben, finden Sie in Ihrer DEV-Box möglicherweise \ Application \ (wie oben angegeben) oder auch (\ System) oder (\ Security), je nachdem, in welches Ereignis Ihre Anwendung hauptsächlich schreibt , (\ Application) sollte immer in Ordnung sein.

2) Auf der Taste oben sein, Aus dem Menü; Wählen Sie "DATEI" -> "Exportieren" und speichern Sie die Datei. (Hinweis: Dadurch werden die erforderlichen Registrierungseinstellungen erstellt, wenn die Anwendung auf diesen Schlüssel zugreifen muss, um in die Ereignisanzeige zu schreiben.) Die neue Datei ist eine .REG-Datei. Nennen Sie sie aus Gründen des Arguments "Meine neue App.REG" ""

3) Wenden Sie sich bei der Bereitstellung unter PRODuction an den Systemadministrator (SA) des Servers, übergeben Sie die Datei "My New App.REG" zusammen mit der Anwendung und bitten Sie die SA, diese REG-Datei zu installieren, sobald dies (als Administrator) geschehen ist Erstellen Sie den Schlüssel für Ihre Anwendung.

4) Führen Sie Ihre Anwendung aus. Sie sollte nur auf diesen Schlüssel zugreifen müssen.

Das Problem sollte jetzt gelöst sein.

Ursache:

Wenn Sie eine Anwendung entwickeln, die etwas in das EventLog schreibt, ist ein SCHLÜSSEL in der Eventlog-Registrierung erforderlich. Wenn dieser Schlüssel nicht gefunden wird, wird versucht, ihn zu erstellen. Dies schlägt fehl, wenn Sie keine Berechtigungen dazu haben. Der oben beschriebene Vorgang ähnelt dem Bereitstellen einer Anwendung (manuell), während wir diese selbst erstellen. Sie müssen keine Kopfschmerzen haben, da Sie die Registrierung nicht optimieren, indem Sie JEDEM Berechtigungen hinzufügen, was ein Sicherheitsrisiko für Produktionsserver darstellt.

Ich hoffe, das hilft bei der Lösung.

Obwohl die Antwort des Installationsprogramms eine gute Antwort ist, ist sie beim Umgang mit Software, die Sie nicht geschrieben haben, nicht immer praktisch. Eine einfache Antwort besteht darin, das Protokoll und die Ereignisquelle mit dem PowerShell-Befehl New-EventLog ( http://technet.microsoft.com/en-us/library/hh849768.aspx ) zu erstellen.

Führen Sie PowerShell als Administrator aus und führen Sie den folgenden Befehl aus, indem Sie den Protokollnamen und die Quelle ändern, die Sie benötigen.

New-EventLog -LogName Application -Source TFSAggregator

Ich habe es verwendet, um die Ereignisprotokollausnahme zu lösen, wenn Aggregator ein Problem mit Codeplex ausführt.

Hatte ein ähnliches Problem mit allen unseren 2008-Servern. Das Sicherheitsprotokoll funktionierte aufgrund eines Gruppenrichtlinienobjekts, bei dem die Gruppe Authentifizierte Benutzer und Leseberechtigung vom Schlüssel entfernt wurden, nicht mehrHKLM\System\CurrentControlSet\Services\EventLog\security

Durch Zurücksetzen gemäß der Empfehlung von Microsoft wurde das Problem behoben. Ich vermute, dass es Ihr Problem auch behebt, wenn alle authentifizierten Benutzer auf einer höheren Ebene gelesen werden.

Ich bin auf ein ähnliches Problem gestoßen - in meinem Fall Quelle enthalten <, >Zeichen. 64-Bit-Maschinen verwenden eine neue gerade log-xml-Basis, würde ich sagen, und diese Zeichen (aus Zeichenfolge festgelegt) erzeugen ungültige XML-Dateien, die Ausnahmen verursachen. Möglicherweise sollte dies ein Microsoft-Problem sein - die Quelle (Name / Zeichenfolge) wird nicht korrekt behandelt.

Die Lösung ist sehr einfach: Führen Sie Visual Studio Application im Admin-Modus aus!

Meine App wird auf Client-Webservern installiert. Anstatt mit den Netzwerkdienstberechtigungen und der Registrierung herumzuspielen, habe ich mich dafür entschieden, mein Installationsprogramm zu überprüfen SourceExistsund auszuführen CreateEventSource.

Ich habe log.source = "xx"der App auch einen Versuch / Fang hinzugefügt , um sie auf eine bekannte Quelle zu setzen, wenn meine Ereignisquelle nicht erstellt wurde (dies würde nur angezeigt, wenn ich eine DLL im laufenden Betrieb ausgetauscht hätte, anstatt sie erneut zu installieren).

versuchen Sie es unten in web.config

 <system.web>

<trust level="Full"/>

</system.web>

Ich hatte dieses Problem beim Ausführen einer App in VS. Ich musste das Programm nur einmal als Administrator ausführen und dann von VS aus ausführen.

Um als Administrator ausgeführt zu werden, navigieren Sie einfach zu Ihrem Debug-Ordner im Windows Explorer. Klicken Sie mit der rechten Maustaste auf das Programm und wählen Sie Als Administrator ausführen.

Der Wiederaufbau der Lösung hat bei mir funktioniert