การกำหนดค่าตัวเลือก Force TLS ในสภาพแวดล้อม Exchange on-Premises | ส่วนที่ 4#12

ในบทความปัจจุบัน เราจะตรวจสอบหัวข้อ Force TLS ในสภาพแวดล้อมที่ใช้ Exchange on-Premises

ในสภาพแวดล้อมที่ใช้ Exchange on-Premises เราสามารถเลือกใช้ตัวเลือก บังคับ TLS โดยใช้สอง ตัวเลือก.

1. การรักษาความปลอดภัยของโดเมน

ตัวเลือกนี้กำหนดชุดของตัวเชื่อมต่อเมลและการตั้งค่าการกำหนดค่าที่ใช้สำหรับการสร้างความหมายช่องทางการสื่อสารที่ปลอดภัย การเข้ารหัสข้อมูล และการรับรองความถูกต้องร่วมกัน ในสถานการณ์ที่ทั้งสองฝ่ายใช้โครงสร้างพื้นฐานเมล Exchange on-Premises

กล่าวอีกนัยหนึ่ง เราไม่สามารถใช้ตัวเลือก ความปลอดภัยของโดเมน ในกรณีที่โครงสร้างพื้นฐานเมล "ด้านอื่น ๆ " ไม่ได้ขึ้นอยู่กับสถาปัตยกรรมเซิร์ฟเวอร์ Exchange

ตัวเลือกของการรักษาความปลอดภัยของโดเมน (TLS รวม) ถูกนำมาใช้โดยการเปิดใช้งานตัวเลือกชื่อ - DomainSecureEnabled

<แข็งแกร่ง>2. TlsAuthLevel

เพื่อให้สามารถกำหนดค่าตัวเลือก บังคับ TLS ด้วยโครงสร้างพื้นฐานเมลที่ไม่ใช่ Exchange on-Premises เราจะต้องกำหนดค่าพารามิเตอร์เฉพาะชื่อ -TlsAuthLevel

การใช้ตัวเลือกของ TlsAuthLevel ช่วยให้เราสามารถกำหนดความจำเป็นที่จำเป็นในการใช้ TLS และยังรวมตัวเลือกสำหรับการระบุวิธีการที่แน่นอนที่เราต้องการใช้เพื่อระบุ “บุคคลอื่น” ที่เกี่ยวข้องกับการรับส่งอีเมล

การแลกเปลี่ยนภายในองค์กรกับการแลกเปลี่ยนออนไลน์

เกี่ยวกับเรื่องของ Force TLS มีความแตกต่างที่สำคัญสองสามข้อระหว่าง Exchange ภายในองค์กร สภาพแวดล้อมและสภาพแวดล้อมที่ใช้ Exchange Online

1. Exchange Online ไม่รองรับตัวเลือก Domain Security ในอนาคต

แม้ว่าสถาปัตยกรรม Exchange Online ที่ใช้สถาปัตยกรรม Exchange 2013 โครงสร้างพื้นฐานจดหมาย Exchange Online จะแตกต่างจากสถาปัตยกรรม Exchange on-Premises

ในกรณีที่เราจำเป็นต้องใช้สถานการณ์ บังคับ TLS ระหว่างโครงสร้างพื้นฐานอีเมล Exchange on-Premises และโครงสร้างพื้นฐานอีเมล Exchange Online เราจะต้องใช้ “ตัวเลือกอื่น” ชื่อ - TlsAuthLevel

<แข็งแกร่ง>2. อินเทอร์เฟซการจัดการ

ในสภาพแวดล้อมที่ใช้ Exchange ภายในองค์กร วิธีเดียวในการกำหนดค่าตัวเลือก บังคับ TLS โดยใช้พารามิเตอร์ TlsAuthLevel คือการใช้อินเทอร์เฟซคำสั่ง PowerShell

ในสภาพแวดล้อมที่ใช้ Exchange Online กระบวนการกำหนดค่า Force TLS จะถูกนำไปใช้โดยใช้อินเทอร์เฟซกราฟิกผู้ดูแลเว็บ Exchange Online

การตั้งค่า Force TLS ถูกนำมาใช้โดยใช้ตัวช่วยสร้างกราฟิก ซึ่งเราใช้ในการกำหนดค่าพารามิเตอร์ที่จำเป็นทั้งหมดที่เราต้องการสำหรับ Force TLS

Exchange Online มีตัวเลือกในการตั้งค่าที่จำเป็นทั้งหมดสำหรับ Force TLS โดยใช้อินเทอร์เฟซคำสั่ง PowerShell แต่โดยส่วนใหญ่เราจะใช้อินเทอร์เฟซกราฟิกผู้ดูแลระบบเว็บ Exchange Online

การกำหนดการตั้งค่า TLS ในสภาพแวดล้อม Exchange on-Premises และสภาพแวดล้อมเมลผสม | ความท้าทาย

ก่อนที่เราจะเริ่มต้นด้วยคำอธิบายของ บังคับ TLS กำหนดค่าในสภาพแวดล้อมที่ใช้ Exchange on-Premises สิ่งสำคัญคือ ว่าเราจะตระหนักถึง “อุปสรรค” สองสามประการที่อาจนำไปสู่ความสับสนและงุนงงได้ง่าย

