Anteriormente había escrito sobre las distintas versiones de Exchange 2003 que se pueden encontrar en:
http://www.eseutil.net/que-version-de-exchange-elegir
Hace unos días Microsoft publicó las features y diferencias entre la version Standard y Enterprise de Exchange 2007. La info está disponible en:
http://www.microsoft.com/exchange/preview/edition_compare.mspx
Saludos,
Vernocchi Pablo
Finalmente luego de muchas expectativas de aquellos que trabajamos con Exchange llegó el momento, a fin del 2007 se liberara la versión final de Exchange 2007. Seguramente si usted no le presta atención a los nuevos lanzamientos de producto, en este momento se estará preguntando que tiene de especial esta nueva versión que no hayamos visto hasta ahora. La respuesta es simple…. TODO.
Nos encontramos ante un salto similar o incluso mayor al que vimos entre las versiones 5.5 y 2000. Pero empecemos desde el principio.
Instalando Exchange 2007.
Antes de comenzar la instalación deberemos cumplir una cantidad de pre-requisitos relacionados tanto con el hardware como con el software. Es importante recalcar que si bien existirá una versión de 32 bits disponible para pruebas, las instalaciones en producción deberán correr sobre plataformas X64, con un mínimo recomendado de 2 GB de RAM + 5 MB adicionales por usuario alojado. En este equipo se deberá instalar un Windows 2003 SP1 o R2 (obviamente 64 bits), el cual tendrá que estar unido a un dominio de Windows 2000 en modo nativo como mínimo. Adicionalmente deberemos instalar .NET Framework 2.0, Microsoft Management Console 3.0, Microsoft Command Shell (MSH) y en caso de instalar el rol de acceso a cliente necesitaremos IIS. En cuanto estos requisitos sean cumplidos podremos comenzar con la instalación de Exchange, ya sea en un único servidor o dividiendo los roles en múltiples equipos.
Divide y triunfaras.
La nueva arquitectura basada en roles dará a los administradores la posibilidad de instalar servidores íntimamente relacionados con las funciones que cumplirán en la organización, reduciendo significativamente la superficie de ataque.
Entremos un poco más en detalle, los roles pueden ser separados en 2 categorías bien definidas. Por un lado el Edge Transport o Servidor de borde y por otro los 4 roles restantes.
Edge Transport: Sera el servidor encargado de recibir los correos provenientes de Internet, en él se aplicaran los filtros de higiene relacionados con el flujo de mensajes y actuara como Relay de SMTP. Este rol es opcional.
Hub Transport: Ya sea tratando con mensajes provenientes del edge server de la DMZ o directamente desde Internet, este rol será el primer contacto del mensaje con nuestro forest. Adicionalmente será el encargado del ruteo de todos los mensajes de la organización, tanto internos como externos. Por lo tanto es el lugar ideal para configurar filtros de contenido y journaling. Este rol es requerido.
Mailbox: Como su nombre lo indica, es el rol encargado de hostear las bases de datos que serán utilizadas tanto para mailboxes como para carpetas públicas. Este rol es requerido.
Client Access: El rol de acceso a clientes será necesario si queremos utilizar OWA, ActiveSync, Outlook Anyware (RPC/http), IMAP, POP3 o web services. Este rol es opcional.
Unified Mesaging: Sera el encargado en la comunicación con la PBX para brindar servicios de llamadas a VoIP, Mensajes de voz y fax. Este rol es opcional
Como puede ver las posibilidades y combinaciones existentes para cada implementación son muchas y podrán ajustarse a las necesidades más diversas. Desde una implementación con un único servidor hasta una más compleja que incluya redundancia en todos sus roles y almacenamientos.
Ya está instalado. Y ahora?
Como no podía ser de otra manera la nueva administración de Exchange esta a la altura de los cambios de infraestructura. En esta versión Microsoft introduce un cambio radical en la administración de su producto. La nueva Exchange Management Console, mejor organizada y menos compleja que su predecesora.
Esta íntegramente basada en PowerShell, por lo tanto todas las acciones que realicemos por medio de la interfaz gráfica serán traducidas a cmdlets (comandos de powershell) que luego ser ejecutadas por un intérprete. Esto da como resultado una interfaz de línea de comandos robusta y con posibilidades de alterar todos los objetos de la organización, lo que disminuirá en gran medida las tareas de administración rutinarias, ya que podrán ser reemplazados por scripts altamente portables.
Para ir cerrando…
Definitivamente 2 hojas no son suficientes para repasar todas las virtudes de esta versión, por lo tanto me voy a limitar a simplemente a nombrar algunas características que dejamos afuera y son dignas de mención: Autodiscover, Local Continuos Replication, Cluster Continuos Replication, Messaging Records management, Address rewriting, disclaimers, Sender & IP reputation, Calendaring, Exchange Toolbox.
Espero que la sola mención de estas funciones los incite a la lectura y a seguir investigando.
Leandro Amore y Pablo Vernocchi para la revista Nexx IT
Luego de casi dos años en estadío de beta, Microsoft lanzó la versión final de Windows Defender (en beta 1 se llamaba Microsoft Antispyware), como resultado de la adquisición de Giant.
La descarga se puede hacer desde http://www.microsoft.com/athome/security/spyware/software/default.mspx sin costo alguno para los usuarios con Windows XP.
Windows Defender ya estará incluído en Windows Vista.
Saludos,
Vernocchi Pablo
Gente,
Estamos generando un nuevo tipo de eventos de capacitación. En medio de proyectos enormes, y lanzamientos de productos nuevos (EVO: Exchange, Vista, Office), Microsoft lanza un reality show de IT.
Básicamente empezamos a hacer trabajo de consultoría en una empresa con dos dominios NT4 y una estructura muy desalineada, para convertirla en una empresa altamente tecnológica y automatizada.
El evento, que durará aproximadamente 10 meses, se llevará a cabo con el mismo escenario, y con consultores de Argentina, Chile, Uruguay, Paraguay y Bolivia.
A los interesados, les dejo un link para que puedan enterarse más sobre esta impresionante propuesta:
Saludos,
PV
Microsoft lanzó IE 7 final!
Disponible para su descarga desde:
http://www.microsoft.com/windows/ie/downloads/default.mspx
Saludos,
Vernocchi Pablo
En esta oportunidad veremos como redirigir los accesos al OWA para que los usuarios sólo tengan que acceder al servidor web ingresando http://nombredeservidor/, sin la necesidad de agregar el /Exchange al final.
De esta manera, facilitaremos mucho el acceso pudiendo, por ejemplo, crear un registro en el DNS para que se acceda via http://webmail.dominio.com/
Redirigir automáticamente las peticiones a /Exchange
Luego de hacer estas configuraciones, los usuarios podrán acceder al Webmail sin la necesidad de tipear /exchange en el browser:
1. Abrir la consola de Internet Information Server (IIS6) desde las Administrative Tools.
2. Expandir Web Sites
3. Hacer clic con el botón secundario del Mouse sobre el Default Web Site y seleccionar Propierties.
4. Seleccionar la solapa “Home Directory”.
a. Seleccionar “A redirection to a URL”
b. En el campo “Redirect to” escribir /Exchange
c. Tildar “A directory below URL entered”
Reenviar peticiones http a https:
Luego de configurar los siguientes pasos, IIS automáticamente redirigirá las peticiones http a https, con lo cual los usuarios no deberán ingrear https:// en la barra de direcciones. Previamente debemos haber instalado un certificado para SSL y configurado en los directorios virtuales de Exchange.
1. Crear una carptea en c:\inetpub\wwwroot llamada owaasp
2. Descargar el archivo owahttps.zip y descomprimirlo en la carpeta previamente creada
3. Abrir la consola de Internet Information Server (IIS6) desde las Administrative Tools
4. Expandir sites, expandir Default Web Site.
5. Sobre el directorio virtual Exchange hacer clic con el botón secundario del Mouse y seleccionar Propierties.
6. Ir a la solapa Custom Errors
7. Buscar de la lista 403;4 y seleccionar Edit
8. En Message Type Seleccionar URL, escribir /owaasp/owahttps.asp, y aceptar todas las ventanas.
9. Ubicar el directorio OWAASP dentro del Default Website
10. Hacer clic con el botón secundario del Mouse y seleccionar Propierties.
11. En la sección Application Settings hacer clic en Create y luego seleccionar ExchangeApplicationPool en el campo “Application Pool”.
Espero que les haya sido útil,
Saludos,
Vernocchi Pablo
Amigos,
En esta oportunidad los invito a participar de una conferencia que estaré brindando para el GLUE (Grupo Latinoamericano de Usuarios de Exchange) sobre migración de Exchange 5.5 a 2003.
El link para la registración (gratuita) es:
http://msevents.microsoft.com/cui/EventDetail.aspx?culture=es-AR&EventID=1032311033&EventCategory=1
—————–
Además, el 26 de Octubre estaré brindando otra conferencia. Esta vez el tema será Windows Vista, y será en el Auditorio del MUG. Los temas a tratar serán:
• Interfaz gráfica
– Windows Search
• Seguridad en Vista
– Hardening de Sistema operativo
– Malware
– Firewall
– UAC
– BitLocker
– Defaults
• Mejoras en conexiones de red
• Políticas de grupo
– Overview
– Nuevas funcionalidades de Group Policies
– Funcionalidades actualizadas.
Esta conferenica es arancelada, y tiene un costo de 20 pesos para los socios del MUG y de 60 para los no socios.
El link para registrarse es:
http://www.mug.org.ar/Eventos/2355.aspx
Los espero!!
Buenas a todos,
Hace un tiempo actualicé la version de WordPress (software utilizado para el Blog) y se corrompió la búsqueda. En realidad andaba bastante mal.
Es por eso que, temporariamente, habilité la búsqueda de Google en el sitio, para darles la posibilidad de buscar en la cantidad de información que hay.
Gracias a todos y disculpen las molestias.
Saludos,
PV
Ya tenemos todo configurado. Entendemos las diferencias entre las distintas posibilidades dentro de la seguridad ofrecida por estándares y aplicadas en Exchange.
Hemos logrado firmar un mensaje digitalmente y asegurarnos que el contenido no fue modificado en tránsito pero… ¿qué pasa si alguien más está husmeando las conexiones?
Acá les pego una porción de una conexión smtp con un mensaje sin cifrar:
Y acá tenemos los resultados de una comunicación estándar entre un servidor Exchange y un servidor de un tercero:
Si juntamos todos los pedazos de conexión obtenemos:
Así es, ese texto lo puede leer cualquiera que se interponga entre nuestro servidor y el servidor de destino. Pero, para todas los problemas tenemos una solucón.
En esta oportunidad, veremos como proteger la confidencialidad de un correo, evitando que cualquiera lo pueda leer, y veremos su resultado.
El primer intento de cifrar un mensaje, puede no ser tan exitoso:
Y justamente se debe a que el usuario de destino no tiene un certificado, por lo tanto no tenemos acceso a sus claves para cifrarlo. Sin mucho más, se le otorga un certificado a ese usuario y con eso se resuelve el inconveniente.
Para esta demo, iniciamos sesión con el usuario Jorge, e intentamos enviar un mail cifrado a Pablo:
También veremos en la pantalla un ícono diferente, pero esta vez azul, informando que el correo está encriptado:
Como medida de seguridad, ese mensaje no es accesible via “Vista previa”, solamente se puede leer al abrirlo:
Y, al abrirlo, nos encontramos con un batallón de íconos y candados:
Al hacer clic sobre el ícono azul, que indica encripción, podemos ver los detalles del certificado, aí como también el nivel de encripción utilizado:
Y ahora, la prueba final. Sniffeando una conexión SMTP enviando un correo encriptado, obtenemos los siguientes resultados:
Cumplimos nuestra meta, ahora el mensaje se transmite de manera tal que no se puede interpretar a simple vista.
Saludos,
Vernocchi Pablo
Se larga la segunda parte de este artículo!
En esta oportunidad vamos a ver cómo configurar las firmas digitales en los correos electrónicos, para agregar Integridad a la información transportada y, además, brindar Autenticación en el mensaje ya que esa firma sólamente nos pertenece a nosotros.
Paso a paso. Lo primero que vamos a necesitar para implementar S/MIME es un certificado. Podemos utilizar la infraestructura de Certificados que provee Microsoft o adquirir los certificados através de terceros como Verising (pago) o CACert.org (grauito), entre otros. Si optamos por la de Microsoft (gratuita, parte de Windows Server) necesitaremos instalarla. Para ello he redactado una pqueñísima guia disponible en http://www.eseutil.net/como-instalar-una-ca-certificate-authority-en-windows-2003
***NOTA***
Este artículo utiliza la CA provista por Microsoft
******
Bien, como primer paso obtendremos un certificado digital para nuestra cuenta de usuario. Para ello abrimos el navegador y vamos a la URL de nuestra CA interna, iniciando sesión con nuestro usuario y contraseña:
En las tareas disponibles, seleccionamos “Request a Certificate”:
Como tipo de certificado, seleccionamos “User Certificate” y hacemos clic en submit:
Saldrá una advertencia de seguridad, diciéndonos que el sitio web está intentando obtener un certificado en nuestro nombre. Como confiamos en este sitio, elejiremos “Yes”:
Y ahora a instalar el certificado y nuevamente aceptar la ventana de advertencia de seguridad:
——————————————————
Primera etapa finalizada. Ya tenemos certificado para firmar digitalmente nuestros correos y para poder encriptarlos. Ahora, a proteger nuestra confidencialidad!:
Abrimos el Outlook, escribimos un mensaje nuevo y hacemos clic en el boton “Opciones”:
Luego, Opciones de Seguridad:
Y ahora sí, seleccionamos el checkbox “Add digital signature to this message”. Si queremos agregar nuestra firma a todos los correos salientes, por default, tenemos que ir (dentro del Outlook) a Herramientas –> Opciones –> Seguridad –> Tildar la segunda casilla:
Bien, ya tenemos escrito nuestro correo y configurado para que vaya a un remitente determinado:
——————
Cuando el correo llega a destino, la primer modificación visible es el ícono con el que se representa el sobre cerrado:
Luego, al abrir el mensaje, un sello aparece a la izquierda del mensaje indicando que ese correo fue firmado:
Al hacer clic en el sello, se mostrará toda la información referente al certificado que avala la firma digital:
***NOTA***
Si utilizan un servidor interno como CA, probablemente las firmas digitales lleguen como inválidas a destinos externos. Esto se debe a que su CA no es de confianza de destino. Solución? Adquirir un certificado comercial, o distribuír el Certificado de nuestra CA interna para que se agregue en las PCs de los destinatarios
******
Saludos,
Vernocchi, Pablo