דגשים והגדרות מול Azure AD Pass-through Authentication

לכל מי שהטמיע ADFS אז אפשר לומר שהרגע שציפינו לו הגיע עם יכולות Azure AD Pass-through Authentication!

רוב הארגונים שעובדים עם שירותי הענן Azure + Office 365 אינם נולדו אל הענן והצעד הראשון של הארגונים מול הענן התחיל בתצורה היברידית של סביבת Active Directory ועבודה עם Directory אחד בלבד לשירותי הענן ולמשאבי On-Prem.

אותם ארגונים שעובדים בתצורה היברידית מצבע סנכרון Hash של הסיסמא וחלקם מבצע SSO ללא סנכרון Hash של הסיסמא עם שרתי ADFS.

ההיבטים החשובים לארגונים בתצורה היברידית של Active Directory נחלקו למספר היבטים:

  • עבודה מול Directory אחד בלבד ללא יצירה של Directory נוסף
  • חווית משתמש עם אימות והזדהות אחד בלבד בגישה למשאבי ענן ומשאבים מקומיים
  • שמירה על זהויות המשתמשים והקשחת הגישה לפי מאפיינים
  • למנוע Overhead בניהול המשתמשים בין סביבת הענן לסביבה המקומית
  • לשמור על יכולות הניהול של המשתמשים בתצורה היברידית

אפשר לומר שכיום רוב הארגונים עובדים בתצורה היברידת עם Active Directory המאפשרת סנכרון Hash של הסיסמא ובמידת הצורך עושים שימוש ביכולות Conditional Access עם Azure AD.

בתרחישים שבהם סנכרון Hash של הסיסמא לא ענה על הדרישות היה צורך ביישום של ADFS.
יישום של שרתי ADFS דרש מספר שרתים עם היבטים ודרישות של שרידות בין אתרים, ניהול ותחזוקה, כתובת חיצונית ייעודית ותעודות דיגיטליות ולכן היישום של ADFS במקרים מסוימים יכל להיות מורכב.

לפני שנרחיב על Azure PTA נבין מהם היכולות הקיימות של AAD Connect מול Azure AD לביצוע אוטנטיקציה עם Direcotry אחד:

  • Authenticating Directly to Office 365 – מציע שתי אפשרויות של ניהול סיסמאות בצורה נפרדת בין הסביבה המקומית לבין סביבת הענן והאפשרות השניה היא שימוש ביכולות AAD Connect עם סנכרון HASH של הסיסמא.
  • Authenticate using AD FS – שרתים מקומיים שמבצעים claim based authentication ולכן כל דרישה להזדהות מול הענן עוברת דרך שרתי ADFS.
  • Authenticate using AAD Premium or a third-party – שימוש במוצרים צד שלישי לביצוע הזדהות מבוססת claim כגון: Okta ולכן אינו מצריך שרתי ADFS מקומיים. מצריך AAD Premium.
  • Azure Pass-Through Authentication או בקצרה Azure PTA – צורת הזדהות חדשה שקיימת בגרסת AAD Connect 1.1.377 ומעלה ומאפשרת:
    • יכולות SSO מול הסביבה המקומית
    • מקטין את השימוש ברכיבים
    • פשוט ליישום

איך עובד Azure PTA

Azure PTA מפשט את הפתרון של ביצוע אוטנטיקציה מול הענן והצורך באימות מקומי מול Active Directory ע”י שימוש
של AAD Connect מול Azure AD Application Proxy ומול Azure AD.
הדרך הפשוטה ביותר לתאר את Azure PTA היא ע”י ביצוע פרוקסי של האוטנטיקציה החיצונית אל שרתי Active Directory ולאחר מכן ביצוע Kerberos אל Saml.

תהליך הלוגין של משתמש בתצורת PTA נעשית באופן הבא:

  • משתמש חיצוני מבצע לוגין מול Office 365 או Azure AD
  • Azure AD שולח בקשה אל רכיב AAD Connect
  • רכיב AAD Connect מבצע תשאול ונותן תוקף לבקשה מול Active Directory מקומי
  • Active Directory מקומי מחזיר את הבקשה אל רכיב AAD Connect
  • רכיב AAD Connect מחזיר את הבקשה אל שירות Azure AD
  • שירות Azure AD מחזיר את הבקשה אל המשתמש ומאפשר לו לבצע לוגין

image
מכיוון שהקונקטור עובד באופן מוצפן ניתן להתקין את הקונקטור בסביבה הפנימית וללא צורך בהתקנה בסביבת DMZ,  כאשר קונקטור מבצע בקשה מול Azure AD הוא מבצע בקשה אקטיבית מול Azure AD (ולכן אין צורך בהגדרה של תעדוה דיגיטלית, רשומת DNS וכו’).

כאשר מתבצעת אוטנטיקציה בין הקונקטור המקומי לבין בשרת ADDS ייעשה שימוש עם Kereberos ולכן נקבל חווית שימוש של SSO עם מחשבים המחוברים לדומיין.

