การรับรองความถูกต้องแบบพาสทรูของ Azure AD Connect

ที่ Ignite 2017 มีการประกาศว่า Pass Through Authentication (PTA) เข้าถึงความพร้อมใช้งานทั่วไป (GA) แล้ว ดังนั้นจึงเป็นสถานการณ์ที่ได้รับการสนับสนุนอย่างสมบูรณ์ในขณะนี้

แต่ ปตท. คืออะไร? หาก Office 365 มี Cloud Identities, Synced Identities และ Federated Identities สองรายการแรกได้รับการรับรองความถูกต้องใน Azure Active Directory ส่วนรายการสุดท้ายได้รับการรับรองความถูกต้องกับตัวควบคุมโดเมนภายในองค์กร เพื่อให้สิ่งนี้เกิดขึ้น คุณต้องมีโครงสร้างพื้นฐาน ADFS ซึ่งประกอบด้วยเซิร์ฟเวอร์ ADFS ภายในหลายตัวและเซิร์ฟเวอร์ WAP (Windows Application Proxy) หลายตัวใน DMZ ซึ่งทำหน้าที่เป็นพร็อกซี ADFS โอ้ และเซิร์ฟเวอร์ทั้งหมดจะต้องมีสมดุลโหลดเช่นกันเพื่อให้มีความซ้ำซ้อนและความสามารถในการขยายขนาด

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

ความคิดแรกของฉันคือวิธีที่กลไกการรับรองความถูกต้องใช้เครื่องมือการจำลองแบบอะซิงโครนัส (Azure AD Connect ซิงโครไนซ์บัญชีทุก 30 นาทีและรหัสผ่านภายใน 2 นาที) เคยเป็นโซลูชันที่เชื่อถือได้และปลอดภัย สิ่งสุดท้ายที่คุณต้องการให้เกิดขึ้นคือ คุณไม่สามารถตรวจสอบสิทธิ์บริการใดๆ ในระบบคลาวด์ของ Microsoft ได้ เนื่องจากเซิร์ฟเวอร์ Azure AD Connect ของคุณกำลังยุ่งอยู่กับการทำสิ่งอื่นๆ (เช่น การอัปเดตกลไกโดยอัตโนมัติ เป็นต้น)

ความคิดที่สองของฉันคือสิ่งนี้จะปลอดภัยแค่ไหน ไม่มีการเชื่อมต่อขาเข้าไปยังเซิร์ฟเวอร์ Azure AD Connect มีเพียงการเชื่อมต่อขาออกบนพอร์ต 80 (ใช้สำหรับรายการเพิกถอนใบรับรอง SSL เท่านั้น) และ 443 และการสื่อสารเองก็ควรได้รับการรักษาความปลอดภัยเช่นกัน ดังนั้น…. แต่ตอนนี้โดยทั่วไปแล้ว PTA มีข้อมูลมากขึ้น และสิ่งต่างๆ ก็ชัดเจนขึ้น

ขั้นตอนการรับรองความถูกต้อง

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

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

ดังนั้นการเข้ารหัสทำงานอย่างไร? ระหว่างการติดตั้งเซิร์ฟเวอร์ Azure AD Connect จะสร้างคู่คีย์ รหัสสาธารณะจะถูกส่งไปยัง Azure AD และสร้างใบรับรองแล้ว ใบรับรองนี้จะถูกส่งกลับไปยังเซิร์ฟเวอร์ Azure AD Connect และรวมกับคีย์ส่วนตัว คีย์สาธารณะใช้เพื่อเข้ารหัสข้อมูลประจำตัวของผู้ใช้ และเซิร์ฟเวอร์ Azure AD Connect เป็นเพียงเซิร์ฟเวอร์เดียวที่มีคีย์ส่วนตัวในการถอดรหัสคู่คีย์ เอาล่ะ

การกำหนดค่าการรับรองความถูกต้องแบบพาสทรู

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

หากต้องการเปิดใช้งาน PTA บนเซิร์ฟเวอร์ Azure AD Connect จะต้องปฏิบัติตามข้อกำหนดต่อไปนี้:

• Azure AD Connect เวอร์ชัน 1.1.557.0 หรือใหม่กว่าจะต้องทำงานบน Windows 2012 R2
• จำเป็นต้องเปิดพอร์ตขาออก 80/443

