GuilleSQL :: Microsoft SQL Server, SSIS, y más !!

Consideraciones de Directorio Activo (Active Directory) para instalar SQL Server 2005, instalar Analysis Services 2005 (SSAS) e instalar Integration Services 2005 (SSIS)

Volver a: [Manual Instalación: Instalar SQL Server 2005 en Cluster, Instalar Analysis Services 2005 en Cluster, e Instalar Integration Services 2005]


Este apartado detalla las principales consideraciones de Directorio Activo para la instalación de SQL Server 2005 en Cluster y/o la instalación de Analysis Services 2005 (SSAS) en Cluster. ¿Qué es Directorio Activo? ¿Por qué nos interesa Directorio Activo en SQL Server, Analysis Services, etc.? ¿Qué Grupos de Directorio Activo son necesario crear para instalar un Cluster de SQL Server 2005 ó un Cluster de Analysis Services 2005? ¿Para que sirven estos Grupos? ¿Qué usuarios son necesarios crear en Directorio Activo para instalar un Cluster de SQL Server 2005 o instalar un Cluster de Analysis Services 2005?

Desde el punto de vista de Directorio Activo, lo primero recordar que Directorio Activo es un requisito para una instalación de un Cluster MSCS. En consecuencia, también es requisito para una instalación de SQL Server 2005 en Cluster y/o para una instalación de Analysis Services en Cluster (SSAS).

¿Qué es Directorio Activo? Para nosotros (es decir, para nuestro uso), Directorio Activo es simplemente una base de datos centralizada de cuentas de Usuario (con su pertenencia a grupos, y otros permisos), Grupos y Cuentas de Equipo, que permite almacenar todos los Usuarios, Grupos y Equipos (esto es, objetos de Directorio Activo) de nuestra Compañía, pudiendo organizarlos en carpetas denominadas Unidades Organizativas, y sobre dichas carpetas aplicar Configuraciones (Políticas de Directorio Activo) para garantizar el despliegue de determinadas configuración a lo largo de nuestra Compañía. Realmente, Directorio Activo es mucho más, y tiene multitud de consideraciones, resultando su Diseño en Factor Crítico de Éxito en muchas empresas, pero para nosotros, con la definición antes descrita, más que suficiente.

¿Por qué nos interesa Directorio Activo en SQL Server, Analysis Services, etc.? Para empezar, porque en muchas ocasiones se trata de la base de datos de los usuarios que acceden a nuestra base de datos. Sólo con ésto, ya estaría justificada su importancia. Sin embargo, Directorio Activo también almacena la cuentas de equipo de nuestros servidores, y las Políticas de Directorio Activo permiten desplegar los permisos necesarios para los usuarios que inician los servicios de SQL Server 2005, Analysis Services 2005, etc.

Antes de empezar a instalar SQL Server 2005 o de empezar a instalar Analysis Services 2005, se debe crear en Directorio Activo, los siguientes objetos de tipo Grupo de Seguridad:

  • Un Grupo de Seguridad para agrupar los usuarios utilizados para iniciar el servicio de SQL Server. En mi caso, crearé el grupo SQL Server Svcs.
  • Un Grupo de Seguridad para agrupar los usuarios utilizados para iniciar el servicio del Agente de SQL Server. En mi caso, crearé el grupo SQL Agent Svcs.
  • Un Grupo de Seguridad para agrupar los usuarios utilizados para iniciar el servicio de Búsqueda de Texto (Full-Text Search). En mi caso, crearé el grupo SQL FullText Svcs.
  • Un Grupo de Seguridad para agrupar los usuarios utilizados para iniciar el servicio de Analysis Services. En mi caso, crearé el grupo SQL Analysis Services Svcs.