• ความแตกต่างระหว่างอินเทอร์เฟซ Exchange GUI และ Exchange PowerShell - อินเทอร์เฟซ Exchange Graphic ไม่มีตัวเลือกทั้งหมดที่มีอยู่เมื่อใช้ Exchange PowerShell ตัวเลือกบางอย่างที่เกี่ยวข้องกับการตั้งค่า TLS มีอยู่เมื่อใช้ PowerShell เท่านั้น
• ความแตกต่างระหว่างเวอร์ชัน Exchange, อินเทอร์เฟซ GUI - ในบทความของเรา เราจะแสดงตัวอย่างการกำหนดค่า TLS โดยใช้อินเทอร์เฟซของเซิร์ฟเวอร์ Exchange 2010 ภายในองค์กร ตรรกะที่นำไปใช้ใน Exchange 2013 ภายในองค์กรจะคล้ายกัน แต่มีความแตกต่างบางประการระหว่างอินเทอร์เฟซกราฟิกของเวอร์ชัน Exchange สองเวอร์ชัน
• ความแตกต่างระหว่าง Exchange on-Premises และ Exchange Online - หากพูดถึงด้านเทคนิค Exchange Online ใช้สถาปัตยกรรมและแนวคิดที่คล้ายกันมากเมื่อเปรียบเทียบกับเซิร์ฟเวอร์ Exchange 2013 เกี่ยวกับเรื่องของตัวเชื่อมต่อจดหมายและการตั้งค่า TLS ตัวเลือกการจัดการ Exchange Online และการตั้งค่าการกำหนดค่าที่เกี่ยวข้องกับตัวเชื่อมต่อจดหมาย Exchange และการตั้งค่า TLS นั้นแตกต่างอย่างมากจากอินเทอร์เฟซและตัวเลือก "Exchange on-Premises"
• การตั้งค่าที่จำเป็นซึ่งจำเป็นต้องนำไปใช้กับ ส่ง + รับตัวเชื่อมต่อ และพารามิเตอร์ที่แตกต่างกันระหว่าง ส่ง + รับตัวเชื่อมต่อ
  ในทางเทคนิค ในทางกลับกัน การกำหนดค่าของ TLS ไม่มีข้อกำหนดบังคับในการกำหนดค่าบนบูธของตัวเชื่อมต่อ Exchange ซึ่งหมายถึง - Exchange ส่ง + รับตัวเชื่อมต่อ
  อย่างไรก็ตาม หลายครั้งที่ธุรกิจ ข้อกำหนดในการใช้ Force TLS จะกำหนดความจำเป็นในการกำหนดค่า TLS บนบูธของตัวเชื่อมต่อ “ความต้องการ ” นี้ก่อให้เกิดปัญหาอื่นเนื่องจากตัวเลือกและอินเทอร์เฟซของตัวเชื่อมต่อการส่ง Exchange ภายในองค์กรเทียบกับตัวเชื่อมต่อการรับ Exchange ภายในองค์กรไม่เหมือนกัน

การกำหนดค่าตัวเลือกการบังคับ TLS ในสภาพแวดล้อม Exchange on-Premises

ในบทความปัจจุบัน เราจะทบทวนวิธีกำหนดค่าตัวเลือก “บังคับ TLS ” ใน Exchange 2010 ในสถานที่

ขอแจ้งเตือนสั้นๆ โดยค่าเริ่มต้นแล้ว เซิร์ฟเวอร์ Exchange ได้รับการกำหนดค่าให้ใช้ตัวเลือก TLS ที่ฉวยโอกาส

• แต่ละครั้งที่เซิร์ฟเวอร์ Exchange พยายามเชื่อมต่อเซิร์ฟเวอร์จดหมายอื่น เขาจะพยายามสร้างช่องทางการสื่อสารโดยใช้ TLS
• แต่ละครั้งที่เซิร์ฟเวอร์จดหมายภายนอกพยายามสื่อสารกับเซิร์ฟเวอร์ Exchange เซิร์ฟเวอร์ Exchange จะ "เสนอ" เพื่อสร้างช่องทางการสื่อสารโดยใช้ TLS

ตามค่าเริ่มต้น Office 365 จะส่งอีเมลโดยใช้การเข้ารหัส TLS โดยมีเงื่อนไขว่าเซิร์ฟเวอร์ปลายทางรองรับ TLS ด้วย หากองค์กรพันธมิตรของคุณสนับสนุน TLS คุณจะต้องสร้างตัวเชื่อมต่อเฉพาะในกรณีที่คุณต้องการบังคับใช้ข้อจำกัดด้านความปลอดภัยบางอย่าง เช่น คุณต้องการใช้ TLS อยู่เสมอ หรือคุณต้องการการตรวจสอบใบรับรองทุกครั้งที่ส่งจดหมายจากพันธมิตรของคุณไปยังองค์กรของคุณ

คำถามที่ปรากฏในใจเราอาจจะเป็น:

ถาม: หากมีการกำหนดค่า Exchange ให้ใช้ตัวเลือกของ TLS ที่ฉวยโอกาส และพยายามสร้างลิงก์การสื่อสารที่ปลอดภัยอยู่เสมอ เพราะเหตุใดหรือเมื่อใดฉันจึงควรใช้ตัวเลือก บังคับ TLS?

ก: คำตอบสำหรับคำถามนี้อาจเป็นได้

1. ธุรกิจต้องแน่ใจว่าเปิดใช้งานเฉพาะการสื่อสาร TLS เท่านั้น

ความต้องการด้านความปลอดภัยหรือข้อกำหนดด้านกฎระเบียบเฉพาะ ซึ่งกำหนดความจำเป็นในการตรวจสอบว่าช่องทางการสื่อสารระหว่างเซิร์ฟเวอร์ Exchange ของเราและเซิร์ฟเวอร์ปลายทางเป็นช่องทางการสื่อสารที่เข้ารหัสซึ่งใช้โปรโตคอล TLS

