Elimina o aviso de certificado quando os usuários acessam o Outlook / Exchange 2010 na configuração do domínio dividido

2

Eu tenho um servidor Exchange 2010 hospedado internamente com um domínio interno, EXCHANGE0.COMPANY.COM .

Eu configurei todos os usuários para acessar o Outlook (mesmo internamente) usando o Outlook-over-HTTP. Para isso, configurei um certificado de acesso para cliente para o domínio externo mail.company.com .

O problema é que sempre que os usuários abrem o Outlook, eles são recebidos prontamente por avisos de certificados sobre a incompatibilidade entre mail.company.com e EXCHANGE0.COMPANY.COM . Eu gostaria de eliminar esses avisos e sinto que existe uma maneira de fazer isso através do DNS ou do Exchange. Eu não tenho certeza do que fazer.

O AutoDiscover é configurado usando o método SRV, se isso realmente importa.

EDIT: A configuração nos clientes é a seguinte

Exchange Server: EXCHANGE0.COMPANY.COM Conecte-se usando o Outlook em Qualquer Lugar (HTTP): em conexões rápidas e lentas, conecte-se a mail.company.com e confie apenas em msstd: mail.company.com

O nome no certificado é mail.company.com, mas o Outlook estava esperando EXCHANGE0.COMPANY.COM

    
por tacos_tacos_tacos 16.12.2011 / 17:27

6 respostas

4

Você pode resolver esse problema definindo os atributos InternalURL dos vários componentes do Exchange para que correspondam ao seu nome externo (mail.company.com). Uma vez feito isso, você pode criar um registro DNS (provavelmente um CNAME para "mail.company.com" para "exchange0.company.com" - parece que você nomeou seu domínio do AD da mesma forma que seu nome de domínio real da Internet ) para que os clientes possam se conectar ao "mail.company.com" e serem direcionados ao computador do Exchange Server.

Os comandos "set" para cada componente que você precisará executar estão abaixo. Você pode usar as versões "Get-" desses comandos para ver como eles estão definidos agora.

Set-ActiveSyncVirtualDirectory -InternalURL
Set-AutodiscoverVirtualDirectory -InternalURL
Set-ClientAccessServer -AutodiscoverServiceInternalUri
Set-ECPVirtualDirectory -InternalURL
Set-OABVirtualDirectory -InternalURL
Set-OWAVirtualDirectory -InternalURL
Set-WebservicesVirtualDirectory -InternalURL
    
por 29.12.2011 / 02:25
0

Para resolver este problema, você precisará de um novo certificado! Por que é que? Porque você precisará do assunto do certificado para corresponder a mail.company.com, exchange0.company.com e preferencialmente autodiscover.company.com também.

Uma solução alternativa seria usar um certificado curinga para todos os serviços (* .company.com)

    
por 29.12.2011 / 01:46
0

Se eu entendi corretamente que você deseja reconfigurar seus serviços de troca para trabalhar em um domínio (mesmo internamente) usando este KB940726 ou este link (ambos cobrindo a mesma coisa). O erro é consistente para o servidor Exchange 2007/2010. Caso contrário, você precisará de um certificado SAN (ou um certificado curinga) para abranger mais de um domínio com o mesmo certificado (que é custoso).

Além disso, se você estiver com pouco dinheiro ou apoiando uma pequena empresa, eu recomendo que você use autodiscover.domain.com como seu domínio principal para tudo (mesmo para os seus clientes do Outlook se conectarem, owa, etc.). Pode parecer inconveniente, mas isso economiza custos em certificados que exigem a cobertura de mais de um domínio (certificados SAN). Descobri que esta é a solução mais econômica para meus pequenos clientes que não querem pagar 100-1000 $ anuais apenas para obter um certificado que possa manipular vários domínios em um ip / port.

E, para terminar, você pode obter certificados SSL gratuitos (reais gratuitos!) de StartSSL renovados anualmente sem qualquer custo. Apenas a revogação não é gratuita, mas contanto que você gere certs corretamente e não solte chaves, você deve estar seguro.

    
por 29.12.2011 / 01:34
0

Eu tive esse problema no outro dia em um cliente onde eu (na época) não conseguia descobrir como fazer o reflexo do NAT funcionar, para que os usuários acessassem o mail.example.com no Outlook 2010 (que aparentemente adiciona o Outlook HTTP por padrão) estavam sendo redirecionados para a interface interna do firewall (que tinha um certificado self-signed do somefirewall.local).

Resolvi o problema configurando DNS dividido: criei uma Zona para example.com no DNS do Active Directory (e adicionei todos os registros e subdomínios apropriados, como A, CNAMEs, MX, TXT, etc.) e certificou-se de que mail.example.com fosse resolvido para o endereço IP interno do Exchange Server. Trabalhou sem problemas, mas é uma dor ter que lembrar de manter ambas as Zonas (reais e internas) atualizadas se não houver confiança / método automatizado de fazê-lo.

EDITAR

Isso deve funcionar para você se você criar uma zona para mail.company.com e criar um registro A para que o (pai) seja resolvido em seu servidor Exchange interno, porque se o certificado mail.company.com estiver instalado no Exchange, deve ser válido / confiável.

    
por 29.12.2011 / 01:39
0

Consertei o meu com esses 4 comandos (altere os nomes dos servidores / URLs da web conforme necessário)

Set-ClientAccessServer -Identity EXCHANGE-SERVER -AutoDiscoverServiceInternalUri https://exchange-server.example.com/Autodiscover/Autodiscover.xml

Enable-OutlookAnywhere -Server EXCHANGE-SERVER -ExternalHostname "exchange-server.example.com" -DefaultAuthenticationMethod "Basic" -SSLOffloading:$False

Set-OABVirtualDirectory -identity "EXCHANGE-SERVER\OAB (Default Web Site)" -externalurl https://exchange-server.example.com/OAB -RequireSSL:$true -InternalUrl https://exchange-server.example.com/OAB

Set-WebServicesVirtualDirectory -identity "EXCHANGE-SERVER\EWS (Default Web Site)" -externalurl https://exchange-server.example.com/EWS/Exchange.asmx -BasicAuthentication:$True -InternalUrl https://exchange-server.example.com/EWS/Exchange.asmx

Eu recuperei o IIS depois de uma boa medida.

    
por 03.10.2014 / 17:46
0

Corrigido o estranho alerta de segurança ao alternar para o Modo off-line no Outlook e de volta ao Work Online. O alerta foi exibido um minuto depois de abrir o Outlook. O nome no certficate não era o nome correspondente da conexão. Todos os webservices, oab, ecp, autodiscover, activesync e owa, foram definidos corretamente.

    
por 13.04.2017 / 20:32