System.Security.SecurityException podczas zapisywania do dziennika zdarzeń

Pracuję nad próbą przeniesienia aplikacji ASP.NET z Server 2003 (i IIS6) na Server 2008 (IIS7).

Kiedy próbuję odwiedzić stronę w przeglądarce, otrzymuję to:

Błąd serwera w aplikacji „/”.

Wyjątek bezpieczeństwa

Opis: Aplikacja próbowała wykonać operację niedozwoloną przez zasady zabezpieczeń. Aby przyznać tej aplikacji wymagane uprawnienia, skontaktuj się z administratorem systemu lub zmień poziom zaufania aplikacji w pliku konfiguracyjnym.

Szczegóły wyjątku: System.Security.SecurityException: Nie znaleziono źródła, ale nie można przeszukiwać niektórych lub wszystkich dzienników zdarzeń. Niedostępne dzienniki: bezpieczeństwo

Błąd źródła:

Podczas obsługi bieżącego żądania sieciowego wygenerowano nieobsługiwany wyjątek. Informacje dotyczące pochodzenia i lokalizacji wyjątku można zidentyfikować, korzystając ze śledzenia stosu wyjątków poniżej.

Ślad stosu:

[SecurityException: Nie znaleziono źródła, ale nie można przeszukiwać niektórych lub wszystkich dzienników zdarzeń. Niedostępne dzienniki: bezpieczeństwo.]

System.Diagnostics.EventLog.FindSourceRegistration (źródło ciągu, ciąg machineName, wartość logiczna tylko do odczytu) +562 System.Diagnostics.EventLog.SourceExists (źródło ciągu, ciąg machineName) +251

[fantastyczna okazja]

Oto rzeczy, które zrobiłem, aby spróbować to rozwiązać:

1. Nadaj kluczowi „Wszyscy” pełne uprawnienia dostępu HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog\Security. To zadziałało. Ale oczywiście nie mogę tego zrobić w produkcji. Usunąłem więc uprawnienie „Wszyscy” po uruchomieniu aplikacji przez kilka minut i błąd pojawił się ponownie.

2. Źródło zostało utworzone w dzienniku aplikacji i dzienniku zabezpieczeń (i sprawdziłem, czy istnieje za pośrednictwem regedit) podczas instalacji z podwyższonymi uprawnieniami, ale błąd pozostał.

3. Dałem aplikacji pełny poziom zaufania do web.configpliku (i za pomocą appcmd.exe), ale bezskutecznie.

Czy ktoś ma wgląd w to, co można tutaj zrobić?

PS: Jest to kontynuacja tego pytania . Postępowałem zgodnie z podanymi odpowiedziami, ale bezskutecznie (patrz # 2 powyżej).

Aby udzielić Network Servicezgody na odczyt EventLog/Securityklucza (zgodnie z sugestiami Firenzi i royrules22), postępuj zgodnie z instrukcjami z http://geekswithblogs.net/timh/archive/2005/10/05/56029.aspx

1. Otwórz Edytor rejestru:
   1. Wybierz StartwtedyRun
   2. Wpisz regedt32lubregedit

2. Przejdź / rozwiń do następującego klucza:

   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog\Security

3. Kliknij ten wpis prawym przyciskiem myszy i wybierz Uprawnienia

4. Dodaj Network Serviceużytkownika

5. Daj mu uprawnienia do odczytu

AKTUALIZACJA: Powyższe kroki są odpowiednie na komputerach programistów, w których nie używasz procesu wdrażania do zainstalowania aplikacji.
Jeśli jednak wdrożysz aplikację na innym komputerze, rozważ rejestrację źródeł dziennika zdarzeń podczas instalacji, jak sugerują odpowiedzi SailAvid i Nicole Calinoiu .

Korzystam z funkcji PowerShell (wywołanie w 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")
            }
    }
}

Problem polega na tym, że EventLog.SourceExistspróbuje uzyskać dostęp do EventLog\Securityklucza, który jest dozwolony tylko dla administratora.

Typowym przykładem logowania do programu C # EventLogjest:

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);

