Este contenido está protegido por contraseña. Para verlo introduce tu contraseña a continuación:

Anuncios

Esta semana ha saltado la alerta debido a la vulnerabilidad CVE-2014-0160 más conocida como HeartBleed que abre un enorme agujero para el acceso a passwords, claves de encriptado… en OpenSSL.

Si has llegado hasta aquí y no tienes ni idea de qué es heartbleed, tal vez quieras leer esto: http://heartbleed.com/ y después cambiar tus passwords de sitios importantes (como el banco).

Para Checkpoint, el único producto afectado es Check Point Mobile VPN for iOS & Android. Para el resto podéis estar tranquilos. https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk100173

Si tenéis un ArcSight y estáis preocupados por su seguridad, dejad de hacerlo. La librería utilizada por los ArcSight en el mercado es openssl (version 0.9.8r) que no se encuentra afectada por la vulnerabilidad.

F5 parece tener algunos productos vulnerables a Heartbleed. El hilo de recomendaciones para su resolución es:  http://support.f5.com/kb/en-us/solutions/public/15000/100/sol15159.html

Algunos fabricantes que manejo (como Fortinet, Bluecoat o Microsoft) no han dicho “oficialmente” nada pero no parecen afectados.

Una lista no oficial de fabricantes afectados, la encontraréis aquí: http://www.kb.cert.org/vuls/byvendor?searchview&Query=FIELD+Reference=720951&SearchOrder=4

Si tienes un servidor SSL y quieres saber si estás afectado por el problema, puedes probar aquí: http://filippo.io/Heartbleed

Espero que os sirva de algo!

Saludillos!

 

UPDATE: Parece ser que FORTINET si que tiene productos afectados. La lista de productos y la solución, las podéis encontrar:  http://www.fortiguard.com/advisory/FG-IR-14-011/

Tip: “Unknown NAS” en cisco ACS 4.2

Publicado: 10/28/2013 en Manual
Etiquetas:,

Si os aparecen estos eventos en un cisco ACS 4.a significa que el equipo que está intentando acceder no se encuentra dado de alta en el ACS.

Saludillos

Los que conocéis las connector appliances de ArcSight sabéis que el acceso a las mismas está tremendamente cerrado ya que, pese a ser un software propietario instalado sobre un proliant G7, son consideradas “cajas negras”.

Para acceder, Arcsight nos ofrece una consola web por HTTPS bastante completa, pese a ser un poco engorrosa en cuanto a visualizacion de logs y troubleshooting. Esta consola es la que se usa para gestión, configuración… de los conectores, incluyendo aquellos instalados fuera de la consola con la gestión remota activada. Si el acceso web deja de funcionar, nos quedamos sin uno de los puntos vitales de nuestra arquitectura de ArcSight.

Si esto ocurre pero los conectores siguen funcionando (siguen enviando eventos a los destinos) el acceso por SSH a root es una opción aunque por desgracia, al estar el sistema cerrado, para realizar este acceso necesitaremos la respuesta a un Challenge que debe ser obtenida a través del soporte de HP. Si queremos ahorrarnos este engorroso proceso, el truco es sencillo:

  1. Accedemos a la consola del appliance bien por método teclado+pantalla, conexión al puerto serie del appliance o mediante ILO (en caso de tenerlo configurado)
  2. Accedemos con nuestro usuario local al appliance. Para aquellos que tengan autenticación remota el método es igualmente válido.
  3. ejecutamos status process
  4. ejecutamos restart process web.
  5. En caso de que siga inaccesible, reiniciar apache con el mismo procedimiento.

Espero que os sirva.

Saludillos.

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

Generando el CSR para cada container

Si no contamos con un certificado previo y no hay límite de firma:

1. Backup de certificados remote_management.cer y remote_management.p12

2. Crear una JKS Keystore con su Keypair (Se inserta la indormación del certificado de CA. Debe tener la misma password que el keystore original)

c:\arcsight\testing\current\jre\bin\keytool -keystore c:\arcsight\testing\current\user\agent\remote_management.jks -storepass changeit -genkeypair -alias tomcat -keysize 2048 -keyalg RSA