Así, antes de continuar, en relación con los Grupos de Seguridad de Directorio Activo, es importante tener en cuenta que los Grupos de Seguridad de Directorio Activo se utilizan sólo y exclusivamente en las instalaciones en Cluster. Esto no quiere decir que una instalación de SQL Server sobre un servidor independiente (standalone, es decir, sin Cluster) sea totalmente distinta, simplemente en una instalación de SQL Server, Analysis Services o Integration Services sobre un servidor independiente (standalone) se utilizan Grupos Locales de la máquina que son creados de forma automática durante el proceso de instalación (por eso no se pregunta por Grupos durante la instalación, ya que son creados de forma automática). En particular, los grupos locales utilizados SQL Server 2005, Analysis Services 2005 (SSAS) e Integration Services 2005 (SSIS) son:

  • SQLServer2005DTSUser$MachineName
  • SQLServer2005MSFTEUser$MachineName$InstanceName
  • SQLServer2005MSOLAPUser$MachineName$InstanceName
  • SQLServer2005MSSQLServerADHelperUser$MachineName
  • SQLServer2005MSSQLUser$MachineName$InstanceName
  • SQLServer2005NotificationServicesUser$InstanceName
  • SQLServer2005SQLAgentUser$MachineName$InstanceName
  • SQLServer2005SQLBrowserUser$MachineName

Sin embargo, en una instalación en Cluster, sólo encontraremos los siguientes Grupos locales:

  • SQLServer2005DTSUser$MachineName
  • SQLServer2005MSSQLServerADHelperUser$MachineName
  • SQLServer2005NotificationServicesUser$InstanceName
  • SQLServer2005SQLBrowserUser$MachineName

Los términos MachineName e InstanceName, deben sustituirse por el Nombre de Máquina y el Nombre de Instancia (MSSQLSERVER para la Instancia por Defecto).

Un detalle a tener en cuenta en relación con estos Grupos (sean Grupos Locales o Grupos de Directorio Activo): Es posible aprovechar que a estos Grupos se les conceden privilegios elevados sobre sus correspondientes servicios. Así, si tenemos una Instancia de SQL Server 2005 a la cual hemos perdido acceso (ej: hemos eliminado por error los inicios de sesión miembros de sysadmin cuyas credenciales conocíamos - ej: BUILTIN\Administrators), podemos utilizar de forma temporal (Workaround) el correspondiente Grupo, haciendo miembro del mismo a un usuario de Directorio Activo, el cuál con dicha pertenencia obtendrá privilegios elevados, con los cuales poder tomar las medidas correctoras necesarias. Esta solución (dícese truquillo), me ha venido bien en algún cliente que había instalado alguna instancia de SQL Server 2005 hace un tiempo... y ya no sabía con que usuario conectarse (sobre todo, después de eliminar el inicio de sesión de BUILTIN\Administrators ;-). Lo malo de este truco, es que un Administrador de Directorio Activo, no lo tendrá muy dificil para entrar en nuestro SQL Server hasta la cocina (como se dice comunmente... ;-) Quién hizo la ley, hizo la trampa.

Continuando con el artículo, se debe crear en Directorio Activo los siguientes objetos de tipo Usuario (para los servicios SQL Server, Agente de SQL Server, SQL Browser y Analysis Services):

  • Un Usuario para iniciar la Cuenta de Servicio de SQL Server. Se debe hacer a este usuario, miembro del correspondiente grupo creado anteriormente (en mi caso, miembro de SQL Server Svcs). No es necesario que este usuario tenga permisos elevados, es decir, no es necesario que sea Administrador del Dominio ni Administrador local de la máquina (en los Nodos de Cluster). Esto lo veo mucho, y además de que no es necesario, tampoco es recomendable (es una mala práctica, pero en instalaciones pequeñas es cierto que ayuda a evitar algunos quebraderos de cabeza).
  • Un Usuario para iniciar la Cuenta de Servicio del Agente de SQL Server. Se debe hacer a este usuario, miembro del correspondiente grupo creado anteriormente (en mi caso, miembro de SQL Agent Svcs). Del mismo modo que se comentó en el caso anterior, no es necesario que este usuario tenga permisos elevados.
  • Un Usuario para iniciar la Cuenta de Servicio SQL Browser. Del mismo modo que se comentó anteriormente, no es necesario que este usuario tenga permisos elevados.
  • Un Usuario para iniciar la Cuenta de Servicio de Analysis Services. Se debe hacer a este usuario, miembro del correspondiente grupo creado anteriormente (en mi caso, miembro de SQL Analysis Services Svcs). Del mismo modo que se comentó en el caso anterior, no es necesario que este usuario tenga permisos elevados.

