Exchange Blog Latino : Articulos - Exchange 2003

Como prevenir que los usuarios usen la OAB de Outlook en Cached Mode

Carlos — Tue, 27 Nov 2007 18:17:10 GMT

En ciertas oportunidades, como se discutió en Administrando la descarga de OAB en Outlook 2003 y 2007, necesitaremos que los usuarios no consulten la OAB (Offline Address Book) del cache local de Outlook y, en cambio, utilicen los Domain Controllers en manera online.

De esta manera, no tendremos el problema que algunos clientes de Outlook no encuentren a los usuarios creados recientemente.

En Administrando la descarga de OAB en Outlook 2003 y 2007 podemos configurar através de una GPO (Group Policy) qué comportamiento tendrán los clientes Outlook ante la descarga de la OAB. Pero el problema es que aún así, el usuario puede descargar la Address Book manualmente y Outlook nunca la actualizaría con lo cuál estamos en un escenario peor que antes :).

NOTA: Una vez que Outlook haya descargado una copia Offline de la OAB, le dará prioridad a ésta, esté actualizada o no. Siempre usará la copia local. Es por eso que antes de ejecutar este procedimiento es necesario eliminar los archivos con extensión .oab que se encuentren en el perfil de los usuarios.

Estos scripts (en formato VBS), para Outlook 2003 y Outlook 2007 crean unas claves en la registry para que la OAB nunca sea descargada y evitan que se descargue manualmente, grisando la opción en el menú "Enviar/Recibir" del Outlook.

Para Outlook 2003:

const HKEY_CURRENT_USER = &H80000001
strComputer = "."
Set oReg=GetObject("winmgmts:{impersonationLevel=impersonate}!\\" &_
strComputer & "\root\default:StdRegProv")
strKeyPath = "SOFTWARE\Policies\Microsoft\Exchange\Exchange Provider"
strKeyValue = "Limit SRS Incremental Download"
strKeyValue1 = "Limit Manual OAB Download"
strKeyValue2 = "Limit SRS Full OAB Download"
strKeyValue3 = "Allow SRS Full OAB Download"
oReg.CreateKey HKEY_CURRENT_USER,strKeyPath
oReg.SetDWORDValue HKEY_CURRENT_USER,strKeyPath,strKeyValue,0
oReg.SetDWORDValue HKEY_CURRENT_USER,strKeyPath,strKeyValue1,0
oReg.SetDWORDValue HKEY_CURRENT_USER,strKeyPath,strKeyValue2,0
oReg.SetDWORDValue HKEY_CURRENT_USER,strKeyPath,strKeyValue3,0
strKeyPath1 = "SOFTWARE\Policies\Microsoft\Office\11.0\Outlook\DisabledCmdBarItemsList"
strValueName1 = "TCID1"
strValue1 = "5658"
oReg.CreateKey HKEY_CURRENT_USER,strKeyPath1
oReg.SetStringValue HKEY_CURRENT_USER,strKeyPath1,strValueName1,strValue1

Para Outlook 2007:

const HKEY_CURRENT_USER = &H80000001
strComputer = "."
Set oReg=GetObject("winmgmts:{impersonationLevel=impersonate}!\\" &_
strComputer & "\root\default:StdRegProv")
strKeyPath = "SOFTWARE\Policies\Microsoft\Exchange\Exchange Provider"
strKeyValue = "Limit SRS Incremental Download"
strKeyValue1 = "Limit Manual OAB Download"
strKeyValue2 = "Limit SRS Full OAB Download"
strKeyValue3 = "Allow SRS Full OAB Download"
oReg.CreateKey HKEY_CURRENT_USER,strKeyPath
oReg.SetDWORDValue HKEY_CURRENT_USER,strKeyPath,strKeyValue,0
oReg.SetDWORDValue HKEY_CURRENT_USER,strKeyPath,strKeyValue1,0
oReg.SetDWORDValue HKEY_CURRENT_USER,strKeyPath,strKeyValue2,0
oReg.SetDWORDValue HKEY_CURRENT_USER,strKeyPath,strKeyValue3,0
strKeyPath1 = "SOFTWARE\Policies\Microsoft\Office\12.0\Outlook\DisabledCmdBarItemsList"
strValueName1 = "TCID1"
strValue1 = "5658"
oReg.CreateKey HKEY_CURRENT_USER,strKeyPath1
oReg.SetStringValue HKEY_CURRENT_USER,strKeyPath1,strValueName1,strValue1