Jednak następujące wiersze nie działają, jeśli program nie ma uprawnień administratora, a klucz nie został znaleziony pod, EventLog\Applicationco EventLog.SourceExistsspowoduje próbę uzyskania dostępu EventLog\Security.

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

Dlatego zalecanym sposobem jest utworzenie skryptu instalacyjnego, który tworzy odpowiedni klucz, a mianowicie:

HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ EventLog \ Application \ dotNET Przykładowa aplikacja

Następnie można usunąć te dwie linie.

Możesz także utworzyć .regplik, aby utworzyć klucz rejestru. Po prostu zapisz następujący tekst w pliku create.reg:

Windows Registry Editor Version 5.00

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

Rozwiązaniem było przyznanie uprawnienia do odczytu konta „Usługa sieciowa” na kluczu EventLog / Security.

U mnie tylko udzielanie uprawnień „Odczyt” dla „NetworkService” całemu oddziałowi „EventLog” działało.

Miałem bardzo podobny problem z programem konsolowym, który tworzę pod VS2010 (uaktualniony z VS2008 pod XP). Mój program używa EnLib do logowania. Błąd został uruchomiony, ponieważ EntLib nie miał uprawnień do zarejestrowania nowego źródła zdarzeń.

Zacząłem więc, kiedy mój skompilowany program został jako Administrator : zarejestrował źródło zdarzenia. Potem bez problemu wróciłem do programowania i debugowania od wewnątrz VS.

