iis-7 - services - permisos sobre iis

Problema de permisos de registro de eventos de log4Net usando una cuenta que no es de administrador

Question

Probablemente esto no sea un problema con SiteCore per se, pero lo he incluido para que esté completo. Tengo el sitio 6.3 corriendo bajo IIS7 usando una identidad personalizada para el grupo de aplicaciones. No puedo hacer que Sitecore escriba su información de registro (usando la configuración predeterminada de log4net) en el registro de eventos. He seguido los consejos aquí: http://logging.apache.org/log4net/release/faq.html#Why%20doesn%27t%20the%20EventLogAppender%20work? y aunque funciona bien cuando hago de la identidad personalizada un miembro del grupo del administrador, necesito encontrar la manera de que funcione en producción sin ese truco de seguridad.

Lo extraño es que tengo un MSI que lo instala (se ejecuta en una cuenta que es miembro del grupo del administrador) y crea las claves de registro correctas en el registro de eventos para mí y, a pesar de eso, sigo recibiendo el siguiente error cuando Ejecuto la aplicación usando la identidad personalizada (sin que sea miembro de los administradores).

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.

Pensando que podría reducirlo a un problema de permiso de registro, otorgé a Todos permisos completos para la siguiente clave de registro y subclaves, pero tampoco funcionó: HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/services/eventlog

La identidad personalizada es un miembro de los siguientes grupos:

• Lectores de registro de eventos
• IIS_USERS
• Usuarios de Monitor de rendimiento

También he visto la siguiente pregunta que parece preguntar lo mismo. El artículo de Microsoft parece sugerir que podría ser un problema con las ACL en un registro de eventos y da ejemplos sobre cómo puede cambiar las SSDL, pero prefiero evitar eso si es posible.

EDITAR: Tengo otro servidor ejecutándose donde el registro se está poblando bien. La identidad personalizada era miembro de los administradores, así que la revoqué y reinicié, intentando romperla deliberadamente, pero no puedo. Config es idéntico en ambos cuadros y con la misma identidad utilizada para ejecutar el MSI que crea las claves de registro. Han ejecutado procmon en ambos (después de hacer un IISReset y girar el grupo de aplicaciones de nuevo) para examinar la actividad del registro. Lo extraño es que en el cuadro que funciona, obtienes 477 registros de nombres no encontrados para mi fuente de eventos en los lugares incorrectos (Aplicación y una CustomLog diferente "MyCompany"). No hits para el lugar donde está registrando que es "MyCompany / MyCompany.SiteCore". Mientras está en la caja que está rota, parece que está solicitando leer la clave correcta (aunque solo 6 veces) pero luego obtiene el error de acceso al registro de Log4Net.

Answer 1

Creo que, contrariamente a la documentación de Apache , log4net SÍ necesita acceso de escritura al registro, o al menos lo hace en mi caso. Para probar esto, hice una copia de seguridad del registro en el servidor donde no estaba funcionando y le concedí privilegios de administrador de IIS antes de hacer girar el sitecore. Efectivamente, comenzó a cerrar sesión en el registro de eventos muy bien y luego, cuando exporté el registro nuevamente para ejecutar un diff, HABÍA una diferencia.

El valor para el archivo eventlogmessage en mi fuente de evento se ha actualizado desde:

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

A

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

Así que asumí que simplemente cambiar este valor en el registro a mano funcionaría.

Pero no fue así.

Así que ejecuté procmon en los dos servidores que tengo: A = el que está trabajando, B = el que falla. Efectivamente, en el servidor BI tiene una línea que dice: Operation: RegOpenKey, Path: HKLM/System/CurrentControlSet/Services/EventLog, Desired Access:Read/Write, Result: ACCESS DENIED.

Lo he rastreado con el Servidor A y exactamente en el mismo lugar, la clave se solicita con Acceso Deseado: Leer.

Conclusión: parece inevitable que necesite otorgar privilegios de administrador de identidad de mi grupo de aplicaciones en producción durante al menos el tiempo suficiente para programar las escrituras de registro necesarias por primera vez desde log4net. No sé por qué administrador; He intentado otorgar permisos completos a todo el nodo de registro de eventos en el registro de mi aplicación personalizada en vano. Parece hacer algo que no puedo identificar o precisar. Luego, revocaré este privilegio inmediatamente después de que comience a registrar y supervisar si las instalaciones posteriores anularán la funcionalidad posteriormente. (Ojalá no).

Si alguien tiene alguna idea de este comportamiento, sería muy apreciado.

Answer 2

Según tengo entendido, EventStores se almacenan en el registro, por lo que solo necesita permiso de escritura en el registro para crear o eliminar un EventStore. Por lo general, esto solo se necesita una vez y la mayoría de las aplicaciones lo crean como parte del procedimiento de instalación, por lo que no es necesario que la aplicación se ejecute como administrador durante la ejecución normal.

Sin embargo, su mensaje de error (en la pregunta) incluye el método DeleteEventSource del cual deduciría / adivinaría que el EventSource existe, pero que está mal de alguna manera. Por lo tanto, quizás esto esté actualmente registrado como una escritura en el registro de eventos llamado MyCompany y ahora está tratando de cambiarlo a "MyCompany / MyCompany.SiteCore", lo que requiere que elimine el viejo origen de eventos y cree uno nuevo.

Por lo tanto, parece que su rutina de instalación está creando un EventSource diferente del que está usando su aplicación.

Si eso no ayuda, sugeriría habilitar el registro interno para Log4net (pero obviamente no para el registro de eventos), que probablemente le brinde más información.

Dar permiso completo a la clave de registro no es suficiente. De acuerdo con Microsoft

Para crear un origen de evento en Windows Vista y posterior o Windows Server 2003, debe tener privilegios administrativos.

El motivo de este requisito es que se deben buscar todos los registros de eventos, incluida la seguridad, para determinar si el origen del evento es único. Comenzando con Windows Vista, los usuarios no tienen permiso para acceder al registro de seguridad; por lo tanto, se lanza una SecurityException.

Comenzando con Windows Vista, User Account Control (UAC) determina los privilegios de un usuario. Si es miembro del grupo Administradores integrados, tiene asignados dos tokens de acceso en tiempo de ejecución: un token de acceso de usuario estándar y un token de acceso de administrador. Por defecto, usted está en la función de usuario estándar. Para ejecutar el código que accede al registro de seguridad, primero debe elevar sus privilegios del usuario estándar al administrador. Puede hacerlo cuando inicie una aplicación haciendo clic con el botón derecho en el icono de la aplicación e indicando que desea ejecutarlo como administrador.