System.Security.SecurityException podczas zapisywania do dziennika zdarzeń

189

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

encee
źródło
Otrzymywałem to podczas próby zapisu do niestandardowego źródła w usłudze .Net działającej jako NetworkService. Właśnie zmieniłem źródło dziennika zdarzeń, aby pasowało do nazwy usługi skonfigurowanej za pomocą pakietu .Net Service Setup i działało bez ustawiania uprawnień do rejestru. Zauważyłem to, widząc nazwę usługi jako klucz już w HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ EventLog \ Application
Jon Adams
2
Inna możliwa odpowiedź: kliknij exe prawym przyciskiem myszy i wybierz „Uruchom jako administrator”
MacGyver,

Odpowiedzi:

169

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")
            }
    }
}
Michael Freidgeim
źródło
W IIS7 możesz przypisać „USŁUGĘ SIECIOWĄ” jako tożsamość puli aplikacji (może się okazać, że ApplicationPoolIdentity jest domyślna) lub zamiast tego możesz utworzyć nowego użytkownika dla każdej puli aplikacji i ustawić uprawnienia na tym „koncie niestandardowym”. patrz Określanie tożsamości dla puli aplikacji (IIS 7)
Grokodile
5
Zmiany zaczną obowiązywać dopiero po ponownym uruchomieniu aplikacji na IIS
Zé Carlos
7
Dałem IIS_IUSRS pozwolenie na odczyt / zapis klucza dziennika zdarzeń i odczytanie klucza bezpieczeństwa. Mój produkt potrzebował dostępu do zapisu w kluczu dziennika zdarzeń, ponieważ tworzy własne źródło zdarzeń.
duck9
1
duck9 i poprawiam do IIS8, zobacz tutaj po więcej szczegółów: stackoverflow.com/questions/712203/…
thedrs
1
Zobacz także serverfault.com/a/81246/219898 na temat użytkowników puli aplikacji i powiązanych uprawnień - dla tego rozwiązania. Dzięki @Michael Freidgeim - była bardzo pomocna.
Anthony Horne
59

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]
Stefan Profanter
źródło
1
Właśnie to robię dla wszystkich moich usług. Uważam, że tak należy zrobić. W każdej usłudze, w której korzystam z dziennika zdarzeń, mam plik .reg, taki jak powyższy. Jedna mała uwaga, że ​​plik musi być zapisany jako Unicode-32 (cp 1200.)
Valo
Ta odpowiedź opisuje prawdziwy powód błędu. Sprawdzanie istnieje próbuje wyliczyć cały klucz. jeśli istnieje, checkExists działa poprawnie.
DanO
EventLog \ Security jest to klucz do działania, upewnij się, że masz na to pozwolenie.
Princa
45

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

encee
źródło
1
Wokoło widzę podobne rozwiązania. Ale zastanawiam się, dlaczego tak jest. Ponieważ widzę, że wiele usług jest zalogowanych jako NetworkService i muszą być w stanie odczytać dziennik zdarzeń / zabezpieczenia. Dlaczego więc konieczne jest dodanie uprawnienia do usługi sieciowej?
h - n
11
Dla tych z nas, którzy normalnie nie czołgają się przez rejestr, ten link może być pomocny: social.msdn.microsoft.com/forums/en-US/…
Allan
Niezły link Allan. Punkt 3 przy przyjętej odpowiedzi jest ważny i już raz mnie ugryzł. tzn. udzielenie uprawnień nadrzędnemu kluczowi rejestru EventLog NIE jest propagowane do „niedostępnych dzienników”, takich jak Security i Virtual Server, nawet jeśli są kluczami podrzędnymi w rejestrze. Jeśli chcesz uzyskać pełny dostęp do dziennika zdarzeń, musisz udzielić ZARÓWNO POZIOMU ​​poziomu dziennika zdarzeń nadrzędnych, jak i poziomów zabezpieczeń podrzędnych.
Ben Barreth,
1
Zmiany zaczną obowiązywać dopiero po ponownym uruchomieniu aplikacji na IIS
Zé Carlos
Dla tych, którzy próbowali skopiować / wkleić, upewnij się, że między słowami „usługa sieciowa” jest spacja.
Chris Fremgen
7

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

evictorov
źródło
nie jest to bardzo istotne, ponieważ dla podkluczów, takich jak „Bezpieczeństwo” lub „Serwer wirtualny”, należy przyznać dostęp do odczytu indywidualnie, ponieważ uprawnienia nie są dziedziczone z klucza nadrzędnego.
Serge
7

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

oldbrazil
źródło
7

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
tswann
źródło
3
Uratowałeś mi dzień. BTW, zezwolenie na odczyt było wystarczające w dniu eventlog\Applicationi eventlog\Security; pełna kontrola wymagana eventlogtylko w katalogu głównym.
Ruud Helderman,
6

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

Gelásio
źródło
Zmiana puli aplikacji z „ApplicationPoolIdentity” na „LocalSystem” rozwiązała dla mnie problem tworzenia / odczytu dzienników zdarzeń.
majestzim
4

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.

nodonoghue
źródło
1
Spróbuj także ustawić aplikację tak, aby działała jako LocalSystem, aby utworzyć klucz rejestru, a następnie możesz wrócić do NetworkService.
demoncodemonkey
4

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

Dom
źródło
4

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”.

Pablishe
źródło
3

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 ...

DaleS
źródło
3

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ć.

tobriand
źródło
2

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.

omgtitb
źródło
2

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ć.

Heider Sati
źródło
2

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.

John Brown
źródło
1

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.

Steve M.
źródło
1

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

alflesio
źródło
1

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

fregata
źródło
Podczas rozwiązywania problemów w VS i otrzymywania tego błędu, naprawiłem to dla mnie
wruckie
Spowodowałoby to błąd, ponieważ to nie VS wywołuje to wywołanie, to aplikacja, która prawdopodobnie działa w innym kontekście bezpieczeństwa.
CodeMonkey1313
0

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

basher
źródło
0

spróbuj poniżej w pliku web.config

 <system.web>

<trust level="Full"/>

</system.web>
Anjan Kant
źródło
-1

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.

Bob Horn
źródło
-3

Przebudowanie rozwiązania działało dla mnie

Stephen ebichondo
źródło