(możesz również odnieść się do http://www.blackwasp.co.uk/EventLog_3.aspx , pomogło mi to

Ten wyjątek występował dla mnie z aplikacji konsoli .NET działającej jako zaplanowane zadanie, a ja próbowałem zrobić w zasadzie to samo - utworzyć nowe źródło zdarzeń i zapisać w dzienniku zdarzeń.

Na koniec ustawianie pełnych uprawnień dla użytkownika, w ramach którego zadanie było uruchomione na następujących kluczach, pomogło mi:

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

Próbuję prawie wszystkiego tutaj, aby rozwiązać ten problem ... Udostępniam tutaj odpowiedź, która pomaga mi:

Inny sposób rozwiązania problemu:

• w konsoli IIS przejdź do puli aplikacji zarządzającej witryną i zanotuj tożsamość, która ją uruchamia (zazwyczaj usługa sieciowa)
• upewnij się, że ta tożsamość może odczytać KEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ Eventlog (kliknij prawym przyciskiem myszy, uprawnienia)
• teraz zmień tożsamość tej puli aplikacji na System lokalny, zastosuj i wróć do Usługi sieciowej

Poświadczenia zostaną ponownie załadowane, a EventLog będzie dostępny

w http://geekswithblogs.net/timh/archive/2005/10/05/56029.aspx , dzięki Michael Freidgeim

Zetknąłem się z tym samym problemem, ale musiałem przejść o jeden poziom wyżej i dać wszystkim pełny dostęp do klucza HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ EventLog \, zamiast przejść do bezpieczeństwa, co rozwiązało problem.

Ten sam problem w systemie Windows 7 64 bity. Uruchom jako administrator rozwiązał problem.

Nowy klucz z użytą nazwą źródła musi zostać utworzony w HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ services \ eventlog \ Application w regEdit, gdy używasz System.Diagnostics.EventLog.WriteEntry („SourceName”, „ErrorMessage”, EventLogEntryType.Error);

Zasadniczo więc użytkownik nie ma uprawnień do utworzenia klucza. W zależności od użytkownika, którego używasz, można wykonać następujące czynności na podstawie wartości Tożsamość w Ustawieniach zaawansowanych puli aplikacji:

1. Uruchom RegEdit i przejdź do HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ services \ eventlog

2. Kliknij prawym przyciskiem myszy klucz EventLog i wybierz opcję Uprawnienia ... 3. Dodaj użytkownika z pełnym dostępem kontrolnym.

   -Jeśli używasz „NetworkService”, dodaj użytkownika USŁUGA SIECIOWA

   -Jeśli korzystasz z „ApplicationPoolIdentity”, dodaj IIS APPPOL {nazwa puli aplikacji} (podczas wyszukiwania użytkownika użyj lokalizacji komputera lokalnego).

   -Jeśli używasz „LocalSystem”, upewnij się, że użytkownik ma uprawnienia administratora. Nie jest zalecane w przypadku luk w zabezpieczeniach.

3. Powtórz kroki od 1 do 3 dla HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ services \ eventlog \ Security

Do debugowania w Visual Studio używam „NetworkService” (jest to użytkownik ASP.NET), a kiedy witryna jest opublikowana, korzystam z „AppicationPoolIdentity”.

Do Twojej wiadomości… moim problemem było to, że przypadkowo wybrałem „Usługa lokalna” jako Konto we właściwościach ProcessInstaller zamiast „System lokalny”. Po prostu wspominając o kimkolwiek innym, kto poszedł za samouczkiem MSDN, jak pokazuje wybór usługi lokalnej, a ja nie zwracałem szczególnej uwagi ...

Wydaje się, że istnieje rażąco oczywiste rozwiązanie tego problemu, które jeszcze nie spotkało się z poważnym minusem, przynajmniej tam, gdzie uzyskanie uprawnień administracyjnych w celu utworzenia własnego źródła zdarzeń nie jest praktyczne: użyj takiego, które już tam jest.

Dwa, z których zacząłem korzystać, to „.Net Runtime” i „Application Error”, które wydają się być obecne na większości komputerów.

Głównymi wadami jest niemożność grupowania według tego zdarzenia i prawdopodobnie nie masz powiązanego identyfikatora zdarzenia, co oznacza, że ​​wpis do dziennika może być bardzo dobrze poprzedzony czymś w rodzaju „Opis identyfikatora zdarzenia 0 ze źródła .Net Nie można znaleźć środowiska wykonawczego… ”, jeśli go pominięto, ale dziennik się loguje, a dane wyjściowe wydają się zasadniczo sensowne.

Wynikowy kod wygląda następująco:

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

Oczywiście, ponieważ zawsze istnieje szansa, że ​​jesteś na maszynie, która nie ma tych źródeł zdarzeń z jakiegokolwiek powodu, prawdopodobnie chcesz ją try {} catch{}zawinąć na wypadek awarii i pogorszenia sytuacji, ale zdarzenia można teraz zapisać.

Nie pracuję nad IIS, ale mam aplikację, która generuje ten sam błąd na polu 2K8. Działa dobrze na pudełku 2K3, idź rysunek.

Moim rozwiązaniem było „Uruchom jako administrator”, aby nadać aplikacji podwyższone uprawnienia i wszystko działa szczęśliwie. Mam nadzieję, że to pomoże poprowadzić cię we właściwym kierunku.

Windows 2008 to prawa / uprawnienia / podniesienie uprawnień naprawdę różni się od Windows 2003, gar.

Cześć. Natrafiłem na ten sam problem podczas tworzenia aplikacji i chciałem zainstalować ją na zdalnym komputerze, naprawiłem to, wykonując następujące czynności:

1) Przejdź do rejestru, znajdź: HKLM \ System \ CurrentControlSet \ Services \ EventLog \ Application (??? YOUR_SERVICE_OR_APP_NAME ???)

Pamiętaj, że „(??? YOUR_SERVICE_OR_APP_NAME ???)” to nazwa usługi aplikacji zdefiniowanej podczas tworzenia wdrożenia platformy .NET, na przykład jeśli nazwa nowej aplikacji to „Moja nowa aplikacja”, kluczem będzie: HKLM \ System \ CurrentControlSet \ Services \ EventLog \ Application \ My New app

Uwaga 2: W zależności od zdarzenia eventLog, w którym piszesz, możesz znaleźć na swoim polu DEV, \ Application \ (jak wspomniano powyżej), a także (\ System) lub (\ Security) w zależności od zdarzenia, w którym pisze Twoja aplikacja, głównie , (\ Aplikacja) powinna być w porządku przez cały czas.

2) Będąc na powyższym klawiszu, Z menu; Wybierz „PLIK” -> „Eksportuj”, a następnie zapisz plik. (Uwaga: spowoduje to utworzenie niezbędnych ustawień rejestru, gdy aplikacja będzie musiała uzyskać dostęp do tego klucza, aby zapisać się w Podglądzie zdarzeń), nowy plik będzie plikiem .REG, na wszelki wypadek nazwij go „My New App.REG „