3. Se genera el CSR (certificate Signing Request)

c:\arcsight\testing\current\jre\bin\keytool -keystore c:\arcsight\testing\current\user\agent\remote_management.jks -storepass changeit -certreq -alias tomcat -file c:\arcsight\testing\current\user\agent\remote_management.csr

4. Se envía el CSR a la CA para su firma y se obtiene el certificado firmado

5. Importar el certificado de CA (Se debe importar el certificado de CA al almacén de confizanza anted de este paso)

c:\arcsight\testing\current\jre\bin\keytool  -keystore c:\arcsight\testing\current\user\agent\remote_management.jks -storepass changeit -importcert -alias whateverca -file c:\arcsight\testing\current\user\agent\ca.crt

6. Importar el certificado firmado.

c:\arcsight\testing\current\jre\bin\keytool  -keystore c:\arcsight\testing\current\user\agent\remote_management.jks -storepass changeit -importcert -alias tomcat -file c:\arcsight\testing\current\user\agent\remote_management.cer

7. Convertir el keystore a formato p12 

c:\arcsight\testing\current\jre\bin\keytool -importkeystore -srckeystore c:\arcsight\testing\current\user\agent\remote_management.jks -srcstorepass changeit -deststorepass changeit -srcstoretype JKS -deststoretype PKCS12 -destkeystore c:\arcsight\testing\current\user\agent\remote_management.p12

8. Reiniciar el container

CON EL CERTIFICADO YA GENERADO PARA HTTPS

 

1. Una vez se ha generado el CSR y se ha importado el certificado a través de la interfaz web disponemos tanto del certificado firmado por la CA como de la clave privada necesarias para la comunicación. Estas pueden encontrarse en los ficheros:

/opt/arcsight/userdata/platform/ssl.crt/server.crt -> certificado de CA
/opt/arcsight/userdata/platform/ssl.crt/server.pem -> clave privada

2. A través del acceso SSH, generamos el fichero en formato p12 que contendrá el keypair correspondiente con el comando:

# openssl pkcs12 -export -in server.crt -inkey server.pem -out server.p12

3. Se agregan los certificados de CA a server.p12 a través de keytool o keytoolgui.

4. Se realiza una copia de seguridad de los ficheros existentes:

/opt/arcsight/container_X/current/user/agent/remote_management.cer
/opt/arcsight/container_X/current/user/agent/remote_management.p12

5. Se substituyen los ficheros por los creados con el certificado de CA:

/opt/arcsight/container_X/current/user/agent/remote_management.cer -> sustituye por server.crt
/opt/arcsight/container_X/current/user/agent/remote_management.p12 -> sustituye por server.p12

6. Se reinicia el container, enviando el comando restart a través de la web console.

Si tenéis que hacer troubleshooting de un tráfico rechazado en un Fortigate, podéis sufrir una pequeña pesadilla para saber que está ocurriendo. Resulta que el logado de tráfico en este firewall es un tanto peculiar y puede dar más de un quebradero de cabeza. Funciona así:

Si la regla es de tráfico permitido, sólo quedarán registrado en los ficheros de logs aquellos paquetes permitidos en la regla y que atraviesen correctamente el firewall. Si el paquete es rechazado por cualquier motivo (porque no esté permitido en la regla o se rechace por otro motivo que no se encuentre entre las funcionalidades UTM con log propio) no queda registrado este Reject en ninguna parte y no podemos saber si la regla está mal, si el paquete original no está llegando o si el firewall se lo esta comiendo porque tiene hambre.

Para saber que porras pasa con nuestro paquete, Fortigate dispone de dos comandos que nos facilitarán la vida enormemente: Diagnose Sniffer Packet y Diagnose Debug Flow.

Diagnose Sniffer Packet

Es el equivalente al tcpdump en el universo Fortinet y nos permite visualizar los paquetes registrados a nivel de kernel por cualquiera de las interfaces del firewall o por todas a un tiempo. Se ejecuta desde el CLI con el siguiente formato:

