¿Pueden los usuarios normales actualizar la configuración de SPPersistedObject si se ejecuta con privilegios elevados?

Question

Tengo un ícono de cinta personalizado "Alistar" implementado en cada biblioteca de documentos.Un normal (es decirel usuario no administrador puede hacer clic en este icono;cuando lo haga, me gustaría guardar permanentemente la información de la biblioteca de documentos (ID, nombre) en algún lugar.Luego, un administrador central puede (a través de una página de administración central personalizada) ver una lista de todas las bibliotecas de documentos registradas por los usuarios.

Estoy pensando en usar SPPersistedObject para almacenar la información de la biblioteca de documentos cuando un usuario hace clic en el icono de la cinta.Sin embargo, que yo sepa, esto requiere privilegios de administrador de la granja, lo que significa que los usuarios normales encontrarán un error al hacer clic en "Registrarse". ¿Ejecutar el código que escribe SPPersistedObject con privilegios elevados resolvería este problema?, ¿o aún podría ocurrir un error?Esto es lo que quiero decir:

// Execute this code when a ribbon icon is clicked by a normal user
SPSecurity.RunWithElevatedPrivileges(delegate()
{
    // Write DocumentLibrary Id and Name to some custom SPPersistedObject
});

MSDN dice que RunWithElevatedPrivileges() "Se ejecuta bajo la identidad del grupo de aplicaciones, que tiene privilegios de administrador de colección de sitios en todas las colecciones de sitios alojadas por ese grupo de aplicaciones". ¿Es esto suficiente para actualizar SPPersistedObject?

¿Debo anular? SPPersistedObject.HasAdditionalUpdateAccess para volver siempre verdadero, o esto todavía no sería suficiente para los entornos menos privilegiados?Si no es así, ¿qué opciones tengo para almacenar dicha información además de una base de datos personalizada?

Answer 1

Los privilegios elevados no son suficientes para escribir en la base de datos de configuración.Con los privilegios elevados, utilizará la identidad del grupo de aplicaciones de aplicaciones web, que solo tiene permiso de lectura para el DB de configuración de forma predeterminada.Por supuesto, el usuario administrador (que ejecuta el administrador central debe tener permisos de lectura y escritura).

Ver más en: http://joelblogs.co.uk/2010/10/10/persisting-configuration-data-in-sharepoint-2010-with-sppersistedobject/

SPPersistedObject.HasAdditionalUpdateAccess

todavía necesita que el usuario administrador que no es de la granja sea suplantado por el usuario administrador de la granja.

Un último tema que requiere cierta cobertura es la seguridad.Como se describió anteriormente, el HOS existe en la base de datos de configuración de la granja.Estrictamente hablando, existe para apoyar la funcionalidad administrativa, sin embargo, tiene usos más allá de este alcance.Por ejemplo, si estamos construyendo un trabajo de temporizador personalizado y queremos tener la capacidad de enviar tareas a nuestro trabajo para su finalización.Es muy probable que estas tareas se originen dentro de un alcance no administrativo.Posiblemente como resultado de un usuario haciendo clic en un botón en una parte web en alguna otra colección de sitios.Con versiones anteriores de SharePoint, esto simplemente no fue posible.Solo los administradores agrícolas pueden actualizar los Hos.Sin embargo, con SharePoint 2010, se ha hecho una adición al Base SperPersistedObject que abre los HOS a otros usuarios.Para ver cómo funciona esto, podemos modificar nuestra función principal de la siguiente manera:

using System;
using System.Runtime.InteropServices;
using System.Security.Principal;

namespace PersistedObjectDemo
{
    internal class Program
    {
        private const int LOGON_TYPE_INTERACTIVE = 2;
        private const int LOGON_TYPE_PROVIDER_DEFAULT = 0;

        [DllImport("advapi32.dll", CharSet = CharSet.Unicode, SetLastError = true)]
        public static extern bool LogonUser(string userName, string domain, string password, int logonType,
                                            int logonProvider, ref IntPtr accessToken);

        private static void Main(string[] args)
        {
            try
            {
                IntPtr accessToken = IntPtr.Zero;
                if (LogonUser("non-farm-admin-username", "your-domain-name", "your-password", LOGON_TYPE_INTERACTIVE,
                              LOGON_TYPE_PROVIDER_DEFAULT, ref accessToken))
                {
                    using (var identity = new WindowsIdentity(accessToken))
                    {
                        using (identity.Impersonate())
                        {
                            MyPersistedObject obj = MyPersistedObject.Local;
                   //delete existing object and recreate to keep things simple
                            obj.Delete();
                            obj = MyPersistedObject.Local;
                            obj.Foo = "Some updated value";
                            obj.Update();
                        }
                    }
                }

            }
            catch (Exception ex)
            {
                Console.Write(ex);
            }

            Console.WriteLine("Press return to exit");
            Console.ReadLine();
        }
    }
}

Este código simula un intento de un usuario administrativo no agrícola para actualizar los HOS.Si ejecutamos esto, veremos la siguiente excepción, que es nuestro número 3 de Gotcha:

System.Security.SecurityException:Acceso denegado.en microsoft.sharepoint.administration.sppersistedObject.baseUpdate () en persistedObjectDemo.MyPersistedObject.Update ()

Como era de esperar, tratar de actualizar el HOS usando un usuario administrativo no agrícola lanza una excepción.Sin embargo, si agregamos el siguiente código a myPersistedObject.cs y ejecutamos nuestro programa nuevamente, podemos ver que el HOS se actualiza adecuadamente.

protected override bool HasAdditionalUpdateAccess()
{
    return true;
}

Por supuesto, en una aplicación del mundo real, probablemente quisiéramos agregar algunas verificaciones de seguridad en esta función en lugar de simplemente devolverlo y permitir que cualquiera actualice nuestro objeto, pero con suerte esto ilustra el punto lo suficiente.

Hay otro Gotcha con respecto a la seguridad: cuando SharePoint está instalado en 2010, de forma predeterminada, solo la cuenta de administración de la granja tiene acceso de lectura/escritura a la base de datos de configuración.En una instalación de menos privilegio, todas las aplicaciones web, además de la administración central, se ejecutarán bajo su propia cuenta de servicio y estas cuentas no tendrán acceso de escritura a la base de datos de configuración.En consecuencia, no será posible agregar, eliminar y actualizar objetos en los HOS.Aunque la anulación de HasAdditionalUpdateAccess nos permite un poco más de control sobre quién puede actualizar los HOS, si la cuenta de grupo de aplicaciones subyacente no tiene los permisos de base de datos apropiados, nos vamos a despegar bastante rápido.

• Ver más en: http://www.chaholl.com/archive/2011/01/30/the-skinny-on-sppersistedobject-and-the-hierarchical-object-store-in.aspx#sthash.YUJnw8Op.dpuf