sharepoint timer privileges stsadm event-viewer

Sharepoint: ejecutando stsadm desde un trabajo del temporizador+SHAREPOINT / Derechos del sistema



timer privileges (3)

Las tareas de temporizador de SharePoint se ejecutan con las credenciales de administrador de la firma de SharePoint, ya que la información entra en la base de datos de configuración de SharePoint. Por lo tanto, el grupo de aplicaciones no tendrá acceso.

Para probar el trabajo del temporizador en el entorno de desarrollo, podemos cambiar temporalmente la cuenta del grupo de aplicaciones a la cuenta del grupo de aplicaciones que se utiliza para Administración central.

Tengo una situación inusual en la que necesito un trabajo de temporizador de SharePoint para que ambos tengan privilegios de administrador local de Windows y tener privilegios de SHAREPOINT/System SharePoint.

Puedo obtener los privilegios de Windows simplemente configurando el servicio del temporizador para usar una cuenta que es miembro de los administradores locales. Entiendo que esta no es una buena solución ya que le da al servicio de temporizador de SharePoint más derechos de los que debería tener. Pero al menos permite que mi trabajo del temporizador de SharePoint ejecute stsadm .

Otro problema con la ejecución del servicio de temporizador bajo el administrador local es que este usuario no necesariamente tendrá los SHAREPOINT/System SharePoint que también necesito para este trabajo de SharePoint. Resulta que SPSecurity.RunWithElevatedPrivileges no funcionará en este caso. Reflector muestra que RunWithElevatedPrivileges comprueba si el proceso actual es owstimer (el proceso de servicio que ejecuta trabajos de SharePoint) y no realiza ninguna elevación este es el caso (lo racional aquí, supongo, es que el servicio de temporizador se debe ejecutar bajo NT AUTHORITY/NetworkService cuenta de Windows que tiene SHAREPOINT/System SharePoint, y por lo tanto no hay necesidad de elevar los privilegios para un trabajo del temporizador).

La única solución posible aquí parece ser ejecutar el servicio de temporizador en su cuenta de Windows NetworkService habitual y ejecutar stsadm como administrador local almacenando las credenciales de administrador en algún lugar y pasándolas a System.Diagnostics.Process.Run () a través del nombre de usuario de StarInfo. dominio y contraseña

Parece que todo debería funcionar ahora, pero aquí hay otro problema con el que estoy atrapado en este momento. Stsamd está fallando con el siguiente mensaje emergente de error (!) (Winternals filemon muestra que stsadm se está ejecutando bajo el administrador en este caso):

The application failed to initialize properly (0x0c0000142).
Click OK to terminate the application.

El Visor de eventos no registra nada excepto la ventana emergente.

El usuario administrador local es mi cuenta y cuando solo ejecuto stsadm interactivamente en esta cuenta, todo está bien. También funciona bien cuando configuro el servicio del temporizador para que se ejecute en esta cuenta.

Cualquier sugerencia es apreciada :)


No estoy en el trabajo, así que esto está fuera de mi cabeza, pero: si obtiene una referencia al sitio, ¿puede intentar crear un nuevo SPSite con SYSTEM-UserToken?

SPUserToken sut = thisSite.RootWeb.AllUsers["SHAREPOINT/SYSTEM"].UserToken; using (SPSite syssite = new SPSite(thisSite.Url,sut) { // Do what you have to do }


Otras aplicaciones si se ejecutan de esta manera (es decir, desde un trabajo del temporizador con credenciales explícitas) están fallando de la misma manera con "La aplicación no pudo inicializar propely". Acabo de crear una aplicación simple que toma la ruta de otro ejecutable y sus argumentos como parámetros y cuando se ejecuta desde ese trabajo del temporizador falla de la misma manera.

internal class ExternalProcess { public static void run(String executablePath, String workingDirectory, String programArguments, String domain, String userName, String password, out Int32 exitCode, out String output) { Process process = new Process(); process.StartInfo.UseShellExecute = false; process.StartInfo.RedirectStandardError = true; process.StartInfo.RedirectStandardOutput = true; StringBuilder outputString = new StringBuilder(); Object synchObj = new object(); DataReceivedEventHandler outputAppender = delegate(Object sender, DataReceivedEventArgs args) { lock (synchObj) { outputString.AppendLine(args.Data); } }; process.OutputDataReceived += outputAppender; process.ErrorDataReceived += outputAppender; process.StartInfo.FileName = @"C:/AppRunner.exe"; process.StartInfo.WorkingDirectory = workingDirectory; process.StartInfo.Arguments = @"""" + executablePath + @""" " + programArguments; process.StartInfo.UserName = userName; process.StartInfo.Domain = domain; SecureString passwordString = new SecureString(); foreach (Char c in password) { passwordString.AppendChar(c); } process.StartInfo.Password = passwordString; process.Start(); process.BeginOutputReadLine(); process.BeginErrorReadLine(); process.WaitForExit(); exitCode = process.ExitCode; output = outputString.ToString(); } }

AppRunner básicamente hace lo mismo que el fragmento anterior, pero sin nombre de usuario y contraseña