Posts etiquetados ‘Manual’

Cuando establecemos filtros en los destinos de los distintos conectores desde las herramientas de edición de la interfaz web de la connector appliance (versión 6.4), estos almacenan de forma errónea los caracteres especiales y por tanto, nunca son matcheados.

Por ejemplo si escribimos el filtro como se muestra en la imagen
Entrada antes de guardar

Al hacer click en aceptar y volver a editar las opciones del destino este aparece como:

FiltersError2

Es decir, las comillas son sustituidas por " que es la forma de escribir los cararcteres especiales en XML.

Para corregir este filtro y que se aplique correctamente debemos editar el fichero xml dentro del container que define el filtro para eliminar los carácteres especiales adicionales.

NOTA: No podemos realizar la modificación mediante el Diagnostic Wizard del container correspondiente ya que presenta el mismo problema

Para editar el XML:

  1. Realizamos un backup del container desde el repositorio de backups.
  2. Descargamos el backup en formato zip.
  3. Extraemos todos los ficheros del backup para que podamos trabajar cómodamente.
  4. Entre los ficheros .xml existentes con nombres del tipo 3+BET8T4BABCADtPYAQdd6g==.xml buscar el que contiene el filtro erróneo. Aparecerá la línea con formatodeviceEventClassId EQ "agent:050"
  5. Corregimos el filto eliminando los amp; sobrantes. El fitro quedaría: deviceEventClassId EQ "agent:050"
  6. Comprobamos que el filtro es correcto visualizando el xml en un navegador. El filtro debe aparecer correctamente
  7. Comprimimos en zip los ficheros de backup extraídos previamente, incluyendo los .xml modificados.
  8. Subimos el nuevo zip al repositorio de backup.
  9. Aplicamos los cambios al container correspondiente.

Hasta la proxima

Anuncios

Hoy, de hecho ahora mismo, he tenido que realizar la actualización de un cluster de cortafuegos UTM-1 que se encuentra configurado en full ha (o full hihg avaiability) desde su versión R70 a R75. De hecho la versión final es la R75.20 pero no es posible realizarla directamente y hay que dar el paso intermedio a la R75.

Como está siendo un infierno, os describo a continuación los pasos que deben darse, los problemas encontrados y su resolución.

Tenemos un clúster full ha con dos nodos. Fw1 es el nodo activo tanto de firewall como de management y es el que tiene una mayor prioridad y Fw2 es el nodo pasivo de ambos elementos que asumirá los roles sólo en caso de fallo del nodo principal.

Backup de los elementos:

Lo primero que debemos hacer es un backup completo de ambos nodos, así como de la base de datos de políticas en un equipo externo a los mismos. Así, nos curamos en salud y nos ahorramos disgustos.

1)      Backup de la configuración del equipo a través de la administración web de secureplatform. Esto nos guarda los datos básicos de red del equipo. Aseguraos de tener cerradas todas las GUIs de Smartdashboard o fallará.

2)      Exportado de la política en versión R70 – > #$FWDIR/bin/upgrade_tools/upgrade_export <nombredelfichero>

3)      Exportado de la política en versión R75

  • Para ello, descargamos las migration tools correspondientes a R75 del usercenter y las subimos al appliance principal (bien por SCP bien por FTP) a una carpeta temporal. “/var/tmp” es un buen punto.
  • Damos permiso de ejecución a las migration tools: #chmod a+x *
  • Generamos el fichero de políticas: #migrate export <nombrefichero>

Aseguraos de descargar las políticas generadas bien por FTP, bien por SCP.

4)      Ejecutad el verificador de actualización para comprobar que no existen errores a corregir. Este se encuentra en las migration tools. Si da un error, corregidlo antes de empezar.

Bien, hasta ahora, nada fuera de lo normal de cualquier actualización.

Actualización:

Los pasos son:

1)      Realizar un failover del tráfico al nodo secundario:

#cphaprob -d STOP -s problem -t 0 register

Para dar marcha atrás (por si fuera necesario)

# cphaprob -d STOP unregister

Nota: este paso supone un microcorte

2)      Entrar con Smartdashboard en el management secundario. Al entrar nos dirá que el nodo activo es fw1 y que si queremos cambiarlo. Hacemos que el management secundario sea el activo.

3)      Actualizamos el nodo principal, cargando el correspondiente paquete a través de la interfaz de administración web del nodo fw1. Ojo, en este paso, es recomendable realizar un snapshot y una actualización segura. Es más lento pero nos salvaguardará de errores en la actualización, asegurando la marcha atrás.

4)      Accedemos con la consola de dashboard de R75 al nodo fw1. Colocamos el objeto de clúster a versión R75 e instalamos políticas. Recordad desmarcar la opción de “For firewall cluster install on all members” o fallará.

5)      Actualizamos vía web el nodo fw2 con la imagen correspondiente. Al ejecutar un cpstop para actualizar, el tráfico pasará al nodo fw1 con un microcorte.

6)      Una vez sincronizado, abrimos smartdashboard en fw1. Instalamos políticas en ambos nodos.

7)      Abrimos Policy > Management high Availability y pulsamos el botón sincronizar.

Parece fácil y sencillo ¿verdad? Pues nada más lejos de la realidad.

Problemas, problemas, problemas.

