Cómo resolver errores de acceso denegado con stsadm -o retractsolution

Tenemos una granja de 2 servidores que ejecuta MOSS 2007 SP1. Soy miembro del grupo de Administradores en ambos servidores.

También soy miembro del grupo de administradores de granjas.

Necesitaba actualizar algunas soluciones, así que, naturalmente, comencé con el comando stsadm retractsolution en las soluciones antiguas. No importa qué solución intente ejecutar el comando, obtengo 'Acceso denegado'.

Afortunadamente, el archivo de registro de ULS me da un poco más de información:

System.Data.SqlClient.SqlException: no se puede abrir la base de datos "SharePoint_AdminContent" solicitada por el inicio de sesión. El inicio de sesión falló. Error de inicio de sesión para el usuario '*** Mi inicio de sesión de dominio ***'.

Lo que parece extraño aquí es el hecho de que SharePoint está intentando conectarse con MI cuenta utilizando la autenticación integrada de Windows en lugar de conectarse con la cuenta de servicio de granja configurada. Por supuesto, mi cuenta no tiene acceso a la base de datos de contenido administrativo.

Entonces la pregunta es: ¿Es necesario que mi cuenta tenga permisos para la base de datos de Contenido de administrador para realizar tareas de administración? Espero que no, ¿hay algo más terriblemente mal?

La respuesta corta es "sí" para la mayoría de las actividades que realizará a través de STSADM en las bases de datos SQL.

Para la inmensa mayoría de los comandos STSADM que se ejecutan directamente en la API de SharePoint (en lugar de programar tareas para llevar a cabo una acción), el contexto de seguridad dentro del cual se ejecutan los comandos es suyo: el usuario que inició sesión. Como ha visto en el ejemplo que citó, el contexto de su cuenta de usuario es el que se utilizará para la retracción. Si no tiene los derechos apropiados en SQL para llevar a cabo la operación, fallará (como ha visto).

Esto contrasta con la mayoría de las actividades que realizará a través de la interfaz de usuario (es decir, Administrador central). En el ejemplo que citó, retraer la solución a través de Central Admin resultaría en que el comando se ejecute dentro del contexto de la cuenta de servicio de la granja, ya que esa cuenta es la identidad del grupo de aplicaciones para el sitio de Central Admin. Resultado: la retracción tendrá éxito aunque usted (personalmente) no tenga permisos para la base de datos asociada.

Si su entorno está configurado de manera tal que su cuenta no tenga acceso de nivel de administrador a las bases de datos dentro de la granja de servidores de SharePoint, recomendaría realizar tantas actividades como sea posible a través de la interfaz de usuario para evitar el tipo de problemas de contexto de seguridad que está encontrando . Descubrirá que puede hacer la mayor parte de lo que necesita hacer de esa manera. Sin embargo, una excepción notable que viene a la mente es agregar una solución (STSADM -o addolution) al almacén de soluciones de la granja de servidores: no existe una contraparte de la interfaz de usuario del comando STSADM.

Alternativamente, podría hacer algo similar a lo que MadlyAlive sugirió (es decir, iniciar sesión con la cuenta de servicio de granja) ... aunque Microsoft no requiere ni recomienda el acceso de administrador local para la cuenta de servicio de granja. También podría tener su cuenta con el conjunto mínimo de permisos dentro de SQL Server necesarios para llevar a cabo sus operaciones.

Para obtener más información, consulte el artículo de KB de Microsoft en http://support.microsoft.com/kb/896148 .

Resumen de la regla general: STSADM usa el contexto de su cuenta, Central Admin usa el contexto de la cuenta del servicio de granja.

¡Espero que esto ayude!

Esto puede estar evitando el problema central, pero al intentar ejecutar un comando stsadm similar

stsadm -o preupgradecheck

Estaba recibiendo acceso denegado también. Pero ejecutar el símbolo del sistema como administrador me permitió ejecutarlo.