Mi recomendación (habitual, no siempre) es crear un único usuario para iniciar todos los servicios, o en su defecto, un usuario para Analysis Services y otro usuario para SQL Server, Agente de SQL Server y SQL Browser. El motivo de mi recomendación, es simplificar la administración. En caso de una instalación dónde la seguridad sea un factor clave de éxito, puede ser interesante utilizar distintos usuarios para cada servicio (ajustando para cada usuario los mínimos permisos necesarios, incluyendo permisos de Directorio Activo, etc.), pero claro, si la seguridad es tan importante, habrá muchas cosas de importancia que ver además que éste detalle. En mi caso, crearé el usuario SQLSvc que utilizaré para todos los servicios.

Los derechos que debe tener el usuario utilizado para iniciar Microsoft SQL Server 2005, son los siguientes:

  • Actuar como parte del sistema operativo (act as part of the operating system)
  • Iniciar sesión como trabajo por lotes (log on as a batch job)
  • Iniciar sesión como servicio (log on as a service)
  • Bloquear páginas en memoria (lock pages in memory)
  • Reemplazar un testigo a nivel de proceso (replace a process level token)
  • Omitir la comprobación de recorrido (bypass traverse checking)

Por defecto, no es necesario realizar ninguna acción para configurar estos derechos. Sin embargo, en instalaciones con configuraciones complicadas de Directorio Activo (múltiples políticas en niveles superiores, políticas que sobrescriben, unidades organizativas que impiden la herencia, etc.), es importante conocer estos permisos para poder garantizar que el usuario utilizado para iniciar el servicio de SQL Server dispone de los mismos, en cuyo caso, deberemos de realizar las correspondientes configuraciones en una o varias políticas (GPOs) de Directorio Activo. Esta es una tarea sencilla pero muy delicada, ya que algunos de estos derechos también deben de concederse a otros usuarios del sistema, de tal modo, que si sobrescribimos dichas configuraciones con una políticas nuestra asignando dichos derechos al usuario de SQL Server 2005 y se nos olvida incluir a los usuarios del sistema, podemos encontrarnos con serios problemas (y por supuesto, olvidarnos de que arranque SQL Server).

También recomiendo utilizar un usuario para iniciar el servicio de Microsoft Cluster, y un usuario diferente para iniciar los servicios de SQL Server (un usuario o varios usuarios, uno para cada Servicio). Esto es debido a que el usuario utilizado para iniciar el servicio Microsoft Cluster, debe ser miembro del grupo de Administradores Locales, luego tendrá permisos elevados sobre las máquinas (Nodos del Cluster) que no son necesarios para el usuario que inicia los servicios de SQL Server. También es muy importante recordar, que ni el usuario utilizado para iniciar el servicio Microsoft Cluster ni el usuario utilizado para iniciar los servicios de SQL Server, tienen que ser Administradores del Dominio (algo, que me he encontrado en demasiadas ocasiones).

