ארמגדון בשירות Exchange Online
היום המיוחל מתקרב אלינו בצעדי ענק וממש בקרוב יחל השלב האחרון בתהליך של ביטול אימות בסיסי בשירות Exchange Online. בארגונים מסוימים מדובר על תהליך פשוט שאינו יגרום לאפקט מסוים, אך בארגונים אחרים מדובר על תהליך מורכב שיכול להשפיע על אפליקציות שונות.
התהליך של ביטול אימות בסיסי החל כבר בשלהי 2019 והיה אמור להסתיים במחצית השניה של 2020, אבל מאז היו המון שינויים ובעיקר חוסר מוכנות של טננטים לביטול של רכיבים מסוימים וכן אימות בסיסי מול שירות Exchange Online. אפשר לומר שכבר באוקטובר 2020 החל תהליך מסוים של דיסבול אימות בסיסי לארגונים שאינם משתמשים בפרוטוקלים השונים מול Exchange Online.
המאמר הינו מאמר המשך למאמר אפוקליפסת Basic Authentication בשירות Exchange Online שעלה בתחילת 2020 ועודכן בהמשך מספר פעמים עם נקודות מסוימות בלבד. למאמר המלא בקישור המצורף.
המאמר הנוכחי מתמקד בעדכונים האחרונים וכן בהכרזה האחרונה, בנוסף מתמקד באפשרויות לניתוח ובדיקה של שימוש בפרוטוקולים השונים מול Exchange Online, אפשרויות חסימה, נקודות חשובות בתהליך וכן תובנות נוספות שיכולות לסייע.
העדכון הרשמי והמעודכן של קבוצת המוצר לגבי אימות בסיסי
Basic Authentication and Exchange Online – September 2021 Update
המאמר מובא על סמך תובנות, ממצאים ומידע לאחר העברת ארגונים בסדרי גודל של 30K ומעלה לתצורות Modern Auth מלאות ותוך כדי התנהלות מול אפליקציות ישנות ובעיות קצה שקיימות בכל ארגון.
אז מאפוקליפסה עברתי לארמגדון, למה? כי במהלך הזמן נתקלתי במספר ארגונים שתהליך מעבר לאימות מודרני היה ועודנו קשה (אפילו קשה מאוד), וזאת בגלל אפליקציות ישנות שצריכות כתיבה ושינוי מחדש, ולעיתים מדובר על אפליקציות “ללא בעלים”.
חשוב להדגיש כי מהיבט תשתית וארכיטקטורה הדיסבול של אימות בסיסי בענן אינה פעולה סבוכה, להיפך, מדובר על פעולה מאוד פשוטה, אך בכדי להגיע לאותו שלב פשוט אנו צריכים לעבור כברת דרך ארוכה ולוודא שאין בטננט אפליקציות כלשהן שמבצעות אימות בסיסי.
הקדמה
שירות Exchange Online הוא אחד הרכיבים המרכזיים בשירות Microsoft 365, ולכן שינוי בתצורת הזדהות בארגונים רבים הוא אירוע מרכזי שמצריך היערכות לא קצרה (בארגונים גדולים מצריך היערכות בת מספר חודשים), מפני שמדובר על שינוי באפליקציות צד שלישי, ביטול ושינוי גישה למשתמשי קצה, שינוי אפליקציות מבוססות קוד (הפשוט בינהם אוטומציות מבוססות PowerShell) והקריטי מכולם הוא כתיבה של אימות מחדש לאפליקציות שאין להם בעלים.
אם נקח לדוגמה את הרכיב Exchange Web Services והגישה אשר נעשית לאפליקציות על גבי API מול Exchange Online, אז, במהלך השנים האחרונות נעשה רק שינוי אבטחה בודד שהוא באמצעות SOAP API, וזה קרה בשנת 2018, ומאז כל הגישה והפיתוח עבר אל Microsoft Graph API.
למי שצריך לשכתב קוד מחדש אז האפשרויות של Microsoft Graph הם מגוונות ובעלות ערך רב, לצורך העניין, הרבה מעבר לאפשרויות שבוצעו עד כה מול Exchange Online (בצקרים שבהם היה פיתוח על גבי Basic Authentication).
תצורת הזדהות המבוססת על Basic Authentication נמצאת איתנו שנים ארוכות, וקיימת בכל מערכת Legacy ואפילו במערכות חדשות ומתקדמות, ולכן אימות בסיסי הוא סטנדרט מיושן בתעשייה, והאיומים הנובעים מאימות בסיסי רק גדלים ועל אחת כמה וכמה מהכרזת השינוי שייעשה בשירות Exchange Online.
כידוע, המטרה הסופית היא כיבוי וביטול של אימות בסיסי עבור כל הטננטים ללא יוצא מן הכלל. מבחינת מודל האחריות בענן, בכל יום שינו טננט עם אימות בסיסי מופעל ועובד, הגישה והנתונים נמצאים בסיכון.
אפליקציות, מערכות והתקנים רבים מבצעים הזדהות על גבי Basic Authentication בין אם מדובר בהתחברות אל רכיב Exchange Web Services או IMAP. איך עובד Basic Authentication בשירות Exchange Online? במצב של הזדהות עם Basic Authentication בשירות Exchange Online נעשה התהליך הבא:
אפליקצית דואר (Outlook) שולחת שם משתמש וסיסמה אל Exchange Online
שירות Exchange Online מבצע העברה (forward) או פרוקסי של פרטי הזדהות אל Identity Provider, למשל Azure AD
שירות IdP מבצע אימות של אותם פרטי הזדהות ולאחר מכן מחזיר טיקט את הבקשה אל Exchange Online ומשם אל המשתמש
טיפ: במידה ומבוצעת חסימה של Basic Authentication הגישה נחסמת כבר בנקודה הראשונה של הבקשה
ומהו Modern Authentication? שיטת הזדהות שנמצאת איתנו מספר שנים בודדות ומאגדת בתוכה שילוב של הזדהות, הרשאות ותנאים.
שיטת הזדהות מבוססת Modern Authentication מתבססת על תקנים קיימים ותקנים שהותאמו לסביבת Office 365:
- סטנדרט מבוסס Open Source API
- מבוסס על Open ID Connect לביצוע הזדהות
- מבוסס על OAuth 2.0 לטובת הרשאות
- תקן ADAL לביצוע אימות בענן (MSOIDCRL)
- תמיכה באפליקציות ומערכות צד שלישי
- מאפשר הזדהות על גבי Smart-Card או MFA וכן הלאה
OAuth 2.0 הוא פרוטוקול הזדהות ולמעשה מבצע Delegated Access ומקבל סוג של דלגציה ולא Authentication ישיר, ולכן הפרוטוקול נבנה על מנת לאפשר האצלת הזדהות לגורם (אפליקציה/מערכת) אחר לגשת למידע וכן אימות קודם שנעשה קודם לכן ונשמר על ידי צד שלישי. בתוך הפרוטוקול מוגדר מסגרת Authentication שהיא כללית.
הערה: בשיטת הזדהות של Modern Authentication כל האימות וההרשאות נעשות על גבי Azure AD
למה צריך Modern Authentication? שיטת הזדהות אחת עם טוקן אחד לכלל האפליקציות, שליטה טובה יותר בתצורות הזדהות, תמיכה באפליקציות ומערכות צד שלישי, חווית משתמש אחידה ומתקדמת.
תאריכים, השפעה והחרגה
בתהליך ביטול של אימות בסיסי הוכרזו מספר תאריכים כאשר המרכזי והמוכר בהם הוא אוקטובר 2022, אך לפני כן ייעשו ברבעון הראשון של שנת 2022 מספר פעולות לביטול אימות בסיסי בטננטים אקראיים, הטננטים מוכנים לכך? בעקרון, כדאי שכן, בכדי שלא תהיה סגירה של אפליקציות שעושות שימוש עם אימות בסיסי.
התאריכים המרכזיים של ביטול אימות בסיסי הם:
ראשון באקטובר 2022 יבוטל אימות בסיסי לכלל הרכיבים/פרוטוקולים בשירות Exchange Online, למעט SMTP. חשוב להגיש כי אימות בסיסי יבוטל לכלל הטננטים באוקטובר 2022 כולל טננטים שעדיין עובדים עם אימות בסיסי.
בתחילת 2022 (הרבעון הראשון) יבוטל אימות בסיסי לטננטיים אקראים לפרק זמן של עד 48 שעות, כולל טננטים שעדיין עובדים עם אימות בסיסי. הטננטים ייבחרו בצורה אקראית ללא פרמטרים ידועים מראש ובאותו פרק זמן של ביטול האימות לפרוטוקולים השונים לא תהיה אפשרות לעבוד עם אימות בסיסי. לאחר פרק הזמן של 48 השעות האימות הביסי יופעל מחדש לאותם טננטים.
למי שעובד ביומיום עם Message Center אז יצאו מספר הודעות שמסווגות כהודעות MAJOR UPDATE, הראשונה בספטמבר 2021 והשניה באוקטובר 2021 שמפרטות את השינוי, תאריכים וקישור למאמר נוספים של קבוצת המוצר (EXO).
טיפ: טננטים חדשים אינם מופעלים מראש עם אימות בסיסי ולכן אין צורך לבצע את השינוי
העדכון הרשמי והאחרון של קבוצת המוצר לגבי דיסבול אימות בסיסי (Basic Auth) ומעבר לתצורה מתקדמת יותר של אימות מודרני (Modern Auth) יצא בספטמבר 2021, ולמעשה מדגיש את ביטול האימות הבסיסי בתאריך הבא: 1 באוקטובר 2022.
באוקטובר 2022 יבוטל אימות בסיסי לכלל הרכיבים/פרוטוקולים הבאים:
Exchange Web Services (EWS)
Exchange ActiveSync (EAS)
POP
IMAP
Remote PowerShell
MAPI
RPC
OAB
הזדהות מול SMTP תמשיך לעבוד כרגיל ולכן SMTP Auth אינו יושפע מהתהליך הנ”ל.
ישנה אפשרות להימע מביטול אימות הבסיסי או להיעזר בכלי ייעודי לטובת ביצוע Opt Out שימנע ביטול אימות בסיסי בפרק הזמן עד אוקטובר, ולכן, במידה ותופיע הודעה במהלך החודשים הקרובים שתודיע שתהיה השבתה של אימות בסיסי בטננט בגלל אי שימוש, או לחלופין, תהיה נוטיפקציה שישנו שימוש באימות בסיסי אך עדיין תתבצע השבתה, או תהיה כוונה להשבית את האימות לפרק זמן קצר.
במצב כזה אנו יכולים למנוע את הביטול עד אוקטובר 2022 ע”י כלי דיגאנוסטיקה ובקשה לביצוע Opt Out לפרוטוקל מסוים, אחד בכל הרצה.
קישור לכלי Exchange Online Self-Service Tool. במידה ומריצים Run Tests תתבצע בדיקה ודיאגנוסטיקה של שימוש בפרוטוקולים לאותו טננט, ולאחר מכן תוצאה של האם ישנו שימוש בפרוטוקולים אלה, והאם אנו רוצים לבצע Opt Out לאחד הפרוטוקולים.
האפשרות של Opt Out תהיה זמינה עד ספטמבר 2022 בלבד
ניתוח פעילות
הכנה ומעבר אל Modern Authentication נעשית במספר שלבים, בין היתר לפי הנקודות הבאות:
- מיפוי Basic Authentication והוצאת סטטוס ודוחות
- הפעלת Modern Authentication
- ניתוב והעברת אפליקציות שתומכות Modern Authentication
- אכיפת מדיניות ותנאים לאפליקציות מבוססות Basic Authentication
- חסימה של אימות בסיסי ובדיקה מול כלי Diagnostic
טיפ: ישנם אפליקציות ומערכות בשירות Office 365 שמושפעות מהשינוי של Exchange Online, ולכן גם מערכות אלה מצריכות שינוי בשיטת הזדהות
מיפוי Basic Authentication והוצאת סטטוס ודוחות
בשלב ראשון ואולי החשוב מכולם הוא לבצע מיפוי של הסביבה ולהבין בין היתר את הנקודות הבאות:
- איך מתחברים אל Exchange Online
- באמצעות איזה אפליקציות מתחברים
- האם מדובר על אפליקציות שתומכות בשיטת Modern Authentication
- האם מדובר על אפליקציות מקוסטמות ללא בעלים
- האם ישנם מכשירים חכמים עם מערכות הפעלה ישנות
- האם ביטול Basic Authentication יגרום לבעיות באפליקציות מסוימות
- השפעות של שינוי שיטת הזדהות לאפליקציות שאינן תומכות בשיטת Modern Authentication
- האם ישנם השלכות נוספות בביטול Basic Authentication
- האם מערכות נוספות בשירות Office 365 יושפעו מתוך ביטול Basic Authentication
טיפ: במידה וסביבת Exchange Online מוגדרת עם Modern Authentication עדיין צריך לבצע בדיקות לכלל האפליקציות והחיבורים בארגון
על הדוחות עוברים בכל שלב ובכל פרק זמן מסוים ובמיוחד לאחר שינויים שמבצעים מול משתמשים.
ישנם דרכים רבות ומגוונות לנתח, לבדוק ולנטר פעילות ושימוש באימות בסיסי, החל מהכלים הבסיסיים כמו Audit Log ועד מערכות מתקדמות כמו Azure Sentienl.
חלק מהכלים והמערכות המובאים במאמר מותאמים לרישוי בסיסי, חלקם ברישוי מתקדם ואחרים על סמך מערכות מתקדמות
דוחות כלליים בממשק Microsoft 365
בממשק אדמין Microsoft 365 ניתן לקבל נראות ראשונית של אפליקציות שמתחברות אל שירות Exchange Online, החל מגרסאות, התחברויות אל שירות Exchange Online, כמות חיבורים, וכן משתמשים.
בנוסף לכך ישנה טבלה של התחברויות לפי משתמשים, פעילות וגרסאות ואת הנתונים האלה ניתן לייצא לטבל אקסל לפי כלל המשתמשים ולפי פעילות RPC.
היתרון בממשק אדמין Microsoft 365 הוא שניתן לקבל נראות ראשונית ואף לייצא את הנתונים ולנתח בקובץ אקסל, וגם כאן, הניתוח לא יהיה גרנולרי כמו בכלים המתקדמים.
חיפוש בממשק Audit Log
בממשק Audit Log (מתוך Microsoft 365 compliance) מאפשר לחפש ולמצוא פעילות בשירות Exchange Online, ובין היתר את הפעולות הבאות של מי התחבר לשירות Exchange Online, מהו סוג החיבור, באיזה אפליקציה התחברו לשירות ונתונים נוספים. השדה שיכול לסייע הוא בין היתר שדה ClientInfoString.
בכדי למצוא פעילויות מול שירות Exchange Online יש לבחור בפילטר פעילות של יצירת או גישה מול Exchange Online.
למרות שניתן לייצא את כל הפעולות לקובץ אקסל, עדיין ישנו חסרון מהותי בממשק Audit log והוא אי היכולת לבצע חיפושים גרנולרים ובמיוחד חיפוש מול פרוטוקולים מסוימים.
מידע נוסף לגבי המאפיינים ושדות בחיפוש Audit log בקישור הבא Detailed properties in the audit log.
דוחות PowerShell
ניתן להיעזר בממשק PowerShell בכדי להוציא דוחות שונים של אימות בסיסי. כלי חזק שמבוסס PowerShell ויכול לספק דוחות לגבי אימות בסיסי (והרבה מעבר) Ms365UsageReport.
אפשרויות נוספות להוציא דוחות ולדעת מהו הסטטוס כמו Microsoft Cloud App Security או Microsoft Graph API וכן PowerShell עם הסקריפט הבא להוצאת נתונים לגבי מכשירים שמתחברים אל שירות Exchange Online
Get-MobileDevice -RestApi -ResultSize Unlimited | select UserDisplayName,@{n=”User”;e={$_.DistinguishedName.Split(“,”)[2..10] -join “,”}},DeviceType,FirstSyncTime,DeviceAccessState*,ClientType
מיפוי באמצעות Azure AD
בממשק Azure AD האפשרויות מתקדמות יותר ומאפשרות נראות טובה יותר בכל החיבור של משתמשים אל AzureAD והרכיבים והאפליקציות שעושות בו שימוש כמו זה של Exchange Online, ולכן ניתן להוציא נתונים מקוסטמים ומדויקים.
דוחות מתוך Azure AD Workbook
בממשק Azure AD ישנה קטגוריה ייעודית לדוחות וליתר דיוק Workbook. הדוחות נתונים מתקדמים ואפשרויות חיתוך שונות וע”י כך מאפשרים לבצע מעקב פשוט אחר משתמשים ואפליקציות והדרך שבה הם מתחברים לשירות Exchange Online.
ניתן להכין דוח מקוסטם בקלילות אך ישנו דוח מובנה שמכיל את המידע לגבי התחברות מבוססת Legacy Authentication, והדוח נקרא Sign-ins using Legacy Authentication.
היתרון העצום של Azure AD Workbook הוא הפלקסביליות של הדוח עם אפשרויות מיקוד ברמת הבורג על כל אפליקציה, משתמש וכל חיבור ספציפי.
ניטור באמצעות MCAS
כלי מצוין שנותן נראות ברמת הבורג מול מקורות המידע שמחוברים אליו הוא Cloud App Security. מתוך Activity Log ניתן להוציא מידע לגבי התחברויות Legacy על סמך פילטרים שונים לפי אפליקציה, סוג חיבור, סוג התחברות וכן הלאה.
היתרון העצום של Microsoft Cloud App Security הוא האפשרויות נראות, חיפוש והוצאת נתונים מדויקים ברמת הממשק וכן הוצאת הנתונים לקובץ אקסל במידת הצורך.
מיפוי, תנועה וניטור באמצעות Azure Sentinel
התשתית המועדפת עליי היא Azure Sentinel שם אפשר להתפרע ולהוציא מידע ונתונים ברמת הבורג, לבצע מעקב אחר התחברויות, לנטר פעילות של Legacy Authentication וכל מה שעולה בדימיון.
האפשרויות של Azure Sentinel הם כמובן על סמך כתיבה בקוסטו (KQL) ולכן אין לנו מגבלה, שאילתה שיכולה לסייע היא
שאילתות להוצאת נתונים שמבצעים אימות בסיסי Sign-ins using Legacy Auth , ExchangeOnlineLegacyAuth
דוח בממשק OKTA
למי שעובד עם OKTA ינשה אפשרות להוציא מידע מתוך הממשק של OKTA לגבי אימות בסיסי
שאילתה מתוך Reports ומתוך System Log
debugContext.debugData.requestUri eq “/app/office365/{office365 App ID}/sso/wsfed/active
לחיפוש התחברויות כושלות
eventType eq “user.session.start” and outcome.result eq “FAILURE” and debugContext.debugData.requestUri eq “/app/office365/{office365 App ID}/sso/wsfed/active”
למגרץ לאימות מודרני
האפשרויות למיגרציה לאימות מודרני הם פשוטות ואף קלות למכביר ויכולות להתבצע מתוך ממשק אדמין או ממשק PowerShell.
הפעלת Modern Authentication
לאחר המיפוי ניתן להתחיל בתהליך ולהפעיל Modern Authentication, וחשוב מאוד להדגיש כי הפעלה של Modern Authentication (כולל Seamless SSO) אינה פוגעת בשום דרך בחיבור של הזדהות מבוססת Basic Authentication, ושתי השיטות יכולות לפעול במקביל.
איך מפעילים Modern Authentication? ישנם מספר דרכים להפעלת Modern Authentication והעיקריות שבהן הם באמצעות PowerShell או האפשרויות החדשות במשק Microsoft 365 כולל איכפת פוליסי.
טיפ: במידה והטננט הוקם לאחר תאריך אוגוסט 2017 אז Modern Authentication מופעל בשירות Exchange Online
הפעלה של Modern Authentication מתוך PowerShell נעשית באמצעות הפקודות הבאות:
בדיקת מצב קיים
Get-OrganizationConfig | Format-Table Name,OAuth* -Auto
הפעלת Modern Authentication
Set-OrganizationConfig -OAuth2ClientProfileEnabled $true
דרך נוספת להפעיל Modern Authentication היא מתוך ממשק Microsoft 365 אדמין
טיפ: מומלץ להפעיל Modern Authentication פוליסי במצבים מסוימים וזאת במידה ועובדים עם Basic Authentication
כאשר עוברים אל שירות מסוים של Microsoft 365 לתצורת Modern AUthentication מומלץ מאוד להעביר את יתר הרכיבים בשירות גם אל Modern Authentication וזאת למוע בעיות של חוסר אחידות במעבר בין הרכיבים, למשל SharePoint Online.
ברכיב SharePoint Online ניתן לבטל תצורת Legacy עם הפקודה הבאה
Set-SPOTenant –LegacyAuthProtocolsEnabled $false
טיפ: לפני שמפעילים Modern Authentication לרכיבי ענן אחרים מומלץ לוודא תאימות של משתמשי קצה ואפליקציות
לאחר הפעלה Modern Authentication ברמת Microsoft 365 צריך להשלים את ההגדרות גם ברמת Azure AD Connect לפי התהליך במאמר המצורף של הגדרת Configure Azure AD Seamless SSO.
ניתוב והעברת אפליקציות שתומכות Modern Authentication
לאחר המיפוי והפעלה של Modern Authentication בשירות Microsoft 365 מגיעים השלבים המורכבים יותר והוא להחליף את האפליקציות ואת אופן הגישה של מערכות מתוך Basic Authentication אל התצורה של Modern Authentication.
במצב כזה אנו מחלקים את השלבים לפי המיפוי, לדוגמה:
מערכות אשר תומכות בתצורת Modern Authentication אך עדיין עובדות Basic Authentication, למשל Office 2016 או Office 2013 – השלב הכי קל בו מבצעים עדכון ברמת Office או מוסיפים ערכי רישום (Registry) והגישה של המשתמש באופן אוטומטי הופכת להיות Modern Authentication.
אפליקציות שאינן תומכות כלל בתצורת Modern Authentication וניתן להעביר אותן אל Modern Authentication – שלב עדיין פשוט שבו לוקחים אפליקציה מסוימת שניגשת עם POP3 ומשנים אותה למצב Modern Authentication או לחלופין מנתבים אותה למצב של תמיכה של OAuth2. למאמר Authenticate an IMAP, POP or SMTP connection using OAuth
אפליקציות מקוסטומות שמצריכות שכתוב קוד מחדש, למשל אפליקציות שניגשות אל EWS לפי שם משתמש וסיסמה בלבד. המצב הקשה מבין השלושה ובמצב כזה צריך תשומות פיתוח בכדי לשנות את המצב שבו ניגשת האפליקציה אל Exchange Online.
סגירת Basic Auth
בשלב הרביעי אנו נמצאים במצב שבו הפעלנו Modern Authentiation ויש לנו את התמונה הכללית והמפורטת של האפליקציות שניתן להנגיש עם Modern Authentication ואפליקציות שמצריכות שכתוב.
בנוסף לכך, אנו נמצאים במצב שבו אנו יכולים להגדיר תנאים מבוססים Azure AD Conditional Access, או להחיל מדיניות מבוססת Authentication Policy לשירות Exchange Online וכן הלאה.
הגדרת תנאי לחסימת Legacy Authentication
דוגמה לביצוע חסימה של Legacy Authentication מול משתמשי קצה לאפליקציה מסוימת או לכלל האפליקציות.
לאחר שבוצעו בדיקות לגבי אפליקציות ומשתמשים שניגשים בתצורת Basic Authentication בממשקים השונים נוודא שאין מכונות, אפליקציות והתקנים מתוך הרשימה הבאה:
- גרסאות Office 2010
- גרסאות Office 2013 ללא ערך EnableADAL
- מכשירים חכמים ללא אפליקציות מייל Native
- התקני MAC בגרסאות Office 2013 ומטה (כולל Office 2013)
- אפליקציות מבוססות IMAP או POP3
בכדי להגדיר תנאי אשר חוסם Basic Authentication בממשק Azure AD Conditional Access יש לבצע את הפעולות הבאות:
בממשק Azure ניגש אל Conditions ונבחר באפשרות Client Apps, לאחר מכן נבחר באפשרויות הבאות:
טיפ: כמו בכל תנאי מומלץ לבצע על תנאי שאינו שייך לסביבת הייצור, וכן לשים את התנאי במצב Monitor לניטור התנאי
הפעלת Authentication Policy היא דרך נוספת המאפשרת לאנבל או לדסבל את הגישה של Basic Authentication אך היא משפיעה על כלל השירות ולכן מומלץ רק במצבים שבהם אין יותר גישה של אפליקציות ומשתמשי קצה בתצורת Basic Authentication.
תובנות
המעבר מתוך אימות בסיסי אל אימות מודרני נחלק למספר שלבים כאשר שלב היישום של סגירה Legacy Auth היא פשוה מאוד, ולכן כדאי מאוד להתעכב בשלב המיפוי והוצאת הנתונים מתוך הממשקים השונים. שלב הוצאת הנתונים הוא קריטיט בגלל שאנו מסתמכים עליו בשלבים שלאחר מכן, ובפרט סגירת אימות בסיסי.
במעבר אל אימות מודרני וחיסמת אימות בסיסי ישנם מקרי קצה, פערים ובעיות שונות, בין אם מדובר על ארגון בינוני, ארגון Enterprise או ארגוני ענק. הבעיות משתנות בין כל ארגון וארגון, למשל:
אפליקציות ללא בעלים היא הבעיה החמורה ביותר ואפליקציות שמתחברות עם אימות בסיסי מצריכות כתיבה ושינוי בקוד, ולכן במצב כזה אנו יכולים להיות “תקועים” זמן רב עם אותה אפליקציה. במצב כזה מומלץ להתקדם עם התהליך לצד בדיקת סטטוס מול אותה אפליקציה בעייתית.
גרסאות אופיס ישנות הם בעיה קריטית בארגונים גדולים אך עלולה להיות בעיה כזאת גם בארגונים פחות גדולים, שכן, אנו נדרשים לבצע פריסה של גרסת אופיס חדשה ושם ההשלכות הם של שינוי ממשק בחווית המשתמש וכן התאמת גרסת אופיס לאפליקציות אשר רוכבות על גבי אופיס.
במידה ומדובר רק על שדרוג גרסת אופיס אזה הבעיה פחות מורכבת ומצריכה בעיקר תקשור מול המשתמשים.
כלים להוצאת מיפוי וסטטוס של מצב קיים הם חלק חשוב בתהליך ומומלץ לעבוד לפחות עם הממשק של Azure AD ולהוציא את הנתונים בצורה קריאה.
שאלות ותשובות
איך אפשר לדעת מי מתחבר עם אימות בסיסי? באמצעות הכלים השונים שהוזכרו קודם לכן
האם תהיה אפשרות להארכה של תוקף ביטול האימות? לא תהיה אפשרות, ולכן התאריך האחרון הוא אוקטובר 2022
האם אימות מודרני (Modern Auth) יושפע מהתהליך? לא, אימות מודרני ממשיך לעבוד ללא שינוי
האם תהיה אפשרות לעבוד עם אימות בסיסי למשתמשים מסוימים? לא, אימות בסיסי ידוסבל ברמת Service
האם אני צריך להפעיל MFA בכדי לעבור מאימות בסיסי? לא, במקרה הזה אין קשר מול MFA
מהפ גרסאות אופיס ואפליקציות דואר שתומכות באימות מודרני? בין היתר האפליקציות הבאות
Outlook 2013 or later (Outlook 2013 requires a registry key change)
Outlook 2016 for Mac or later
Outlook for iOS and Android
Mail for iOS 11.3.1 or later
קישורים נבחרים
Audit logs in Azure Active Directory
חסימת Legacy Authentication באמצעות Azure AD
Basic Authentication and Exchange Online – September 2021 Update
