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.
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).