diagnose sniffer packet {interface | all}  ‘net z.z.z.z/p and/or host x.x.x.x and/or port yyy’  [options]

Para realizar una búsqueda más precisa y no ver un montón de lineas a lo Matrix tenemos las opciones:

  • net/prefix : Muestra todo lo existente para una red
  • host : Muestra sólo lo relativo a un host.
  • port: Muestra sólo lo relativo a un puerto concreto
  • and/or: Permite combinar varios de los filtros anteriores.

Las opciones son:

  • 1: Imprime la cabecera de los paquetes
  • 2: Imprime la cabecera y la informacion de capa IP de los paquetes
  • 3: Imprime la cabecera y la informacion desde capa TCP/Ethernet de los paquetes (si está disponible)
  • 4: Imprime la cabecera de los paquetes con el nombre de la interfaz
  • 5: Imprime la cabecera y la informacion de capa IP de los paquetes con el nombre de la interfaz
  • 6: Imprime la cabecera y la informacion desde capa TCP/Ethernet de los paquetes (si está disponible)con el nombre de la interfaz

Ejemplos:

diagnose sniffer packet any ‘net 10.0.0.0/8 and host 172.16.16.14 and port 3389′

diagnose sniffer packet any ‘host 10.4.131.97 and host 172.16.16.14 and port 3389′ 4

Diagnose Debug Flow

Es una herramienta que nos permite ver el camino que sigue un paquete dentro de el Fortigate, las reglas que aplica al mismo, las rutas …

Se ejecuta a través de CLI y os adjunto algunos ejemplos que os permitirá su uso según queráis filtrar las reglas aplicadas a una IP.

# diagnose debug enable
# diagnose debug flow show console enable
show trace messages on console
# diagnose debug flow filter add 10.10.20.30
# diagnose debug flow trace start 100

El resultado es:

id=36871 trace_id=1132 msg=”vd-root received a packet(proto=17, 10.10.20.30:1029->192.168.110.11:161) from internal.”
id=36871 trace_id=1132 msg=”allocate a new session-00012042″
id=36871 trace_id=1132 msg=”find a route: gw-172.20.120.2 via wan1″
id=36871 trace_id=1132 msg=”find SNAT: IP-172.20.120.230, port-54409″
id=36871 trace_id=1132 msg=”Allowed by Policy-5: SNAT”
id=36871 trace_id=1132 msg=”SNAT 10.10.20.30->172.20.120.230:54409″

Creo que la salida es lo suficientemente intuitiva para que la comprendáis fácilmente.

EDIT: Para ver aún más detalle de lo que ocurre en el paquete:

#diag deb flow show function enable 
#diagnose debug flow show iprope enable 
#diagnose debug flow filter daddr 1.1.1.0 1.1.1.255 
#diag deb flow trace start 100 
#diag deb enable

El resultado:

id=20085 trace_id=16 func=print_pkt_detail line=4751 msg=”vd-root received a packet(proto=1, 2.2.2.1:1->1.1.1.4:2048) from port1. type=8, code=0, id=1, seq=1969.”
id=20085 trace_id=16 func=init_ip_session_common line=4902 msg=”allocate a new session-001088ad”
id=20085 trace_id=16 func=iprope_dnat_check line=4645 msg=”in-[port1], out-[]”
id=20085 trace_id=16 func=iprope_dnat_tree_check line=835 msg=”len=0″
id=20085 trace_id=16 func=iprope_dnat_check line=4658 msg=”result: skb_flags-00800000, vid-0, ret-no-match, act-accept, flag-00000000″
id=20085 trace_id=16 func=vf_ip4_route_input line=1587 msg=”Match policy routing: to 1.1.1.4 via ifindex-33″
id=20085 trace_id=16 func=vf_ip4_route_input line=1597 msg=”find a route: flags=00000000 gw-1.1.1.4 via VPNIfaz”
id=20085 trace_id=16 func=iprope_fwd_check line=701 msg=”in-[Interna], out-[VPNIfaz], skb_flags-00800000, vid-0″
id=20085 trace_id=16 func=__iprope_tree_check line=543 msg=”gnum-100004, use addr/intf hash, len=2″
id=20085 trace_id=16 func=__iprope_check_one_policy line=1697 msg=”checked gnum-100004 policy-593, ret-matched, act-accept”
id=20085 trace_id=16 func=__iprope_user_identity_check line=1523 msg=”ret-matched”
id=20085 trace_id=16 func=__iprope_check_one_policy line=1893 msg=”policy-593 is matched, act-accept”
id=20085 trace_id=16 func=iprope_fwd_auth_check line=753 msg=”after iprope_captive_check(): is_captive-0, ret-matched, act-accept, idx-593″
id=20085 trace_id=16 func=fw_forward_handler line=697 msg=”Allowed by Policy-593:”
id=20085 trace_id=16 func=ipsecdev_hard_start_xmit line=122 msg=”enter IPsec interface-VPNIfaz”
id=20085 trace_id=16 func=esp_output4 line=1149 msg=”IPsec encrypt/auth”
id=20085 trace_id=16 func=ipsec_output_finish line=519 msg=”send to 2.2.2.20 via intf-VPNIfaz”

 

