Cómo compartir un dominio SMTP entre dos organizaciones de Exchange 2007

  • Article

por Agustín Gallegos

El presente artículo tiene por objetivo proporcionar una visión general, sobre cómo planificar e implementar, un mismo dominio público SMTP entre dos organizaciones utilizando Exchange server 2007

Tomaremos como ejemplo, nuestro dominio público como “@contoso.com”

La organización ORG1 la cual estará conectada directamente a internet, y luego detrás de esto la ORG2. Siendo que ORG2 no tiene salida directa a Internet.

Organización ORG1 tiene:
Dominio de Active Directory: domain1.local

Organización ORG2 tiene:
Dominio de Active Directory: domain2.local

1. Lo primero a tener en cuenta serian nuestros “Dominios aceptados”.

2. Luego tenemos que saber los “conectores de envío” que usaremos
para la organización ORG1 necesitamos:

a) Dominio “ @contoso.com” como “retransmisión interna"
b) Dominio “ @domain1.local” como "dominio autoritativo”

para la organización ORG2 necesitamos:

a) Dominio “ @contoso.com” como "dominio autoritativo”
b) Dominio “ @domain2.local” como "dominio autoritativo

¿Cuál es la diferencia entre estos dos  tipos de dominios y por qué tomar esta decisión?

Un dominio autoritativo (Authoritative Domain) se utiliza para configurar que nuestra Organización sea la única encargada de enviar correos para este dominio. Si recibimos un correo para un destinatario inexistente, nuestra organización se encargará de enviar un correo NDR.

Un dominio de retransmisión interna (Internal Relay) se utiliza para configurar que nuestra Organización pueda enviar correos para este dominio en particular. Si recibimos un correo para un destinatario inexistente, nuestra organización buscará por un conector de envió (Send Connector) que esté asignado con el mismo espacio de dirección, y así re direccionar este correo.

Por ejemplo, si un e-mail es recibido por la organización ORG1 destinado para “user1@contoso.com”. Se reconocerá que es un dominio aceptado.
Si existe el destinatario en la organización local, enviara el correo al buzón del usuario especificado.
Si no existe el usuario, como " @contoso.com" se configura como un “Internal Relay”, buscará a un conector de salida con la dirección "@contoso.com”.

Es necesario tener este conector de envío, y apuntado a ORG2.

Cuando el correo electrónico llega a ORG2, sigue el mismo proceso.
" @contoso.com” se reconoce como dominio aceptado y validará que el destinatario existe en esta organización. Si existe, le hará llegar el correo al buzón del usuario especificado. Si no existe, se generará un NDR al remitente, ya que " @contoso.com” está configurado como un "dominio autoritativo" en esta organización.
clip_image002

Ejemplo del flujo de mensajes

  1. El correo electrónico enviado desde Internet para user1@contoso.com es recibido por ORG1.
  2. Como el mismo es un dominio aceptado, el destinatario se comprueba para ver si existe en esta Organización
  3. Si el destinatario no existe, este se retransmite a través de un conector de envío con la direccion "contoso.com" hacia ORG2.
  4. Igual que en el paso 2, "contoso.com" es un dominio aceptado, y el receptor se valida contra el Active Directory.
  5. Si el destinatario no existe, y considerando que esta es una Organización autoritativa para este dominio, este no se retransmitirá, generando un NDR el cual se le envía al remitente.

Ahora, ¿cómo configuramos estos conectores?

Para una simple explicación, vamos a considerar que los conectores de recepción (Receive Connector) de cada organización aceptan tanto comunicaciones SMTP anónimas como autenticadas.

Para permitir el flujo de correo, desde ORG2 a Internet, tenemos que crear un “conector de recepción” nuevo con el fin de que permita la retransmisión anónima de los servidores HUB de la ORG2, a través de ORG1. Este procedimiento es muy simple y detallado en el siguiente artículo: Cómo permitir la retransmisión anónima en un conector de recepción

 

Para los conectores, la Organización ORG1 necesitamos

  1. Un conector de envío hacia  Internet con espacio de dirección "*", con el método de resolución deseada para DNS. Este conector permitirá la transferencia de cualquier correo electrónico de ORG1 u ORG2 hacia Internet
  2. Un conector de envío hacia ORG2
    a) Espacio de Direcciones: contoso.com
    b) Costo: 1
    c) Método de resolución: smarthost
    d) Smarthost seleccionado: Servidores de transporte de la organización ORG2.
    e) Autenticación de smarthost: depende de la necesidad y la infraestructura de red que tenemos. En nuestro ejemplo va a ser simplemente anónima

Con estos conectores, y estos dominios aceptados, propiamente configurados, podemos enviar un correo electrónico a user1@contoso.com situado en ORG1 de Internet. También podríamos enviar un correo electrónico a user2@contoso.com situado en ORG2, desde ORG1 o desde Internet.

Ahora, ¿qué pasa si al "usuario1" que se encuentra en ORG1, queremos enviarle un mensaje desde "usuario2", que se encuentra ubicado en la ORG2?
clip_image004 

  1. El mensaje es redactado por el "usuario2" para user1@contoso.com.
  2. El servidor HUB reconoce que este correo, es de un “Dominio Aceptado”.
  3. El servidor HUB comprobará si el destinatario existe en Active Directory, pero como no existe, y "contoso.com" es considerado un dominio autoritativo. 
  4. Un NDR que se emite al remitente

He visto en estos escenarios, que algunos administradores deciden tomar "contoso.com" como un dominio de “Internal Relay” en ambas organizaciones ORG1 y ORG2.

Lo mismo que tenemos en ORG1, un conector de envío para el espacio de direcciones “contoso.com", dirigido a ORG2,  tendríamos en ORG2, un conector para enviar el mismo espacio de direcciones dirigido a ORG1.

Analicemos este caso:

  1. si el mensaje viene de Internet hacia ORG1.
  2. el destinatario será verificado, Si no existe, se enviará a la ORG2.
  3. el destinatario será verificado en ORG2.
  4. Si no existe, como hemos determinado también este dominio como un “Internal Relay”, el mismo será devuelto a la organización ORG1.

En este escenario, no hay organización autoritativa a cargo de la creación de un NDR para contoso.com, por lo que el mensaje a un destinatario inexistente@contoso.com rebotará entre ambas organizaciones hasta alcanzar el límite máximo de saltos, para finalmente generar un NDR cuando este límite sea alcanzado.

Con el fin de evitar este problema, y tener ORG2 como autoritativa para su dominio SMTP, se pueden utilizar dominios SMTP alternativos.

Por lo tanto como en nuestro ejemplo inicial, estamos utilizando nuestros propios dominios de Active Directory "domain1.local" para nuestra ORG1. Lo mismo "domain2.local" para ORG2.
Así que el nuevo modelo sería de crear los conectores de envío y recepción de la siguiente manera:

clip_image006

Como podemos ver, hemos añadido un conector que envía hacia internet desde ORG1, considerando también enviar mensajes a Internet. 

También se han añadido los conectores de envío necesarios para permitir el flujo de correo entre las dos organizaciones.

Primer escenario: Envío de correo a user1@contoso.com situado en ORG1 desde Internet

  1. El correo electrónico es recibido por ORG1.
  2. "contoso.com" es un dominio aceptado, entonces el destinatario se valida en Active Directory. Si el destinatario existe, el correo es entregado al buzón del usuario deseado.

Segundo Escenario: Envío de correo a user2@contoso.com situado en ORG2 desde Internet

  1. El correo electrónico es recibido por ORG1.
  2. "contoso.com" es un dominio aceptado, entonces el destinatario se valida en Active Directory.
  3. Como el destinatario no se encuentra en ORG1, y "contoso.com" es considerado "Internal Relay" ORG1 busca de un conector de envió adecuado, y lo manda a ORG2.
    Tenemos el conector “Send to ORG2” con el espacio de direcciones “@contoso.com” destinado hacia OR2.
  4. El correo es recibido por ORG2 , si el destinatario existe en Active Directory, el correo electrónico es enviado como deseado a la casilla del usuario.

Tercer escenario: Envío de correo a user2@contoso.com situado en ORG2 desde user1@contoso.com situado en ORG1.

Igual que el segundo escenario, el flujo de correo funcionará de la misma manera.

