Escenario de partida
Partimos de un Bosque de Directorio Activo, formado por Controladores de Dominio Windows 2000 Server. El nivel funcional del dominio y del bosque, es Windows 2000 Nativo en ambos casos. Denominaremos al domino, como guillesql.local con nombre NetBIOS de GUILLESQL.
Las máquinas sobre las que se tiene instalado ISA Server 2006 Enterprise, montan el Sistema Operativo Windows Server 2003 R2, y son servidores miembros del dominio de directorio activo mencionado (guillesql.local). Denominaremos a los servidores ISA01.guillesql.local e ISA02.guillesql.local. Se tiene montado un único CSS.
Así, uno de los ISA Server 2006 (ej: ISA01.guillesql.local), actúa como Configuration Storage Server (CSS), es decir, contiene el servicio ADAM (Active Directory Application Mode) que utiliza ISA Server 2006 como repositorio de configuración. Este servicio ADAM, está funcionando sobre el puerto TCP 2171 (recordemos que ADAM es un servidor LDAP, y que el puerto por defecto de LDAP es el puerto TCP 389).
Sin embargo, el otro ISA Server 2006 (ej: ISA02.guillesql.local), no es capaz de sincronizar con el CSS, produciéndose el siguiente error:
ISA Server cannot connect to the Configuration Storage Server ISA01.guillesql.local for one of the following reasons:
- The Configuration Storage server is not available.
- There are general networking or authentication issues.
- The firewall policy for the array is incorrectly configured.
A continuación, se muestra una pantalla captura del error ISA Server cannot connect to the Configuration Storage Server:
Como comentábamos, este error queda registrado en el Visor de Sucesos con Event ID 21238 y Event Source Microsoft ISA Server Control.
Diagnóstico y solución al error ISA Server cannot connect to the Configuration Storage Server
En nuestro caso, el CSS estaba disponible y funcionando correctamente, de hecho, el problema afectaba a un único ISA Server 2006, ya que el ISA Server 2006 que tenía en local el CSS, funcionaba y sincronizaba OK.
No existían problemas de red, ni de configuración incorrecta de las políticas de Firewall. De hecho, se podía comprobar con un Telnet, que se podía acceder con éxito al puerto TCP del CSS (el puerto TCP 2171) desde el servidor que no conseguía sincronizar (ISA02.guillesql.local).
Está claro: se trata de un problema de Autenticación.
Llegados a este punto, teniendo en cuenta que estamos hablando de Directorio Activo y de problemas de Autenticación, lo primero que se me viene a la cabeza es Kerberos y los SPN (Service Principal Name).
Por gracia o desgracia, ya me he pegado varias veces con problemas y configuraciones aparentemente parecidas, como es el caso de la Autenticación Integrada y Delegación de Kerberos en IIS, el error Cannot Generate SSPI context y la autenticación de Kerberos en SQL Server, etc.
Investigando por estos lares, encontramos el problema. Parece ser, que al montar ISA Server 2006 Enterprise sobre servidores miembros de un dominio de Directorio Activo, las conexiones remotas al CSS (es decir, al ADAM o servidor LDAP), deben utilizar la Autenticación de Kerberos (o al menos, así lo hemos deducido). En consecuencia, para que la Autenticación de Kerberos pueda utilizarse, es necesario que estén registrados en Directorio Activo los correspondientes Service Principal Names (SPN) asociados al ADAM (es decir, al LDAP), como ocurre con otros servicios (ej: IIS, SQL Server, etc).
Descargamos de la Web de Microsoft la herramienta setspn.exe, que es la utilidad que nos permitirá mostrar, crear, modificar y eliminar los SPNs en Directorio Activo (ojo, necesitaremos permisos de Administrador en Directorio Activo, con un usuario moñas, no tira). Podemos comprobar con setspn.exe, los SPNs actualmente registrados para la cuenta de equipo del servidor (isa01.guillesql.local). Para ello, ejecutaremos el comando setspn.exe -l isa01 con lo que obtendremos el siguiente resultado:
Registered ServicePrincipalNames for CN=ISA01,CN=Computers, DC=guillesql,DC=local:
MSSQLSvc/ISA01.guillesql.local HOST/ISA01 HOST/isa01.guillesql.local |
Como se puede observar, no existe ningún SPN asociado a LDAP. Teniendo en cuenta que el ADAM no se está corriendo en el puerto 389 (que es el puerto por defecto para LDAP), procedemos a crear dos nuevos SPN, teniendo en cuenta el puerto TCP utilizado por el ADAM o CSS (el puerto TCP 2171), y los nombres corto y largo del servidor que hospeda el CSS. En particular, se crean los siguientes SPNs sobre la cuenta de equipo del ISA Server que ejecuta el ADAM o CSS:
- ldap/isa01:2171
- ldap/isa01.guillesql.local:2171
Esto lo realizamos ejecutando los siguientes comandos setspn:
- setspn.exe -a ldap/isa01:2171 isa01
- setspn.exe -a ldap/isa01.guillesql.local:2171 isa01
Y ya está. Pasados unos momentos, ISA Server 2006 empezó a sincronizar correctamente, y el error ISA Server cannot connect to the Configuration Storage Server desapareció (aquí paz, y después gloria, como decía un amigo ;-).
Resuelto el problema, nos surgió una duda, ya que en otra instalación similar, no ocurrió este problema (ojo, que se trataba de un dominio de Directorio Activo sobre Windows Server 2003). Sin embargo, comprobamos con SETSPN en dicha instalación, que estaban registrados los correspondientes SPN para LDAP en el puerto 2171, aunque en dicha instalación, no fue necesario hacer este trabajo manual, ni se produjo el presente error. Cosas de la vida.
Poco más por hoy. Espero que el presente frikiconsejo, os resulte de ayuda.