Espero que os sirva!

Saludillos.

Error De Active directory en Controlador de Dominio.

En ocasiones existen las siguientes entradas en los registros de eventos de los servidores Windows Server 2008.

Nombre de registro:System
Origen: Microsoft-Windows-GroupPolicy
Fecha: 14/08/2012 12:11:03
Id. del evento:1006
Categoría de la tarea:Ninguno
Nivel: Error
Palabras clave:
Usuario: SYSTEM
Equipo: WS2008
Descripción:
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.

En los detalles aparece: “ErrorCode” 82

La solución es eliminar la entrada correspondiente al servidor que presenta el problema del fichero de hosts.

Para comprobar que todo es correcto, ejecutar desde la consola:

gpupdate /force

Saludillos

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

En esta entrada trato de resumir las conclusiones de tres días de intenso y tedioso troubleshooting, investigacion, aprendizaje express y prueba y error de numerosos métodos de resolución hasta lograr reunir todos los datos que encontraba con cuenta gotas en la Technet y dar con la solución definitiva. Espero que este post ahorre trabajo de investigación a través de las engorrosas páginas de la Technet a alguien.

Me notificaron que las búsquedas de Sharepoint del portal corporativo de uno de mis clientes habían dejado de funcionar. Casualmente habían dejado de funcionar el mismo día que tuvimos un problema con el Sharepoint completo relacionado con el antivirus que había provocado la necesidad de reinicio de los servidores de Sharepoint.

Antes de continuar, os explico la arquitectura, aunque esta es poco relevante para la solución. Disponen de un clúster de balanceo de carga para el servicio de Sharepoint formado por dos servidores (SP1 y SP2) y un cluster de alta disponibilidad que aloja las bases de datos correspondientes a Sharepoint (bdd). Para el servicio de búsquedas disponen de un único servicio compartido (SharedService) del cual el servidor SP1 es el índice y servidor de consulta y el SP2 se usa tan sólo como servidor de consulta.

Bueno pues, manos a la obra. A la hora de investigar un problema en Sharepoint, el registro de eventos de windows es vuestro amigo. Es bastante chivato y proporciona información útil. En este caso, observamos en un pricipio los errores:

Nombre de registro:Application
Origen: Office Server Search
Fecha: 19/06/2012 13:37:25
Id. del evento:10038
Categoría de la tarea: Servicio de búsqueda
Nivel: Advertencia
Palabras clave: Clásico
Usuario: No disponible
Equipo: SP2
Descripción:
El equipo de consulta ‘SP1’ ha salido de la rotación a causa del error El índice de contenido está dañado. 0xc0041800. Se volverá a intentar dentro de 900 segundos. Componente: cc575544-4acf-490f-bed4-d23cd4b56d90

——————————————————————————————————————————————————————————–