Cuarto Escenario: Envío de correo a user1@contoso.com situado en ORG1 desde user2@contoso.com situado en ORG2

  1. Como "contoso.com" es considerado un dominio autoritativo, el destinatario será buscado en Active Directory en ORG2.
  2. Si el destinatario no se encuentra, la organización autoritativa va a emitir un NDR al remitente.

Quinto escenario: Envío de correo a user1@domain1.local situado en ORG1 desde user2@contoso.com situado en ORG2

  1. ORG2 no es autoritativo para este dominio, por lo que buscará por un conector de envío
  2. El conector "Send to the Internet and ORG1" es localizado.
  3. El mensaje es enviado desde ORG2 a ORG1
  4. "domain1.local" es un dominio aceptado y autoritativo en ORG1, por lo que se busca el destinatario en el Active Directory
  5. Si el destinatario existe, el mensaje se entrega. Si el destinatario no existe, se emite un NDR al remitente.

Sexto Escenario: Envío de correo desde user1@contoso.com situado en ORG1 o desde user2@contoso.com situado en ORG2, hacia Internet

Si el correo es enviado a un destinatario con algún dominio no aceptado de ambas organizaciones, se localiza un conector de envío, para hacerse cargo del enrutamiento del correo.

Ahora que hemos preparado todo el enrutamiento, los dominios con los que vamos a trabajar para todos los usuarios, tenemos que conseguir dejarlo claro para nuestros usuarios finales.

La manera más amigable para nuestros usuarios, es que les permitamos resolver sus destinatarios buscándolos en la "listas de direcciones". Llegando a esta instancia, tendríamos que compartir nuestras “listas globales de direcciones” (GAL) entre ambas organizaciones. Esto se logra mediante la generación de contactos representando los usuarios de ORG1 en la ORG2. Y también la creación de contactos representando los usuarios de ORG2 en ORG1.

Como generamos los contactos

Esto se puede lograr por medio de aplicaciones de sincronización de terceros o de Microsoft, externas a Exchange. En este artículo, no vamos a profundizar sobre cómo utilizar estas herramientas, pero vamos a dar un consejo, sobre cómo el contacto debe ser creado a fin de cuentas, para la resolución de nombres correcta en nuestras “GALs”.

En nuestro ejemplo, en ORG1 necesitaríamos los contactos representando los usuarios de ORG2 de la siguiente manera:

clip_image008

Como en nuestro tercer escenario, 

  1. user1 resolverá "user2" de ORG2, directamente de su Libreta de direcciones o GAL.
  2. La dirección de correo electrónico será resuelta como user2@contoso.com porque es nuestra dirección proxy por defecto (Default Proxy Address) .
  3. Cuando el contacto es resuelto, este se valida dónde tenemos que enviar el correo.
  4. La dirección de correo electrónico externa (External E-mail Address) se utilizará, para enrutar el mensaje y por lo tanto usa el dominio interno user2@domain2.local

Para ORG2 necesitaríamos los contactos representando los usuarios de ORG1 de la siguiente manera:

clip_image010

Así que, como en nuestro quinto escenario 

  1. User2 resolverá "user1" de ORG1, directamente de su Libreta de direcciones o GAL.
  2. La dirección de correo electrónico será resuelta como user1@contoso.com porque es nuestra dirección proxy por defecto (Default Proxy Address) .
  3. Cuando el contacto es resuelto, este se valida dónde tenemos que enviar el correo.
  4. La dirección de correo electrónico externa (External E-mail Address) se utilizará, para que el correo esté dirigido a user1@domain1.local

Aquí les presento un método simple, sobre cómo crear los contactos necesarios utilizando CSVDE.
"CSVDE" es una herramienta con la que podemos extraer los usuarios de una organización de origen, e importar como contacto en la organización de destino.

1) Podemos utilizar la siguiente línea de comando para exportar a los usuarios de una unidad organizativa específica denominada "ORG1 users" de ORG1, con los atributos deseados

csvde -f output.csv -d "OU=ORG1 Users,DC=Domain1,DC=Local" -l objectClass,dn,name,cn,sn,givenName,displayName,proxyAddresses,targetAddress,mail,mailnickname

