Tag Archives: Autodiscover

Autodiscover en escenarios de múltiples dominios SMTP

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

Autodiscover a fondo (nota adicional)

Microsoft ha actualizado el Whitepaper correspondiente al servicio de Autodiscover con cotenidos más extensos sobre:

  • How Autodiscover is found by domain-joined Outlook 2007 clients using the Service Connection Point (SCP) object
  • How Autodiscover is found by Outlook 2007 clients connecting over the Internet using DNS
  • Step-by-step instructions for configuring Autodiscover – including certificate instructions – for Outlook Anywhere clients connecting over the Internet in four scenarios
  • How to configure the Exchange services Urls
  • How to configure Autodiscover in a resource forest scenario
  • How to configure Site Affinity
  • How to configure Autodiscover in a cross-forest scenario
  •  

    La información está disponible en: http://technet.microsoft.com/en-us/library/bb332063.aspx

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

    Autodiscover a fondo

    Exchange Server 2007 incluye un nuevo servicio llamado Autodiscover que se encarga de configurar automáticamente los perfiles de los usuarios que cuenten con Outlook 2007, además de algunos dispositivos móviles. Todo esto siempre y cuando lo configuremos correctamente 🙂

    Configurando perfiles

    En versiones anteriores de Exchange y Outlook la configuración de perfiles debía hacerse manualmente, creando perfil por perfil, o utilizando las opciones de automatización provistas por el Resource Kit de Office. Pero si algún cambio no previsto existiera en el ambiente, tendríamos que ejecutar nuevamente los asistentes.

    El servicio de Autodiscover utiliza la dirección de correo electrónico y cuenta de dominio para configurar el perfil de Outlook. Utilizando la cuenta de usuario o la dirección de correo, el servicio de autodiscover es capaz de obtener la siguiente información:

    • El Display Name del usuario
    • Configuraciones de Outlook Anywhere
    • Ubicación del buzón
    • URLs de webservices de Exchange

    Cuando la información del usuario cambia, o su casilla es movida a otro Mailbox Server, o no se puede establecer conexión con el servidor de Mailbox, Outlook contactará al servicio de Autodiscover para descargar las configuraciones nuevas y modificar el perfil existente.

    Cómo funciona?

    Cuando se instala el servicio de Client Access Server, un directorio virtual nuevo es creado (Autodiscover) en IIS. Este directorio virtual recibirá las peticiones de los clientes Outlook 2007 cuando:

    • Una cuenta de usuario es configurada o creada
    • El usuario chequea periódicamente cambios en las URLs de webservices de Exchange
    • Existe un cambio en las conexiones de red en el entorno de Exchange.

    Además, un nuevo objeto es creado en Active Directory denominado SCP o Service Connection Point al instalar el CAS. Este objeto tiene una lista de todos las URLs autoritativas para el servicio de Autodiscover del forest. Para mayor información, pueden visitar http://go.microsoft.com/fwlink/?LinkId=72744

     

    Desde la red interna, y con una PC miembro de un dominio, el proceso de Autodiscover puede graficarse de la siguiente manera:

    autodiscoverinterno

     

    Desde fuera de la red, o desde una PC que no es miembro del dominio, el proceso puede graficarse así:

    autodiscoverexterno

     

    Desde fuera de la red, el cliente Outlook intenta conectarse al servicio de Autodiscover tomando como base el dominio SMTP de la cuenta de correo ingresada en el asistente de configuración del perfil. Las URLs visitadas por el cliente serían:

    https://<smtp-address-domain>/autodiscover/autodiscover.xml o https://autodiscover.<smtp-address-domain>/autodiscover/autodiscover.xml

     

    Cuando los clientes se conectan a Active Directory, buscan el objeto SCP que fue creado durante la instalación del CAS. En deployments donde se incluyen varios CAS, un objeto SCP es creado por cada servidor. El objeto SCP contiene el atributo ServiceBindingInfo que tiene el FQDN del servicio de Autodiscover interno en formato https://servidor/Autodiscover/Autodiscover.xml.

    Si el cliente es miembro del dominio se utilizarán las credenciales de la sesión autenticada. De lo contrario, el proceso pedirá credenciales para poder consumir el servicio.

     

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

    Overview de novedades de Exchange 2007

    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