Nombre de registro: Application
Origen: Office Server Search
Fecha: 19/06/2012 13:37:25
Id. del evento:10039
Categoría de la tarea: Servicio de búsqueda
Nivel: Advertencia
Palabras clave: Clásico
Usuario: No disponible
Equipo: SP1
Descripción:
El intento del equipo de consulta ‘SP1’ no se ha producido a causa del error El índice de contenido está dañado. 0xc0041800. Se volverá a intentar dentro de 900 segundos. Componente: cc575544-4acf-490f-bed4-d23cd4b56d90

Y tras el reinicio de los servicios de búsqueda con net stop osearch (se inicia sólo automáticamente) comienza a aparecer también el registro:

Nombre de registro:Application
Origen: Office Server Search
Fecha:19/06/2012 15:20:04
Id. del evento:4138
Categoría de la tarea: Servidor de índice de contenido
Nivel: Error
Palabras clave: Clásico
Usuario: No disponible
Equipo: SP1
Descripción:
Se han detectado daños de índice en el componente ShadowMerge del catálogo Portal_Content. La referencia de la pila es .Componente: cc575544-4acf-490f-bed4-d23cd4b56d90

Y aquí es cuando os ahorro el calvario. Este error viene del reinicio realizado al servidor de índices en el momento equivocado y en el lugar equiv… no, no. Sólo en el momento equivocado, dado que el servidor estaba realizando el registro de transacciones del índice en el momento del reinicio y estas han quedado en estado inconsistente. Al haberse fastidiado el índice, las búsquedas no funcionan aunque exista otro nodo de consulta. Tampoco funcionan los rastreos de contenido. Aparecen como “En ejecución” pero no están haciendo nada. Puedes comprobarlo accediendo al registro de rastreo y comprobando que no existe ninguna entrada con fecha posterior a la corrupción del índice. ¿Por qué este bloqueo no canta en ningun lado? Pues no lo sé, tal vez a los rastreos de índice les guste vaguear.

Para arreglarlo tenemos que seguir unos sencillos pasos (una vez te los sabes…)

1) Paramos completamente los servicios de búsqueda de Sharepoint en ambos nodos. Es decir, los desconfiguramos y desactivamos a nivel de Sharepoint en los dos nodos.(ojo, antes de hacer esto, asegúrate de apuntar todos los parámetros del servicio) Esto puede hacerse desde el menú de servidor en la administración central de Sharepoint o con el comando de consola:

stsadm –o osearch –action stop

Stsadm lo podreis encontrar en C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN.

2) Paramos los servicios de búsqeda de ambos servidores desde el administrador de servicios o con el comando

net stop osearch

En este caso el servicio se mantiene detenido.

3) Accedemos a la ruta de almacenamiento de índices del servidor de índice. Allí habrá una carpeta cuyo nombre-número-chorizo coincida con el componente que se indica como dañado en los registros de eventos anteriores. En nuestro caso, habrá una carpeta llamada cc575544-4acf-490f-bed4-d23cd4b56d90. Renombramos esta carpeta, la movemos a otra localización o si somos unos temerarios, la borramos.

4) Desde la administración central de Sharepoint reconfiguramos y arrancamos los servicios de búsqueda de los nodos tal y como estaban antes. Puede que no reaccione y tengais que ejecutar en la consola:

stsadm –o osearch –action start

5) Levantamos los servicios de búsqueda desde el administrador de servicios o con el comando:

net start osearch

6) Configuramos el servicio SharedService para usar SP1 como generador de índice. Para ello, en la pestaña de “Administración de servicios compartidos” de la administración central de Sharepoint pinchamos sobre “SharedServices” (nombre de nuestro servicio, si el vuestro se llama “pepito”, pues debeis pulsar en él) y aparecerá un desplegable con las opciones de configuración, donde en el SSP, podreis configurar el indizador.

A partir de aquí, la carpeta de índice debería haberse regenerado y el servicio de búsqueda debería funcionar de nuevo. Sólo queda asegurar que el nuevo contenido añadido durante el problema se incluya en la búsqueda y esto se consigue realizando un rastreo completo de las áreas de búsqueda.

Eso es todo amiguitos. Si quereis mi dirección para mandarme jamones de agradecimiento por esta valiosa información, dejad un comentario con vuestro email y os la haré llegar encantada.

Saludillos.