กล่าวอีกนัยหนึ่ง เรา ไม่เต็มใจที่จะรับโอกาส ที่ลิงก์การสื่อสารไปยังองค์กรใดองค์กรหนึ่งหรือเซิร์ฟเวอร์อีเมลเฉพาะจะนำไปใช้โดยใช้ โปรโตคอลที่ไม่ได้เข้ารหัส เช่น SMTP . มันเป็นสถานการณ์ขาวดำ ซึ่งมีเพียงเราเท่านั้นที่เราตกลงที่จะสร้างช่องทางการสื่อสารทางอีเมลคือ - โดยใช้โปรโตคอล TLS

2 ความจำเป็นในการระบุ “เมลเซิร์ฟเวอร์อื่น ”

นอกจากความจำเป็นที่จำเป็นในการสร้างช่องทางการสื่อสารเมลที่ปลอดภัยแล้ว เรายังต้องการกำหนดการตั้งค่าความปลอดภัยเพิ่มเติมที่เกี่ยวข้องกับเซสชัน TLS กับเซิร์ฟเวอร์เมลปลายทาง

ตัวอย่างเช่น เมลเซิร์ฟเวอร์แต่ละเครื่องจำเป็นต้องมีใบรับรองที่จะใช้ในการเข้ารหัสข้อมูลที่ไหลในช่องทางการสื่อสารและใช้สำหรับการตรวจสอบสิทธิ์ได้ โดยเมลเซิร์ฟเวอร์แต่ละเครื่องสามารถ “นำเสนอ” ใบรับรองของเขาเพื่อเป็นแนวทางในการพิสูจน์ตัวตนที่ถูกต้องตามกฎหมายของเขา .

ในบางสถานการณ์ นอกเหนือจากความจำเป็นในการเข้ารหัสช่องทางการสื่อสารโดยใช้ TLS แล้ว เรายังต้องพิสูจน์ตัวตนของ "เซิร์ฟเวอร์อีเมลอื่น" อย่างไม่ต้องสงสัยด้วยการระบุพารามิเตอร์เฉพาะที่ควรปรากฏบนใบรับรองเซิร์ฟเวอร์ของเขา

ตัวอย่างเช่น ตรวจสอบว่าเซิร์ฟเวอร์อีเมลปลายทางใช้ใบรับรองสาธารณะ และตรวจสอบว่าชื่อโฮสต์ปรากฏในใบรับรองสาธารณะ

เพื่อให้สามารถตอบสนองข้อกำหนดเหล่านี้ได้ เราจะต้องใช้ตัวเลือก บังคับ TLS

1. การกำหนดค่าตัวเลือกของการรักษาความปลอดภัยของโดเมน (Mutual TLS) ในสภาพแวดล้อม Exchange on-Premises

ตามที่กล่าวไว้แล้ว ในสภาพแวดล้อมแบบ Exchange การกำหนดค่า Force TLS มีสองรูปแบบ การใช้ตัวเชื่อมต่อเมล

1. ความปลอดภัยของโดเมน (TLS รวม)
2. TlsAuthLevel

ในส่วนปัจจุบัน เราจะตรวจสอบคุณลักษณะ Exchange on-Premises โดยย่อ - Domain Security และใน ในส่วนถัดไป เราจะตรวจสอบตัวเลือกของ TlsAuthLevel
ตัวเลือกของ Domain Security คือ เกี่ยวข้องเฉพาะกับสถานการณ์ที่ “ทั้งสองฝ่าย” ใช้โครงสร้างพื้นฐานเมล Exchange on-Premises

ตัวเลือกของ Domain Security (Mutual TLS) สามารถใช้ได้ในเวอร์ชันเซิร์ฟเวอร์ Exchange 2010 และ 2013

การเปิดเผยที่เหมาะสมคือ ฉันจะได้รับข้อมูลที่ชัดเจนและให้ข้อมูลเกี่ยวกับพารามิเตอร์เฉพาะที่นำไปใช้เมื่อใช้ตัวเลือกของ ความปลอดภัยของโดเมน (TLS ร่วมกัน)

โซลูชันของ Domain Security (Mutual TLS) ได้รับการปรับใช้ในสถานการณ์ที่อธิบายว่าเป็น "ความสัมพันธ์ของคู่ค้า ". องค์กร Exchange สองแห่งที่ต้องการสร้างช่องทางการสื่อสารที่ปลอดภัยระหว่างกัน

การกำหนดค่าที่จำเป็นสำหรับ Domain Security (Mutual TLS) จำเป็นต้องนำไปใช้ในแต่ละ “ ฝ่าย” ที่เกี่ยวข้องกับความสัมพันธ์

เมื่อใช้ตัวเลือก Domain Security (Mutual TLS) ไคลเอ็นต์ Exchange เช่น Outlook ก็มีส่วนเกี่ยวข้องด้วย ในกระบวนการนี้ และพวกเขามีความสามารถในการ "เข้าใจ" เมื่อที่อยู่อีเมลถูกส่งจาก "องค์กรอื่น" ที่ใช้ Domain Security (Mutual TLS) กับ “องค์กรแลกเปลี่ยนของเรา”

ในแผนภาพต่อไปนี้ เราจะเห็นตัวอย่างของ Domain Security (Mutual TLS) ระหว่างสอง องค์กรที่มีการแลกเปลี่ยน

