Проблема разрешений журнала событий log4Net с использованием учетной записи без прав администратора - PullRequest
5 голосов
/ 09 декабря 2011

Это, вероятно, не проблема с SiteCore как таковая, но я включил его для полноты. У меня sitecore 6.3, работающий под IIS7 с использованием пользовательского удостоверения для пула приложений. Я не могу заставить Sitecore записать информацию о своем журнале (используя настройки log4net по умолчанию) в журнал событий. Я следовал этому совету: http://logging.apache.org/log4net/release/faq.html#Why%20doesn%27t%20the%20EventLogAppender%20work? и хотя он работает нормально, когда я делаю пользовательскую идентификацию членом группы администраторов, мне нужно найти способ заставить ее работать в работе без такого взлома безопасности.

Странная вещь в том, что у меня есть MSI, который устанавливает его (работает под учетной записью, которая является членом группы администраторов) и создает для меня правильные ключи реестра в журнале событий, и все же, несмотря на это, я все еще получаю следующая ошибка при запуске приложения с использованием пользовательского удостоверения (без участия администратора).

log4net:ERROR DOMConfigurator: Could not create Appender [EventLogAppender] of type [log4net.Appender.EventLogAppender]. Reported error follows.
System.Security.SecurityException: Requested registry access is not allowed.
at Microsoft.Win32.RegistryKey.OpenSubKey(String name, Boolean writable)
at System.Diagnostics.EventLog.GetEventLogRegKey(String machine, Boolean writable)
at System.Diagnostics.EventLog.FindSourceRegistration(String source, String machineName, Boolean readOnly)
at System.Diagnostics.EventLog.DeleteEventSource(String source, String machineName)
at log4net.Appender.EventLogAppender.ActivateOptions()
at log4net.Repository.Hierarchy.DOMHierarchyConfigurator.ParseAppender(XmlElement appenderElement)
The Zone of the assembly that failed was:
MyComputer
log4net:ERROR DOMConfigurator: Appender named [EventLogAppender] not found.

Думая, что я могу сузить проблему с разрешением реестра, я предоставил всем полные права доступа к следующему разделу реестра и подразделам, но он тоже не работал: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\eventlog

Настраиваемый идентификатор входит в следующие группы:

  • Читатели журнала событий
  • IIS_USERS
  • Пользователи системного монитора

Я также видел следующий вопрос , который, кажется, задает то же самое. Кажется, в статье Microsoft предлагается, что это может быть проблемой с ACL в журнале событий, и приводятся примеры того, как вы можете изменить SSDL, но я бы предпочел этого избежать, если это вообще возможно.

EDIT: У меня работает другой сервер, где журнал заполняется нормально. Пользовательский идентификатор был членом администраторов, поэтому я отозвал его и перезагрузил, пытаясь преднамеренно сломать его, но не могу. Config идентичен на обоих полях и идентичен для запуска MSI, который создает ключи реестра. Запустите procmon на обоих (после выполнения IISReset и повторного запуска пула приложений), чтобы проверить активность реестра. Странно то, что на поле, которое работает, вы получаете 477 имен не найденных записей для моего источника событий в неправильных местах (Приложение и другой Custom EventLog "MyCompany"). Нет попаданий для места, где ведется логирование - MyCompany \ MyCompany.SiteCore. Хотя на поле, которое не работает, он, похоже, запрашивает чтение правильного ключа (хотя и только 6 раз), но затем вы получаете ошибку доступа к реестру Log4Net.

Ответы [ 2 ]

4 голосов
/ 12 декабря 2011

Насколько я понимаю, EventStore хранятся в реестре, поэтому вам нужно только разрешение на запись в реестр, чтобы создать или удалить EventStore. Обычно это требуется только один раз, и большинство приложений создают его как часть процедуры установки, чтобы приложение не запускалось от имени администратора во время обычного выполнения.

Однако ваше сообщение об ошибке (в вопросе) включает в себя метод DeleteEventSource , из которого я бы сделал вывод / предположил, что EventSource действительно существует, но в некотором смысле неверен. Так что, возможно, это в настоящее время зарегистрировано как запись в журнал событий с именем MyCompany, и теперь вы пытаетесь изменить его на «MyCompany \ MyCompany.SiteCore», что требует удаления старого источника событий и создания нового.

Похоже, ваша процедура установки создает другой EventSource из того, который фактически использует ваше приложение.

Если это не поможет, то я бы предложил включить внутреннюю запись в журнал для Log4net (но, очевидно, не в журнал событий), что, вероятно, даст вам больше информации.

Дать полное разрешение для раздела реестра недостаточно. По данным Microsoft

Чтобы создать источник событий в Windows Vista и более поздних версиях или Windows Server 2003, у вас должны быть права администратора.

Причина этого требования заключается в том, что все журналы событий, включая безопасность, должны быть найдены, чтобы определить, является ли источник события уникальным. Начиная с Windows Vista, пользователи не имеют прав доступа к журналу безопасности; поэтому выдается исключение SecurityException.

Начиная с Windows Vista, контроль учетных записей (UAC) определяет привилегии пользователя. Если вы являетесь участником группы «Встроенные администраторы», вам назначаются два токена доступа во время выполнения: стандартный токен доступа пользователя и токен доступа администратора. По умолчанию вы находитесь в роли стандартного пользователя. Чтобы выполнить код, который обращается к журналу безопасности, вы должны сначала повысить свои привилегии от обычного пользователя до администратора. Вы можете сделать это при запуске приложения, щелкнув правой кнопкой мыши значок приложения и указав, что вы хотите запускать от имени администратора.

2 голосов
/ 12 декабря 2011

Я думаю, что вопреки документации Apache , log4net ДОЛЖЕН иметь права на запись в реестр - или, по крайней мере, в моем случае.Чтобы доказать это, я сделал резервную копию реестра на сервере, где он не работал, и предоставил привилегии администратора IIS, прежде чем раскручивать sitecore.Конечно же, он начал красиво выходить в журнал событий, а затем, когда я снова экспортировал реестр, чтобы запустить diff, БЫЛА разница.

Значение для файла eventlogmessage в моем источнике событий было обновлено с:

C:\Windows\Microsoft.NET\Framework\v2.0.50727\EventLogMessages.dll

To

C:\Windows\Microsoft.NET\Framework64\v2.0.50727\EventLogMessages.dll

Поэтому я предположил, что простое изменение этого значения в реестре вручную сработает.

Но этого не произошло.

Итак, я запустил procmon на двух моих серверах: A = рабочий, B = отказавший.Конечно, на сервере BI есть строка, которая гласит: Operation: RegOpenKey, Path: HKLM\System\CurrentControlSet\Services\EventLog, Desired Access:Read/Write, Result: ACCESS DENIED.

Я проследил через сервер A, и в том же месте ключ запрашивается с помощью Desired Access:Читать.

Вывод: Кажется неизбежным, что мне нужно будет предоставить привилегии администратора удостоверений своего пула приложений в рабочей среде, по крайней мере, достаточно времени, чтобы программно выполнить необходимые записи реестра в первый раз из log4net.Я не знаю, почему администратор;Я попытался предоставить полные разрешения всему узлу журнала событий в реестре для моего пользовательского приложения, но безрезультатно.Кажется, что-то делает, что я не могу определить или определить.Затем я отзову эту привилегию сразу после того, как она начнет регистрировать и отслеживать, выбивают ли последующие установки функциональность впоследствии.(Надеюсь, что нет).

Если у кого-то есть понимание этого поведения, это будет с благодарностью.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...