Además, hacerles saber que este método es mejor que el mencionado en Administrando la descarga de OAB en Outlook 2003 y 2007.

Pablo Vernocchi
Microsoft Exchange MVP
MCSE + M / MCSE + Sec
https://mvp.support.microsoft.com/profile/Pablo

Verificando opciones de Relay en Exchange 2000 y 2003

Carlos — Thu, 24 May 2007 12:26:00 GMT

Hace unos días me tocó atender un incidente de Exchange relacionado a problemas de autenticación en el SMTP por ende, problemas de SPAM.

No es muy difícil entender el comportamiento de SMTP y como restringirlo para no convertirlo en un Open Relay.

Ante la duda, lo primero que tenemos que hacer es testear desde fuera de la LAN si es o no. Para eso existe una aplicación Web proporcionada por Abuse.net (entre otros tantos) que la pueden encontrar en http://www.abuse.net/relay.html. El único dato que hay que ingresar es la dirección IP o el nombre público de nuestro SMTP. Esta aplicación hace una serie de pruebas (unas 17 aproximadamente).

NOTA: Para los administradores de Exchange 2000. La prueba 8 de este test da positiva. Pero no es de alarmarse, porque en realidad ese mensaje es rechazado luego por Exchange cuando hace las consultas a Active Directory.

Si el test da OK, entonces no tenemos nada para preocuparnos, todo funciona como debiera. Si no diese OK, tendríamos que hacer algunas verificaciones en las configuraciones:

Como primer punto, verificar las opciones de autenticación del protocolo SMTP. Para ello abrimos la consola de Administración de Exchange, expandimos servers –> protocols –> SMTP –> y entramos a las propiedades del SMTP Virtual Server

Una vez dentro, vamos a la solapa “Access”, y entramos en Autenticación:

Quiero mostrar esta configuración porque es clásica pregunta:

SI, Tiene que tener ANONYMOUS ACCESS. ¿Porqué es esto? Porque los SMTP externos que intenten enviar correos hacia nuestro dominio no usan autenticación. Sería utópico. Tendríamos que estar repartiendo nuestra contraseña a miles de millones de SMTPs en el mundo

Volviendo al tema del Relay, tenemos que entrar al botón “Relay” y corroborar que las configuraciones sean las siguientes:

Con esta configuración estamos permitiendo que sólo los equipos en la lista (vacía por default) puedan hacer relay a nuestro servidor, sin autenticación. Y además es importante que el tilde “Allow all computers…” esté marcado.

—————————-

Si nuestro servidor tiene un conector SMTP, con address space ” * ” (asterisco), entonces tendríamos que verificar en las propiedades:

Que NO esté marcada la opción “Allow messages to be relayed to this domains”, de lo contrario estaríamos permitiendo el relay hacia TODOS los dominios.

—————————-

Una vez finalizadas las configuraciones, podríamos reiniciar el servicio de SMTP para que se apliquen los cambios y volver a correr el test de http://www.abuse.net/relay.html

Espero que les haya servidor,
Vernocchi Pablo

Cómo recibir los logs de ntbackup por correo

Carlos — Sun, 20 May 2007 12:13:00 GMT

Buenas a todos,

Durante muchos años administré los servidores de muchos clientes pequeños y medianos. No todos tenían implementado soluciones corporativas de Backup que enviaran el reporte con el resultado por correo electrónico, y este reporte es especialmente importante para tener un control.

