Este problema probablemente se deba al servicio de detección automática de Outlook , que forma parte de la funcionalidad de Outlook en cualquier lugar . La detección automática proporciona información diversa al cliente Outlook del usuario final sobre los diversos servicios ofrecidos por Exchange y dónde se pueden ubicar; Esto se utiliza para una variedad de propósitos:
Configuración automática de perfiles de Outlook en la primera ejecución de Outlook, que puede configurar una cuenta de Exchange utilizando solo la dirección de correo electrónico y la contraseña del usuario, ya que la otra información se ubica y recupera automáticamente.
Ubicación dinámica de los servicios basados en la web a los que accede el cliente de Outlook, incluido el asistente de fuera de la oficina, la funcionalidad de mensajería unificada, la ubicación del Panel de control de Exchange (ECP), etc.
Esta es la implementación patentada de Microsoft de RFC 6186 . Desafortunadamente, realmente no siguieron las recomendaciones de esa RFC en el diseño de Outlook Anywhere, pero eso es quizás de esperar ya que Exchange y RPC sobre la funcionalidad HTTPS no es un servidor IMAP / SMTP tradicional.
¿Cómo funciona la detección automática (para usuarios externos *)?
La detección automática se comunica con un servicio web en un servidor de acceso de cliente (en este caso, todas las funciones están en el servidor SBS) en la ruta /Autodiscover/Autodiscover.xml, desarraigada de su sitio web predeterminado. Para localizar el FQDN del servidor con el que comunicarse, elimina la parte del usuario de la dirección de correo electrónico, dejando el dominio (es decir, @ companyB.com). Intenta comunicarse con Autodiscover utilizando cada una de las siguientes URL, a su vez:
https://companyB.com/Autodiscover/Autodiscover.xmlhttps://autodiscover.companyB.com/Autodiscover/Autodiscover.xml
Si estos fallan, intentará una conexión no segura deshabilitando SSL e intentando comunicarse en el puerto 80 (HTTP), generalmente después de pedirle al usuario que confirme que esta es una acción aceptable (una opción defectuosa en mi opinión, ya que los usuarios despistados lo harán). normalmente aprueban esto y corren el riesgo de enviar credenciales sobre texto sin formato, y los administradores de sistemas sin idea que no requieren una comunicación segura de credenciales y datos confidenciales son un riesgo para la continuidad del negocio).
Finalmente, se realiza una verificación de seguimiento utilizando un registro de servicio (SRV) en el DNS, que existe en una ubicación conocida fuera del companyB.comespacio de nombres y puede redirigir Outlook a la URL correcta donde el servidor está escuchando.
¿Qué puede ir mal?
Uno de varios problemas puede surgir en este proceso:
No hay entradas DNS
Por lo general, la raíz del dominio ( companyB.com) podría no resolverse en un registro de host en el DNS. La configuración incorrecta de DNS (o una decisión consciente de no exponer el servicio Outlook en cualquier lugar) podría significar que el autodiscover.companyB.comregistro tampoco existe.
En estos casos, no hay problema importante; Outlook simplemente continúa comunicándose con Exchange usando la última configuración conocida, y puede degradarse con respecto a ciertas funciones basadas en la web para las cuales necesita recuperar URL a través de Detección automática (como el asistente de fuera de la oficina). Una solución alternativa es utilizar Outlook Web Access para acceder a dichas funciones.
La configuración automática de las cuentas de Exchange en los nuevos perfiles de Outlook tampoco está automatizada, y requiere la configuración manual de la configuración RPC sobre HTTPS. Sin embargo, esto no causará el problema que usted describe.
Certificados SSL defectuosos
Es completamente posible que la URL que Outlook utiliza para intentar contactar con el servidor de Exchange se resuelva en un host, que puede o no ser un servidor de acceso de cliente. Si Outlook puede comunicarse con ese servidor en el puerto 443, los certificados se intercambiarán, por supuesto, para configurar un canal seguro entre Outlook y el servidor remoto. Si la URL que Outlook cree que está hablando no figura en ese certificado, ya sea como el nombre común o un nombre alternativo de sujeto (SAN), esto provocará que Outlook presente el cuadro de diálogo que describe en su publicación inicial.
Esto puede suceder por varias razones, todo depende de cómo se configura el DNS y cómo Outlook verifica las URL que describí anteriormente:
Si el https://companyB.com/... URL se resuelve en un registro de host, y el servidor web en esa dirección escucha en el puerto 443, y tiene un certificado SSL que no figura companyB.comen el nombre común o Nombre alternativo del sujeto, entonces se producirá el problema. No importa si el host es un servidor de Exchange o no; podría ser un servidor web que aloja un sitio web de la empresa que no está configurado correctamente. Corrige bien:
- Deshabilite el registro de host en la raíz de la
companyB.comzona (que requiere que los visitantes del sitio web u otro servicio ingresen www.companyB.com, o equivalente; o
- Deshabilite el acceso a la máquina en
companyB.comel puerto 443, lo que hace que Outlook rechace la companyB.comURL antes de intercambiar certificados y seguir adelante; o
- Arregle el certificado en
companyB.compara asegurarse de companyB.comque aparezca en ese certificado y que los intentos de visitar https://companyB.comen un navegador estándar no fallen.
Lo anterior se aplica independientemente de si se companyB.comresuelve en el servidor de Exchange; si Outlook puede comunicarse con él, más tarde descubrirá que la /Autodiscover/Autodiscover.xmlruta produce un error HTTP 404 (no existe) y continuará.
Si el https://autodiscover.companyB.com/... URL se resuelve en el servidor de Exchange (o en cualquier otro servidor) pero, de nuevo, autodiscover.companyB.comno aparece en la lista como el nombre común o un nombre alternativo de sujeto, observará este comportamiento. Se puede fijar el anterior fijando el certificado, o como usted indica con razón, se puede utilizar un registro SRV para redirigir Outlook para una URL que se enumeran en el certificado y los que Outlook puede comunicarse con.
Su probable solución a este problema
En este caso, la solución típica es hacer lo último; cree registros SRV en el nuevo proveedor de DNS para garantizar que se redirija Outlook autodiscover.companyA.com, que (aparte de cualquier otro problema) funcionará correctamente, ya que aparece en el certificado como SAN. Para que esto funcione, debe:
- Configure un
_autodiscover._tcp.companyB.comregistro SRV de acuerdo con la documentación .
- Elimine el
autodiscover.companyB.comregistro de host, si existe, para evitar que Outlook lo resuelva e intente alcanzar la Detección automática de esa manera.
- También resuelva cualquier problema con el acceso HTTPS al
https://companyB.comanterior, ya que Outlook enumerará las URL derivadas de la dirección de correo electrónico del usuario antes de pasar al enfoque de registro SRV.
* ¿Cómo funciona la detección automática (para clientes internos unidos a un dominio)?
Agrego esto simplemente para completar, ya que es otra razón común para que se produzcan estas solicitudes de certificado.
En un cliente unido al dominio, cuando es local en el entorno de Exchange (es decir, en la LAN interna), no se utilizan las técnicas anteriores. En cambio, Outlook se comunica directamente con un punto de conexión de servicio en Active Directory (que se enumera en la configuración de acceso de cliente de Exchange), que enumera la URL donde Outlook puede ubicar el servicio de detección automática.
Es común que ocurran advertencias de certificados en estas circunstancias, porque:
- La URL predeterminada configurada para este propósito se refiere a la URL interna de Exchange, que a menudo es diferente de la URL pública.
- Los certificados SSL pueden no incluir la URL interna en ellos. En la actualidad, el suyo sí, pero esto puede convertirse en un problema en el futuro para los dominios de Active Directory que usan
.localy sufijos similares de nombres de dominio de gTLD no globales, ya que una decisión de ICANN prohíbe la emisión de certificados SSL para dichos dominios después de 2016.
- Es posible que la dirección interna no se resuelva en el servidor adecuado.
En este caso, el problema se resuelve corrigiendo la URL registrada para que haga referencia a la dirección externa adecuada (incluida en el certificado), ejecutando el Set-ClientAccessServercmdlet con el -AutodiscoverServiceInternalUriconmutador. Las partes que hacen esto generalmente también configuran DNS de horizonte dividido , ya sea porque están obligados a hacerlo por la configuración de su red y / o por la continuidad de la resolución en caso de una interrupción de resolución / conexión ascendente.