“ความไว้วางใจ ” ถูกสร้างขึ้นระหว่างองค์กร Exchange ชื่อ o365pilot.com และองค์กร Exchange (องค์กรอื่น) ที่แสดงด้วยชื่อโดเมนสาธารณะ - ขอขอบคุณสำหรับการแบ่งปัน .org

เราจะไม่ลงรายละเอียดเฉพาะของการกำหนดค่าที่จำเป็นสำหรับการใช้ตัวเลือก Domain Security ( TLS ร่วมกัน)

อย่างไรก็ตาม โดยทั่วไป เพื่อให้งานการกำหนดค่าตัวเลือกของ Domain Security (Mutual TLS) บรรลุผลสำเร็จ ในสภาพแวดล้อม Exchange on-Premises เราจะต้องสร้างตัวเชื่อมต่อเมลสองตัว:

ส่งตัวเชื่อมต่อ และ รับการเชื่อมต่อrที่จะใช้เพื่อรองรับการรับส่งอีเมลขาเข้าและขาออกกับ "พันธมิตร"

ระยะที่ 1#2 - การกำหนดค่าตัวเลือก เปิดใช้งานการรักษาความปลอดภัยของโดเมน |ส่ง + รับตัวเชื่อมต่อ

เมื่อเราสร้าง ส่งตัวเชื่อมต่อ ที่จำเป็น ในแท็บเครือข่าย เราจะต้องตรวจสอบตัวเลือก - เปิดใช้งานการรักษาความปลอดภัยของโดเมน (TLS การตรวจสอบสิทธิ์ร่วมกัน)

เมื่อเราสร้าง รับตัวเชื่อมต่อ ที่จำเป็น ในแท็บเครือข่าย เราจะต้องตรวจสอบตัวเลือก - เปิดใช้งานการรักษาความปลอดภัยของโดเมน (TLS การตรวจสอบสิทธิ์ร่วมกัน)

ระยะที่ 2#2 - ใช้คำสั่ง PowerShell Set-TransportConfig

เราจะต้องใช้คำสั่ง PowerShell สองคำสั่ง ซึ่งจะตั้งค่าพารามิเตอร์ที่จำเป็นใน ส่งตัวเชื่อมต่อ และ รับตัวเชื่อมต่อ

ในสถานการณ์ของเรา คำสั่ง PowerShell ที่เราจะใช้สำหรับการกำหนดค่า Domain Security (Mutual TLS) กับ “องค์กร Exchange อื่น ๆ ” ที่แสดงโดยชื่อโดเมน Thankyouforsharing.orgคือ:

Set-TransportConfig -TLSSendDomainSecureList thankyouforsharing.org

คำสั่ง PowerShell ถัดไปจะกำหนดค่า ตัวเชื่อมต่อรับ

Set-TransportConfig -TLSReceiveDomainSecureList o365info.com

แนบคำพูดบางส่วนจากบทความของ Microsoft เกี่ยวกับหัวข้อ - Domain Security (Mutual TLS):

การตรวจสอบสิทธิ์ Mutual TLS Mutual TLS แตกต่างจาก TLS เนื่องจากปกติจะมีการปรับใช้ TLS โดยทั่วไป เมื่อใช้งาน TLS จะมีการใช้เพื่อให้การรักษาความลับในรูปแบบของการเข้ารหัสเท่านั้น ไม่มีการตรวจสอบสิทธิ์เกิดขึ้นระหว่างผู้ส่งและผู้รับ
นอกจากนี้ บางครั้งเมื่อใช้งาน TLS จะมีการตรวจสอบสิทธิ์เฉพาะเซิร์ฟเวอร์ที่รับเท่านั้น การใช้งาน TLS นี้เป็นเรื่องปกติของการใช้งาน HTTP ของ TLS การใช้งานนี้
โดยที่เฉพาะเซิร์ฟเวอร์ที่รับการรับรองความถูกต้องเท่านั้นที่เป็น SSL
ด้วยการตรวจสอบสิทธิ์ TLS ร่วมกัน แต่ละเซิร์ฟเวอร์จะตรวจสอบข้อมูลประจำตัวของเซิร์ฟเวอร์อื่นโดยการตรวจสอบใบรับรองที่ได้รับจากเซิร์ฟเวอร์อื่นนั้น ในสถานการณ์สมมตินี้ เมื่อได้รับข้อความจากโดเมนภายนอกผ่านการเชื่อมต่อที่ตรวจสอบแล้วในสภาพแวดล้อม Exchange 2013 Microsoft Outlook จะแสดงไอคอน Domain Secured

ความปลอดภัยของโดเมน ความปลอดภัยของโดเมนคือชุดคุณลักษณะ เช่น การจัดการใบรับรอง ฟังก์ชันตัวเชื่อมต่อ และลักษณะการทำงานของไคลเอนต์ Outlook ที่ทำให้ TLS ร่วมกันเป็นเทคโนโลยีที่สามารถจัดการได้และมีประโยชน์ ไม่รองรับการรักษาความปลอดภัยของโดเมนเมื่อมีการกำหนดเส้นทางอีเมลขาออกผ่านเซิร์ฟเวอร์ Exchange 2013 Client Access

เปิดใช้งานโดเมนปลอดภัยแล้ว

พารามิเตอร์ DomainSecureEnabled เป็นส่วนหนึ่งของกระบวนการเปิดใช้งานการรับรองความถูกต้อง Transport Layer Security (TLS) ร่วมกันสำหรับโดเมนที่ให้บริการโดยตัวเชื่อมต่อการส่งนี้ การรับรองความถูกต้อง TLS รวมจะทำงานได้อย่างถูกต้องเมื่อตรงตามเงื่อนไขต่อไปนี้เท่านั้น:

ค่าของพารามิเตอร์ DomainSecureEnabled ต้องเป็น $true

ค่าของพารามิเตอร์ DNSRoutingEnabled ต้องเป็น $true

ค่าของพารามิเตอร์ IgnoreStartTLS ต้องเป็น $false

ไม่รองรับอักขระไวด์การ์ด (*) ในโดเมนที่กำหนดค่าสำหรับการตรวจสอบสิทธิ์ TLS ร่วมกัน ต้องกำหนดโดเมนเดียวกันบนตัวเชื่อมต่อรับที่สอดคล้องกันและในแอตทริบิวต์ TLSReceiveDomainSecureList ของการกำหนดค่าการขนส่ง

โดยการตรวจสอบใบรับรองที่ได้รับจากเซิร์ฟเวอร์อื่นนั้น ดังนั้นจึงไม่รวมไคลเอ็นต์เลย เราสร้างช่องทาง SMTP ที่ปลอดภัยระหว่างเซิร์ฟเวอร์ Exchange สองเครื่อง ซึ่งโดยปกติจะผ่านทางอินเทอร์เน็ต

โปรแกรมรับส่งเมล เช่น Outlook และ Outlook Web App จะทราบว่า Domain Security ได้รับการจัดตั้งขึ้น ไอคอนสีเขียวพร้อมเครื่องหมายถูกจะแสดงในแต่ละข้อความที่แลกเปลี่ยนระหว่างเซิร์ฟเวอร์ที่ใช้การรักษาความปลอดภัยของโดเมน

Domain Security หมายถึงชุดฟังก์ชันใน Microsoft Exchange Server 2010 และ Microsoft Office Outlook 2007 ที่ให้ทางเลือกที่มีต้นทุนต่ำแทน S/MIME หรือโซลูชันการรักษาความปลอดภัยระดับข้อความอื่นๆ วัตถุประสงค์ของชุดคุณลักษณะการรักษาความปลอดภัยของโดเมนคือ เพื่อให้ผู้ดูแลระบบมีวิธีจัดการเส้นทางข้อความที่ปลอดภัยผ่านอินเทอร์เน็ตร่วมกับพันธมิตรทางธุรกิจ หลังจากกำหนดค่าเส้นทางข้อความที่ปลอดภัยเหล่านี้แล้ว ข้อความที่เดินทางผ่านเส้นทางที่ปลอดภัยจากผู้ส่งที่ได้รับการรับรองความถูกต้องได้สำเร็จจะแสดงต่อผู้ใช้เป็น Domain Secured ในอินเทอร์เฟซ Outlook และ Microsoft Office Outlook Web App

Domain Security ใช้การตรวจสอบความถูกต้อง Transport Layer Security (TLS) ร่วมกันเพื่อให้การรับรองความถูกต้องและการเข้ารหัสตามเซสชัน การตรวจสอบสิทธิ์ TLS แบบรวมจะแตกต่างจาก TLS เนื่องจากมักจะมีการใช้งาน โดยทั่วไป เมื่อใช้งาน TLS ไคลเอนต์จะตรวจสอบว่าการเชื่อมต่อนั้นเชื่อมต่อกับเซิร์ฟเวอร์ที่ต้องการอย่างปลอดภัยโดยการตรวจสอบใบรับรองของเซิร์ฟเวอร์ ซึ่งได้รับมาโดยเป็นส่วนหนึ่งของการเจรจา TLS ในสถานการณ์สมมตินี้ ไคลเอ็นต์รับรองความถูกต้องของเซิร์ฟเวอร์ก่อนที่ไคลเอ็นต์จะส่งข้อมูล อย่างไรก็ตาม เซิร์ฟเวอร์ไม่รับรองความถูกต้องของเซสชันกับไคลเอนต์

ด้วยการตรวจสอบสิทธิ์ TLS ร่วมกัน แต่ละเซิร์ฟเวอร์จะตรวจสอบการเชื่อมต่อกับเซิร์ฟเวอร์อื่นโดยตรวจสอบใบรับรองที่ได้รับจากเซิร์ฟเวอร์อื่นนั้น ในสถานการณ์สมมตินี้ เมื่อได้รับข้อความจากโดเมนภายนอกผ่านการเชื่อมต่อที่ตรวจสอบแล้วในสภาพแวดล้อม Exchange 2010 Outlook 2007 จะแสดงไอคอน Domain Secured

2. การกำหนดค่าการบังคับใช้ TLS ใน Exchange โดยใช้ TlsAuthLevel

ในส่วนนี้ เราจะตรวจสอบการใช้งาน บังคับ TLS ในสภาพแวดล้อมที่ใช้ Exchange on-Premises โดยใช้ ตัวเลือกของ TlsAuthLevel

ตามที่กล่าวไว้ การใช้ “TlsAuthLevel” จะถูกนำไปใช้ในสถานการณ์ที่ “เซิร์ฟเวอร์เมลอื่น” ไม่ใช่เซิร์ฟเวอร์ที่ใช้ Exchange หรือไม่ใช่เซิร์ฟเวอร์ที่ใช้ Exchange ภายในองค์กร

ตัวอย่างเช่น ในกรณีที่เราจำเป็นต้องกำหนดค่าตัวเลือก บังคับ TLS ระหว่าง Exchange ของเราใน- เซิร์ฟเวอร์ในองค์กรและเซิร์ฟเวอร์ Exchange Online เราจะต้องใช้ตัวเลือกของ TlsAuthLevel เนื่องจากแม้ว่า Exchange Online จะใช้สถาปัตยกรรมเซิร์ฟเวอร์ Exchange แต่ Exchange Online ก็แตกต่างจากเซิร์ฟเวอร์ Exchange on-Premises

ส่วนปัจจุบันประกอบด้วยสองส่วน

1. การกำหนดค่าที่จำเป็นสำหรับการตั้งค่าตัวเลือก Force TLS สำหรับ Exchange on-Premises ส่งตัวเชื่อมต่อ
2. การกำหนดค่าที่จำเป็นสำหรับการตั้งค่าตัวเลือก Force TLS สำหรับ Exchange on-Premises Receive connector

1. ตัวเชื่อมต่อการส่ง Exchange ภายในองค์กร | การตั้งค่าตัวเลือกการบังคับ TLS

ในส่วนปัจจุบัน เราจะเน้นไปที่การตั้งค่าที่จำเป็นของ บังคับ TLS ในสถานการณ์ที่ "อีกด้านหนึ่ง" ไม่ใช่เซิร์ฟเวอร์ Exchange on-Premises ที่จำเป็น

ในสถานการณ์นี้ เราจะต้องใช้คำสั่ง PowerShell ที่จะช่วยให้เราตั้งค่าที่จำเป็นสำหรับพารามิเตอร์ - TlsAuthLevel

เมื่อเราเปิดพารามิเตอร์ TlsAuthLevel เราจะ "เปิด" ตัวเลือกของ บังคับ TLS

“การเปิดใช้งาน” ของพารามิเตอร์ TlsAuthLevel เป็นไปตามหนึ่งในสามตัวเลือกที่เป็นไปได้ที่กำหนดค่าความสัมพันธ์กับ “เซิร์ฟเวอร์อีเมลอื่น”

เราสามารถเลือกจากสามตัวเลือกที่เป็นไปได้เป็นค่าสำหรับ TlsAuthLevel

ตัวเลือก 1 - การเข้ารหัสเท่านั้น

ตัวเลือกของ - EncryptionOnly เหมาะสำหรับสถานการณ์ที่เมลเซิร์ฟเวอร์ปลายทางใช้ใบรับรองที่ไม่สามารถใช้สำหรับ “ระบุ” เมลเซิร์ฟเวอร์ได้ ตัวอย่างเช่น ฉากที่เมลเซิร์ฟเวอร์เป้าหมายใช้ใบรับรองที่ลงนามด้วยตนเอง

ในสถานการณ์สมมตินี้ ใบรับรองของเมลเซิร์ฟเวอร์ปลายทางจะใช้สำหรับการเข้ารหัสข้อมูลที่ส่งผ่านช่องทางการสื่อสารเท่านั้น

กล่าวอีกนัยหนึ่ง เมื่อเรากำหนดค่าตัวเลือก EncryptionOnly ความหมายก็คือเราไม่จำเป็นต้องระบุเซิร์ฟเวอร์อีเมลในอีกด้านหนึ่งโดยการตรวจสอบใบรับรองเซิร์ฟเวอร์ของเขา จุดสนใจหลักอยู่ที่ความจำเป็นในการเข้ารหัสช่องทางการสื่อสารโดยใช้ TLS

ตัวเลือก 2 - การตรวจสอบใบรับรอง

ตัวเลือกของ - การตรวจสอบใบรับรอง เหมาะสำหรับสถานการณ์ที่เซิร์ฟเวอร์เมลต้นทาง (เซิร์ฟเวอร์ Exchange ในสถานการณ์ของเรา) จำเป็นต้องตรวจสอบข้อมูลประจำตัวของเซิร์ฟเวอร์เมลปลายทาง

เมลเซิร์ฟเวอร์ปลายทางสามารถพิสูจน์ตัวตนได้โดยการจัดเตรียมใบรับรองสาธารณะที่สร้างโดย Public CA (ผู้ออกใบรับรอง)

ตัวเลือก 3 - การตรวจสอบโดเมน

ตัวเลือกของ - DomainValidation ถือได้ว่าเป็นตัวเลือกที่เข้มงวดที่สุด

ในกรณีนี้ ข้อกำหนดบังคับจะรวมถึงส่วนต่อไปนี้:

• ความจำเป็นในการเข้ารหัสข้อมูลที่ส่งผ่านช่องทางการสื่อสาร
• ความจำเป็นในการระบุเซิร์ฟเวอร์ปลายทาง เซิร์ฟเวอร์อีเมลปลายทางจะต้องจัดเตรียมใบรับรองสาธารณะที่ถูกต้องซึ่งสร้างโดย CA
• ใบรับรองที่เซิร์ฟเวอร์ปลายทางให้จะต้องมีหนึ่งในตัวเลือกต่อไปนี้: FQDN หรือชื่อโดเมนที่กำหนดค่าโดยพารามิเตอร์เพิ่มเติม TlsDomain

เมื่อเราใช้ตัวเลือก DomainValidation เราจะต้องระบุมูลค่าเพิ่มเติมของ TlsDomain ด้วย

เมื่อใช้ตัวเลือกของ TlsDomain เราจะต้อง “เปิดใช้งาน” พารามิเตอร์เพิ่มเติมชื่อ RequireTls

ในแผนภาพต่อไปนี้ เราจะเห็นตัวเลือกและการรวมกันที่หลากหลายที่เกี่ยวข้องกับ Force TLS

เพื่อให้สามารถสาธิตไวยากรณ์คำสั่ง PowerShell ที่จำเป็นที่เราจำเป็นต้องใช้เมื่อต้องการกำหนดค่าตัวเลือกของ Force TLS ลองใช้สถานการณ์ต่อไปนี้:

เราต้องการใช้การกำหนดค่า บังคับ TLS กับพันธมิตรบริษัทของเราที่ใช้ชื่อโดเมนสาธารณะ - < แข็งแกร่ง>contoso.com

ในสถานการณ์ของเรา เราทุกคนได้สร้างส่งตัวเชื่อมต่อเฉพาะที่กำหนดเส้นทางข้อความอีเมลที่ส่งไป ผู้รับจากโดเมน contoso.com

ชื่อของตัวเชื่อมต่อการส่งคือ - Contoso

สถานการณ์ที่ 1 - การใช้ตัวเลือก Force TLS เพื่อวัตถุประสงค์ในการเข้ารหัสการรับส่งอีเมลเท่านั้น

ในสถานการณ์สมมตินี้ ไม่จำเป็นต้องระบุเซิร์ฟเวอร์จดหมายอื่น

ระดับ TlsAuthLevel จะถูกตั้งค่าโดยการกำหนดค่าพารามิเตอร์ EncryptionOnly

ไวยากรณ์คำสั่ง PowerShell คือ:

Set-SendConnector -Identity Contoso -TlsAuthLevel EncryptionOnly

สถานการณ์ที่ 2 - การเข้ารหัสการรับส่งเมล + คำขอใบรับรองเซิร์ฟเวอร์ที่ถูกต้องจากเซิร์ฟเวอร์เมลอื่น

ในสถานการณ์นี้ เราจำเป็นต้องระบุเซิร์ฟเวอร์อีเมลอื่น เมลเซิร์ฟเวอร์อื่นจะต้องจัดเตรียมใบรับรองเซิร์ฟเวอร์ที่ถูกต้อง

ระดับ TlsAuthLevel จะถูกตั้งค่าโดยการกำหนดค่าพารามิเตอร์ CertificateValidation

ไวยากรณ์คำสั่ง PowerShell คือ:

Set-SendConnector -Identity Contoso -TlsAuthLevel CertificateValidation

สถานการณ์ที่ 3 - การเข้ารหัสการรับส่งเมล + คำขอใบรับรองเซิร์ฟเวอร์ที่ถูกต้องจากเซิร์ฟเวอร์เมลอื่น + ตรวจสอบว่าใบรับรองเซิร์ฟเวอร์มีชื่อโฮสต์เฉพาะ

ในสถานการณ์นี้ เราต้องการใช้ตัวเลือก บังคับ TLS และนอกเหนือจากความจำเป็นในการเข้ารหัสสายการสื่อสาร เราต้องการระบุเซิร์ฟเวอร์จดหมาย Contoso ตรวจสอบว่าเขาใช้ใบรับรองสาธารณะที่เชื่อถือได้ และ นอกจากนี้ ตรวจสอบว่าใบรับรองเซิร์ฟเวอร์มีชื่อโดเมน - contoso.com

ระดับ TlsAuthLevel จะถูกตั้งค่าโดยการกำหนดค่าพารามิเตอร์ DomainValidation

เมื่อใช้ตัวเลือก - DomainValidation เราจะต้องตั้งค่าพารามิเตอร์เพิ่มเติมสองตัว

พารามิเตอร์ TlsDomain - พารามิเตอร์ TlsDomain ใช้สำหรับกำหนดชื่อโฮสต์เฉพาะหรือชื่อโดเมนที่ต้องรวมอยู่ในใบรับรองเซิร์ฟเวอร์ที่ “เซิร์ฟเวอร์อีเมลอื่น” นำเสนอเป็นหลักฐานยืนยันตัวตน
RequireTls $true

ไวยากรณ์คำสั่ง PowerShell คือ:

Set-SendConnector -Identity contoso3 -RequireTls $true -TlsAuthLevel DomainValidation -TlsDomain *.contoso.com

แนบใบเสนอราคาจากบทความ Microsoft TechNet:

TlsAuthLevel
พารามิเตอร์ TlsAuthLevel ระบุระดับการตรวจสอบสิทธิ์ TLS ที่ใช้สำหรับการเชื่อมต่อ TLS ขาออกที่สร้างโดยตัวเชื่อมต่อการส่งนี้ ค่าที่ถูกต้องคือ:
EncryptionOnly: TLS ใช้เพื่อเข้ารหัสช่องทางการสื่อสารเท่านั้น ไม่มีการดำเนินการตรวจสอบใบรับรอง
การตรวจสอบใบรับรอง: TLS ใช้เพื่อเข้ารหัสช่องสัญญาณและการตรวจสอบห่วงโซ่ใบรับรอง และดำเนินการตรวจสอบรายการการเพิกถอน
การตรวจสอบโดเมน: นอกเหนือจากการเข้ารหัสช่องสัญญาณและการตรวจสอบใบรับรองแล้ว ตัวเชื่อมต่อการส่งยังตรวจสอบด้วยว่า FQDN ของใบรับรองเป้าหมายตรงกับโดเมนที่ระบุในพารามิเตอร์ TlsDomain หากไม่มีการระบุโดเมนในพารามิเตอร์ TlsDomain ระบบจะเปรียบเทียบ FQDN บนใบรับรองกับโดเมนของผู้รับ
คุณไม่สามารถระบุค่าสำหรับพารามิเตอร์นี้ได้หากตั้งค่าพารามิเตอร์ IgnoreSTARTTLS เป็น $true หรือหากพารามิเตอร์ RequireTLS ถูกตั้งค่าไว้ ตั้งค่าเป็น $false

พารามิเตอร์ TlsDomain ระบุชื่อโดเมนที่ตัวเชื่อมต่อการส่งใช้เพื่อตรวจสอบ FQDN ของใบรับรองเป้าหมายเมื่อสร้างการเชื่อมต่อที่ปลอดภัยของ TLS
พารามิเตอร์นี้ใช้เฉพาะเมื่อพารามิเตอร์ TlsAuthLevel ตั้งค่าเป็น DomainValidation
ค่า สำหรับพารามิเตอร์นี้จำเป็นหาก:
พารามิเตอร์ TLSAuthLevel ตั้งค่าเป็น DomainValidation
พารามิเตอร์ DNSRoutingEnabled ถูกกำหนดเป็น $false (ตัวเชื่อมต่อการส่งโฮสต์อัจฉริยะ)

2. ตัวเชื่อมต่อการรับ Exchange ภายในองค์กร | การตั้งค่าตัวเลือกการบังคับ TLS

เกี่ยวกับการกำหนดค่าที่จำเป็นซึ่งจำเป็นสำหรับการใช้งานตัวเลือก บังคับ TLS บน ตัวเชื่อมต่อรับ ในสถานที่ของ Exchange เราจะต้องใช้พารามิเตอร์ 2 ตัวร่วมกัน:

1. กลไกการตรวจสอบสิทธิ์
2. RequireTLS - ค่านี้ “เปิดใช้งาน ” ตัวเลือกของ บังคับ TLS

ในภาพหน้าจอต่อไปนี้ เราจะดูตัวอย่างพารามิเตอร์เริ่มต้นของตัวเชื่อมต่อการรับ Exchange on-Premises

เราจะเห็นว่าพารามิเตอร์ - AuthMechanism มีตัวเลือกสองสามตัว รวมถึง TLS
นอกจากนี้ เราจะเห็นว่าค่าเริ่มต้นของพารามิเตอร์ RequireTLS ถูกตั้งค่าเป็น False>

ในสถานการณ์ของเรา เราต้องการใช้ตัวเลือก บังคับ TLS เกี่ยวกับอีเมลที่ส่งถึงเราโดยพันธมิตรซึ่งมีชื่อโดเมนเป็นตัวแทน - Thankyouforsharing.org

เราได้สร้างตัวเชื่อมต่อการรับบนเซิร์ฟเวอร์ Exchange on-Premises ชื่อ - EX01 และชื่อตัวเชื่อมต่อคือ - Thankyouforsharing.org

หากต้องการกำหนดค่า ตัวเชื่อมต่อการรับ ของ Exchange on-Premises ให้ใช้ Force TLS เราจะต้องตั้งค่าของพารามิเตอร์ RequireTLS ให้เป็นจริง

คำสั่ง PowerShell ที่เราจะใช้ในสถานการณ์ของเราคือ:

Set-ReceiveConnector EX01\<strong><em>thankyouforsharing-receive</em></strong> -RequireTLS $true

แนบคำพูดบางส่วนจากบทความของ Microsoft:

พารามิเตอร์ AuthMechanism ระบุกลไกการตรวจสอบสิทธิ์ที่โฆษณาและยอมรับ ตัวเลือกการตรวจสอบสิทธิ์ได้แก่ ไม่มี, Tls, รวม, BasicAuth, BasicAuthRequireTLS, ExchangeServer และ ExternalAuthoritative คุณสามารถป้อนค่าหลายค่าสำหรับพารามิเตอร์ AuthMechanism ได้โดยคั่นค่าด้วยเครื่องหมายจุลภาค
หากพารามิเตอร์ RequireTLS ถูกตั้งค่าเป็น $true พารามิเตอร์ AuthMechanism จะต้องตั้งค่าเป็น TLS (Transport Layer Security) หากคุณตั้งค่าพารามิเตอร์ AuthMechanism เป็น BasicAuthRequireTLS คุณต้องเลือก BasicAuth และ TLS ด้วย
ค่าพารามิเตอร์ AuthMechanism ExternalAuthoritative อาจอยู่ร่วมกับค่า Tls เท่านั้น หากคุณตั้งค่าพารามิเตอร์ AuthMechanism เป็น ExternalAuthoritative พารามิเตอร์ PermissionGroups จะต้องมีค่า

บทความถัดไป

บทความถัดไป (บังคับ TLS | สภาพแวดล้อม Exchange Online กับสภาพแวดล้อม Exchange on-Premises | ตอนที่ 5#12) ในชุดบทความ TLS มีไว้เพื่อหัวข้อของ - ความแตกต่างที่มีอยู่ระหว่างสภาพแวดล้อมที่ใช้ Exchange on-Premises กับ สภาพแวดล้อมที่ใช้ Exchange Online ที่เกี่ยวข้องกับตัวเชื่อมต่อเมลและการตั้งค่า TLS และคำอธิบายของอักขระสถานการณ์ที่เราจะใช้ในบทความถัดไปในชุดบทความ TLS ซึ่งจะช่วยให้เราสาธิตขั้นตอน TLS ที่เป็นตัวเลือกระหว่างสภาพแวดล้อมที่ใช้ Exchange on-Premises และ Exchange Online .