Blog

ทางเลือกการตรวจสอบตัวตนใน Azure AD

fabrizio-verrecchia-252588-unsplash.jpg

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

บัญชีผู้ใช้งานสำหรับบริการในระบบคลาวด์ของไมโครซอฟท์มี 2 แบบ แบบแรกคือการสร้างตรงๆ ในไดเรคทอรี่เซอร์วิสบนคลาวด์เลย เรียกว่า cloud-only identity และแบบที่สองคือ sync identity ซึ่งเป็นการซิงโครไนซ์บัญชีผู้ใช้งานจาก on-premises ไดเรคทอรี่เซอร์วิสขึ้นไปบนคลาวด์ โดยที่ sync identity ยังมีรูปแบบการตรวจสอบตัวตนที่แตกต่างกันอีก 5 แบบ!

ดังนั้นรวมๆ แล้วเรามี 6 ทางเลือก (1 x cloud-only + 5 x sync identity) ที่จะมาทำความรู้จัก และเลือกใช้วิธีที่เหมาะสมกันครับ

. . .

1. Cloud-Only Identity

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

+ ไม่ต้องมี on-premises ไดเรคทอรี่เซอร์วิส
– ไม่เหมาะกับองค์กรที่มีบัญชีรายชื่อผู้ใช้งานจำนวนมากใน on-premises ไดเรคทอรี่เซอร์วิส
– ต้องดูแลพาสเวิร์ดให้เหมือนกันทั้ง 2 ระบบ

. . .

2. Password Hash Synchronization (PHS)

องค์กรที่มีพนักงานจำนวนมาก ส่วนใหญ่ก็จะมี on-premises ไดเรคทอรี่เซอร์วิสอยู่ก่อนแล้ว เช่่น Active Directory Domain Services (AD DS) ดั้งนั้นหากเราไม่ต้องการสร้าง cloud-only identity สำหรับผู้ใช้งานจำนวนมากๆ เราก็สามารถติดตั้งเครื่องมือที่ทำ directory synchronization เช่น Azure AD Connect ให้ซิงโครไนซ์บัญชีผู้ใช้งานและแฮชพาสเวิร์ดขึ้นไปยัง Azure AD ได้ หากผู้ใช้งานพบหน้าใดที่ถามพาสเวิร์ดก็ให้ใส่พาสเวิร์ดเดียวกันทั้งการเข้าถึงบริการบนคลาวด์และ on-premises วิธีนี้ช่วยให้ผู้ใช้ไม่ต้องจำพาสเวิร์ดหลายตัวครับ

แฮชพาสเวิร์ดที่ถูกส่งขึ้นไปยัง Azure AD จะถูกแฮชอีกรอบ (จึงกลายเป็น “ดับเบิ้ลแฮช” เลย) สบายใจได้ครับ

+ ไม่ต้องสร้างบัญชีผู้ใช้งานด้วยตัวเองในระบบคลาวด์
+ บริการในระบบคลาวด์ไม่ขึ้นอยู่กับระบบใน on-premises
– สถานะของบัญชีผู้ใช้ใน on-premises ต้องรอเวลา sync 30 นาที เช่น disabled account

. . .

3. Federated Identity

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

ส่วนใหญ่เราก็ติดตั้ง AD FS 2 เครื่อง เพื่อรับ authentication request จากผู้ใช้ภายใน และ Web Application Proxy (WAP) อีก 2 เครื่องใน perimeter network เพื่อ publish AD FS farm ภายในออกไปให้ผู้ใช้งานภายนอกวิ่งเข้ามาทำ authentication นับรวมกันทั้งหมดได้ 4 เครื่องพอดี T_T ก็จะช่วยให้ระบบมี high availability และความปลอดภัยครับ

+ ไม่ต้องซิงโครไนซ์แฮชพาสเวิร์ดขึ้นไปยังระบบคลาวด์
+ ตรวจสอบสถานะของบัญชีผู้ใช้งานโดยตรงจาก on-premises เช่น disabled account, account locked out, password expired, หรือ sign-in hours ก่อนอนุญาตให้ใช้งาน
– มีเครื่องในระบบ AD FS ที่ต้องดูแล 1-4 เครื่อง
– เมื่อระบบใน on-premises หยุดทำงานจะทำให้ใช้งานบริการในระบบคลาวด์ไม่ได้

. . .

4. Pass-Through Authentication (PTA)

บางท่านติดตั้ง AD FS เพียงเพื่อไม่ต้องการซิงโครไนซ์แฮชพาสเวิร์ดขึ้นไปยังระบบคลาวด์ แต่กลับต้องมาดูแลเครื่องเพิ่มอีก 4 เครื่อง บางทีก็ไม่ไหวครับ ตอนนี้มีอีกทางเลือกนึงคือ Pass-Through Authentication (PTA) วิธีนี้จะมีการติดตั้ง authentication agent บนเครื่องที่ติดตั้ง Azure AD connect หากต้องการ high availability เราควรติดตั้ง agent ลงบนคอมพิวเตอร์เครื่องอื่นด้วย ไมโครซอฟท์แนะนำให้มีอย่างน้อย 3 authentication agent ต่อ 1 tenant ครับ

Authentication request จะถูกคิวอยู่ที่ Azure AD ก่อน แล้ว authentication agent ใน on-premises ก็จะไปดึง authentication request ลงมาตรวจสอบก่อนอนุญาตให้ผู้ใช้เข้าถึงบริการในระบบคลาวด์

+ ไม่ต้องซิงโครไนซ์แฮชพาสเวิร์ดขึ้นไปยังระบบคลาวด์
+ ตรวจสอบสถานะของบัญชีผู้ใช้งานโดยตรงจาก on-premises เช่น disabled account, account locked out, password expired, หรือ sign-in hours ก่อนอนุญาตให้ใช้งาน
+ ไม่ต้องติดตั้งระบบ AD FS จำนวน 4 เครื่อง
– ยังต้องพึ่งพา authentication agent ในระบบ on-premises
– ไม่เป็น single sign-on ผู้ใช้เจอหน้าถามพาสเวิร์ด

. . .

5. Seamless SSO + PTA

PTA ยังมีหน้าถามพาสเวิร์ด แต่ถ้าใช้งานร่วมกับ Azure AD Seamless Single Sign-On (Seamless SSO) จะไม่มีหน้ากรอกพาสเวิร์ดมากวนใจผู้ใช้งานครับ

เราเปิดฟีเจอร์ Seamless SSO ผ่านการรีรัน Azure AD Connect ซึ่งจะมีการสร้างคอมพิวเตอร์ออปเจ็ค 1 ตัวชื่อว่า AZUREADSSOACC ไว้ใน on-premises AD ของเรา คอมพิวเตอร์ออปเจ็คตัวนี้คือตัวแทนของ Azure AD

ผู้ใช้งานจะทำ Kerberos authentication กับ on-premises AD เพื่อขออนุญาตเข้าใช้งานคอมพิวเตอร์ออปเจ็คตัวนี้ ถ้าผ่านก็จะได้ Kerberos ticket เอาไปยื่นให้กับ Azure AD เพื่อเข้าใช้งานบริการในระบบคลาวด์โดยไม่ต้องกรอกพาสเวิร์ดอีกครั้งครับ

+ ไม่ต้องซิงโครไนซ์แฮชพาสเวิร์ดขึ้นไปยังระบบคลาวด์
+ ตรวจสอบสถานะของบัญชีผู้ใช้งานโดยตรงจาก on-premises เช่น disabled account, account locked out, password expired, หรือ sign-in hours ก่อนอนุญาตให้ใช้งาน
+ ไม่ต้องติดตั้งระบบ AD FS จำนวน 4 เครื่อง
+ ผู้ใช้ไม่เจอหน้าถามพาสเวิร์ด
– ยังต้องพึ่งพา authentication agent ใน on-premises

. . .

6. Seamless SSO + PHS

แบบสุดท้ายนี้ สะดวกที่สุดครับ เขาเหมือนกับ PHS แต่เนื่องจากเรา enable Seamless SSO ไว้ ทำให้ผู้ใช้ไม่ต้องเจอหน้าถามพาสเวิร์ดอีกต่อไป ที่สำคัญคือ ไม่ต้องมีระบบ on-premises เหมือนกับ PTA อีกด้วย!

+ ไม่ต้องซิงโครไนซ์แฮชพาสเวิร์ดขึ้นไปยังระบบคลาวด์
+ ไม่ต้องติดตั้ง AD FS จำนวน 4 เครื่อง
+ ผู้ใช้ไม่เจอหน้าถามพาสเวิร์ด
+ ไม่ต้องพึ่งพา authentication agent ใน on-premises
– สถานะของบัญชีผู้ใช้ใน on-premises ต้องรอเวลา sync 30 นาที เช่น disabled account

. . .

ตัดสินใจเลือกด้วย Flow Chart

ทั้ง 6 แบบนี้ ลองดูเงื่อนไขต่างๆ ว่าเราควรจะใช้แบบไหนจาก flow chart ได้ครับ

. . .

Cloud-only, PHS, และ AD FS เราพูดถึงกันไปเยอะแล้ว ส่วน PTA เรากระโดข้ามไปดู Seamless SSO + PTA กันเลยดีกว่า และใครที่ไม่อยากให้ระบบคลาวด์ขึ้นอยู่กับความเป็นอยู่ของระบบ on-premises เราก็จะไปดู Seamless SSO + PHS กันต่อไปครับ

จาก Choose the right authentication method for your Azure Active Directory hybrid identity solution

INC