이 문제는 Outlook Anywhere 기능의 일부인 Outlook의 자동 검색 서비스에서 발생 합니다. 자동 검색은 Exchange에서 제공하는 다양한 서비스와 해당 서비스가있는 곳에서 최종 사용자의 Outlook 클라이언트에 다양한 정보를 제공합니다. 이것은 다양한 목적으로 사용됩니다 :
Outlook을 처음 실행할 때 Outlook 프로필 자동 구성. 다른 정보는 자동으로 찾아서 검색되므로 사용자의 전자 메일 주소와 암호 만 사용하여 Exchange 계정을 구성 할 수 있습니다.
부재 중 알림, 통합 메시징 기능, ECP (Exchange 제어판) 위치 등 Outlook 클라이언트가 액세스하는 웹 기반 서비스의 동적 위치.
이것은 RFC 6186 의 Microsoft 독점 구현입니다 . 안타깝게도 Outlook Anywhere 디자인에서 RFC의 권장 사항을 따르지 않았지만 Exchange 및 RPC over HTTPS 기능은 기존의 IMAP / SMTP 서버가 아니기 때문에 예상됩니다.
자동 검색은 어떻게 작동합니까 (외부 * 사용자의 경우)?
자동 검색 /Autodiscover/Autodiscover.xml
은 기본 웹 사이트에서 시작된 경로의 클라이언트 액세스 서버 (이 경우 모든 역할이 SBS 서버에 있음)의 웹 서비스와 통신 합니다. 통신 할 서버의 FQDN을 찾으려면 전자 메일 주소의 사용자 부분을 제거하고 도메인 (예 : @ companyB.com)을 남겨 둡니다. 다음 각 URL을 사용하여 자동 검색과 통신을 시도합니다.
https://companyB.com/Autodiscover/Autodiscover.xml
https://autodiscover.companyB.com/Autodiscover/Autodiscover.xml
이것이 실패하면 SSL을 비활성화하고 포트 80 (HTTP)에서 통신을 시도하여 비보안 연결을 시도합니다. 일반적으로이를 승인하고 일반 텍스트를 통해 자격 증명을 보낼 위험이 있습니다. 자격 증명을 안전하게 전달할 필요가없고 비즈니스에 민감한 데이터를 필요로하는 우연한 sysadmin은 비즈니스 연속성에 위험이 있습니다).
마지막으로, companyB.com
네임 스페이스 에서 잘 알려진 위치에있는 DNS의 SRV (서비스 레코드)를 사용하여 후속 확인이 이루어지며 Outlook이 서버가 수신하는 적절한 URL로 리디렉션 될 수 있습니다.
무엇이 잘못 될 수 있습니까?
이 과정에서 여러 가지 문제 중 하나가 발생할 수 있습니다.
DNS 항목이 없습니다
일반적으로 도메인의 루트 ( companyB.com
)는 DNS의 호스트 레코드로 확인되지 않을 수 있습니다. 부적절한 DNS 구성 (또는 Outlook Anywhere 서비스를 공개하지 않으려는 의도적 인 결정)은 autodiscover.companyB.com
레코드가 존재하지 않음을 의미 할 수 있습니다.
이 경우 큰 문제는 없습니다. Outlook은 마지막으로 알려진 구성을 사용하여 Exchange와 계속해서 통신하며 자동 검색 (예 : 부재 중 지원)을 통해 URL을 검색해야하는 특정 웹 기반 기능과 관련하여 성능이 저하 될 수 있습니다. 해결 방법은 Outlook Web Access를 사용하여 이러한 기능에 액세스하는 것입니다.
새 Outlook 프로필에서 Exchange 계정의 자동 구성도 자동화되지 않으며 RPC over HTTPS 설정을 수동으로 구성해야합니다. 그러나 이로 인해 설명하는 문제가 발생하지는 않습니다.
잘못된 SSL 인증서
Outlook에서 Exchange Server에 연결하기 위해 사용하는 URL은 클라이언트 액세스 서버 일 수도 있고 아닐 수도있는 호스트로 확인 될 수 있습니다. Outlook이 포트 443에서 해당 서버와 통신 할 수 있으면 Outlook과 원격 서버간에 보안 채널을 설정하기 위해 인증서가 교환됩니다. 대화중인 URL Outlook이 해당 인증서에 나열되어 있지 않다고 판단되면 (일반 이름 또는 주체 대체 이름 (SAN)) Outlook에서 초기 게시물에 설명하는 대화 상자를 표시합니다.
이것은 여러 가지 이유로 발생할 수 있습니다. DNS 구성 방식과 위에서 설명한 URL을 Outlook에서 확인하는 방식에 이르기까지 다양합니다.
경우 https://companyB.com/
호스트 레코드에 ... URL이 결의 및 포트 443에 해당 주소를 기울인다에서 웹 서버 와 는 않습니다 SSL 인증서가 없는 목록을 companyB.com
일반 이름 또는 주체 대체 이름에를 한 후 문제가 발생합니다. 호스트가 Exchange Server인지 여부는 중요하지 않습니다. 제대로 구성되지 않은 회사 웹 사이트를 호스팅하는 웹 서버 일 수 있습니다. Corrige 중 하나
- 의 루트에있는 호스트 레코드를 사용하지 않도록
companyB.com
웹 사이트 또는 입력하는 다른 서비스에 방문자가 필요한 영역 ( www.companyB.com
또는 이에 상응하는, 또는
companyB.com
포트 443 에서 컴퓨터에 대한 액세스를 비활성화하여 companyB.com
인증서를 교환하고 계속하기 전에 Outlook에서 URL 을 거부합니다 . 또는
- 에 인증서를 수정
companyB.com
확인하는 companyB.com
해당 인증서에 상장를 방문 시도하는 https://companyB.com
표준 브라우저에서 실패하지 않습니다.
위의 내용은 여부에 관계없이 적용됩니다 companyB.com
은 Exchange Server로 해석 . Outlook이 통신 할 수있는 경우 나중에 /Autodiscover/Autodiscover.xml
경로에 HTTP 404 오류 (존재하지 않음)가 발생 하고 계속 진행됨을 알게 됩니다.
경우 https://autodiscover.companyB.com/
다시, Exchange 서버 (또는 다른 서버)하지만,에 ... URL의 결의 autodiscover.companyB.com
일반 이름 또는 주체 대체 이름으로 나열되지 않은, 당신은이 동작을 관찰합니다. 그것은 인증서를 고정하여 위와 같이 고정 할 수있다, 또는 당신이 올바르게 표시로, 당신은 사용할 수 있습니다 SRV 레코드를 URL로 Outlook을 리디렉션하는 것입니다 인증서에 등록하고있는 Outlook이 수 와 통신합니다.
이 문제에 대한 가능한 해결책
이 경우 일반적인 수정은 후자를 수행하는 것입니다. 새 DNS 공급자에서 SRV 레코드를 만들어 Outlook이 리디렉션되도록합니다.autodiscover.companyA.com
문제는 인증서에 SAN으로 나열되어 있기 때문에 다른 문제는 제외합니다. 이것이 작동하려면 다음이 필요합니다.
_autodiscover._tcp.companyB.com
에 따라 SRV 레코드 구성설명서 하십시오 .
- 삭제
autodiscover.companyB.com
호스트 레코드가있는 경우 Outlook에서이를 해결하여 자동 검색에 도달하지 못하게 호스트 레코드를 .
https://companyB.com
Outlook은 SRV 레코드 방식으로 넘어 가기 전에 사용자의 전자 메일 주소에서 파생 된 URL을 열거하므로 위와 같이 HTTPS 액세스 관련 문제도 해결하십시오 .
* 자동 검색은 어떻게 작동합니까 (내부 도메인 가입 클라이언트의 경우)?
이 인증서 프롬프트가 발생하는 또 다른 일반적인 이유이기 때문에이를 완벽하게 추가합니다.
도메인 가입 클라이언트에서 Exchange 환경에 로컬 인 경우 (예 : 내부 LAN) 위의 기술은 사용되지 않습니다. 대신 Outlook은 Exchange 클라이언트 액세스 설정에 나열된 Active Directory의 서비스 연결 지점과 직접 통신하여 Outlook에서 자동 검색 서비스를 찾을 수있는 URL을 나열합니다.
다음과 같은 상황에서 인증서 경고가 발생하는 것이 일반적입니다.
- 이 목적으로 구성된 기본 URL 은 Exchange 의 내부 URL을 나타내며, 종종 공용 URL과 다릅니다.
- SSL 인증서는 내부 URL을 나열하지 않을 수 있습니다. ICANN의 결정에 따라 2016 년 이후에 그러한 도메인에 대한 SSL 인증서가 발행되는 것을 금지하기
.local
때문에 현재 귀하는 그럴 것입니다 .
- 내부 주소가 올바른 서버로 확인되지 않을 수 있습니다.
이 경우 스위치 Set-ClientAccessServer
와 함께 cmdlet을 실행하여 기록 된 URL이 올바른 외부 주소 (인증서에 나열 됨)를 참조하도록 수정하여 문제를 해결 -AutodiscoverServiceInternalUri
합니다. 이 작업을 수행하는 당사자는 일반적으로 분할-수평 DNS를 구성합니다. 네트워크 구성 및 / 또는 업스트림 리졸버 / 연결 중단시에도 지속적으로 해결해야하기 때문입니다.