Cuando hablamos de 10 servidores quizás tengamos tiempo de entrar uno por uno para ver el .log, y tomar acciones correctivas, pero cuando hablamos de redes con 3 servidores por cliente (promedio) y multiplicamos eso por 40, se hace inviable.

En esta nota mostraremos dos alternativas.

He aquí la primera, con este script (provisto por https://www.smallbizserver.net/) podremos recibir una copia del log por correo electrónico.

NOTA: Este script requiere IIS o Exchange instalado


‘Send using the Pickup directory on the IIS server.
Dim iMsg 
Dim iConf 
Dim Flds 
Dim strHTML 
Const cdoSendUsingPickup = 1 
set iMsg = CreateObject(”CDO.Message”)
set iConf = CreateObject(”CDO.Configuration”) 
Set Flds = iConf.Fields
With Flds 
.Item(”http://schemas.microsoft.com/cdo/configuration/sendusing”) = cdoSendUsingPickup
‘ TODO: Replace <PICKUP DIRECTORY> with path to your pickup directory
‘ Typically, c:\Inetpub\mailroot\pickup
.Item(”http://schemas.microsoft.com/cdo/configuration/smtpserverpickupdirectory”)=”C:\Program Files\Exchsrvr\Mailroot\vsi 1\PickUp”
.Update
End With 
‘ Build HTML for message body.
strHTML = “<HTML>”
strHTML = strHTML & “<HEAD>”
strHTML = strHTML & “<BODY>”
strHTML = strHTML & “<b>Attached is your backup log</b></br>”
strHTML = strHTML & “</BODY>”
strHTML = strHTML & “</HTML>” 
Dim iBP
With iMsg
Set .Configuration = iConf
.To = “mariette@matterhorn.xs4all.nl”
.From = “NTBackup”
.Subject = “NTBackup Log”
.HTMLBody = strHTML
‘TODO: if adding an attachment,
‘uncomment the next line and alter file path as required
Set iBP = iMsg.AddAttachment(”c:\backup\backlog.txt”)
.Send
End With 
‘ Clean up variables.
Set iBP = Nothing
Set iMsg = Nothing
Set iConf = Nothing
Set Flds = Nothing

——————————–

Otra alternativa, que no requiere IIS o Exchange, es usar alguna aplicación que pueda enviar un correo electrónico y adjuntar un archivo. Una de ellas se llama BMAIL. En este ejemplo, lo primero que haremos es juntar todos los logs en un mismo archivo, para después adjuntarlo:


type “c:\Documents and Settings\Administrador\Configuración local\Datos de programa\Microsoft\Windows NT\NTBackup\data\*.log” >c:\backup\backlog.txt

Luego, ese mismo archivo lo mandamos por correo:


C:\Backup\bmail -s direccion_ip_de_smtp -f from@dominio.com -t to@dominio.com.ar -a “Backup” -m “c:\backup\backlog.txt”

Con eso es todo, espero que les sirva.
Vernocchi Pablo

Cómo redirigir el acceso Web en OWA

Carlos — Wed, 18 Oct 2006 12:01:00 GMT

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

Seguridad en mensajes (Parte 3)

Carlos — Mon, 07 Aug 2006 13:22:00 GMT

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

Seguridad en mensajes (Parte 2)

Carlos — Sun, 06 Aug 2006 13:10:00 GMT

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.itpros.com.ar/blog/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

Cómo mover las bases de datos de Exchange a otra ubicación

Carlos — Sat, 05 Aug 2006 13:03:00 GMT

En diversos escenarios es necesario mover las bases de Exchange de disco, carpeta, partición, etc.
En esta oportunidad cubriremos todos los aspectos técnicos para realizar esta operación satisfactoriamente.

Almacenes de Buzones y Carpetas Públicas:

Como primer paso abriremos la consola de Administración de Exchange. Expandimos “Servers”, ubicamos nuestro servidor, lo expandimos también, expandimos nuestro “Storage Group” y allí encontraremos los almacenes de buzones.

Una vez que tengamos ubicado el almacén de buzón que querramos mover, hacemos clic con el botón secundario sobre él, y luego propiedades:

Aparecerála siguiente ventana, donde se muestran las rutas de las bases actuales:

Para cambiar la ruta y mover automáticamente las bases, debemos hacer clic en browse y seleccionar la carpeta de destino:

Cuando tengamos casi todo listo, en la pantalla aparecerán las nuevas rutas a modo de confirmación.

Cuando presionemos “OK” saldrá una advertencia. El proceso de mover las bases de datos requiere que los buzones sean desmontados, por lo tanto no accesibles a los usuarios. Si estamos muy seguros de lo que estamos haciendo, y que lo estamos haciendo cuando nadie está trabajando, le decimos que SI.

Qué placer ver este tipo de carteles!! :

Para el almacén de carpetas públicas es exactamente el mismo procedimiento.

***NOTA***
Para brindar adecuadamente los permisos NTFS a las bases de datos deberíamos configurar, en la carpeta de destino, los siguientes permisos:

Administrators: Full control
Authenticated Users: Read and Execute, List Folder Contents, Read
Creator Owner: Nada
Server Operators: Modify, Read and Execute, List Folder Contents, Read, Write
System: Full Controll
******

Logs de transacciones:

El procedimiento para mover los registros de transacciones es similar. Los logs son compartidos por todos los mailbox stores de un storage group, por lo tanto esta configuración debe ser realizada a nivel de SG:

Veremos una ventana similar a las anteriores, seleccionamos Browse y luego le declaramos la nueva ruta:

Nuevamente, si estamos seguros de lo que estamos haciendo y nadie está trabajando, podemos darle OK y saldrá la advertencia porque se desmontarán los buzones:

Y el breve pero relajante mensaje de:

Con eso ya hemos movido las bases de mensajes y registros de transacciones de disco.

Recursos adicionales:

How to move Exchange databases and logs in Exchange Server 2003
http://support.microsoft.com/kb/821915/en-us

XADM: How to Move Exchange Databases and Logs in Exchange 2000 Server
http://support.microsoft.com/kb/257184/en-us

Optimizing Storage for Exchange Server 2003
http://www.microsoft.com/technet/prodtechnol/exchange/guides/StoragePerformance/fa839f7d-f876-42c4-a335-338a1eb04d89.mspx

Saludos,
Vernocchi, Pablo

Seguridad en mensajes (Parte 1)

Carlos — Thu, 03 Aug 2006 21:00:00 GMT

En esta oportunidad veremos algunos aspectos en cuanto a seguridad en los mensajes.

Un poco de historia:
Con el crecimiento de Internet en los últimos 10 años, el correo electrónico ha sufrido un cambio en su utilización. Ya no es más una herramienta de mensajería interna en empresas, sino que se ha difundido en todos nosotros.

El protocolo adoptado para transmitir los correos fue SMTP (Simple Mail Transfer Protocol). El estándar SMTP posibilita el intercambio de correos desde diferentes plataformas. Históricamente este protocolo fue diseñado para enviar mensajes cortos, sin confidencialidad en redes cerradas, y principalmente no diseñado para transmitir información sensible através de una red mundial, como Internet. Básicamente SMTP transporta los mensajes de una manera que cualquiera puede leerlos (clear text).

S/MIME (Secure/Multipurpose Internet Mail Extension) fue desarrollado como estándar para reforzar la seguridad y confidencialidad de SMTP.
S/MIME fue desarrollado en 1995 por un grupo de vendors de seguridad. Fue una de las tantas especificaciones, como PGP. En 1998 se desarrolló la segunda versión de S/MIME, a diferencia de la versión 1 ésta ya estaba por considerarse como un estándar. En 1999, la versión 3 fue propuesta por la IETF con una serie de especificaciones técnicas.

S/MIME 3 fue altamente aceptado y los productos Microsoft que lo soportan son:

Microsoft Outlook 2000 SR-1 y superior
Microsoft Outlook Express 5.01 y superior
Microsoft Exchange 5.5 y superior

Qué beneficios brinda S/MIME?:

S/MIME provee dos servicios de seguridad: Firma digital y encripción de mensajes.
Estos dos servicios son la base en la seguridad en mensajes y los veremos en detalle a continuación:

Firma Figital
La firma digital es la contrapartida de la firma en un documento en papel. Como en las firmas legales, la Firma Digital provee:

* Autenticación: Valida la identidad. Como no hay autenticación en SMTP, no hay manera de saber quién envió el mensaje. Autenticación en una firma digital resuelve ese problema, permitiendo al destinatario del mensaje asegurarse que el mensaje fue enviado or quien dice haberlo enviado.

* No repudiación: Por ser única, la firma digital evita que el remitente del mensaje lo desconozca.

* Integridad de información: La integración de información es el resultado de una operación específica que hace posible la firma digital. Cuando el mensaje es enviado, se calcula el hash del mensaje. Cuando se recibe, el hash es calculado nuevamente y, si el mensaje fue modificado en tránsito, da un error en la firma digital.

***NOTA***: Muchos softwares que agregan discalimers a los mensajes hacen que las firmas digitales sean inválidas, ya que son modificados en tránsito cuando se les agrega la nota de pie de mensaje.

Los pasos, en líneas generales son:

Y cuando el mensaje es recibido, el cliente realiza lo siguiente:

Encripción de mensajes:

La encriptación del mensaje prevee una solución para evitar que terceros puedan tener acceso al contenido del mensaje, ya que el correo SMTP se transporta en texto plano.

Encriptar es el proceso de modificar el contenido para que no sea leído o entendido hasta que no se revierta la alteración producida. De esta manera encriptar un mensaje nos provee:

* Confidencialidad: Proteje el contenido del correo. Sólo el destinatario seleccionado puede desencriptar el correo y poder leerlo. Éste método provee confidencialidad mientras el mensaje está en tránsito o almacenado.

* Integridad de la información: Como en la firma digital, encriptar un correo provee integridad de información, como resultado de las operaciones que se efectúan sobre el mismo.

Al momento de enviar un correo, los pasos son los siguientes:

Y cuando se recibe:

Aunque encriptar el contenido del mensaje provea confidencialidad e integridad, no autentica el remitente de ninguna manera. Un mensaje encriptado, pero sin firma digital sufre los mismos problemas de suplantación de identidad que el correo común.

Rights Management Services (RMS):

Como alternativa tenemos un servicio llamado RMS. Dentro de los beneficios de implementar una solución basada en RMS, podemos encontrar:

* Proteger la información confidencial contra un acceso o uso compartido con usuarios no autorizados

* La capacidad de controlar no únicamente el acceso a los datos, sino la manera en que se utilizan y distribuyen.

* Garantizar que el contenido de los datos esté protegido y sea resistente a la manipulación

* La capacidad de controlar la fecha de caducidad de los contenidos

Un mensaje protegido por RMS no puede ser reenviado, ni impreso. Cuando respondemos sobre ese mismo mensaje, el cuerpo original es eliminado. Además las funciones de captura de pantalla están deshabilitadas. No se puede mostrar en paneles de vista previa y no se muestran las primeras líneas del mensaje en la advertencia de escritorio de Outlook 2003.

En resúmen, podemos destacar las siguientes diferencias entre S/MIME y RMS:

Función	RMS	Firma S/MIME	Encripta-ción S/MIME
Avala la identidad del editor		*
Establece una diferencia de los permisos por usuario	*
Impide una vista no autorizada	*		*
Encripta el contenido protegido	*		*
Ofrece expiración del contenido	*
Controla la lectura, reenvío, guardado, modificación o impresión del contenido por parte del usuario	*
Amplía la protección más allá de la ubicación de publicación inicial	*	*	*

La intención de esta primer parte es que puedan distiguir entra todas las alternativas de seguridad de mensajería que soporta Exchange..

Próximamente estaré mostrando cómo implementar todo esto, S/Mime y RMS en acción.

Saludos,
Vernocchi Pablo

Utilizando Grupos de almacenamiento de recuperación

Carlos — Tue, 04 Jul 2006 17:45:00 GMT

En esta oportunidad mostraremos cómo utilizar el “Grupo de almacenamiento de recuperación” para recuperar un buzón desde un backup.

En innumerables ocasiones he recibido pedidos de “un correo importantísimo” eliminado por error del usuario. En versiones anteriores a Exchange 2003, teníamos pocas alternativas de recuperación. Si usábamos software de backup de terceras partes, la tarea podría ser sencilla. Pero si utilizábamos la herramienta de Windows (ntbackup.exe) era bastante tedioso que podría llevar bastante tiempo (montar un servidor en otro hardware, montar el mismo dominio de AD, montar un servidor Exchange de la misma versión con el mismo nivel de Service Pack, hacer el restore, extraer los datos con Exmerge). Al final siempre intentaba influenciar al usuario de que el correo no era tan importante .

Con Exchange 2003 se introdujo el concepto de Grupo de almacenamiento de recuperación que nos permite restaurar un backup completo en el mismo servidor, sin la necesidad de andar montando otro paralelo, ni mucho menos.

¿Cómo utilizar la herramienta? Previamente tendremos que leer la nota de cómo configurar exmerge, ya que es el único medio por el que podremos acceder a los correos restaurados. Post SP1, podremos recuperar los buzones desde la consola de administración de Exchange, armaremos un tutorial en breve.

Para comenzar el procedimiento abriremos la consola de Adminstración de Exchange, expandimos Servidores y hacemos clic con el botón secundario sobre el servidor Exchange sobre el cual queremos hacer la restauración, luego seleccionamos “Nuevo –> Grupo de almacenamiento de recuperación…”.

Seleccionamos la ruta donde ubicaremos los archivos de transacciones y de acceso del sistema, y acemos clic en aceptar.

Veremos que tenemos un nuevo grupo de Almacenamiento. Ahora lo que tenemos que hacer es decirle qué base de datos de mensajes vamos a restaurar. Para eso haremos clic con el botón secundario del mouse sobre “Grupo de almacenamiento de recuperación –> Agregar base de datos para recuperar…”

Esto disparará una búsqueda que mostrará las bases disponibles para la restauración, donde debemos seleccionar una:

Aparecerán las propiedades, y hacemos clic en aceptar:

Ya tenemos todo configurado del lado del Exchange para hacer el restore. Ahora iniciamos la herramienta de backup (ntbackup.exe), seleccionamos la copia de seguridad a restaurar y, dentro de los contenidos, seleccionamos SOLAMENTE el almacén de buzón:

Como siguiente paso, indicaremos una ruta temporaria de extracción y tildaremos la opción “Último conjunto de restauración…” si correspondiese.

Una vez finalizada la restauración, aparecerá el siguiente mensaje:

Como siguiente paso, montaremos el almacén de recuperación para poder accederlo:

Aparecerá la siguiente advertencia que indicaremos “si”:

Bien, hasta este punto estamos en orden. La única manera de acceder a este almacen de recuperación es con Exmerge. Para ello deberíamos haber configurado todo como se explica en la nota cómo configurar exmerge en este mismo Blog. La única diferencia que encontraremos es que al iniciar Exmerge tendremos una base de datos más de donde extraer la información:

Espero que este breve tutorial les sirva, podrán encontrar más información en http://www.microsoft.com/downloads/details.aspx?FamilyID=df144af6-bee5-4b35-866a-557e25fe2ba1&displaylang=en
Vernocchi Pablo

PD: Gracias Benjamin Mateos (MVP Exchange) por los comentarios y modificaciones de la nota.

Directivas de Destinatarios

Carlos — Tue, 06 Jun 2006 12:35:00 GMT

En esta oportunidad cubriremos aspectos básicos sobre las “Directivas de Destinantarios”.

A través de las directivas podremos configurar globalmente los dominios de Internet que nuestro servidor Exchange aceptará. Además podremos definir la estructura que van a tener las direcciones de correo electrónico al momento de su creación.

Por default, la dirección de correo se forma con el nombre que tiene el buzón (que es el mismo que el nombre de usuario). Pero… ¿qué pasa si mis usuarios inician sesión con un nombre y quiero que sus direcciones de correo sean distintas? Por ejemplo, si mi nombre de usuaro es pvernocchi, y quiero que mi dirección de correo sea pablo.vernocchi@dominio. ¿Tengo que hacerlo uno por uno? La solución la encontrarán en esta nota.

Para empezar, abriremos la consola de Administración de Sistema. Expandiremos destinatarios –> Directivas de destinatario. Ahí encontraremos una ventana parecida a la siguiente:

Si abrimos la directiva por defecto, encontraremos todo lo que expliqué más arriba, y en la solapa dominios, los declarados por los asistentes que hayamos ejecutado anteriormente (Asistente de conexión).

Si entramos a las propiedades de la directiva predeterimanda encontraremos tres solapas.

La tercera es para notas administrativas. Entonces, entramos a la segunda solapa, y ahí podremos definir las direcciones de correo. Para eso, haremos doble clic en el dominio predeterminado y, antes de la arroba escribiremos:

%s        La dirección de correo tendrá solo el apellido     vernocchi@vernocchi.com.ar
%g        La dirección de correo tendrá sólo el nombre     pablo@vernocchi.com.ar
%i         La dirección de correo tendrá sólo la inicial del 2do nombre     d@vernocchi.com.ar

Estas son algunas de las opciones que podremos elegir. Por supuesto se pueden combinar y poner %g.%s@vernocchi.com.ar y mi dirección de correo sería pablo.vernocchi@…

Bien, con eso ya tenemos resuelto la primer parte de nuestro desafío. Pero… ¿qué pasa si nuestra compañía tiene 3 sucursales con distinto nombre de dominio?
Supongamos el siguiente escenario:
Argentina: dominio @empresa.com.ar
España: dominio @empresa.com.es
Mexico: dominio @empresa.com.mx

Cada país cuenta con un servidor de Exchange. Para eso, tendremos que hacer uso de múltiples directivas y, a través de LDAP, decirle: si tu buzón está en España, tu cuenta de correo debe ser %g.%s@dominio.com.es . Parece medio críptico, pero en realidad nos llevará un par de clics.

Por cuestiones de esta demo, haremos sólo una:

Hacemos clic con el botón secundario –> nuevo –> Directiva de destinatario

Seleccionamos que sea de “Direcciones de correo electrónico”

Le damos un nombre descriptivo y hacemos clic en Modificar:

Se abrirá una ventana de búsqueda, donde podremos definir en qué servidor están alojados los buzones

Luego de aceptar ese cuadro de diálogo, saldrá la siguiente advertencia:

Y el filtro LDAP ya está creado automáticamente. Lo único que queda es definir los dominios y la estructura de la dirección de la cuenta, para ello abriremos la política creada recientemente:

Vamos a nueva y seleccionamos dirección SMTP:

Seleccionamos el formato que queremos:

Ahora tendremos que activarla y configurarla como predeterminada:

Al aceptar la ventana, nos preguntará si queremos aplicar esta nueva regla al filtro que configuramos previamente:

Y con eso termina este breve repaso de Directivas de Destinatarios.

Saludos,
Vernocchi, Pablo