หมายเหตุ คุณสามารถดาวน์โหลด Azure AD Connect เวอร์ชันล่าสุดได้ที่นี่: https://www.microsoft.com/en-us/download/details.aspx?id=47594 เมื่อเขียนบล็อกโพสต์ Azure AD Connect เวอร์ชันล่าสุดคือ 1.1.647.0

ในสภาพแวดล้อมของฉัน ฉันเปิดใช้งาน Azure AD Connect แล้ว (พร้อมการซิงโครไนซ์แฮชรหัสผ่าน) ดังนั้นจึงเป็นเพียงเรื่องของการเปลี่ยนแปลงการกำหนดค่า

เริ่ม Azure AD Connect เลือก กำหนดค่า และเลือก เปลี่ยนการลงชื่อเข้าใช้ของผู้ใช้

คลิก ถัดไป และป้อนข้อมูลประจำตัวของผู้ดูแลระบบผู้เช่า ข้อมูลประจำตัวเหล่านี้จำเป็นในการเข้าสู่ระบบ Azure Active Directory เปิดใช้งาน PTA ใน Azure AD และสร้างใบรับรอง

คลิก ถัดไป เพื่อไปที่หน้าลงชื่อเข้าใช้ของผู้ใช้ ที่นี่คุณมีสี่ตัวเลือก:

• การซิงโครไนซ์รหัสผ่าน (ชื่อผิด ควรเป็น การซิงโครไนซ์รหัสผ่านแฮช)
• การรับรองความถูกต้องแบบพาสทรู (หัวข้อของบล็อกนี้)
• สหพันธ์กับ AD FS (บล็อกในอนาคต)
• อย่ากำหนดค่า (เมื่อใช้โซลูชันสหพันธรัฐบุคคลที่สามเช่น Okta)

ช่องทำเครื่องหมายสามารถใช้เพื่อเปิดใช้งานการลงชื่อเพียงครั้งเดียว

เลือก การตรวจสอบสิทธิ์แบบพาส-ทรู และคลิก ถัดไป เพื่อดำเนินการต่อ สังเกตคำแนะนำที่ด้านล่างของหน้า นี่สมเหตุสมผลแล้ว โปรดจำไว้ว่าการตั้งค่า PTA เป็นการตั้งค่าสำหรับทั้งผู้เช่า ดังนั้นบัญชีทั้งหมดในผู้เช่าของคุณจะถูกบังคับให้ใช้ PTA หากมีสิ่งผิดปกติเกิดขึ้นบนเครือข่ายของคุณ และไม่มีตัวแทน AuthN ที่พร้อมใช้งาน จะไม่มีใครสามารถเข้าสู่ระบบได้อีกต่อไป ดังนั้น คุณจำเป็นต้องมีบัญชีผู้ดูแลระบบบนคลาวด์เท่านั้นที่มีชื่อผู้ใช้ @.onmicrosoft.com

เมื่อคุณคลิก ถัดไป วิซาร์ด Azure AD Connect จะตรวจสอบส่วนประกอบที่ติดตั้ง และหากทุกอย่างเป็นไปด้วยดี คุณสามารถเริ่มกระบวนการกำหนดค่าได้

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

คลิก ออก เพื่อสิ้นสุดวิซาร์ด

เมื่อคุณเข้าสู่ระบบ Azure Portal ให้เลือก Azure Active Directory และคลิกไทล์ Azure AD Connect คุณจะเห็นว่าการรับรองความถูกต้องแบบ Pass-through ถูกเปิดใช้งานแล้ว:

ดังนั้นคุณเห็นอะไรเมื่อคุณเข้าสู่ระบบเช่น Outlook Web App ใน Exchange Online ไม่มีอะไรพิเศษ คุณจะเห็นหน้าเข้าสู่ระบบ Azure AD มาตรฐาน (ผ่าน https://login.microsoftonline.com) และหลังจากป้อนข้อมูลประจำตัวของคุณ คุณจะสามารถเข้าถึงกล่องจดหมาย Exchange Online ของคุณได้

หากคุณเปิดบันทึกเหตุการณ์ความปลอดภัยบนเซิร์ฟเวอร์ Azure AD Connect คุณสามารถค้นหาเหตุการณ์ 4624 ได้ ซึ่งจะแสดงให้คุณเห็นว่าบัญชีผู้ใช้ได้รับการตรวจสอบสิทธิ์จริงกับตัวควบคุมโดเมนภายในองค์กร:

นี่เป็นหนึ่งในไม่กี่แห่ง (ฉันรู้) ที่คุณสามารถตรวจสอบบัญชีรับรองความถูกต้องของ PTA ได้

ตัวแทน Azure AD Connect ไม่พร้อมใช้งาน

จะเกิดอะไรขึ้นเมื่อตัวแทน Azure AD Connect ไม่พร้อมใช้งาน ผู้ใช้ไม่สามารถเข้าสู่ระบบได้อีกต่อไป เพื่อจำลองว่าคุณสามารถหยุด ตัวแทนการตรวจสอบสิทธิ์ Microsoft Azure AD Connect ในสแนปอิน MMC ของบริการได้

หากคุณพยายามเข้าสู่ระบบ OWA คุณจะป้อนข้อมูลประจำตัวในพอร์ทัลเข้าสู่ระบบ Microsoft Online และหลังจากนั้นไม่กี่วินาที คุณจะเห็นข้อความแสดงข้อผิดพลาดที่ไม่สามารถอธิบายได้:

ความซ้ำซ้อนในการรับรองความถูกต้องแบบพาส-ทรู

เพื่อแก้ไขปัญหานี้ คุณสามารถติดตั้งตัวแทน AuthN บนเครื่องหลายเครื่องได้ โดยส่วนตัวแล้ว ฉันไม่แนะนำให้ติดตั้งสิ่งนี้บน Domain Controller เพียงเซิร์ฟเวอร์ Windows 2012 R2 ปกติหรือสูงกว่าเท่านั้นที่ควรทำ

เมื่อเข้าสู่ระบบเซิร์ฟเวอร์ ให้เปิดพอร์ทัล Azure (https://portal.azure.com) เลือก Azure Active Directory คลิกไทล์ Azure AD Connect และคลิกที่ การรับรองความถูกต้องแบบพาสทรู

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

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

ลูกค้าที่ได้รับการสนับสนุน

เมื่อพูดถึงไคลเอนต์และสถานการณ์ที่รองรับ สิ่งต่อไปนี้ได้รับการสนับสนุน:

• ลงชื่อเข้าใช้ด้วยแอปพลิเคชันบนเว็บเบราว์เซอร์ทั้งหมด
• Office 2013 และ Office 2016 ที่รองรับการรับรองความถูกต้องสมัยใหม่
• Windows 10 Azure AD เข้าร่วมอุปกรณ์
• แลกเปลี่ยน ActiveSync

ไคลเอนต์และสถานการณ์ต่อไปนี้ ไม่ รองรับ:

• แอปพลิเคชันไคลเอนต์ Office รุ่นเก่า (2010/2013 โดยไม่มีการรับรองความถูกต้องสมัยใหม่)
• แอปพลิเคชันไคลเอ็นต์ Skype for Business (รวมถึงไคลเอ็นต์ SfB 2016 ด้วย!)
• พาวเวอร์เชลล์ 1.0.
• บริการโดเมน Azure AD
• รหัสผ่านสำหรับแอปสำหรับ MFA
• การตรวจจับผู้ใช้ที่มีข้อมูลรับรองรั่วไหล

รายการนี้ก็ไม่น่าแปลกใจ ยกเว้นไคลเอ็นต์ Skype for Business รายการเป็นของเดือนตุลาคม 2017

สรุป

โดยทั่วไปการรับรองความถูกต้องแบบพาส-ทรูจะพร้อมใช้งานตั้งแต่ Ignite 2017 ซึ่งเป็นกลไกการตรวจสอบสิทธิ์ที่ไม่มีการจัดเก็บแฮชรหัสผ่านใน Azure AD นอกจากนี้ยังเบากว่า ADFS มาก ซับซ้อนน้อยกว่าและจัดการได้ง่ายกว่า

มันจะมาแทนที่ ADFS หรือไม่? ไม่ใช่ในระยะสั้น ในขณะนี้ รองรับแอปพลิเคชัน Microsoft สมัยใหม่ที่สามารถใช้เซอร์วิสบัส Azure และโซลูชันที่เกี่ยวข้องได้ แอปพลิเคชันอื่นๆ อีก 3^rd (นับพันรายการ) ที่มีอยู่ใน App Store ยังคงต้องพึ่งพา ADFS และจะยังคงใช้ต่อไปอีกระยะหนึ่ง

สามารถดูข้อมูลเพิ่มเติมได้ที่https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-pass-through-authentication-quick-start