הגדרת Azure PTA נעשית מקומית על שרת AAD COnnect ולכן אם השרת אינו זמין לא תהיה אפשרות לבצע אוטנטיקציה ובתרחיש כזה ניתן להגדיר קונקטור נוסף בשרת אחר בכדי שנוכל לקבל שרידות מול Azure AD.

מתי PTA מתאים לארגון

Azure PTA מתאים לארגונים שרוצים לנהל זהות אחת של המשתמשים וליישם SSO ואינם רוצים לסנכרן Hash של הסיסמא וכל זאת ללא שרתי ADFS.
בין PTA לבין ADFS ישנם מספר הבדלים, כגון:

  • PTA מבוסס על אוטנטיקציה עם Kerberos
  • ADFS עובד עם חוקים מבוססים Claim Based
  • PTA אינו מאפשר אינטגרציה עם Office 365 בלבד ואינו מאפשר אינטגרציה מול מערכות, כגון: Salesforce
  • PTA מבטל סנכרון Hash של הסיסמא במידה וקיים

דרישות להגדרת Azure PTA

בכדי לעבוד עם Azure PTA צריך לוודא את הדרישות הבאות:

  • שרת מבוסס Windows Server 2012 R2
  • Azure AAD Connect בגרסה 1.1.371
  • גישה לכתובות הבאות:
    • *.msappproxy.net
    • *.servicebus.windows.net.
    • טווחי הכתובות של Azure Data Center
  • לוודא שלא מבוצעת inspection על גבי SSL מול השרת
  • הגדרות Firewall עם הפורטים הבאים: 443, 9090, 9091, 9352, 5671, 10100-101200
  • אופציונלי – שרת נוסף לביצוע שרידות (ניתן להתקנה על שרת ADDS קיים)
  • משתמשים עם גרסת Office שתומך באפשרות Modern Authentication

התקנה והגדרת PTA

1

2

3

הערה: חשוב לסמן את אפשרות Pass-through authentication ואת אפשרות Enable single sign on

4

5

6

7

8

9

10

הערה: אין לנו צורך בסימון Password synchronization כאשר מגדירים PTA

16

13

14

15

בסיום התקנה והגדרת Azure PTA עם AAD Connect יוגדרו מספר פרמטרים ומאפיינים:

  • אובייקט מסוג Computer שנקרא AZUREADSSOACC ומבצע אימות Kerberos (לשימוש ASA)
  • Services ייעודיים של Microsoft AAD Application Proxy Connector

מידע נוסף https://docs.microsoft.com/en-us/azure/active-directory/active-directory-aadconnect-pass-through-authentication

דגשים והגדרות מול Azure AD Pass-through Authentication

לכל מי שהטמיע ADFS אז אפשר לומר שהרגע שציפינו לו הגיע עם יכולות Azure AD Pass-through Authentication!

רוב הארגונים שעובדים עם שירותי הענן Azure + Office 365 אינם נולדו אל הענן והצעד הראשון של הארגונים מול הענן התחיל בתצורה היברידית של סביבת Active Directory ועבודה עם Directory אחד בלבד לשירותי הענן ולמשאבי On-Prem.

אותם ארגונים שעובדים בתצורה היברידית מצבע סנכרון Hash של הסיסמא וחלקם מבצע SSO ללא סנכרון Hash של הסיסמא עם שרתי ADFS.

ההיבטים החשובים לארגונים בתצורה היברידית של Active Directory נחלקו למספר היבטים:

  • עבודה מול Directory אחד בלבד ללא יצירה של Directory נוסף
  • חווית משתמש עם אימות והזדהות אחד בלבד בגישה למשאבי ענן ומשאבים מקומיים
  • שמירה על זהויות המשתמשים והקשחת הגישה לפי מאפיינים
  • למנוע Overhead בניהול המשתמשים בין סביבת הענן לסביבה המקומית
  • לשמור על יכולות הניהול של המשתמשים בתצורה היברידית

אפשר לומר שכיום רוב הארגונים עובדים בתצורה היברידת עם Active Directory המאפשרת סנכרון Hash של הסיסמא ובמידת הצורך עושים שימוש ביכולות Conditional Access עם Azure AD.

בתרחישים שבהם סנכרון Hash של הסיסמא לא ענה על הדרישות היה צורך ביישום של ADFS.
יישום של שרתי ADFS דרש מספר שרתים עם היבטים ודרישות של שרידות בין אתרים, ניהול ותחזוקה, כתובת חיצונית ייעודית ותעודות דיגיטליות ולכן היישום של ADFS במקרים מסוימים יכל להיות מורכב.

לפני שנרחיב על Azure PTA נבין מהם היכולות הקיימות של AAD Connect מול Azure AD לביצוע אוטנטיקציה עם Direcotry אחד:

  • Authenticating Directly to Office 365 – מציע שתי אפשרויות של ניהול סיסמאות בצורה נפרדת בין הסביבה המקומית לבין סביבת הענן והאפשרות השניה היא שימוש ביכולות AAD Connect עם סנכרון HASH של הסיסמא.
  • Authenticate using AD FS – שרתים מקומיים שמבצעים claim based authentication ולכן כל דרישה להזדהות מול הענן עוברת דרך שרתי ADFS.
  • Authenticate using AAD Premium or a third-party – שימוש במוצרים צד שלישי לביצוע הזדהות מבוססת claim כגון: Okta ולכן אינו מצריך שרתי ADFS מקומיים. מצריך AAD Premium.
  • Azure Pass-Through Authentication או בקצרה Azure PTA – צורת הזדהות חדשה שקיימת בגרסת AAD Connect 1.1.377 ומעלה ומאפשרת:
    • יכולות SSO מול הסביבה המקומית
    • מקטין את השימוש ברכיבים
    • פשוט ליישום