Justo después de sincronizar, si refrescamos el estado de ambos cortafuegos, aparece el nodo fw2 como unreachable. Si tratas de comprobar la SIC de este nodo, se indica lo siguiente:

“SIC Status for : Not Communicating Authentication error [error no. 147] ** Check that peer SIC is configured properly and that system date and time on the SmartCenter Server and peer are synchronized.

Tratamos de resetar la SIC de este nodo pero no hay cambios, no se puede conectar.

Si cerramos el smartdashboard, no podremos conectar de nuevo con fw1 apareciendo un error:

“Connection cannot be initiated make sure the server “xx.xx.xx.xx” is up and running and you are defined as a GUI Client”

Si realizamos: # ps aux | grep cpca  el resultado aparecerá como cpca – readonly

Lo que ocurre es que durante la actualización se ha perdido un certificado de CA en el nodo principal fw1 y es por esto por el que no podemos conectar al smartdashboard o al otro nodo.

Para corregirlo ejecutamos en el nodo fw1:

#cd $CPDIR/conf

# cp sic_cert.p12 sic_cert.p12old

#cpca_client revoke_cert -n “CN=cp_mgmt”

#cpca_client create_cert -n “CN=cp_mgmt” -f $CPDIR/conf/sic_cert.p12

#cpstop

#cstart

Esto regenera los certificados y nos permitevolver a conectar al smartdashboard. OJO: ESTO PROVOCA CORTE TOTAL ya que paramos los servicios del nodo que gestiona el tráfico y el cluster no está montado.

Pero, ¿Qué pasa con el nodo secundario? Pues que aún no lo hemos conectado. Para ello:

Ejecutamos en ambos nodos #fw unloadlocal esto vuelve a PROVOCAR CORTE TOTAL  pero es necesario dado que las políticas no nos permiten conectar ambos nodos del cluster puesto que en este momento fw2 no forma parte del cluster. Reestablecemos la SIC e instalamos políticas. En este punto el firewall está operativo.

Sólo nos queda sincronizar ambos management, pero el del nodo 2 no se deja. Pese a que la SIC está establecida y funcionando, la sincronización de managements nos dice que el fw2 está unreachable. Para corregir esto:

#cpstop

#cd $FWDIR/conf/mgha

# rm ./*

#cd ..

#rm applications.C* CPMIL*

#cpstart

Ahora podemos realizar la sincronización y todo vuelve a la normalidad. Ya sólo queda la actualización a R75.20. Que cthulhu nos coja confesados.

Saludillos

La extensión de directorio activo para Exchange 2010, puede ejecutarse mediante el instalador de Exchange 2010 pero es recomendable realizarlo por línea de comandos. Además, es recomendable ejecutarlo desde el dc que tenga asignado el rol de maestro de esquema para evitar posibles problemas de conectividad con el directorio.

Para comprobar qué dc es maestro de esquema, se debe ejecutar, desde la Shell de Windows de cualquier dc:

#dsquery server -forest -hasfsmo schema

En mi caso, dicho dc es dc2. Se copian los ficheros de instalación de Exchange 2010 a la carpeta c:\Exchange.

Se instalan en la shell los requisitos previos necesarios:

#ServerManagerCmd -i RSAT-ADDS

Nos dirá que servermanager está obsoleto pero debemos ignorar este mensaje.

El usuario que usamos para la extensión debe tener permisos de administración de esquema, de dominio y de empresa, por lo que comprobamos en el active directory que poseemos los permisos necesarios.

Se accede a la Shell de Windows, como administrador y se ejecutan los comandos de extenión, desde la carpeta de Exchange creada antes:

#setup /PrepareSchema
#setup /PrepareAD
#setup /PrepareDomain

En mi caso, la ejecución daba un error en la comprobación de requisitos:

Cannot retreive schema master information from active directory.

Si se ejecutaba el comando especificando el dc maestro de esquema (setup /prepareschema /domaincontroller:dc2) el mensaje cambia indicando que dc2 no existe (lo cual es raro porque estaba ejecutando los comandos desde ahí).

Buscando posibles resoluciones de este error, se sugiere que pueda ser un error de resolución DNS pero se comprueba que todo es correcto. Para asegurar que no existe ningún problema en el dc se ejecuta:

#dcdiag

Todas las comprobaciones son correctas excepto algunos mensajes en el registro de eventos. De entre estos mensajes, se observa que no se están aplicando las directivas de grupo:

Evento de error. Id. de evento: 0x000003EE
Hora de creación: 08/30/2011 16:11:19
Cadena de eventos:
Error al procesar la directiva de grupo. Windows no pudo autenticarse en el servicio de Active Directory en un controlador de dominio (error en la llamada a la función LDAP Bind). Busque el código y la descripción del error en la ficha de detalles.

Se comprueba que la replicación con el resto de dcs es correcta. No se aplican las directivas de grupo con:

#gpupdate /force

Todo esto era debido a que en el fichero hosts de dc2 existía una entrada para dc2 y producía algún error en la resolución para las tareas de directiva de grupo y extensión de directorio. Una vez eliminada la entrada, la extensión se realiza con normalidad.

Página de microsoft con los pasos: http://technet.microsoft.com/en-us/library/bb125224.aspx