การลงชื่อเพียงครั้งเดียวและการรับรองความถูกต้องแบบพาสทรูของ Azure AD Connect

ในบล็อกโพสต์ก่อนหน้าของฉัน ฉันได้พูดถึง Azure AD Connect Pass-Through Authentication (PTA) วิธีการทำงาน และวิธีกำหนดค่า ในบล็อกโพสต์นั้น ฉันไม่ได้เปิดใช้งานการลงชื่อเพียงครั้งเดียว (SSO) และนั่นก็เป็นความคิดเห็นแรกที่ฉันได้รับภายในหนึ่งหรือสองวัน การเปิดใช้งาน SSO และวิธีการทำงานของหัวข้อของบล็อกโพสต์นี้

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

ฉันได้อธิบายขั้นตอนการตรวจสอบสิทธิ์เมื่อใช้ PTA แล้ว เมื่อเข้าถึงบริการใน Office 365 คุณจะถูกเปลี่ยนเส้นทางไปยัง Azure AD คุณจะป้อนข้อมูลประจำตัวของคุณและข้อมูลประจำตัวจะถูกวางไว้ใน Azure Service Bus เซิร์ฟเวอร์ Azure AD Connect ดึงข้อมูลประจำตัวเหล่านี้จาก Service Bus และนำเสนอต่อ Domain Controller ภายในองค์กร ผลลัพธ์จะถูกส่งกลับไปยังเซอร์วิสบัส และคุณจะได้รับสิทธิ์ในการเข้าถึง หรือปฏิเสธเมื่อมีบางอย่างผิดปกติ

แล้วจะเกิดอะไรขึ้นหากคุณเปิดใช้งาน SSO ในตัวช่วยสร้าง Azure AD Connect การเปิดใช้งาน SSO เป็นเพียงเรื่องของการเลือกช่องทำเครื่องหมาย เปิดใช้งานการลงชื่อเพียงครั้งเดียว ในตัวช่วยสร้าง Azure AD Connect:

หมายเหตุ ฉันข้ามขั้นตอนการกำหนดค่าส่วนใหญ่ เนื่องจากขั้นตอนนี้จะเหมือนกันกับขั้นตอนการกำหนดค่าในบล็อกโพสต์ก่อนหน้า

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

พูดตามตรง ไม่ใช่ SSO ที่แท้จริงเช่นเดียวกับสหพันธรัฐ (ผ่าน ADFS) แต่เป็น Single-Sign On (sSSO) ที่ราบรื่น เมื่อเปิดใช้งาน SSO ในตัวช่วยสร้าง Azure AD Connect ผู้ใช้จะต้องป้อนชื่อเข้าสู่ระบบเมื่อเข้าถึงบริการใน Office 365 เช่น Outlook Web App:

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

หากคุณไม่ต้องการเลือกหรือป้อนชื่อการเข้าสู่ระบบ คุณสามารถใช้ คำแนะนำโดเมน ได้เช่นกัน เมื่อใช้ร่วมกับ Outlook Web App คุณจะใช้ URL เช่น https://outlook.office.com/owa/contoso.com หากคุณทำเช่นนั้น ข้อมูลประจำตัวปัจจุบันของคุณ (อีกครั้งบนเวิร์กสเตชันที่เข้าร่วมโดเมนซึ่งมีสิทธิ์เข้าถึงตัวควบคุมโดเมน) จะถูกส่งผ่านโดยอัตโนมัติ และคุณจะได้รับสิทธิ์ในการเข้าถึง

การลงชื่อเพียงครั้งเดียวที่ไร้รอยต่อภายใต้ประทุน

แต่ sSSO นี้ทำงานอย่างไรภายใต้ประทุน

เมื่อเปิดใช้งาน SSO ในตัวช่วยสร้าง Azure AD Connect คุณต้องป้อนบัญชีผู้ดูแลระบบโดเมนภายในองค์กรของคุณ ใช้เพื่อสร้างวัตถุคอมพิวเตอร์เพิ่มเติมใน Active Directory ชื่อ AZUREADSSOACC

บัญชีคอมพิวเตอร์นี้ใช้เพื่อสร้างคีย์ Kerberos ที่ใช้ร่วมกันระหว่าง Active Directory ภายในองค์กรและ Azure Active Directory ซึ่งจำเป็นสำหรับการสร้างประสบการณ์ sSSO

ในระหว่างการเข้าสู่ระบบในสถานการณ์นี้ 8 ขั้นตอนต่อไปนี้เกิดขึ้น:

1. ลูกค้าเข้าถึงบริการในระบบคลาวด์ของ Microsoft เช่น OWA ผ่าน https://outlook.office.com/owa
2. คำขอถูกเปลี่ยนเส้นทางจาก Office 365 ไปยัง Azure Active Directory
3. การเข้าถึงถูกปฏิเสธ และข้อผิดพลาด 401 ถูกส่งกลับไปยังไคลเอ็นต์
4. ไคลเอนต์เข้าถึงตัวควบคุมโดเมนภายในเครื่องและร้องขอโทเค็น Kerberos
5. ตั๋วเซสชัน Kerberos จะถูกส่งกลับไปยังไคลเอนต์
6. ตั๋วเซสชันจะแสดงต่อ Azure Active Directory เนื่องจาก Azure Active Directory มีตั๋วที่แชร์กับ Active Directory ภายในองค์กรของคุณ คุณจึงสามารถสร้างโทเค็น Kerberos เพื่อให้ไคลเอ็นต์ใช้งานได้
7. โทเค็น Kerberos จะถูกส่งกลับไปยังไคลเอ็นต์
8. โทเค็น Kerberos จะแสดงต่อ Office 365 และได้รับสิทธิ์การเข้าถึง ผู้ใช้สามารถเริ่มใช้ OWA ได้แล้ว

ดังที่คุณเห็นว่าวิธีนี้ใช้ได้เฉพาะกับโดเมนที่เข้าร่วมไคลเอนต์ที่มีสิทธิ์เข้าถึงตัวควบคุมโดเมนในเครื่องเท่านั้น หากพวกเขาไม่มีสิทธิ์เข้าถึง Domain Controller ภายใน ระบบจะปฏิบัติตามกระบวนการ PTA ปกติดังที่แสดงในตอนต้นของบล็อกโพสต์นี้ (และบล็อกโพสต์ก่อนหน้า)

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

• https://autologon.microsoftazuread-sso.com
• https://aadg.windows.net.nsatc.net

เคล็ดลับ ใช้ GPO เพื่อเปลี่ยนแปลงสิ่งนี้สำหรับไคลเอนต์ทั้งหมดในเครือข่ายของคุณ

หากคุณใช้เบราว์เซอร์และไปที่ Exchange Online คุณจะยังคงได้รับแจ้งให้ป้อนชื่อผู้ใช้ของคุณ (หรือเลือกชื่อผู้ใช้เมื่อใช้ก่อนหน้านี้) แต่คุณไม่จำเป็นต้องป้อนรหัสผ่าน:

หากคุณใช้คำใบ้โดเมนใน URL ของคุณ เช่น https://outlook.office.com/owa/inframan.nl บัญชีจะถูกเข้าสู่ระบบโดยอัตโนมัติ บันทึกเล็กๆ น้อยๆ แต่แปลกอย่างหนึ่ง ซึ่ง Microsoft Internet Explorer รองรับ แต่ไม่ใช่ในเบราว์เซอร์ Microsoft Edge (อย่างน้อยก็ไม่ใช่ตอนที่เขียน ต้นเดือนพฤศจิกายน 2017) สิ่งนี้อาจมีการเปลี่ยนแปลงในอนาคต

เพื่อให้สิ่งนี้ทำงานกับ Outlook 2016 (หรือ Outlook 2013 ที่ได้รับแพตช์เต็มรูปแบบซึ่งรองรับ Modern Authentication) เราจำเป็นต้องเปิดใช้งาน OAuth ในระดับผู้เช่า เพื่อให้บรรลุเป้าหมายนี้ ให้เข้าสู่ระบบโดยใช้ PowerShell ระยะไกลใน Exchange Online โดยใช้คำสั่งต่อไปนี้:

$Cred= Get-Credential 'administrator@contoso.onmicrosoft.com'
$Session= New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/PowerShell-LiveID -Credential $Cred -Authentication Basic -AllowRedirection
Import-PSSession -Session $Session

และเมื่อเข้าสู่ระบบแล้วให้ป้อนคำสั่งต่อไปนี้:

ชุด-OrganizationConfig -OAuth2ClientProfileEnabled:$TRUE

ครั้งถัดไปที่คุณเริ่ม Outlook คุณจะเห็นว่าจะเข้าสู่ระบบ Exchange Online โดยอัตโนมัติ (ในขณะที่ไม่ได้เปิดใช้งาน Oauth)

หมายเหตุ ตามที่อธิบายไว้ก่อนหน้าในโพสต์นี้มีคีย์ที่ใช้ร่วมกันระหว่างบัญชีคอมพิวเตอร์ใน Active Directory ภายในองค์กรและ Azure Active Directory ขอแนะนำอย่างยิ่งให้วางคีย์เหล่านี้ทุกๆ 30 วัน สำหรับข้อมูลเพิ่มเติม โปรดตรวจสอบคำถามที่พบบ่อยของ Microsoft เกี่ยวกับเรื่องนี้: https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-sso-faq

สรุป

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

ปัญหาหลายประการที่ควรทราบ: ลูกค้าบางรายอาจไม่รองรับ PTA หรือ sSSO ตามที่อธิบายไว้ในบทความนี้ ตัวอย่างเช่น Internet Explorer รองรับ แต่เบราว์เซอร์ Edge ไม่รองรับ Outlook 2013/2016 รองรับ (การรับรองความถูกต้องสมัยใหม่) แต่ Outlook 2010 ไม่รองรับ นอกจากนี้ Lync/Skype สำหรับไคลเอนต์ธุรกิจไม่รองรับสิ่งนี้เลย ฉันคาดว่าสิ่งนี้จะเปลี่ยนแปลงในอนาคต (ใกล้) และเมื่อใดฉันจะอัปเดตบทความนี้

ข้อมูลมากกว่านี้

Azure Active Directory การลงชื่อเพียงครั้งเดียวอย่างราบรื่น: คำถามที่ถามบ่อย - https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-sso-faq