איך עובד Azure PTA

Azure PTA מפשט את הפתרון של ביצוע אוטנטיקציה מול הענן והצורך באימות מקומי מול Active Directory ע”י שימוש
של AAD Connect מול Azure AD Application Proxy ומול Azure AD.
הדרך הפשוטה ביותר לתאר את Azure PTA היא ע”י ביצוע פרוקסי של האוטנטיקציה החיצונית אל שרתי Active Directory ולאחר מכן ביצוע Kerberos אל Saml.

תהליך הלוגין של משתמש בתצורת PTA נעשית באופן הבא:

  • משתמש חיצוני מבצע לוגין מול Office 365 או Azure AD
  • Azure AD שולח בקשה אל רכיב AAD Connect
  • רכיב AAD Connect מבצע תשאול ונותן תוקף לבקשה מול Active Directory מקומי
  • Active Directory מקומי מחזיר את הבקשה אל רכיב AAD Connect
  • רכיב AAD Connect מחזיר את הבקשה אל שירות Azure AD
  • שירות Azure AD מחזיר את הבקשה אל המשתמש ומאפשר לו לבצע לוגין

image
מכיוון שהקונקטור עובד באופן מוצפן ניתן להתקין את הקונקטור בסביבה הפנימית וללא צורך בהתקנה בסביבת DMZ,  כאשר קונקטור מבצע בקשה מול Azure AD הוא מבצע בקשה אקטיבית מול Azure AD (ולכן אין צורך בהגדרה של תעדוה דיגיטלית, רשומת DNS וכו’).

כאשר מתבצעת אוטנטיקציה בין הקונקטור המקומי לבין בשרת ADDS ייעשה שימוש עם Kereberos ולכן נקבל חווית שימוש של SSO עם מחשבים המחוברים לדומיין.

הגדרת Azure PTA נעשית מקומית על שרת AAD COnnect ולכן אם השרת אינו זמין לא תהיה אפשרות לבצע אוטנטיקציה ובתרחיש כזה ניתן להגדיר קונקטור נוסף בשרת אחר בכדי שנוכל לקבל שרידות מול Azure AD.

מתי PTA מתאים לארגון

Azure PTA מתאים לארגונים שרוצים לנהל זהות אחת של המשתמשים וליישם SSO ואינם רוצים לסנכרן Hash של הסיסמא וכל זאת ללא שרתי ADFS.
בין PTA לבין ADFS ישנם מספר הבדלים, כגון:

  • PTA מבוסס על אוטנטיקציה עם Kerberos
  • ADFS עובד עם חוקים מבוססים Claim Based
  • PTA אינו מאפשר אינטגרציה עם Office 365 בלבד ואינו מאפשר אינטגרציה מול מערכות, כגון: Salesforce
  • PTA מבטל סנכרון Hash של הסיסמא במידה וקיים

דרישות להגדרת Azure PTA

בכדי לעבוד עם Azure PTA צריך לוודא את הדרישות הבאות:

  • שרת מבוסס Windows Server 2012 R2
  • Azure AAD Connect בגרסה 1.1.371
  • גישה לכתובות הבאות:
    • *.msappproxy.net
    • *.servicebus.windows.net.
    • טווחי הכתובות של Azure Data Center
  • לוודא שלא מבוצעת inspection על גבי SSL מול השרת
  • הגדרות Firewall עם הפורטים הבאים: 443, 9090, 9091, 9352, 5671, 10100-101200
  • אופציונלי – שרת נוסף לביצוע שרידות (ניתן להתקנה על שרת ADDS קיים)
  • משתמשים עם גרסת Office שתומך באפשרות Modern Authentication

התקנה והגדרת PTA

1

2

3

הערה: חשוב לסמן את אפשרות Pass-through authentication ואת אפשרות Enable single sign on

4

5

6

7

8

9

10

הערה: אין לנו צורך בסימון Password synchronization כאשר מגדירים PTA

16

13

14

15

בסיום התקנה והגדרת Azure PTA עם AAD Connect יוגדרו מספר פרמטרים ומאפיינים:

  • אובייקט מסוג Computer שנקרא AZUREADSSOACC ומבצע אימות Kerberos (לשימוש ASA)
  • Services ייעודיים של Microsoft AAD Application Proxy Connector

מידע נוסף https://docs.microsoft.com/en-us/azure/active-directory/active-directory-aadconnect-pass-through-authentication

You may also like...

1 Response

  1. 29/04/2017

    […] דגשים והגדרות מול Azure AD Pass-through Authentication […]

כתיבת תגובה

האימייל לא יוצג באתר. שדות החובה מסומנים *