Cambio de Hora en Chile

Como es de conocimiento mundial, el 27 de febrero hubo un “mega-terremoto” con devastadoras consecuencias, tanto en pérdida de vidas humanas como en pérdidas de miles de hogares y cuantiosos daños a la infraestructura pública.

En lo estrictamente informático, esto trajo muchas consecuencias, como las que revisa Luis Montenegro en su blog sobre planes de contingencia, pero una de las consecuencias más importantes que el Gobierno de Chile determinó retrasar el cambio de horario de invierno, el cual se aplaza desde la media noche del sábado 13 de marzo (cuando debiese ocurrir) a la medianoche del sábado 3 de abril (nueva fecha)

Microsoft liberó un hotfix que actualiza los sistemas operativos para este cambio de horario, el cual puede ser descargado en la siguiente dirección:

Le recomiendo leer detenidamente la información referente al hotfix y luego solicitarlo desde el link “Ver y Solicitar la descarga de la revisión” que aparece al inicio de la página. Se recomienda instalar la actualización lo antes posible.

image

 

Aprovecho la oportunidad para responder un par de preguntas que ya he recibido:

  1. ¿Cómo se aplica el hotfix en un entorno virtualizado con Hyper-V?
    El Hotfix DEBE ser aplicado tanto en la partición padre (host) y como en las particiones hijas (guests). Hay que tener cuidado con las máquinas virtuales que están sincronizando la información de horas con con el host de virtualización.
  2. ¿Cómo afecta este cambio a los Usuarios/Administradores de Exchange Server?
    Las citas del calendario se verán desfasadas 1 hora durante el período entre el 13 de marzo y el 3 abril.
    Una vez aplicado el hotfix, hay 4 formas para enfrentar esto:
    A. No hacer nada, y decir a los usuarios que confirmen sus reuniones por mail o por teléfono.
    B. Pedir a los usuarios que revisen y re-programen manualmente sus reuniones para ese período de tiempo.
    C. Utilizar la herramienta “Time Zone Data Update Tool for Microsoft Outlook” en cada estación de trabajo.
    D. Utilizar la herramienta “Microsoft Exchange Calendar Update Configuration Tool” , con la cual se pueden actualizar las citas en el calendario centralizadamente, pero ojo, pues es un proceso complejo.
    Como pueden ver, hay varias opciones y la mejor dependerá de su entorno particular (cantidad de usuarios, uso de outlook para calendarios, etc.)

Más información:

Cualquier duda pueden hacerla como comentario, o a través de la lista de distribución del Grupo Latinoamericano de Usuarios de Exchange (G.L.U.E.)

Gonzalo

Relay Bueno: Permitiendo Relay en Exchange 2000/2003?

NOTA:

Este post fue publicado originalmente en mi anterior blog el
16/08/2007. 
Hice algunos cambios, modificaciones y adiciones para mejorar el artículo

 

En los artículos previos explicamos:
 

Ahora, me gustaría hablar un poco sobre cómo efectivamente y de forma «segura» permitir el Relay (Reenvío) a través de nuestro servidor SMTP.

La pregunta obvia es: Por qué razón alguien querría permitir Relay en sus servidores de correo?
Razones pueden haber varias: Clientes de correo qué sólo poseen compatibilidad para POP3/IMAP4 necesitarán un servidor de correo SMTP para enviar mensajes (Por ejemplo, aún hay dando vueltas clientes de correo antiguos o dispositivos móviles y PDAs que no soporten ActiveSync.), usuarios que viajan, etc.

La esencia del Relay Bueno es que sólo permitiremos el envío de correo para los usuarios del dominio que se autentifiquen con nuestro servidor de correo. En el artículo sobre Cómo enviar Correo Electrónico a mano, Parte II: SMTP Autenticado, vimos este comportamiento. Ahora les mostraré cómo hay que configurar el Servidor para que funcione de ésta forma.

Paso 1. Cerrar el Open Relay

En Exchange 2003 el Open Relay viene cerrado por defecto. De todas formas, les sugiero comparar la configuración de su servidor con la mostrada en éste artículo:

Verificando las opciones de Relay en Exchange 2000/2003.

Paso 2. Permitir el Relay SOLO a Usuarios Autenticados

En las propiedades del servidor Virtual SMTP (Exchange System Manager -> … -> Servidor -> Procolos -> SMTP -> SMTP Virtual Server), en la lengüeta Acceso (Access) presionamos el botón de Autenticación (Autentication). Tendremos un par de ventanas como las del siguiente dibujo:

img01

En la ventana de Autenticación, deben estar seleccionados los 3 checkboxes principales (como muestra la figura).
Ahora presionamos el botón Usuarios (Users) y se abrirá una nueva ventana.

En esta nueva ventana debemos dejar solamente el grupo de Usuarios Autenticados (Authenticated Users), con los permisos de Enviar (Submit) y Reenviar (Relay).

En este último paso realizamos la configuración más importante: le dijimos al servidor smtp que los usuario autenticados y sólo éstos (es decir, los usuarios que se identificaron exitosamente con su nombre de usuario y contraseña al establecer la sesión smtp), pueden reenviar correo a través de este servidor smtp a direcciones que no pertenecen a la organización (dominio smtp).

img02

Luego cerramos todas las ventanas y reiniciamos el servicio SMTP para que se apliquen los cambios.

Finalmente, debo recordar que toda la información de usuarios y sus claves que se envían al servidor smtp (y al pop3 y al imap4), viajan en texto plano (o codificadas en Base64), por lo que es trivial con un sniffer poder obtener estas contraseñas.
En Consecuencia, es recomendable usar otros protocolos de envío/recepción de correo (Mapi, RPC sobre HTTP(S), HTTPS, ActiveSync, HTTPS, etc), o al menos cifrar las comunicaciones a estos servicios usando TLS (con certificados digitales para cada protocolo).

Gonzalo

 

Etiquetas de Technorati: ,