Esse problema provavelmente é causado pelo serviço de Descoberta Automática do Outlook , parte da funcionalidade do Outlook em Qualquer Lugar . A descoberta automática fornece várias informações ao cliente Outlook do usuário final sobre os vários serviços oferecidos pelo Exchange e onde eles podem ser localizados; isso é usado para vários propósitos:
Configuração automática de perfis do Outlook na primeira execução do Outlook, que pode configurar uma conta do Exchange usando apenas o endereço de email e a senha do usuário, pois as outras informações são localizadas e recuperadas automaticamente.
Localização dinâmica de serviços baseados na Web acessados pelo cliente Outlook, incluindo o assistente de ausência temporária, a funcionalidade de Unificação de Mensagens, a localização do Painel de Controle do Exchange (ECP) e assim por diante.
Esta é a implementação proprietária da Microsoft do RFC 6186 . Infelizmente, eles realmente não seguiram as recomendações dessa RFC no design do Outlook em Qualquer Lugar, mas talvez isso seja esperado, já que a funcionalidade Exchange e RPC sobre HTTPS não é um servidor IMAP / SMTP tradicional.
Como a Descoberta Automática funciona (para usuários externos *)?
A descoberta automática se comunica com um serviço da Web em um Servidor de Acesso para Cliente (nesse caso, todas as funções estão no servidor SBS) no caminho /Autodiscover/Autodiscover.xml, com raiz do site padrão. Para localizar o FQDN do servidor com o qual se comunicar, ele remove a parte do usuário do endereço de email, deixando o domínio (por exemplo, @ companyB.com). Ele tenta se comunicar com a Descoberta Automática usando cada um dos seguintes URLs, por sua vez:
https://companyB.com/Autodiscover/Autodiscover.xmlhttps://autodiscover.companyB.com/Autodiscover/Autodiscover.xml
Se eles falharem, ele tentará uma conexão não segura desativando o SSL e tentando se comunicar na porta 80 (HTTP), normalmente após solicitar ao usuário que confirme que esta é uma ação aceitável (uma opção falha na minha opinião, pois os usuários sem noção irão normalmente aprova isso e corre o risco de enviar credenciais em texto sem formatação - e os administradores de sistemas sem noção que não exigem comunicação segura de credenciais e dados sensíveis aos negócios são um risco para a continuidade dos negócios).
Finalmente, é feita uma verificação subseqüente usando um registro de serviço (SRV) no DNS, que existe em um local conhecido fora do companyB.comespaço para nome e pode redirecionar o Outlook para o URL apropriado onde o servidor está escutando.
O que pode dar errado?
Um dos vários problemas pode surgir nesse processo:
Nenhuma entrada DNS
Normalmente, a raiz do domínio ( companyB.com) pode não ser resolvida para um registro de host no DNS. A configuração incorreta do DNS (ou uma decisão consciente de não expor o serviço Outlook em Qualquer Lugar) pode significar que o autodiscover.companyB.comregistro também não existe.
Nesses casos, não há grande problema; O Outlook simplesmente continua a se comunicar com o Exchange usando a última configuração conhecida e pode ser degradado com relação a determinadas funções baseadas na Web, para as quais ele precisa recuperar URLs através da Descoberta Automática (como o assistente de ausência temporária). Uma solução alternativa é usar o Outlook Web Access para acessar essas funções.
A configuração automática de contas do Exchange em novos perfis do Outlook também não é automatizada e requer configuração manual das configurações de RPC sobre HTTPS. No entanto, isso não causará o problema que você descreve.
Certificados SSL com defeito
É perfeitamente possível que o URL que o Outlook usa para tentar entrar em contato com o Exchange Server resolva para um host, que pode ou não ser um Servidor de Acesso para Cliente. Se o Outlook puder se comunicar com esse servidor na porta 443, é claro que os certificados serão trocados para configurar um canal seguro entre o Outlook e o servidor remoto. Se o URL que o Outlook acredita que está falando não estiver listado nesse certificado - seja como o nome comum ou um nome alternativo de assunto (SAN) - isso fará com que o Outlook apresente a caixa de diálogo que você descreve na postagem inicial.
Isso pode acontecer por vários motivos, tudo sobre como o DNS está configurado e como os URLs que descrevi acima são verificados pelo Outlook:
Se a https://companyB.com/URL ... for resolvida para um registro de host e o servidor da Web nesse endereço ouvir na porta 443, e tiver um certificado SSL que não esteja listado companyB.comno nome comum ou no Nome Alternativo do Assunto, o problema ocorrerá. Não importa se o host é um servidor Exchange ou não; pode ser um servidor da web que hospeda um site da empresa que não está configurado corretamente. Corrige :
- Desabilite o registro do host na raiz da
companyB.comzona (exigindo a entrada de visitantes do site ou outro serviço www.companyB.comou equivalente; ou
- Desabilite o acesso à máquina na
companyB.comporta 443, fazendo com que o Outlook rejeite a companyB.comURL antes que os certificados sejam trocados e prossiga; ou
- Corrija o certificado em
companyB.compara garantir que companyB.comesteja listado nesse certificado e que as tentativas de visita https://companyB.comem um navegador padrão não falhem.
O acima se aplica independentemente de a companyB.comresolução ser resolvida no Exchange Server; se o Outlook puder se comunicar com ele, descobrirá mais tarde que o /Autodiscover/Autodiscover.xmlcaminho gera um erro HTTP 404 (não existe) e seguirá em frente.
Se o https://autodiscover.companyB.com/URL ... for resolvido para o Exchange Server (ou qualquer outro servidor) mas, novamente, autodiscover.companyB.comnão estiver listado como o nome comum ou um nome alternativo do assunto, você observará esse comportamento. Ele pode ser fixado como acima, fixando o certificado, ou como você indicar corretamente, você pode usar um registro SRV para redirecionar o Outlook para uma URL que está listada no certificado e que Outlook pode se comunicar com.
Sua provável correção para esse problema
Nesse caso, a correção típica é fazer a última; crie registros SRV no novo provedor DNS para garantir que o Outlook seja redirecionado autodiscover.companyA.com, o qual (quaisquer outros problemas à parte) funcionará com êxito, pois está listado no certificado como uma SAN. Para que isso funcione, você precisa:
- Configure um
_autodiscover._tcp.companyB.comregistro SRV de acordo com a documentação .
- Exclua o
autodiscover.companyB.comregistro do host, se existir, para impedir que o Outlook resolva isso e tente alcançar a Descoberta Automática dessa maneira.
- Resolva também quaisquer problemas com o acesso HTTPS
https://companyB.comconforme acima, pois o Outlook enumera os URLs derivados do endereço de email do usuário antes de recorrer à abordagem de registro SRV.
* Como a Descoberta Automática funciona (para clientes internos ingressados no domínio)?
Eu adiciono isso apenas para fins de integridade, pois é outro motivo comum para a solicitação desses certificados.
Em um cliente ingressado no domínio, quando é local no ambiente do Exchange (ou seja, na LAN interna), as técnicas acima não são usadas. Em vez disso, o Outlook se comunica diretamente com um Ponto de Conexão de Serviço no Active Directory (listado nas configurações de Acesso para Cliente do Exchange), que lista a URL onde o Outlook pode localizar o serviço de Descoberta Automática.
É comum que avisos de certificado ocorram nessas circunstâncias, porque:
- O URL padrão configurado para esse fim se refere ao URL interno do Exchange, que geralmente é diferente do URL público.
- Os certificados SSL podem não listar a URL interna neles. No momento, o seu é o caso, mas isso pode se tornar um problema no futuro para domínios do Active Directory que usam
.localsufixos não globais de nomes de domínio semelhantes a gTLDs, já que uma decisão da ICANN proíbe que certificados SSL para esses domínios sejam emitidos após 2016.
- O endereço interno pode não ser resolvido no servidor apropriado.
Nesse caso, o problema é resolvido corrigindo a URL registrada para se referir ao endereço externo apropriado (listado no certificado), executando o Set-ClientAccessServercmdlet com a -AutodiscoverServiceInternalUriopção As partes que fazem isso normalmente também configuram o DNS com horizonte dividido , porque são obrigadas a fazê-lo por sua configuração de rede e / ou pela continuidade da resolução no caso de uma interrupção de conexão / resolver upstream.