Quantcast
Channel: Blog de Pablo Vernocchi » Autodiscover
Viewing all articles
Browse latest Browse all 4

Autodiscover en escenarios de múltiples dominios SMTP

0
0

En alguna oportunidad, escribí algunas palabras sobre el servicio de Autodiscover (incluído en Exchange 2007 y 2010). En este link podrán encontrar la referencia anterior (http://www.eseutil.net/autodiscover-a-fondo).

Supongamos mi Organización de Exchange, donde hosteo los dominios SMTP eseutil.net y vernocchi.com.ar. En esta organización tengo tanto usuarios de un dominio como del otro.

Si un usuario de vernocchi.com.ar intentara conectarse a Autodiscover lo hará por las siguientes URLs:

https://autodiscover.vernocchi.com.ar/Autodiscover/Autodiscover.xml

https://vernocchi.com.ar/Autodiscover/Autodiscover.xml

Mientras que un usuario de eseutil.net, al conectarse, intentará iniciar sesión a:

https://autodiscover.eseutil.net/Autodiscover/Autodiscover.xml

https://eseutil.net/Autodiscover/Autodiscover.xml

¿Cuál es el desafío en este escenario?

Ambas URLs apuntan al mismo sitio web, y sólo se puede tener un único certificado por sitio Web. En este escenario, claramente tenemos URLs distintas, por lo que nuestros clientes recibirían un error en los Outlook 2007 y 2010. En este escenario tenemos varias alternativas, ya que las configuraciones por default no alcanzan.

Existen, básicamente, 4 escenarios soportados:

  1. Utilizar un certificado que soporte varios nombres (SAN Certificate, o Subject Alternate Name Certificates, o comunmente los podemos encontrar como UC Certificate).
  2. Utilizar un certificado SSL clásico, estándar, de un sólo nombre.
  3. Utilizar dos certificados SSL clásicos, estándar, de un sólo nombre.
  4. Utilizar Autodiscover con Redirects HTTP de IIS.

Dentro de cada uno de estos escenarios, existen varias alternativas que vamos a cubrir una por una.

Utilizar un certificado que soporte varios nombres (SAN Certificate)

Esta es la solución más simple, sin embargo una de las más costosas. Un SAN Certificate cuesta casi 3 veces más que un certificado estándar.

En este casi este certificado podría ser válido para Autodiscover, Webmail, EWS, ActiveSync, etc. Cada URL nueva, es una entrada en el certificado.

 

Utilizar un certificado SSL clásico, de un sólo nombre

Esta es la alternativa más barata.

Este método consiste en apuntar tanto las InternalURL como ExternalURL al mismo nombre. De esta manera todo apunta a un único nombre y no necesitaríamos más de un certificado (proceso descrito en Security warning when you start Outlook 2007 and then connect to a mailbox that is hosted on a server that is running Exchange Server 2007 or Exchange Server 2010: "The name of the security certificate is invalid or does not match the name of the site").

Adicionalmente, tenemos que informarle de alguna manera al cliente Outlook 2007 ó 2010 que la URL de Autodiscover no será https://autodiscover.dominio.com/Autodiscover/Autodiscover.xml sino que será https://webmail.dominio.com. Esto lo podemos hacer a través de un registro SRV (Service Locator).

Entonces, en este caso, el registro SRV debería quedar algo así como:

_autodiscover._tcp.vernocchi.com.ar SRV service location:
          priority       = 0
          weight         = 0
          port           = 443
          svr hostname   = webmail.vernocchi.com.ar

Y:

_autodiscover._tcp.eseutil.net SRV service location:
          priority       = 0
          weight         = 0
          port           = 443
          svr hostname   = webmail.vernocchi.com.ar

Utilizar dos certificados SSL clásicos, estándar, de un sólo nombre

En este escenario, se debería crear un sitio web para cada dominio nuevo a servir dentro de Exchange 2007/2010. Es uno de los que menos recomiendo ya que cada vez que se da de alta un nuevo dominio SMTP, se tendría que dar de alta un sitio web para Autodiscover, configurarlo con una dirección IP diferente al resto y adquirir un nuevo certificado SSL.

Es el que más overhead administrativo tiene de todas las alternativas.

 

Utilizar Autodiscover con Redirects HTTP de IIS

Este tipo de despliegues es y probablemente será la solución ideal para los escenarios de Hosting, ya que no todos los servidores DNS públicos aceptan registros SRV.

Consiste en crear un certificado estándar en el Default Website y crear un nuevo sitio web,  sin certificado, y ahí configurar un redirect al default website.

 

 

>> Pablo Vernocchi

Related posts:

  1. Autodiscover a fondo (nota adicional) Microsoft ha actualizado el Whitepaper correspondiente al servicio de Autodiscover...
  2. Autodiscover a fondo Exchange Server 2007 incluye un nuevo servicio llamado Autodiscover que...
  3. Support Academy Servicio de Autodiscover en Exchange 2007 Para crear un cita en su calendario, haga clic aquí....

Viewing all articles
Browse latest Browse all 4

Latest Images

Vimeo 10.7.0 by Vimeo.com, Inc.

Vimeo 10.7.0 by Vimeo.com, Inc.

HANGAD

HANGAD

MAKAKAALAM

MAKAKAALAM

Doodle Jump 3.11.30 by Lima Sky LLC

Doodle Jump 3.11.30 by Lima Sky LLC

Doodle Jump 3.11.30 by Lima Sky LLC

Doodle Jump 3.11.30 by Lima Sky LLC

Vimeo 10.6.2 by Vimeo.com, Inc.

Vimeo 10.6.2 by Vimeo.com, Inc.

Vimeo 10.6.1 by Vimeo.com, Inc.

Vimeo 10.6.1 by Vimeo.com, Inc.

Vimeo 10.6.0 by Vimeo.com, Inc.

Vimeo 10.6.0 by Vimeo.com, Inc.

Re:

Re:





Latest Images

Vimeo 10.7.0 by Vimeo.com, Inc.

Vimeo 10.7.0 by Vimeo.com, Inc.

HANGAD

HANGAD

MAKAKAALAM

MAKAKAALAM

Doodle Jump 3.11.30 by Lima Sky LLC

Doodle Jump 3.11.30 by Lima Sky LLC

Doodle Jump 3.11.30 by Lima Sky LLC

Doodle Jump 3.11.30 by Lima Sky LLC

Vimeo 10.6.1 by Vimeo.com, Inc.

Vimeo 10.6.1 by Vimeo.com, Inc.

Vimeo 10.6.0 by Vimeo.com, Inc.

Vimeo 10.6.0 by Vimeo.com, Inc.

Re:

Re:

Re:

Re: