Archivos de la categoría ‘Windows’

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/

Solicitamos un certificado de servidor de la Fábrica Nacional de Moneda y Timbre (FNMT) ya que queremos demostrar que somos oficiales y no nos autofirmamos los certificados. Nos vamos a la web de la FNMT y tras pasar un precioso infierno de procedimientos engorrosos de solicitud, pago y procedimientos engorrosos de descarga, obtenemos nuestro par de claves en formato pfx. En este follón de procedimientos no voy a entrar y os lo dejo como terreno para explorar a los administradores valientes en busca de aventuras.

Una vez se dispone del certificado en formato pfx conteniendo la clave privada y la clave pública (supongamos un fichero llamado glados.pfx), se genera el almacén de claves, que debe contener tanto el par de claves almacenado en el pfx como el certificado de la CA o autoridad certificadora correspondiente (en este caso el certificado Raiz de la FMNT) que complete la ruta de certificación. El almacén de claves se llamará .keystore que es el nombre del almacén por defecto en Tomcat y al que no parece hacer mucha gracia que le cambies el nombre.

Se descarga de la web de la FMNT el certificado raíz y se añade al almacén con el comando de Keytool:

keytool -import -alias root -keystore “\.keystore” -trustcacerts -file “FMNTCA.cer”

Esto es importante, ya que los gestores gráficos de claves NO realizan esta funcion y nos toca hacerlo a manita o el quisquilloso Tomcat se negará a mostrarnos la página protegida con este certificado.

Tras esto, se importa el par de claves almacenado en el pfx a nuestro almacén de claves. Podemos hacerlo mediante GUI o mediante comando:

keytool -import -alias tomcat -keystore “\.keystore” -file “glados.pfx”

Sustituimos el .keystore original por el .keystore recién creado en la carpeta de configuracion y reiniciamos los servicios de Tomcat. Y voilá el certificado mostrado a partir de ese momento es el nuevo certificado instalado.

Espero que os ayude.

Saludillos

Decidimos cambiar las bases de datos de nuestro servidor de Exchange a un nuevo disco con mejores características de velocidad de acceso y estabilidad. Cuando el Servidor de Exchange no está en alta disponibilidad el procedimiento es muy sencillo y puede realizarse desde la consola de administración de Exchange. Sólo es necesario tener en cuenta que el grupo de replicación debe estar parado y la base de datos desmontada antes de comenzar el procedimiento.

Para un entorno CCR, la cosa cambia. Para comenzar, el procedimiento debe hacerse desde la shell de Exchange ya que uno de los comandos requiere un parámetro no configurable a través de la consola. Y para continuar, el movimiento de los ficheros se realiza a mano. Los pasos son:

Paramos el grupo de replicación con Suspend-StorageGroupCopy -Identity ‘mailbox\Grupo Buzones’ donde “mailbox” es el nombre de nuestro cluster de servidores Mailbox y “Grupo Buzones” es el grupo de replicación que deseamos mover. En este punto no hay pérdida de servicio.

Peliconsejo: Comprueba que los nombres coinciden con los configurados en el servidor hasta el último espacio o no funcionará.

Ahora desmontamos la base de datos. Esto provoca corte de servicio: Dismount-database -Identity ‘mailbox\Grupo Buzones\database donde “database” es el nombre de la base de datos a mover.

Copiamos (Importante COPIAR no mover, por si hay que dar marcha atrás) los ficheros del grupo de buzones a su nueva ubicación que es la que configuraremos a continuación. Este paso tardará más a más grande sea la base de datos.

Cambiamos las rutas al nuevo disco tanto de la base de datos como del grupo de replicación:

Move-StorageGroupPath -Identity ‘mailbox\Grupo Buzones‘ -LogFolderPath ‘I:\Program Files\Microsoft\Exchange Server\Mailbox\Grupo Buzones’ -SystemFolderPath ‘I:\Program Files\Microsoft\Exchange\Mailbox\Grupo Buzones’ -ConfigurationOnly

Move-DatabasePath -Identity ‘mailbox\Grupo Buzones\database -EdbFilePath ‘I:\Program Files\Microsoft\Exchange\Mailbox\Grupo Buzones\database.edb’ -ConfigurationOnly

Donde los parámetros  path determinan la nueva ruta física. El parámetro -ConfigurationOnly es necesario y no puede ser ejecutado por consola.

Ya podemos reestablecer el servicio montando la base de datos: mount-database -Identity ‘mailbox\Grupo Buzones\database

Peliconsejo: Si os aparece un mensaje de que la base de datos no existe y os pregunta si deseáis crear una en blanco, es que habéis metido la gamba. Cancelad, revisad que el nuevo path escrito en el comando sea correcto y ejecutad de nuevo los comandos de cambio de ubicación pero ahora con los datos correctos.

 Por ultimo reiniciamos la copia  Restart-StorageGroupCopy -Identity ‘mailbox\Grupo Buzones’

Hace unas semanas tuve que que arreglar el desaguisado que había causado un administrador irresponsable. Intentando liberar espacio de disco, tuvo la “genial” idea de mover algunos logs de exchange sin utilizar el procedimiento anteriormente publicado en este blog.

Cuando por fin ampliamos los discos y restauramos los logs (al menos había sido precavido y sólo los había movido) dos de los grupos de almacenamiento de mailbox no levantaban correctamente quedando en estado de error. Al tratar de resincronizar, el error indicaba la falta de un fichero de log cuya numeración no se encontraba entre los existentes.

Lo primero que debemos hacer es ejecutar un comando que nos permitirá conocer el estado real de la replicación de los grupos de almacenamiento. get-storagegroupcopystatus. Estos procedimientos siempre se ejecutan desde la Shell de Exchange.

La salida tendrá el formato:

Name Summary CopyQueue ReplayQueue LastInspectedLogTime
StorageGroup1 Healthy 0 0 6/14/2007 4:42:01 p.m.

Los resultados que nos indican que existen problemas con la base de datos son que en cualquiera de las dos colas aparezca un número distinto a 0 o que en Summary aparezca “error”  Podemos hacer que los datos en ambos nodos coincidan pero para ello tenemos que asegurarnos que la base de datos del nodo principal no está corrupta y que el servicio de correo funciona con normalidad.

Para poder regenerar los datos de forma que se encuentren sincronizados entre ambos nodos el procedimiento que se debe de ejecutar desde el nodo pasivo:

  • Paramos la replicación: Suspend-StorageGroupCopy –id ‘clustermailbox\grupoalmacenamieto’
  • Eliminamos la base de datos del nodo secundario y restauramos desde el nodo 1:Update-storagegroucopy -id ‘clustermailbox\grupoalmacenamieto’ -DeleteExistingFiles
Hay que tener en cuenta que la base de datos almacenada en el nodo pasivo se eliminará durante el procedimiento, por si deseáis realizar antes una copia de seguridad.
Durante la ejecución,
Tras esto, activamos de nuevo la replicación de los grupos de almacenamiento y comprobamos que ya no existe error.

Imaginad esto: nos quedamos sin espacio en el disco de Exchange que almacena los logs de las bases de datos. El correo deja de funcionar. Queremos hacer espacio, pero ¿cómo?

Lo primero y más importante, Los logs de Exchange no deben eliminarse o moverse a la ligera de su ubicación original. Estos logs, almacenan transacciones de la base de datos y son fundamentales para que la información de la misma sea coherente. La información de alguno de estos logs se ha escrito en la base de datos correctamente y ya no son necesarios pero hay una cantidad indeterminada de logs, cuya información aún no haya sido almacenada correctamente en la base de datos y cuya eliminación puede provocar inconsistencias en la información que requieran una restauración de la misma desde backup.

Lo recomendable para vaciar el disco de logs, es la realización de un backup (incremental o Full) exitoso sobre la base de datos de buzones, lo que provoca la eliminación de los logs de forma automática y correcta. En caso de que esto no sea posible y como procedimiento de emergencia, se puede realizar el borrado de los logs no necesarios mediante el siguiente método:

  •  Se localizan los logs necesarios para la base de datos en cuestión. Esto debe hacerse leyendo el contenido del fichero de Checkpoint de la base de datos. Este fichero se encuentra en la ruta principal del grupo de almacenamiento y su nombre responde al patrón EXX.chk. Una vez localizado este fichero, se lee su contenido mediante el comando:

C:\Program Files\exchsrvr\bin\eseutil.exe” /MK “<ruta del fichero EXX.chk>

Este comando nos da una salida de la que debemos revisar el parámetro Checkpoint: Checkpoint (0x21EE,11B0,9A). De estos tres valores de Chekpoint, el importante es el primero que es el número de secuencia del último fichero de logs del que se ha realizado el commit. Por lo que, tomando el ejemplo anterior, el último log necesario es EXX21EE.log y los posteriores pueden eliminarse de forma segura

  • Una vez localizado el log, se pasa a parar el grupo de almacenamiento y desmontar la base de datos en cuestión. Esto provoca cortes de servicio ya que dicho grupo de almacenamiento afectado deja de funcionar durante el procedimiento.
  •  Se mueven los logs no necesarios a otra unidad con espacio. No se borrarán hasta estar seguros de que todo funciona correctamente.
  •  Se vuelven a poner en línea, primero la base de datos y después el grupo de almacenamiento. Si tras un tiempo de pruebas todo es correcto, se puede proceder al borrado de los ficheros movidos.

Como referencia os incluyo el link del blog oficial de desarrolladores de Exchange:

http://blogs.technet.com/b/exchange/archive/2004/05/12/130556.aspx

Las bibliotecas de documentos de sharepoint 2007 tienen la posibilidad de adjuntar documentos de forma sencilla, mediante email. El usuario, no tiene más que enviar un correo a la dirección de la biblioteca con el fichero adjunto y una descripción del mismo en el cuerpo del correo. Pero para que esto funcione, necesitamos que nuestro clúster de Sharepoint sea capaz de recibir estos correos a través de la infraestructura de Exchange existente.

Por suerte, sólo tenemos que seguir unos sencillos pasos de configuración.

1. Se debe crear un alias DNS que será el nombre del clúster de sharepoint: sharepoint.contoso.es A IP_servidor

2. Desde el administrador de la infraestructura de Exchange, vamos a servidor> hub transport y creamos un conector de envío. Estos conectores indican una serie de direcciones de correo que el Exchange escucha e indican a que servidor deber de enviarse estos correos. El dominio de recepción de correos será @sharepoint.contoso.es y el Smarthost de este conector de envío será el alias DNS que acabamos de crear “sharepoint.contoso.es”.

3. En cada uno de los nodos de la granja de Sharepoint instalamos el servicio SMTP y lo configuramos como arranque automático.

4. En cada uno de los nodos de la granja de Sharepoint debemos configurar algunos parámetros del servidor virtual SMTP. Para la configuración de este servidor, debemos acceder a la consola de configuración de IIS 6 de cada uno de los nodos del clúster.

a. Desplegamos el árbol hasta el servidor virtual de SMTP > botón derecho > Propiedades. En la pestaña de acceso, creamos un nuevo Rely y se configura como IP de rely las IPs de los HT de Exchange ( una si va a ser un sólo servidor el que se encargue, varias si es un clúster).
b. En la pestaña de entrega > avanzadas cambiamos el FQDN del servidor virtual de SNMP por el alias sharepoint.contoso.es para mantener el espacio de nombres coherente.
c. Dentro del sitio de SNMP > en el objeto de dominio > botón derecho > nuevo dominio y creamos uno nuevo para sharepoint.contoso.es.

5. Reiniciamos el servicio SMTP de los servidores sharepoint para que los cambios tengan efecto.

6. En la administración central de Sharepoint > Configuración de correo saliente se configura con el servidor sharepoint.contoso.es.

Et voilá, con estos pasos, y la configuración de la cuenta de recepción dentro de la propia biblioteca, ya se pueden recibir los correos.

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

Administro un clúster de servidores activo-activo que da soporte a todas las páginas web corporativas de uno de nuestro clientes. Estos servidores cuentan con un IIS 7 sobre el que corren distintas aplicaciones web, incluyendo una cosa “preciosa” llamada Sharepoint 2007. No niego la utilidad de sharepoint de cara a la gestión de información corporativa y visualización vía web pero la administración del sistema es, en ocasiones, una autentica pesadilla.

El caso es que hace unos días, sin conocer aún las causas, los ficheros de configuración del IIS de uno de los nodos, se corrompieron durante una de las sincronizaciones del clúster. Resultado: las aplicaciones iban sólo a veces (cuando el acceso se hacía contra el nodo correcto del clúster). Para solucionarlo, se regeneraron los ficheros a partir de un backup pero las bases de datos de sharepoint quedaron en un estado extraño. Desde la recuperación empezaron a aparecer en el registro de aplicación los errores:

Nombre de registro:Application
Origen: Office SharePoint Server
Fecha: 12/05/2011 16:00:00
Id. del evento:5555
Categoría de la tarea:Perfiles de usuario
Nivel: Error
Palabras clave:Clásico
Usuario: No disponible
Equipo: sharepoint1
Descripción:
Error al intentar sincronizar la aplicación Web IDAPLICACION, base de datos de contenido IDBDD Mensaje de excepción: Se encontró un Id. de sitio duplicado: IDDELSITIO (http://URLEMPRESA). Esto puede deberse a la restauración de una base de datos de un conjunto de servidores a otro sin quitar primero la base de datos original para, a continuación, ejecutar stsadm -o preparetomove. Si es esa la causa, se puede usar el comando stsadm -o preparetomove con la opción de línea de comandos -OldContentDB para resolver el problema..
XML de evento:

Nombre de registro:Application
Origen: Office SharePoint Server
Fecha: 12/05/2011 16:00:00
Id. del evento:7888
Categoría de la tarea:General de Office Server
Nivel: Error
Palabras clave:Clásico
Usuario: No disponible
Equipo: sharepoint1
Descripción:
Se ha detectado una excepción en tiempo de ejecución. Detalles.
Mensaje: Se encontró un Id. de sitio duplicado: IDDELSITIO (http://URLEMPRESA). Esto puede deberse a la restauración de una base de datos de un conjunto de servidores a otro sin quitar primero la base de datos original para, a continuación, ejecutar stsadm -o preparetomove. Si es esa la causa, se puede usar el comando stsadm -o preparetomove con la opción de línea de comandos -OldContentDB para resolver el problema.
Detalles técnicos:
Microsoft.Office.Server.UserProfiles.ProfileSynchronizationDuplicateSiteIDException: Se encontró un Id. de sitio duplicado: IDDELSITIO (http://URLEMPRESA). Esto puede deberse a la restauración de una base de datos de un conjunto de servidores a otro sin quitar primero la base de datos original para, a continuación, ejecutar stsadm -o preparetomove. Si es esa la causa, se puede usar el comando stsadm -o preparetomove con la opción de línea de comandos -OldContentDB para resolver el problema.
en Microsoft.Office.Server.UserProfiles.ContentDBSynchronizer.RegisterSitesForSynch(Guid[] rgGuid, Int32 nGuids, Object dummy)
en Microsoft.Office.Server.UserProfiles.SynchCollection`2.FlushAdds()
en Microsoft.Office.Server.UserProfiles.ContentDBSynchronizer.AddRemoveSites(String strFirstChangeToken, SPChangeToken lastChangeToken)
en Microsoft.Office.Server.UserProfiles.ContentDBSynchronizer.SynchContentDB()
en Microsoft.Office.Server.Diagnostics.FirstChanceHandler.ExceptionFilter(Boolean fRethrowException, TryBlock tryBlock, FilterBlock filter, CatchBlock catchBlock, FinallyBlock finallyBlock)

Estos errores aparecen cada hora en el registro. La solución consta de tres sencillos pasos que pueden hacerte perder tres días si no estás muy avezado en administracion de sharepoint. Los pasos a ejecutar en la consola (ejecutar > cmd)
1) Detectar la base de datos no sincronizada.

C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\BIN>stsadm -o sync -listolddatabases 5
2) Corregir la duplicación de Id de base de datos:

stsadm -o preparetomove -site http://URLEMPRESA -oldcontentdb IDBDD
Esta información se saca del registro de eventos.

3) Eliminar las notificaciones de sharepoint

stsadm -o sync -deleteolddatabases 0

Ojo, si no realizamos este último paso, el problema estará arreglado (la sincronización se comenzará a realizar correctamente) pero las notificaciones de error seguirán apareciendo cada hora en el registro de eventos.

Espero que os sea útil y no perdais en esto tanto tiempo y tanta salud mental como yo.

¡¡Saludillos!!