Nota: Para importar con éxito y crear los contactos, necesitamos como mínimo, los siguientes atributos:
objectClass,dn,name,cn,sn,givenName,displayName,proxyAddresses,targetAddress,mail,mailnickname

2) Dado que los usuarios exportados no tienen el atributo “targetAddress” (correspondiente al External E-mail Address), necesitaremos agregar manualmente el contenido de esta columna, para luego poder importar el CSV.

objectClass, dn, name, cn, sn, givenName, displayName, proxyAddresses, targetAddress, mail, mailnickname

El resultado del archivo CSV final para la importación, resulta ser:

objectClass,dn,name,cn,sn,givenName,displayName,proxyAddresses,targetAddress,mail,mailnicknamecontact,"CN=user1,OU=ORG1 Contacts,DC=Domain2,DC=Local",user1,user1,lastname,user1,user1, "SMTP:user1@contoso.com;smtp:user1@domain1.local",user1@domain1.local,user1@contoso.com,user1

También tenemos que modificar el atributo “DistinishName” (dn). Este atributo especifica donde se importarán los contactos. En qué OU de la organización de destino se localizarán. Tenemos que saber de antemano la OU, para el “DistingishName”, donde queremos que el contacto sea creado.

3) La proceso de importar los contactos no debe presentar errores. El contacto debe ser visto con la consola "Active Directory Users and Computers", así como la consola “Exchange Management Console”.

4) Más allá que el contacto es generado satisfactoriamente, como estamos utilizando la herramienta “CSVDE” para generarlos, no estamos forzando al servicio de actualización de la GAL.

5) Después de que generamos todos los contactos deseados, sólo tenemos que actualizar nuestra lista global de direcciones con el siguiente comando de Exchange en la consola “Exchange Management Shell”

Get-globalAddressList | update-globalAddressList

Es importante, entender que en relación a CONTACTOS, las direcciones proxy (Proxy Addresses) sólo se utilizan para la resolución de "nombres". Para el enrutamiento real y envío de correo electrónico, se utilizaran las direcciones de “correo electrónico externa” (External E-mail Addresses).

Ahora tenemos, nuestros dominios aceptados (Accepted Domains), nuestros conectores de envío (Send Connectors), y nuestros contactos para todos los usuarios de ambas organizaciones.

Séptimo Escenario: Envío de correo a user@fourthcoffee.com desde user2@contoso.com situado en ORG2, y con copia CC a user1@contoso.com ubicado en ORG1.

  1. El mensaje enviado a user@fourthcoffee.com  se hace como se describe en el Escenario 6.
  2. El mensaje enviado a user1@contoso.com se resuelve por el contacto creado en nuestra ORG2, dirigido a la dirección de correo electrónico externa user1@domain1.local 
  3. Como el mensaje se redirecciona a user1@domain1.local el mismo es enviado como en el Escenario 5.

En este escenario, user@fourthcoffee.com recibirá el correo electrónico de user2@contoso.com  y verá su nombre (display name) como user2@contoso.com  y verá el campo CC al user1@contoso.com  con su nombre para mostrar (display name) como user1@contoso.com. Esto se debe a que hemos configurado antes, la dirección de "proxy" para la resolución de nombres son los que tienen como dominio SMTP "contoso.com".

Octavo Escenario: el usuario de Internet, user@fourthcoffee.com realiza la tarea “responder a todos" con el fin de responder de vuelta a user1@contoso.com situado en ORG1 y user2@contoso.com situado en ORG2

  1. El correo electrónico es enviado a user1@contoso.com  y user2@contoso.com desde internet.
  2. Deben existir registros MX en el DNS público para el dominio "contoso.com", dirigida a ORG1.
  3. Los correos electrónicos se entregan como se describe en los Escenarios 1 y 2 respectivamente.

Para finalizar este artículo, ahora ya tenemos nuestra implementación con las dos organizaciones que comparten el dominio público SMTP, con los dominios aceptados adecuadamente, nuestros conectores de envío, y los contactos adecuados para cada Organización. Espero que esto les sirva para tener un mejor panorama cuando se precisan estos ambientes. 

Referencias

Los siguientes son algunos artículos relacionados con el tema: