อักขระพิเศษของการซิงโครไนซ์ไดเรกทอรีในสภาพแวดล้อม Office 365 | บทความ 1#2 | ตอนที่ 11#23

ในบทความปัจจุบันและบทความถัดไป เราจะตรวจสอบตัวละครหลักของกระบวนการซิงโครไนซ์ไดเรกทอรีในสภาพแวดล้อมที่ใช้ Office 365 เหตุผลที่ฉันเพิ่มบทความเฉพาะสองบทความหรือหัวข้อนี้เป็นเพราะความรู้เกี่ยวกับ "สิ่งที่เกิดขึ้นเบื้องหลัง ฉาก ” ของการซิงโครไนซ์ไดเรกทอรีมีความสำคัญอย่างยิ่งต่อ:

1. ความเข้าใจของเราเกี่ยวกับ "ตรรกะ" ของกระบวนการคืนค่ากล่องจดหมาย Exchange Online ที่เราจำเป็นต้องปฏิบัติตามในสภาพแวดล้อมการซิงโครไนซ์ไดเรกทอรี
2. ความสามารถของเราในการจัดการกับสถานการณ์สมมติได้สำเร็จ ซึ่งกระบวนการคืนค่ากล่องจดหมาย Exchange Online ถูกนำมาใช้ในลักษณะที่ไม่เหมาะสม และในสถานการณ์นี้ เราจะต้องทราบวิธีการแก้ไขข้อผิดพลาดของกล่องจดหมายคืนค่ากล่องจดหมาย

เหตุใดเราจึงต้องรู้เบื้องหลังสภาพแวดล้อมการซิงโครไนซ์ไดเรกทอรีใน Office 365

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

สภาพแวดล้อมการซิงโครไนซ์ไดเรกทอรีสามารถพิจารณาได้ว่าเป็นสภาพแวดล้อมที่ซับซ้อน ซึ่งกำหนดตรรกะ "การเชื่อมโยง" ของโครงสร้างพื้นฐาน Active Directory สองรายการ และโดยส่วนใหญ่แล้วจะเป็นโครงสร้างพื้นฐาน Exchange สองรายการที่แยกจากกัน (Exchange on-Premises + Exchange Online ในสภาพแวดล้อม Exchange Hybrid)

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

เพื่อให้เข้าใจ "ภาพรวม" เราจำเป็นต้องทำความคุ้นเคยกับ "เลเยอร์" ต่างๆ ของ Office 365 ในสภาพแวดล้อมการซิงโครไนซ์ไดเรกทอรี

เลเยอร์ 1 - ทำความเข้าใจตรรกะและแนวคิดของการใช้การซิงโครไนซ์ไดเรกทอรีและ Office 365

ในเลเยอร์นี้ เราจะต้องมีวิธีการซิงโครไนซ์ไดเรกทอรี “เชื่อมโยง” Active Directory ภายในองค์กรกับไดเรกทอรี Office 365 - Azure Active Directory

กระบวนการซิงโครไนซ์ไดเร็กทอรี "เชื่อมโยง" ไดเร็กทอรีที่แตกต่างกันสองรายการโดยใช้แนวคิดที่อธิบายว่าเป็น ImmutableID, Soft Match และ Hard match

เลเยอร์ 2 - ทำความเข้าใจตรรกะและแนวคิดของความสัมพันธ์ที่มีอยู่ระหว่างผู้ใช้ Active Directory และบัญชีผู้ใช้ Office 365 “แบบจำลอง”

ในเลเยอร์นี้ เราจำเป็นต้องเข้าใจแนวคิด เช่น “แหล่งที่มาของสิทธิ์” ที่อธิบายแบบจำลองที่ Active Directory ภายในองค์กรเป็น “แหล่งที่มา” ที่สร้างและจัดการออบเจ็กต์

ไดเรกทอรี Office 365 ทำหน้าที่เป็น "แบบจำลอง" ที่มีสำเนาของออบเจ็กต์ Active Directory ภายในองค์กร เช่น บัญชีผู้ใช้ บัญชีกลุ่ม ฯลฯ

กล่าวอีกนัยหนึ่ง On-Premise Active Directory มีสิทธิ์อ่านและเขียนออบเจ็กต์ Directory และ Office 365 Directory (Azure Active Directory) มีสิทธิ์อ่านเฉพาะออบเจ็กต์ที่จำลองมาจาก Azure Active Directory เท่านั้น

เลเยอร์ 3 - ทำความเข้าใจ “ตรรกะการไหล” ของการสร้างผู้ใช้ Active Directory ใหม่และการลบผู้ใช้ Active Directory ในการซิงโครไนซ์ไดเรกทอรี

เนื่องจาก Office 365 Directory (Azure Active Directory) ถือเป็น “รอง” ของ On-Premise Active Directory แต่ละเหตุการณ์ เช่น การสร้างบัญชีผู้ใช้ Active Directory ใหม่ หรือการลบบัญชีผู้ใช้ On-Premise Active Directory ทำให้เกิด “Ripple” ที่ส่งผลกระทบต่อ ไดเรกทอรี Office 365

เลเยอร์ 4 - ทำความเข้าใจตรรกะของความจำเป็นที่จำเป็นในการกู้คืนบัญชีผู้ใช้ Active Directory ภายในองค์กร ในกรณีที่เราจำเป็นต้องกู้คืนกล่องจดหมาย Exchange Online ที่ถูกลบ

ในสถานการณ์ที่เราจำเป็นต้องกู้คืนกล่องจดหมาย Exchange Online ในสภาพแวดล้อมการซิงโครไนซ์ไดเรกทอรี โดยส่วนใหญ่ สาเหตุของ "การลบกล่องจดหมาย Exchange Online" คือ การลบบัญชีผู้ใช้ Active Directory ในสถานที่

“วิธีที่ถูกต้อง” ในการกู้คืนกล่องจดหมาย Exchange Online คือโดยการกู้คืนบัญชีผู้ใช้ Active Directory ในสถานที่ที่ถูกลบ

เลเยอร์ 5 - ทำความเข้าใจแหล่งที่มาของข้อผิดพลาดในการกู้คืนกล่องจดหมาย Exchange Online

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

เลเยอร์ 6 - ทำความเข้าใจวิธีการที่เราสามารถใช้เพื่อจัดการและซ่อมแซมข้อผิดพลาดในการกู้คืนกล่องจดหมาย Exchange Online

การรู้ว่าอะไรคือสาเหตุของข้อผิดพลาดในการกู้คืนกล่องจดหมายนั้นไม่เพียงพอ

ในเลเยอร์นี้ เราจะต้องคุ้นเคยกับวิธีการและตัวเลือกต่างๆ ที่เราสามารถใช้เพื่อแก้ไขการคืนค่ากล่องจดหมายที่ไม่ถูกต้อง

ความสัมพันธ์ระหว่างผู้ใช้ Active Directory ภายในองค์กรและ “แบบจำลองผู้ใช้” ของ Office 365

ความหมายง่ายๆ ของสภาพแวดล้อมการซิงโครไนซ์ไดเรกทอรีคือสภาพแวดล้อมที่มีมากกว่าหนึ่งไดเรกทอรี

โครงสร้างพื้นฐานการซิงโครไนซ์ไดเร็กทอรีเกี่ยวข้องกับความสัมพันธ์ระหว่าง "ไดเร็กทอรี" และวัตถุประสงค์ทั่วไปตามชื่อคือ - การใช้กลไกการซิงโครไนซ์ซึ่งจะสัมพันธ์กันระหว่างไดเร็กทอรีที่แตกต่างกันสอง (หรือมากกว่า)

ตัวอย่างเช่น เมื่อมี “บางสิ่ง” เกิดขึ้นในไดเรกทอรี A ให้ซิงโครไนซ์ข้อมูลกับไดเรกทอรี B

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

1. รูปแบบการซิงโครไนซ์ที่เท่ากันหรือสองทาง

ในกรณีที่วัตถุ NEW สร้างขึ้นใน Directory A ข้อมูลจะถูกซิงโครไนซ์กับ Directory B ดังนั้นวัตถุ NEW ก็จะสร้างใน Directory B ด้วย

ตรรกะเดียวกันนี้ถูกนำไปใช้ในทิศทางตรงกันข้าม - เมื่อวัตถุ NEW สร้างขึ้นใน Directory, B และข้อมูลจะซิงโครไนซ์กับ Directory A ดังนั้นวัตถุ NEW ก็จะสร้างขึ้นใน Directory A ด้วย

2. “ไม่เท่ากัน” หรือรูปแบบการซิงโครไนซ์ทางเดียว

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

ตัวอย่างเช่น ในกรณีที่วัตถุ NEW สร้างขึ้นใน Directory A ข้อมูลจะถูกซิงโครไนซ์กับ Directory B ดังนั้นวัตถุ NEW ก็จะถูกสร้างขึ้นใน Directory B ด้วย

แนวคิดเดียวกัน ไม่ได้นำไปใช้ ในทิศทางตรงกันข้าม เนื่องจากในกรณีนี้ Directory B ทำหน้าที่เป็น "แบบจำลอง" ของ Directory A

การอัปเดต เช่น การเพิ่มบัญชีผู้ใช้ใหม่ในไดเรกทอรี B จะไม่ทำซ้ำ (ซิงโครไนซ์) ไปยังไดเรกทอรี A

ในโมเดลประเภทนี้ โดยส่วนใหญ่แล้ว เราไม่ควรสร้างการอัปเดตใดๆ ในไดเรกทอรี B แต่ให้สร้างการอัปเดตที่จำเป็นทั้งหมดในไดเรกทอรี A แทน และข้อมูลเกี่ยวกับการอัปเดตจะซิงโครไนซ์กับไดเรกทอรี B .

โครงสร้างพื้นฐานการซิงโครไนซ์ไดเรกทอรีในสภาพแวดล้อมที่ใช้ Office 365

โมเดลการซิงโครไนซ์ไดเรกทอรีที่ใช้งานในสภาพแวดล้อมที่ใช้ Office 365 คือโมเดลที่อธิบายว่าเป็น “ไม่เท่ากัน” หรือโมเดลการซิงโครไนซ์ทางเดียว”

การซิงโครไนซ์ไดเรกทอรีใน Office 365 ดำเนินการในลักษณะต่อไปนี้ Active Directory ภายในองค์กรถือเป็น "แหล่งที่มาของไดเรกทอรีผู้มีอำนาจ"

การจัดการออบเจ็กต์ เช่น การสร้างบัญชีผู้ใช้ใหม่หรือการอัปเดตข้อมูลเกี่ยวกับบัญชีผู้ใช้ที่มีอยู่ ควรสร้างใน Active Directory ภายในองค์กรเท่านั้น

เซิร์ฟเวอร์การซิงโครไนซ์ไดเรกทอรี (Azure AD Connect) เป็นส่วนประกอบซอฟต์แวร์ที่ถือว่ารับผิดชอบในการ "ดึงข้อมูล" ข้อมูลจาก Active Directory ภายในองค์กร และซิงโครไนซ์ข้อมูลกับไดเรกทอรี Office 365 ซึ่งหมายถึง - Azure Active Directory

เพื่อให้สามารถจัดการกับสถานการณ์สมมติของการกู้คืนกล่องจดหมาย Exchange Online ในสภาพแวดล้อมตามการซิงโครไนซ์ไดเรกทอรี หรือ "แก้ไข" กล่องจดหมาย Exchange Online กู้คืนข้อผิดพลาดในการคืนค่าในสภาพแวดล้อมการซิงโครไนซ์ไดเรกทอรี เราจะต้องคุ้นเคยกับหัวข้อต่อไปนี้:

1. วิธีที่วัตถุผู้ใช้ Active Directory ในสถานที่ถูก "ผูกมัด" กับวัตถุผู้ใช้ Office 365 ในสภาพแวดล้อมการซิงโครไนซ์ไดเรกทอรี
2. อะไรคือห่วงโซ่ของเหตุการณ์ที่ถูกทริกเกอร์เมื่อเราสร้างบัญชีผู้ใช้ Active Directory ภายในองค์กรใหม่
3. อะไรคือห่วงโซ่ของเหตุการณ์ที่ถูกทริกเกอร์เมื่อเราลบบัญชีผู้ใช้ Active Directory ภายในองค์กร

ส่วนประกอบในสภาพแวดล้อมการซิงโครไนซ์ไดเรกทอรี

ในแผนภาพต่อไปนี้ เราจะเห็นส่วนประกอบที่เกี่ยวข้องในสภาพแวดล้อมการซิงโครไนซ์ไดเรกทอรี

1. Active Directory ภายในองค์กร - นี่คือไดเร็กทอรีที่ผู้ใช้และออบเจ็กต์กลุ่มได้รับการบรรจุ + อัปเดต
2. เซิร์ฟเวอร์การซิงโครไนซ์ไดเรกทอรีเข้าถึง Active Directory ภายในองค์กรและ "ดึง" ข้อมูล (ผู้ใช้ กลุ่ม วัตถุผู้ติดต่อ ฯลฯ)

เซิร์ฟเวอร์การซิงโครไนซ์ไดเรกทอรี เข้าถึง Azure Active Directory และ "พุช" (ซิงโครไนซ์) ข้อมูล

3. Azure Active Directory สามารถอธิบายได้ว่าเป็น “บริการไดเรกทอรี Office 365”
   เมื่อผู้ดูแลระบบ Office 365 มอบหมายใบอนุญาต Exchange Online ให้กับ “ผู้ใช้ Office 365 ที่ซิงโครไนซ์แล้ว” ข้อมูลดังกล่าวจะถูกซิงโครไนซ์จาก Azure Active Directory ไปยังโครงสร้างพื้นฐาน Exchange Online .
4. โครงสร้างพื้นฐาน Exchange Online - กล่องจดหมาย Exchange Online ที่สร้างขึ้นและเชื่อมโยงกับบัญชีผู้ใช้ Office 365

การจัดการ "วัตถุไดเรกทอรี" ในสภาพแวดล้อมการซิงโครไนซ์ไดเรกทอรี

ในสภาพแวดล้อมที่ซิงโครไนซ์ไดเร็กทอรี งานการสร้าง "ออบเจ็กต์ใหม่" เช่น - บัญชีผู้ใช้และบัญชีกลุ่ม ควรสร้าง เฉพาะใน Active Directory ในสถานที่เท่านั้น เนื่องจากโมเดลการซิงโครไนซ์ตามแนวคิด ของ - “การซิงโครไนซ์ทางเดียว”

ข้อมูลจากสภาพแวดล้อมภายในองค์กรซิงโครไนซ์กับระบบคลาวด์ แต่ ไม่ใช่ในทางกลับกัน

ในภายหลัง เราจะเข้าใจดีขึ้นว่าอักขระเหล่านี้เกี่ยวข้องกับสถานการณ์อย่างไร เช่น การลบบัญชีผู้ใช้ Active Directory ภายในองค์กร และการลบนี้ส่งผลต่อโครงสร้างพื้นฐานของระบบคลาวด์อย่างไร

เพื่อความเรียบง่าย เรามายึดถือคำจำกัดความพื้นฐานที่กำหนดทิศทางการซิงโครไนซ์เป็น "การซิงโครไนซ์ทางเดียว"

การซิงโครไนซ์ไดเรกทอรีและแนวคิดของ "ImmutableID"

ตามที่กล่าวไว้ Azure Active Directory ทำหน้าที่เป็นแบบจำลองสำหรับวัตถุ Active Directory ในสถานที่และไดเรกทอรี Office 365 จำเป็นต้อง "รู้" เกี่ยวกับความสัมพันธ์ที่มีอยู่ระหว่างบัญชีผู้ใช้ Office 365 และ "ต้นแบบ" ซึ่งอยู่ที่ On - Active Directory ในสถานที่

วิธีการที่ใช้ในการเปิดใช้งาน Azure Active Directory เพื่อ "ทำความเข้าใจ" ว่าบัญชีผู้ใช้ Office 365 ใดบัญชีหนึ่งถูก "จำลองแบบ" (ซิงโครไนซ์) จาก On-Premise Active Directory อธิบายว่าเป็น - ImmutableID

จากมุมมองของ Azure Active Directory ความหมาย Office 365 ที่มี ImmutableID คือ ผู้ใช้ Office 365 รายนี้ "ผูกมัด" กับบัญชีผู้ใช้ Active Directory ภายในองค์กร

Azure Active Directory “เข้าใจ” ว่าเธอไม่ใช่เจ้าของออบเจ็กต์นี้ แต่เป็นเพียงเอนทิตีจำลองแบบ “โฮสต์” ที่แสดงถึงบัญชีผู้ใช้ Active Directory ภายในองค์กรแทน

“กลไกการเชื่อมโยง” ที่เชื่อมต่อผู้ใช้ Active Directory ภายในองค์กรกับบัญชีผู้ใช้ Office 365

ตามที่กล่าวไว้ ออบเจ็กต์ Active Directory เช่น “บัญชีผู้ใช้” จะถูกซิงโครไนซ์จาก Active Directory ภายในองค์กรไปยัง Azure Active Directory

ตัวอย่างเช่น บัญชีผู้ใช้ Active Directory ภายในองค์กรชื่อ John ซิงค์กับ “คลาวด์ ” (Azure Active Directory) และผู้ใช้ใหม่ชื่อ John ที่สร้างขึ้นใน Azure Active ไดเรกทอรี

ในทางเทคนิค ขณะนี้มี บัญชีผู้ใช้ที่แตกต่างกันสองบัญชี ซึ่งจัดเก็บไว้ในไดเรกทอรีที่แตกต่างกันสองแห่ง

ในสภาพแวดล้อมการซิงโครไนซ์ไดเรกทอรี เราจำเป็นต้องกำหนดโครงสร้างเชิงตรรกะ ซึ่งจำเป็นต้องเกี่ยวข้องกับบัญชี ผู้ใช้สองราย เป็น "หนึ่งเอนทิตี"

ในเชิงเปรียบเทียบ เราจำเป็นต้องใช้กลไกที่ "ติด" บัญชีผู้ใช้ Active Directory ภายในองค์กรเข้ากับบัญชีผู้ใช้ Office 365 Directory การอัปเดตบัญชีผู้ใช้แต่ละรายการใน On-Premise Active Directory ของคุณสมบัติผู้ใช้จะซิงโครไนซ์กับบัญชีผู้ใช้ไดเรกทอรี Office 365 ที่ "ตรงกัน" ได้สำเร็จ และ "ผู้ใช้ Office 365 ที่ตรงกัน" จะได้รับการอัปเดตตามลำดับ

วิธีการที่ใช้สำหรับ "การเชื่อมโยง" ออบเจ็กต์ Active Directory ภายในองค์กรกับออบเจ็กต์ Active Directory บนระบบคลาวด์ที่ใช้งานโดยใช้ค่าชื่อ - ImmutableID

คำว่า “ImmutableID ” ฟังดูแปลกและลึกลับ อย่างไรก็ตาม แนวคิดของ “ImmutableID ” นั้นค่อนข้างเรียบง่าย

ในกรณีที่ "บัญชีผู้ใช้ Office 365" ถูกสร้างขึ้นผ่านกระบวนการซิงโครไนซ์ไดเรกทอรี ค่า "ImmutableID" ของผู้ใช้ Office 365 จะถูกเติมข้อมูล

ค่าของ “ImmutableID ” จะถูกเติมด้วยค่า GUID ของบัญชีผู้ใช้ Active Directory ภายในองค์กร

ตอนนี้เรากำลังเผชิญกับคำศัพท์ใหม่ - GUID!

คำว่า GUID ย่อมาจาก - Global Unique Identifier
เราใช้ค่า GUID เป็นวิธีการ โดยระบุข้อมูลเฉพาะตัวที่ไม่ซ้ำกันสำหรับออบเจ็กต์ Active Directory แต่ละรายการ
เราอธิบายข้อมูลประจำตัวนี้เป็น “ ไม่ซ้ำกัน ” เนื่องจากไม่มีวัตถุ Active Directory อื่นใดที่สามารถมีค่า GUID ที่เหมือนกันได้

เราสามารถเปรียบเทียบวัตถุประสงค์ของค่า GUID กับ "วิธีการระบุตัวตน" อื่น ๆ เช่น "หมายเลขประกันสังคม" หรือที่อยู่ MAC ที่การ์ดเครือข่ายแต่ละอันมี

เราได้กล่าวไว้ว่าค่า GUID ของบัญชีผู้ใช้ Active Directory ภายในองค์กรจะถูกคัดลอกและบันทึกเป็นค่า ImmutableID ของบัญชีผู้ใช้ Office 365

ถ้าเราต้องการให้มีความแม่นยำมากขึ้น ในสภาพแวดล้อมที่ใช้ Office 365 ค่า GUID ของผู้ใช้ Active Directory ภายในองค์กรจะถูกแปลงเป็นค่า 64 บิต จากนั้นบันทึกเป็นค่า ImmutableID

ในทางเทคนิคแล้ว ถ้าเราพยายามเปรียบเทียบค่า GUID กับค่า ImmutableID ของบัญชีผู้ใช้ Office 365 เราจะเห็นค่าที่แตกต่างกันอย่างเห็นได้ชัด

ในไดอะแกรมต่อไปนี้ เราจะเห็นตัวอย่างความสัมพันธ์ที่มีอยู่ระหว่างบัญชีผู้ใช้ On-Premise Active Directory และออบเจ็กต์ผู้ใช้ระบบคลาวด์ที่ซิงโครไนซ์

ค่า GUID ของ “John ” ได้รับการซิงโครไนซ์โดยเป็นส่วนหนึ่งของแอตทริบิวต์ John's ไปยังไดเรกทอรี Office 365 (Azure Active Directory)
เมื่อ “John บัญชีผู้ใช้ระบบคลาวด์ ” ถูกสร้างขึ้น ค่า GUID จะถูกบันทึกไว้ในแอตทริบิวต์ ImmutableID

สังเกตว่าค่าดูแตกต่างออกไป!

สาเหตุของความแตกต่างคือเนื่องจากค่า GUID ดั้งเดิมอยู่ระหว่างกระบวนการแปลงเป็นรูปแบบ 64 บิต

การผูกข้อมูลระหว่างบัญชีผู้ใช้ Office 365 และกล่องจดหมาย Exchange Online

ในกรณีที่เรามอบหมายใบอนุญาต Exchange Online ให้กับ “บัญชีผู้ใช้ Office 365 ที่ซิงโครไนซ์” (เช่น John จากตัวอย่างก่อนหน้านี้) กล่องจดหมาย Exchange Online ใหม่จะถูกสร้างขึ้นและ “แนบ” กับผู้ใช้ Office 365 บัญชี.

บัญชีผู้ใช้ Office 365 ถือเป็น "เจ้าของ" ของกล่องจดหมาย Exchange Online

โครงสร้างพื้นฐานที่มีผลผูกพันที่สมบูรณ์

ตอนนี้ เราสามารถกำหนด “ขั้นตอนการผูกข้อมูล” ต่อไปนี้ได้เมื่อเราสร้างบัญชีผู้ใช้ Active Directory ภายในองค์กรใหม่และมอบหมายใบอนุญาต Exchange Online ให้กับบัญชีผู้ใช้ Office 365 ใหม่ Office 365 ที่สร้างขึ้น:

• บัญชีผู้ใช้ Office 365 นั้น "แนบมา" กับบัญชีผู้ใช้ Active Directory ภายในองค์กร
• เมื่อเรามอบหมายใบอนุญาต Exchange Online ให้กับบัญชีผู้ใช้ Office 365 กล่องจดหมาย Exchange Online ใหม่จะถูกสร้างขึ้นและ "แนบ" กับบัญชีผู้ใช้ Office 365
• บัญชีผู้ใช้ Office 365 ถือเป็นเจ้าของกล่องจดหมาย Exchange Online
• บัญชีผู้ใช้ Active Directory ภายในองค์กร ถือเป็น “แหล่งที่มาของสิทธิ์” ที่เกี่ยวข้องกับบัญชีผู้ใช้ Office 365

สถานการณ์สมมติที่บัญชีผู้ใช้ Active Directory ในสถานที่ถูกลบ

1. ในกรณีที่บัญชีผู้ใช้ On-Premise Active Directory ถูกลบ ผลที่ตามมาก็คือบัญชีผู้ใช้ Office 365 จะถูกลบด้วย
2. ในกรณีที่บัญชีผู้ใช้ Office 365 ถูกลบ ใบอนุญาต Exchange Online จะถูกลบออก
3. เมื่อใบอนุญาต Exchange Online ถูกเอาออก ผลที่ตามมาคือกล่องจดหมาย Exchange Online จะถูกลบด้วย!

การซิงโครไนซ์ไดเรกทอรีและแนวคิดของ "Hard Match"

คำที่เป็นทางการที่เราใช้เพื่ออธิบายความสัมพันธ์ระหว่างบัญชีผู้ใช้ On-Premise Active Directory และบัญชีผู้ใช้ที่ซิงโครไนซ์ Office 365 ของเขาคือ - การจับคู่แบบยาก

การใช้งานการจับคู่แบบยากนั้นอาศัย "การจับคู่" ที่มีอยู่ระหว่างค่า GUID ของบัญชีผู้ใช้ Active Directory ภายในองค์กรและค่า ImmutableID ของบัญชีผู้ใช้ Office 365 ที่ละเอียดอ่อนของเขา "คู่ค้า"

เมื่อเราสร้างบัญชีผู้ใช้ Active Directory ใหม่ และข้อมูลถูกซิงโครไนซ์กับ Azure Active Directory (โดยเซิร์ฟเวอร์การซิงโครไนซ์ไดเรกทอรี) Azure Active Directory จะสร้างบัญชีผู้ใช้ใหม่ ซึ่งจะ "ผูกมัด" กับ On-Premise Active ไดเรกทอรีบัญชีใหม่

ในกรณีนี้ ค่า ImmutableID ของผู้ใช้ Office 365 จะถูกเติมด้วยค่า GUID ของผู้ใช้ Active Directory ภายในองค์กร

จากนี้ไป บัญชีผู้ใช้ทั้งสองที่แตกต่างกันจะ “เชื่อมโยงกัน” ซึ่งกันและกัน กล่าวอีกนัยหนึ่ง ความสัมพันธ์ระหว่างบัญชีผู้ใช้ทั้งสองได้รับการปกป้องเป็น - การจับคู่ที่ยาก

การใช้กลไกการจับคู่ยากในสถานการณ์การคืนค่ากล่องจดหมาย Exchange Online

ตัวอย่างของแนวคิด Hard Match อาจเป็น - กระบวนการนำกล่องจดหมาย Exchange Online "แนวปฏิบัติที่ดีที่สุด" ไปใช้ในสภาพแวดล้อมที่ใช้ Active Directory

ผู้ใช้ Active Directory Active Directory ที่ถูก "ผูกมัด" กับผู้ใช้ Office 365 ที่ถูกพิจารณาว่าเป็นกล่องจดหมาย Exchange Online ได้รับการกู้คืนแล้ว

เมื่อข้อมูลไปถึง Azure Active Directory แล้ว Azure Active Directory จะ "แจ้งให้ทราบ" ว่าค่า GUID ของ "บัญชีผู้ใช้ Active Directory ที่กู้คืน" จะเหมือนกับค่า ImmutableID ของ "ผู้ใช้ Office 365 ที่ถูกลบโดย Soft" (ผู้ใช้ที่จัดเก็บไว้ในถังรีไซเคิล Azure Active Directory)

เนื่องจากค่า GUID และค่า ImmutableID ของ Office 365 เหมือนกัน นี่เป็นสัญญาณที่ชัดเจนว่าออบเจ็กต์เหล่านี้ "เกี่ยวข้องกัน"

ความจริงที่ว่า Soft Deleted Office 365 มี ImmutableID ที่เหมือนกับ “ผู้ใช้ Active Directory ที่ซิงโครไนซ์ใหม่” หมายความว่าทั้งสองออบเจ็กต์นี้เชื่อมต่อกันในอดีต

กระบวนการ “เชื่อมโยง ” วัตถุผู้ใช้ทั้งสองนั้นถือเป็น - การจับคู่ที่ยาก

หลังจากกระบวนการ “ผูกบัญชีผู้ใช้สองบัญชี ” (การจับคู่แบบยาก) เสร็จสิ้น Azure Active Directory จะเริ่มกระบวนการกู้คืนบัญชีผู้ใช้ Office 365 แบบ Soft Deleted โดยอัตโนมัติ (หมายเลข 2 ในแผนภาพ) .

กระบวนการคืนค่าบัญชีผู้ใช้ Office 365 ตามตรรกะต่อไปนี้ - ถ้าบัญชีผู้ใช้ On-Premise Active Directory (บัญชีหลักของบัญชีผู้ใช้ Office 365) “ยังคงอยู่” บัญชีผู้ใช้ Office 365 ที่เกี่ยวข้องกับ Active นี้ บัญชีผู้ใช้ไดเรกทอรีจะต้อง "มีชีวิต" ด้วย (กู้คืนจากถังรีไซเคิล Azure Active Directory)

การซิงโครไนซ์ไดเรกทอรีและแนวคิดของ "Soft Match"

ในสภาพแวดล้อมการซิงโครไนซ์ไดเรกทอรี คำว่า "Soft Match" จะกำหนดสถานการณ์ที่เรามีบัญชีผู้ใช้ Active Directory ภายในองค์กรและบัญชีผู้ใช้ Office 365 ที่มีคุณสมบัติเหมือนกัน เช่น ที่อยู่อีเมลหรือ UPN ของผู้ใช้ (ชื่อผู้ใช้หลัก) แต่พวกเขา ไม่มีความสัมพันธ์แบบ "ฮาร์ดแมตช์"

กล่าวอีกนัยหนึ่ง ค่าบัญชีผู้ใช้ Office 365 ImmutableID คือ "ว่างเปล่า"

ตัวอย่างเช่น ผู้ใช้ On-Premise Active Directory ที่มีที่อยู่อีเมล - John@o365info.com และผู้ใช้ Office 365 ที่ใช้ที่อยู่อีเมลเดียวกัน (John@o365info.com).

ตามทฤษฎีแล้ว สถานการณ์นี้ "ผิด" เนื่องจากตามที่กล่าวไว้ ในสภาพแวดล้อมการซิงโครไนซ์ไดเรกทอรี Office 365 เราควรสร้างออบเจ็กต์ เช่น บัญชีผู้ใช้โดยใช้ Azure Active Directory

ตามทฤษฎี สถานการณ์สมมติที่บัญชีผู้ใช้ Active Directory ในสถานที่และบัญชีผู้ใช้ Office 365 มีที่อยู่อีเมลเดียวกันจะไม่ "ได้รับอนุญาต"

ตัวเลือกเดียวสำหรับสถานการณ์นี้ที่ต้องตระหนักคือ ถ้าผู้ใช้ Office 365 ถูกสร้างขึ้นผ่าน Office 365 Directory (Azure Active Directory) ซึ่งตรงกันข้ามกับแนวทางในการสร้างและจัดการบัญชีผู้ใช้ในสภาพแวดล้อมการซิงโครไนซ์ไดเรกทอรี Office 365

คนที่สร้างเซิร์ฟเวอร์การซิงโครไนซ์ไดเร็กทอรีเข้าใจว่าความเป็นจริงอาจซับซ้อนกว่านี้ และการซิงโครไนซ์ไดเร็กทอรีจะต้องปรับให้เข้ากับสถานการณ์ "ที่ไม่ได้มาตรฐาน" นี้

ตัวอย่างเช่น - สถานการณ์ที่เราใช้สภาพแวดล้อมที่ไม่ซิงโครไนซ์ และสร้างผู้ใช้ในองค์กรทั้งหมดด้วยตนเองผ่าน Azure Active Directory

ในภายหลัง เราจะติดตั้งเซิร์ฟเวอร์การซิงโครไนซ์ไดเรกทอรีและเริ่มกระบวนการซิงโครไนซ์

ผลลัพธ์ที่คาดหวังคือ "การชนกัน"

ในกรณีที่ผู้ใช้ Directory สองคน (ผู้ใช้ Active Directory ภายในองค์กรและผู้ใช้ Office 365 Directory) มีชื่อเข้าสู่ระบบหรือที่อยู่อีเมลเดียวกัน นี่เป็น "การละเมิด" ของโฟลว์มาตรฐาน ซึ่งวัตถุ Directory ควรจะเป็น ที่จะสร้างผ่าน On-Premise Active Directory เท่านั้น

ข่าวดีก็คือว่าการซิงโครไนซ์ไดเรกทอรี Office 365 นั้นฉลาดพอที่จะรับรู้สถานการณ์ดังกล่าวและเพื่อทำความเข้าใจว่าเอนทิตีของบัญชีผู้ใช้สองคนนี้ควร "ผูก" ให้แน่นยิ่งขึ้นในฐานะ "คู่การซิงโครไนซ์" แม้ว่าจะไม่มีการจับคู่ที่ยากระหว่าง บัญชีผู้ใช้สองบัญชี

กล่าวอีกนัยหนึ่ง การซิงโครไนซ์ไดเรกทอรีเข้าใจว่าแม้ว่าจะไม่มี "เอกสาร" ของความจริงที่ว่าบัญชีผู้ใช้ Active Directory ทั้งสองนี้เกี่ยวข้องกัน (มีความสัมพันธ์กัน) แต่ "ขั้นตอนที่ถูกต้อง" คือการผูกเอนทิตีทั้งสองนี้เข้าด้วยกัน โดยใช้กลไก - ฮาร์ดแมตช์

ในแผนภาพต่อไปนี้ เราจะเห็นตัวอย่างสถานการณ์ ซึ่งเรามีบัญชีผู้ใช้สองรายที่มีชื่อล็อกอินของพวกเขา - John@o365info.com

เมื่อเราเปิดใช้งานเซิร์ฟเวอร์การซิงโครไนซ์ไดเรกทอรี เซิร์ฟเวอร์การซิงโครไนซ์ไดเรกทอรีจะ “แจ้ง ” Azure Active Directory เกี่ยวกับบัญชีผู้ใช้ Active Directory ภายในองค์กรว่าชื่อเข้าสู่ระบบของเขาคือ John@o365info.com

Azure Active Directory “แจ้ง” เซิร์ฟเวอร์การซิงโครไนซ์ไดเรกทอรีว่าเธอมีบัญชีผู้ใช้ที่มีชื่อเข้าสู่ระบบเดียวกันอยู่แล้ว

Directory Synchronization “เข้าใจ” ว่าเขาจำเป็นต้อง “แนบ” บัญชีผู้ใช้เหล่านี้

การซิงโครไนซ์ไดเรกทอรีจะคัดลอกค่า GUID ของบัญชีผู้ใช้ Active Directory ในสถานที่ของ John แปลงค่าเป็นค่า 64 บิต และคัดลอกผลลัพธ์เป็นค่า ImmutableID ของ Office 365 John บัญชีผู้ใช้

สถานะของบัญชีผู้ใช้ John Office 365 เปลี่ยนจาก "ในระบบคลาวด์" เป็น "ซิงโครไนซ์กับ Active Directory ”
จากนี้ไป บัญชีผู้ใช้ Directory สองบัญชีนี้จะถือเป็นบัญชีคู่กัน ”
บัญชีผู้ใช้ Active Directory ภายในองค์กร ถือเป็น “บัญชีหลัก” เนื่องจาก Active Directory ภายในองค์กรเป็นแหล่งที่มาของสิทธิ์ การอัปเดตแต่ละครั้งในบัญชีผู้ใช้ On-Premise Active Directory John จะได้รับการซิงโครไนซ์และ "แทนที่" ข้อมูลที่มีอยู่ในบัญชีผู้ใช้ "John Office 365"

บทความถัดไปในชุดบทความปัจจุบัน

อักขระพิเศษของการซิงโครไนซ์ไดเรกทอรีในสภาพแวดล้อม Office 365 | บทความ 2#2 | ตอนที่ 12#23