จะแก้ปัญหาเกี่ยวกับ Autodiscover (xml) ของ Exchange และไคลเอนต์เฉพาะเช่น Windows Communication Apps [HxTsr.exe] ที่มีการกำหนดค่า DNS ที่ซับซ้อนได้อย่างไร

สำหรับเครื่องมือค้นหา องค์ประกอบบริบท:

• แลกเปลี่ยนออนไลน์
• Office 365 / Microsoft 365 --> Outlook เฉพาะ --> outlook.office.com
• แอปจดหมายและปฏิทินของ Windows [HxTsr.exe, "microsoft.windowscommunicationsapps"]
• เปลี่ยนเส้นทางโดเมน Apex ไปที่ www.~
• Cloudflare DNS
• ใช้คนงาน Cloudflare
• HSTS สำหรับโดเมนย่อยด้วย
• [Azure's] Conditional Access กำลังบล็อกวิธีการรับรองความถูกต้องแบบดั้งเดิม ('การรับรองความถูกต้องพื้นฐาน')
• cname ของ autodiscover.domain.tld ถูกกำหนดค่าเป็น autodiscover.outlook.com ตามที่คาดไว้ ลูกเล่นของ Cloudflare ถูกปิดใช้งานสำหรับบันทึกนี้
• Cloudflare ให้บริการ SSL สำหรับโดเมนส่วนใหญ่ ยกเว้น autodiscover.domain.tld

ตอนนี้พฤติกรรมที่ไม่พึงประสงค์:

ในกรณีนี้ Autodiscover ไม่ทำงานสำหรับ 'windowscommunicationsapps' ซึ่งต่อจากนี้จะเรียกว่า 'problem client' หรือ 'client' มันใช้งานได้กับ Outlook ล่าสุดสำหรับ Windows ส่วนใหญ่เนื่องจากวิธีการค้นหาอัตโนมัติในตัวที่ทันสมัยกว่าซึ่งข้ามการค้นหาอัตโนมัติแบบดั้งเดิม

ไคลเอ็นต์ที่มีปัญหาจะโหลดและโหลดและแจ้งรหัสผ่านการตรวจสอบสิทธิ์พื้นฐาน จากนั้นแจ้งชื่อผู้ใช้และโดเมน จากนั้นแสดงข้อผิดพลาดพร้อมตัวเลือกเพื่อไปที่ขั้นสูงและป้อนทุกอย่างอีกครั้งรวมถึงเซิร์ฟเวอร์ หลังจากนั้นหลังจากที่ฉันจำได้ว่าเข้ามา outlook.office365.com ในฐานะเซิร์ฟเวอร์ ระบบจะแจ้งผู้ใช้ด้วยหน้าต่างการรับรองความถูกต้องที่ทันสมัยของ Microsoft

เกิดอะไรขึ้น:

ลูกค้าพยายามเรียกคืน https://rootdomain.tld/autodiscover/autodiscover.xml. (เห็นในบันทึกไฟร์วอลล์ของ cloudflare)

มันถูกเปลี่ยนเส้นทางไปที่ https://www.rootdomain.tld/autodiscover/autodiscover.xml. (เห็นใน เครื่องมือของ MS.)

เนื่องจากการกำหนดค่าที่ซับซ้อนของผู้ปฏิบัติงาน Cloudflare ลูกค้าจึงไม่ได้รับ 404 กลับมาในอินสแตนซ์แรก มันเอาแต่โหลดและโหลด ในการกำหนดค่ารูปแบบ พนักงาน Cloudflare เฉพาะส่งคืนหน้า 404; มันไม่ได้แก้ปัญหา

ปัญหาคือมันเกิดขึ้นมากเกินไป

• http ถูกเปลี่ยนเส้นทางไปที่ https
• Root (apex) ถูกเปลี่ยนเส้นทางไปที่ www.domain.tld/$1 และ
• autodiscover.~ ควรจะแก้ไขเป็น autodiscover.outlook.com แต่ด้วยเหตุผลบางอย่างไม่ได้ส่ง xml (ด้วยเครื่องมือของ Microsoft แสดงให้ฉันเห็น:

ทดสอบพอร์ต TCP 443 บนโฮสต์ autodiscover.juramanto.nl เพื่อให้แน่ใจว่าสามารถฟังและเปิดได้

พอร์ตที่ระบุถูกบล็อก ไม่รับฟัง หรือไม่สร้างการตอบสนองที่คาดไว้

• หนึ่งในขั้นตอนถัดไปใน Autodiscovery-quest คือการค้นหาการเปลี่ยนเส้นทางที่ autodiscover.domain.tld และนั่นทำให้มันพบ https://autodiscover-s.outlook.com/Autodiscover/Autodiscover.xml

ข้อสันนิษฐานคือไคลเอนต์ที่มีปัญหาไม่สามารถไปได้ไกลถึงเพียงนี้และเลิกทำภารกิจ autodiscover เร็วเกินไป ฉันไม่แน่ใจว่าคำขอ GET ที่ autodiscover.domiain.tld:443 น่าจะส่งข้อผิดพลาดสำหรับ Exchange Online หรือไม่ แต่การเปลี่ยนเส้นทางทำงานตามที่ต้องการและทันทีที่พบเครื่องมือของ Microsoft https://autodiscover-s.outlook.com/Autodiscover/Autodiscover.xml ทุกอย่างเปลี่ยนเป็นสีเขียวจนกระทั่งเกิดข้อผิดพลาดในการตรวจสอบสิทธิ์พื้นฐานที่คาดไว้ เนื่องจากการบล็อกวิธีการตรวจสอบสิทธิ์แบบเดิมในการเข้าถึงแบบมีเงื่อนไข

คำถาม:

1. เหตุใดไคลเอ็นต์นี้จึงไม่สามารถเชื่อมต่อกับ Exchange / Office 365 ได้อย่างรวดเร็ว
2. เหตุใดไคลเอนต์นี้จึงขอการรับรองความถูกต้องขั้นพื้นฐาน
3. เหตุใดการค้นหาอัตโนมัติจึงใช้ไม่ได้กับโดเมนนี้
4. การค้นหาอัตโนมัติกำลังทำอะไรอยู่ทีละขั้นตอน
5. เราจะทำอย่างไรเพื่อลดขั้นตอนการค้นหาอัตโนมัติและช่วยเหลือไคลเอนต์เดิมที่มีปัญหา
6. ฉันจะทำอย่างไรเพื่อแก้ไขการค้นหาอัตโนมัติสำหรับ Exchange Online อย่างรวดเร็ว

เคล็ดลับ

• สร้างบัญชีทดสอบเพิ่มเติม
• ใช้ https://testconnectivity.microsoft.com/tests/Eas/input เป็นการตรวจสุขภาพ
• การทดสอบนี้ https://testconnectivity.microsoft.com/tests/O365Eas/input ฉลาดกว่าแต่ไม่ได้เลียนแบบพฤติกรรมของลูกค้าที่มีปัญหา

สารละลาย

ฉันใช้ Cloudflare DNS เพิ่มกฎการส่งต่อเพื่อส่งต่อทรัพยากรที่ไม่มีอยู่นี้โดยเฉพาะ:

https://apexdomain.tld/autodiscover/autodiscover.xml

ถึง

https://autodiscover-s.outlook.com/Autodiscover/Autodiscover.xml

ซึ่งจะทำให้ห่วงโซ่การค้นหาอัตโนมัติสั้นลงอย่างมาก (ยืนยันโดยเครื่องมือของ Microsoft) ดังนั้นจึงจำกัดจำนวนสิ่งที่ผิดพลาดได้

ไคลเอนต์ที่มีปัญหาจะแสดงหน้าต่างการรับรองความถูกต้องที่ทันสมัยอย่างรวดเร็วตามที่ต้องการ

หมายเหตุ

• ฉันปิดการใช้งาน Cloud worker ที่ส่ง 404 สำหรับ https://apexdomain.tld/autodiscover/autodiscover.xmlแม้ว่าฉันจะปล่อยให้มันทำงาน https://www.domain.tld/autodiscover/autodiscover.xml แม้ว่าฉันจะไม่เห็นโซ่ไปถึงที่นั่นอีกต่อไป เหตุผลเดียวที่ URI นี้ถูกเยี่ยมชมเป็นเพราะส่วนท้ายของ www กฎการส่งต่อ ดังนั้นฉันเพิ่งรู้ว่ามันสามารถลบเส้นทางนี้ได้เช่นกัน ;) แต่สำหรับบันทึกกรณีทดสอบ มันถูกเปิดใช้งานในระหว่างการทดสอบ
• ฉันไม่รู้ว่ากฎของ Cloudflare มีความสำคัญเหนือเส้นทาง Cloudflare Worker หรือไม่ คุณควรกำหนดค่า xOR อยู่ดี

ฉันพบความซับซ้อนของการค้นหาอัตโนมัติที่ยุ่งยาก อาจผิดพลาดได้มากมาย แดกดันกลไกการค้นหาอัตโนมัตินั้นซับซ้อนมาก เราสามารถสร้างการกำหนดค่าการค้นหาอัตโนมัติของ autodiscovery เพื่อโหลดตำแหน่งโดยอัตโนมัติ เริ่ม การค้นหาอัตโนมัติสำหรับโดเมนใดโดเมนหนึ่ง :/

• ก่อนโพสต์ ฉันพบข้อมูลอ้างอิงในช่องค้นหาอัตโนมัติถึง โพสต์ต่อไปนี้. ผู้โพสต์โฆษณาพบปัญหาที่คล้ายกัน รวมถึงข้อผิดพลาดของพอร์ต 443 และวิธีแก้ปัญหาที่คล้ายกัน เพียงตำแหน่งอื่น (reverse proxy)

มันทำให้ฉันงุนงงที่โพสต์ไม่ปรากฏในผลลัพธ์ของ Google แต่ฉันดีใจที่เห็นการสังเกตและวิธีแก้ปัญหาของเราทับซ้อนกัน ^^

แหล่งที่มา

https://practical365.com/fixing-autodiscover-root-domain-lookup-issues-mobile-devices/

https://www.datarepairtools.com/blog/autodiscover-not-working- while-connecting-to-office-365-account/

การอ่านที่เกี่ยวข้อง:

https://docs.microsoft.com/en-us/exchange/architecture/client-access/autodiscover?view=exchserver-2019#autodiscover-services-in-outlook