ปัญหานี้มักเกิดจากบริการAutodiscoverของ Outlook ซึ่งเป็นส่วนหนึ่งของฟังก์ชันOutlook Anywhere Autodiscover ให้ข้อมูลที่หลากหลายไปยังไคลเอนต์ Outlook ของผู้ใช้ปลายทางบนบริการต่าง ๆ ที่นำเสนอโดย Exchange และตำแหน่งที่สามารถอยู่ได้ สิ่งนี้ใช้เพื่อจุดประสงค์ที่หลากหลาย:
การกำหนดค่าโปรไฟล์อัตโนมัติของ Outlook ในการเรียกใช้ครั้งแรกของ Outlook ซึ่งสามารถกำหนดค่าบัญชี Exchange โดยใช้ที่อยู่อีเมลและรหัสผ่านของผู้ใช้เท่านั้นเนื่องจากข้อมูลอื่นจะถูกค้นหาและดึงข้อมูลโดยอัตโนมัติ
ตำแหน่งไดนามิกของบริการบนเว็บที่เข้าถึงได้โดยไคลเอนต์ Outlook รวมถึงผู้ช่วยนอกสำนักงานฟังก์ชันการส่งข้อความ Unified ตำแหน่งของแผงควบคุม Exchange (ECP) และอื่น ๆ
นี้คือการดำเนินการที่เป็นกรรมสิทธิ์ของไมโครซอฟท์ของRFC 6186 น่าเสียดายที่พวกเขาไม่ได้ปฏิบัติตามคำแนะนำของ RFC นั้นในการออกแบบของ Outlook Anywhere แต่อาจเป็นที่คาดหวังเนื่องจากการแลกเปลี่ยนและ RPC ผ่านฟังก์ชัน HTTPS ไม่ใช่เซิร์ฟเวอร์ IMAP / SMTP แบบดั้งเดิม
Autodiscover ทำงานอย่างไร (สำหรับผู้ใช้ภายนอก *)
Autodiscover สื่อสารกับเว็บเซอร์วิสบนไคลเอนต์ Access Server (ในกรณีนี้บทบาททั้งหมดอยู่บนเซิร์ฟเวอร์ SBS) ที่เส้นทาง/Autodiscover/Autodiscover.xmlรูทจากเว็บไซต์เริ่มต้น หากต้องการค้นหา FQDN ของเซิร์ฟเวอร์เพื่อสื่อสารกับมันจะลบส่วนของผู้ใช้ที่อยู่อีเมลออกจากโดเมน (เช่น @ companyB.com) มันพยายามสื่อสารกับ Autodiscover โดยใช้ URL ต่อไปนี้ตามลำดับดังนี้:
https://companyB.com/Autodiscover/Autodiscover.xmlhttps://autodiscover.companyB.com/Autodiscover/Autodiscover.xml
หากสิ่งเหล่านี้ล้มเหลวมันจะพยายามเชื่อมต่อที่ไม่ปลอดภัยโดยการปิดการใช้งาน SSL และพยายามสื่อสารบนพอร์ต 80 (HTTP) โดยทั่วไปหลังจากแจ้งผู้ใช้ให้ยืนยันว่านี่เป็นการกระทำที่ยอมรับได้ (เป็นตัวเลือกที่มีข้อบกพร่องในความคิดของฉัน โดยทั่วไปแล้วอนุมัติเรื่องนี้และความเสี่ยงในการส่งข้อมูลประจำตัวมากกว่าข้อความธรรมดาและผู้ดูแลระบบที่ไม่ต้องการการสื่อสารที่ปลอดภัยของข้อมูลประจำตัวและข้อมูลที่อ่อนไหวทางธุรกิจมีความเสี่ยงต่อความต่อเนื่องทางธุรกิจ)
ในที่สุดการตรวจสอบที่ตามมาจะทำโดยใช้บริการบันทึก (SRV) ใน DNS ซึ่งมีอยู่ในตำแหน่งที่รู้จักกันดีนอกcompanyB.comเนมสเปซและสามารถเปลี่ยนเส้นทาง Outlook ไปยัง URL ที่เหมาะสมที่เซิร์ฟเวอร์กำลังรับฟังอยู่
มีอะไรผิดพลาด?
หนึ่งในหลาย ๆ ปัญหาสามารถเกิดขึ้นได้ในกระบวนการนี้:
ไม่มีรายการ DNS
โดยทั่วไปแล้วรากของโดเมน ( companyB.com) อาจไม่สามารถแก้ไขระเบียนโฮสต์ใน DNS ได้ การกำหนดค่า DNS ที่ไม่เหมาะสม (หรือการตัดสินใจอย่างมีสติไม่เปิดเผยบริการ Outlook Anywhere) อาจหมายความว่าautodiscover.companyB.comไม่มีระเบียนอยู่
ในกรณีเหล่านี้ไม่มีปัญหาสำคัญ Outlook จะสื่อสารกับ Exchange ต่อไปโดยใช้การกำหนดค่าล่าสุดที่ทราบและอาจเสื่อมโทรมเมื่อเทียบกับฟังก์ชั่นบางอย่างบนเว็บที่ต้องการดึง URL ผ่าน Autodiscover (เช่นผู้ช่วยที่ไม่อยู่ที่สำนักงาน) วิธีแก้ปัญหาคือใช้ Outlook Web Access เพื่อเข้าถึงฟังก์ชันดังกล่าว
การกำหนดค่าอัตโนมัติของบัญชี Exchange ในโปรไฟล์ Outlook ใหม่นั้นยังไม่อัตโนมัติและต้องกำหนดค่า RPC ด้วยตนเองผ่านการตั้งค่า HTTPS ด้วยตนเอง อย่างไรก็ตามสิ่งนี้จะไม่ทำให้เกิดปัญหาที่คุณอธิบาย
ใบรับรอง SSL ผิดพลาด
เป็นไปได้ทั้งหมดที่ URL Outlook ใช้เพื่อพยายามติดต่อ Exchange Server จะแก้ไขเป็นโฮสต์ซึ่งอาจเป็นเซิร์ฟเวอร์การเข้าถึงไคลเอ็นต์หรือไม่ก็ได้ หาก Outlook สามารถสื่อสารกับเซิร์ฟเวอร์นั้นบนพอร์ต 443 แน่นอนว่าจะมีการแลกเปลี่ยนใบรับรองเพื่อตั้งค่าช่องทางที่ปลอดภัยระหว่าง Outlook และเซิร์ฟเวอร์ระยะไกล หาก URL Outlook เชื่อว่าไม่ได้อยู่ในรายการใบรับรองนั้นไม่ว่าจะเป็นชื่อสามัญหรือชื่อสำรอง (SAN) - สิ่งนี้จะกระตุ้นให้ Outlook นำเสนอกล่องโต้ตอบที่คุณอธิบายในโพสต์เริ่มต้นของคุณ
สิ่งนี้อาจเกิดขึ้นได้จากหลายสาเหตุรวมถึงวิธีกำหนดค่า DNS และวิธีตรวจสอบ URL ที่ฉันอธิบายด้านบนโดย Outlook:
หากhttps://companyB.com/URL ... แก้ไขเป็นโฮสต์เรคคอร์ดและเว็บเซิร์ฟเวอร์ที่ที่อยู่นั้นฟังพอร์ต 443 และมีใบรับรอง SSL ที่ไม่แสดงcompanyB.comในชื่อสามัญหรือ Subject Alternative Name ปัญหานี้จะเกิดขึ้น มันไม่สำคัญว่าโฮสต์เป็น Exchange Server หรือไม่ อาจเป็นเว็บเซิร์ฟเวอร์ที่โฮสต์เว็บไซต์ บริษัท ที่ไม่ได้รับการกำหนดค่าอย่างเหมาะสม Corrigeอย่างใดอย่างหนึ่ง:
- ปิดการใช้งานบันทึกโฮสต์ที่รูทของ
companyB.comโซน (กำหนดให้ผู้เยี่ยมชมเว็บไซต์หรือบริการอื่น ๆ เข้าwww.companyB.comมาหรือเทียบเท่าหรือ
- ปิดใช้งานการเข้าถึงเครื่องที่
companyB.comพอร์ต 443 ทำให้ Outlook ปฏิเสธcompanyB.comURL ก่อนที่จะมีการแลกเปลี่ยนใบรับรองและดำเนินการต่อ หรือ
- แก้ไขใบรับรองที่
companyB.comเพื่อให้แน่ใจว่าcompanyB.comมีการระบุไว้ในใบรับรองนั้นและความพยายามที่จะเยี่ยมชมhttps://companyB.comในเบราว์เซอร์มาตรฐานจะไม่ล้มเหลว
ข้อมูลข้างต้นมีผลบังคับใช้ไม่ว่าจะcompanyB.comแก้ไขใน Exchange Server หรือไม่ หาก Outlook สามารถสื่อสารกับมันได้ในภายหลังจะพบว่า/Autodiscover/Autodiscover.xmlเส้นทางให้ข้อผิดพลาด HTTP 404 (ไม่มีอยู่) และดำเนินการต่อ
หากhttps://autodiscover.companyB.com/URL ... แก้ไขเป็น Exchange Server (หรือเซิร์ฟเวอร์อื่น ๆ ) ได้ แต่autodiscover.companyB.comจะไม่มีรายชื่อเป็นชื่อสามัญหรือชื่อทางเลือกหัวเรื่องคุณจะสังเกตเห็นลักษณะการทำงานนี้ มันสามารถได้รับการแก้ไขดังกล่าวโดยการแก้ไขใบรับรองหรือตามที่คุณถูกต้องระบุคุณสามารถใช้ระเบียน SRVเพื่อเปลี่ยนเส้นทางของ Outlook ไปยัง URL ที่ถูกระบุไว้ในใบรับรองและ Outlook ที่สามารถสื่อสารกับ
การแก้ไขปัญหานี้น่าจะเป็นของคุณ
ในกรณีนี้การแก้ไขทั่วไปคือการทำหลัง สร้างเรคคอร์ด SRV ในผู้ให้บริการ DNS ใหม่เพื่อให้แน่ใจว่า Outlook ถูกเปลี่ยนเส้นทางไปautodiscover.companyA.comซึ่ง (ปัญหาอื่น ๆ นอกเหนือจากกัน) จะทำงานได้สำเร็จเนื่องจากมีการระบุไว้ในใบรับรองเป็น SAN ในการทำงานคุณต้อง:
- กำหนดค่า
_autodiscover._tcp.companyB.comระเบียน SRV สอดคล้องกับเอกสาร
- ลบ
autodiscover.companyB.comระเบียนโฮสต์ถ้ามีอยู่เพื่อป้องกันไม่ให้ Outlook แก้ไขปัญหานี้และพยายามเข้าถึง Autodiscover ด้วยวิธีดังกล่าว
- แก้ไขปัญหาใด ๆ ด้วยการเข้าถึง HTTPS
https://companyB.comตามด้านบนเนื่องจาก Outlook จะระบุ URL ที่ได้รับจากที่อยู่อีเมลของผู้ใช้ก่อนที่จะเข้าสู่แนวทางการบันทึก SRV
* Autodiscover ทำงานอย่างไร (สำหรับลูกค้าที่เข้าร่วมกับโดเมน)
ฉันเพิ่มสิ่งนี้เพียงเพื่อความสมบูรณ์เนื่องจากเป็นอีกสาเหตุหนึ่งที่ทำให้ใบรับรองเหล่านี้เกิดขึ้น
บนไคลเอนต์ที่เข้าร่วมโดเมนเมื่ออยู่ในระบบ Local Exchange (เช่นบน LAN ภายใน) จะไม่ใช้เทคนิคด้านบน แทน Outlook จะสื่อสารโดยตรงกับจุดเชื่อมต่อบริการใน Active Directory (อยู่ในการตั้งค่าการเข้าถึงไคลเอ็นต์ Exchange) ซึ่งแสดง URL ที่ Outlook สามารถค้นหาบริการ Autodiscover
เป็นเรื่องปกติที่คำเตือนใบรับรองจะเกิดขึ้นในสถานการณ์เหล่านี้เนื่องจาก:
- URL เริ่มต้นที่กำหนดค่าไว้สำหรับวัตถุประสงค์นี้อ้างถึงURL ภายในของ Exchange ซึ่งมักจะไม่เหมือนกันจาก URL สาธารณะ
- ใบรับรอง SSL ไม่สามารถแสดงรายการ URL ภายในได้ ในปัจจุบันคุณทำ แต่สิ่งนี้อาจกลายเป็นปัญหาในอนาคตสำหรับโดเมน Active Directory ที่ใช้
.localและต่อท้ายชื่อโดเมน gTLD ที่ไม่คล้ายกันทั่วโลกเนื่องจากการตัดสินใจโดย ICANNห้ามมิให้มีการออกใบรับรอง SSL สำหรับโดเมนดังกล่าวที่ออกหลังปี 2016
- ที่อยู่ภายในอาจไม่สามารถแก้ไขกับเซิร์ฟเวอร์ที่เหมาะสม
ในกรณีนี้ปัญหาได้รับการแก้ไขโดยแก้ไข URL ที่บันทึกไว้เพื่ออ้างอิงที่อยู่ภายนอกที่เหมาะสม (อยู่ในใบรับรอง) โดยเรียกใช้Set-ClientAccessServercmdlet ด้วย-AutodiscoverServiceInternalUriสวิตช์ โดยทั่วไปฝ่ายที่ทำสิ่งนี้จะกำหนดค่าDNS แบบแยกส่วนด้วยเนื่องจากจะต้องดำเนินการดังกล่าวด้วยการกำหนดค่าเครือข่ายและ / หรือเพื่อความต่อเนื่องของการแก้ไขในกรณีที่เกิดปัญหาเครื่องสำรอง / กระแสไฟดับ