Outlook 보안 경고-보안 인증서의 이름이 유효하지 않거나 사이트 이름과 일치하지 않습니다


14

Exchange 2007 및 IIS6.0을 실행하는 SBS 2008

CompanyA에는 동일한 지붕에서 운영되는 다른 두 회사가 있습니다. 이메일을 수용하기 위해 사용자 당 3 개의 Exchange 계정이 있습니다. 모든 사용자는 CompanyA 계정을 사용하여 도메인에 로그인합니다.

  • CORP \ user user@companyA.com
  • CORP \ user-companyb user@companyB.com <-이메일에만 사용
  • CORP \ user-companyc user@companyC.com <-이메일에만 사용

이메일은 내부 및 OWA를 통해 정상적으로 작동합니다. companyB 및 companyC 전자 메일에 액세스해야하는 원격 사용자를 위해 Outlook을 설정할 때 문제가 발생하면 Outlook에서 인증서 오류가 나타납니다.

SSL cert SAN의 DNS 이름은 다음과 같습니다.

  • webmail.companyA.com
  • www.webmail.companyA.com
  • CORP-SBS
  • CORP-SBS.local
  • autdiscover.companyA.com

companyC 전자 메일 주소에 원격으로 액세스하는 사용자에게 이것이 전에는 결코 발생하지 않았다고 들었습니다. 이것은 CEO가 스스로 DNS 공급자를 변경하고 원래 DNS 설정이 손실되는 과정에서 시작되었습니다. 그는이 문제를 해결 한 SRV 레코드에 대해 언급했지만 그 문제에 관한 것입니다.

이 문제를 올바르게 해결하는 방법에 대한 지침을 찾고 있습니다.

답변:


25

이 문제는 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.comOutlook은 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를 구성합니다. 네트워크 구성 및 / 또는 업스트림 리졸버 / 연결 중단시에도 지속적으로 해결해야하기 때문입니다.


2
뛰어난 쓰기! 마지막 섹션에서는 SLP (Service Locator Point)가 아닌 SCP (Service Connection Point) 여야한다고 생각합니다.
BlueCompute

@BlueCompute 사실, 당신 말이 맞아요, 최근에 너무 오랫동안 System Center에 머리를 썼습니다! (SLP는 SCCM 2007에 존재했으며 SCP와 원격 관련 목적으로 사용되었습니다). 위 수정
Cosmic Ossifrage

작성해 주셔서 감사합니다! autodiscover.companyA.com이 CNAME 레코드가 아니라 A 레코드라는 것을 알았습니다. 이것이 companyB.com에서 올바르게 작동하는 SRV 레코드에 영향을 줍니까?
Mike66350216

1
DNS 제공 업체 중에서도 SRV 레코드에 대한 공개 지원은 여전히 ​​부족합니다. 그래도 정렬 된 것처럼 들립니다!
우주 Ossifrage

3
나는 당신의 훌륭한 글쓰기 + 다음 링크가 내 문제를 해결했다고 지적하고 싶습니다. superuser.com/questions/770308/... . 저와 같은 보트에있는 사람에게이 메모를 남기고 싶었습니다.
James Watt

3

인증서의 이름 중 하나 (autodiscover.companyA.com)와 일치하는 도메인 B 및 C에 SRV 레코드를 작성해야합니다. 이렇게하면 해당 이름이 도메인 B 및 C의 자동 검색을 처리한다고 Outlook에 알립니다.

DNS 섹션의 SRV 레코드를 읽으십시오.

https://jaapwesselius.com/2011/08/28/autodiscover-redirect-srv-record/


1
링크가 끊어졌습니다.
나는 Reinstate Monica

@Twisty 링크를 수정했습니다.
Alexander Gonchiy
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.