Del mismo modo, en caso de disponer múltiples servidores para SQL Server y para Analysis Services (sean instancias en la misma o diferentes máquinas), debe plantearse si utilizar los mismos usuarios y los mismos grupos para los servicios en las diferentes instalaciones, o bien, utilizar diferentes usuarios y grupos. Mi recomendación es utilizar los mismos usuarios y grupos, pero claro, eso podría llegar a ser un pequeño compromiso de seguridad, por lo cual, habrá que volver a poner en la Balanza la Seguridad y la Facilidad de Gestión y Mantenimiento. Por poner un ejemplo, el Grupo de Seguridad de Directorio Activo utilizado para iniciar el servicio de SQL Server será miembro de sysadmin en las instancias de SQL Server en que se utilice. Por lo cual, la pertenencia a dicho grupo de Directorio Activo, concede permisos elevados en todas las instancias en que sea utilizado, y además, cualquiera de dichas instancias se están ejecutando bajo una cuenta de servicio con permisos elevados sobre el resto de instancias. La seguridad es muy importante, y el hecho de que en mi entorno de Laboratorio (o en pequeñas instalaciones) puedan hacerse excepciones, no significa tomar la excepción como la regla... es decir, es preferible tomar una mala decisión sabiendo lo mala que es (y sus implicaciones), que tomar una decisión sin conocer lo mala que puede ser y cómo nos puede impactar.

Es recomendable utilizar una o varias Unidades Organizativas (OUs) en Directorio Activo, dónde ubicar dichos objetos (y también para los objetos correspondientes a las cuentas de Equipo de los Nodos del Cluster), con el objetivo de facilitar la gestión (ej: Políticas o Directivas de Grupo – GPOs, etc.). A continuación muestro un pantallazo del caso particular de mi laboratorio.

Pantalla capturada de la herramienta administrativa Active Directory Users and Computers (ADUC) mostrando la organización de los objetos de Directorio Activo utilizados para la realización del presente Artículo (instalar SQL Server 2005, instalar Analysis Service 2005, e instalar Integration Services 2005).

En muchas ocasiones, resulta de especial interés bloquear la herencia de políticas de Directorio Activo en las Unidades Organizativas (OUs) que utilicemos (Block Policy inheritance), para evitar que nos puedan aplicar configuraciones de otras Políticas de Directorio Activo (existentes en niveles superiores de la Jerarquía de OUs de Directorio Activo), que puedan impactar en nuestra instalación de SQL Server. Bloquear la herencia de Políticas en Directorio Activo es una configuración tan sencilla como delicada, pues en función de las Políticas de nivel superior, etc, podemos estar aplicando configuraciones incompletas que pueden generar multitud de errores en el Visor de Sucesos (Evento Log), impedir el inicio correcto de servicios de Windows (ej: Servicio de Microsoft Cluster, y en consecuencia, de SQL Server y de Analysis Services), etc. Lo digo por experiencia, aunque no quiero entrar en mayor detalle porque cada instalación es un mundo, pero recordar lo delicado de esta configuración y comentarlo con los Administradores de Directorio Activo.

También resulta de interés denegar el permiso de inicio de sesión local y por Terminal Services, a los usuarios utilizados para iniciar los servicios que vamos a instalar (SQL Server, Agente de SQL Server, Búsqueda de Texto – FullText, etc.), principalmente por motivos de seguridad, configuración que también se realiza a través de Políticas de Directorio Activo (consultar a vuestro Administrador de Directorio Activo).

Por último, en algunas instalaciones me he encontrador el error Cannot Generate SSPI Context, por lo que deberemos estar al tanto del mismo para su resolución (ver el anterior enlace).

Volver a: [Manual Instalación: Instalar SQL Server 2005 en Cluster, Instalar Analysis Services 2005 en Cluster, e Instalar Integration Services 2005]


[Fecha del Artículo (UTC): 17/08/2008]
[Autor: GuilleSQL]



Escribir un Comentario

Para poder escribir un comentario, debe Iniciar Sesión con un usuario.

Si no dispone de un usuario, puede Registrarse y hacerse miembro.

Si dispone de un usuario, pero no recuerda sus credenciales de acceso, puede Restablecer su Contraseña.