3) Podczas wdrażania na PRODuction skonsultuj się z administratorem systemu serwera (SA), przekaż plik „My New App.REG” wraz z aplikacją i poproś SA o zainstalowanie tego pliku REG, po zakończeniu instalacji (jako administrator) stwórz klucz do swojej aplikacji.

4) Uruchom aplikację, nie powinno być konieczne uzyskiwanie dostępu do niczego innego niż ten klucz.

Problem powinien już zostać rozwiązany.

Przyczyna:

Podczas opracowywania aplikacji, która zapisuje cokolwiek do EventLog, wymagałby tego KLUCZA w rejestrze Eventlog, jeśli ten klucz nie zostanie znaleziony, spróbuje go utworzyć, a następnie nie powiedzie się to z powodu braku uprawnień. Powyższy proces jest podobny do wdrażania aplikacji (ręcznie), podczas gdy my sami to tworzymy i nie trzeba mieć bólu głowy, ponieważ nie modyfikujesz rejestru, dodając uprawnienia do KAŻDEGO, co stanowi ryzyko bezpieczeństwa na serwerach produkcyjnych.

Mam nadzieję, że to pomoże to rozwiązać.

Chociaż odpowiedź instalatora jest dobrą odpowiedzią, nie zawsze jest praktyczna w przypadku oprogramowania, którego nie napisałeś. Prostą odpowiedzią jest utworzenie dziennika i źródła zdarzeń za pomocą polecenia PowerShell New-EventLog ( http://technet.microsoft.com/en-us/library/hh849768.aspx )

Uruchom PowerShell jako administrator i uruchom następującą komendę, zmieniając potrzebną nazwę i źródło dziennika.

New-EventLog -LogName Aplikacja -Source TFSAggregator

Użyłem go do rozwiązania wyjątku dziennika zdarzeń, gdy agregator uruchamia problem z codeplex.

Miał podobny problem ze wszystkimi naszymi serwerami z 2008 roku. Dziennik zabezpieczeń przestał działać całkowicie z powodu obiektu zasad grupy, który zabrał grupie Uwierzytelnionych użytkowników i odczytał uprawnienia do kluczaHKLM\System\CurrentControlSet\Services\EventLog\security

Przywrócenie tego do zaleceń Microsoft rozwiązało problem. Podejrzewam, że przekazanie wszystkim uwierzytelnionym użytkownikom odczytu na wyższym poziomie również rozwiąże problem.

I hit podobny problem - w moim przypadku źródłowy zawarty <, >znaków. 64-bitowe maszyny używają nowego, nawet dziennika - bazy xml Powiedziałbym, że te znaki (ustawione z łańcucha) tworzą niepoprawny plik XML, który powoduje wyjątek. Prawdopodobnie powinno to być rozważane jako problem Microsoftu - niewłaściwa obsługa źródła (nazwy / łańcucha).

Rozwiązanie jest bardzo proste - uruchom aplikację Visual Studio w trybie administratora!

Moja aplikacja jest instalowana na klienckich serwerach internetowych. Zamiast majstrować przy uprawnieniach usługi sieciowej i rejestrze, zdecydowałem się sprawdzić SourceExistsi uruchomić CreateEventSourcew moim instalatorze.

Dodałem również try / catch log.source = "xx"in w aplikacji, aby ustawić je na znane źródło, jeśli moje źródło zdarzeń nie zostało utworzone (pojawiłoby się to tylko, jeśli zamiast pliku instalacyjnego zmieniłem na gorąco .dll).

spróbuj poniżej w pliku web.config

 <system.web>

<trust level="Full"/>

</system.web>

Miałem ten problem podczas uruchamiania aplikacji w VS. Wszystko, co musiałem zrobić, to raz uruchomić program jako Administrator, a następnie móc uruchomić z poziomu VS.

Aby uruchomić jako Administrator, po prostu przejdź do folderu debugowania w Eksploratorze Windows. Kliknij program prawym przyciskiem myszy i wybierz Uruchom jako administrator.

Przebudowanie rozwiązania działało dla mnie