Miembros de
Miembros de GITCA (Global IT Community Association)

Menu de Usuario
  Iniciar Sesión
  Registrarse
  Restablecer Contraseña
  Ventajas de Registrarse

Acerca de
  Contigo desde Oct 2007
  771 usuarios registrados
  86146 pageloads/mes
  Ranking Alexa 498160

Social Networks
Sigue a Portal GuilleSQL en Linkedin !!
Sigue a Portal GuilleSQL en Twitter !!



Archivo

Marzo de 2017 (3)
Enero de 2017 (4)
Junio de 2016 (1)
Mayo de 2016 (2)
Abril de 2016 (2)
Septiembre de 2015 (2)
Agosto de 2015 (2)
Junio de 2015 (10)
Mayo de 2015 (4)
Abril de 2015 (8)
Marzo de 2015 (11)
Octubre de 2014 (3)
Septiembre de 2014 (7)
Agosto de 2014 (5)
Julio de 2014 (2)
Mayo de 2014 (4)
Abril de 2014 (4)
Marzo de 2014 (4)
Febrero de 2014 (1)
Enero de 2014 (5)
Diciembre de 2013 (8)
Noviembre de 2013 (2)
Octubre de 2013 (7)
Septiembre de 2013 (6)
Agosto de 2013 (1)
Julio de 2013 (6)
Junio de 2013 (11)
Mayo de 2013 (7)
Abril de 2013 (6)
Febrero de 2013 (5)
Enero de 2013 (7)
Diciembre de 2012 (12)
Noviembre de 2012 (13)
Octubre de 2012 (5)
Septiembre de 2012 (3)
Agosto de 2012 (6)
Julio de 2012 (4)
Junio de 2012 (1)
Mayo de 2012 (2)
Abril de 2012 (7)
Marzo de 2012 (16)
Febrero de 2012 (9)
Enero de 2012 (5)
Diciembre de 2011 (10)
Noviembre de 2011 (10)
Octubre de 2011 (4)
Septiembre de 2011 (5)
Agosto de 2011 (2)
Julio de 2011 (2)
Junio de 2011 (4)
Mayo de 2011 (2)
Abril de 2011 (6)
Marzo de 2011 (4)
Febrero de 2011 (10)
Enero de 2011 (5)
Diciembre de 2010 (6)
Noviembre de 2010 (4)
Octubre de 2010 (8)
Septiembre de 2010 (4)
Agosto de 2010 (1)
Julio de 2010 (3)
Mayo de 2010 (5)
Abril de 2010 (6)
Marzo de 2010 (8)
Febrero de 2010 (3)
Enero de 2010 (1)
Diciembre de 2009 (9)
Noviembre de 2009 (14)
Octubre de 2009 (2)
Septiembre de 2009 (8)
Agosto de 2009 (2)
Julio de 2009 (10)
Junio de 2009 (9)
Mayo de 2009 (10)
Abril de 2009 (9)
Marzo de 2009 (3)
Febrero de 2009 (2)
Enero de 2009 (3)
Noviembre de 2008 (2)
Octubre de 2008 (2)
Septiembre de 2008 (2)
Agosto de 2008 (5)
Julio de 2008 (5)
Junio de 2008 (1)
Mayo de 2008 (3)
Abril de 2008 (2)
Marzo de 2008 (2)
Febrero de 2008 (2)
Enero de 2008 (5)
Noviembre de 2007 (2)
Octubre de 2007 (2)






Esta información se proporciona "como está" sin garantías de ninguna clase, y no otorga ningún derecho.
This information is provided "AS IS" with no warranties, and confers no rights.

Copyright © 2007 GuilleSQL, todos los derechos reservados.
GuilleSQL.com y GuilleSQL.net son también parte de Portal GuilleSQL.

Visitas recibidas (Page Loads) en GuilleSQL (fuente: StatCounter):

screen resolution stats
Visitas