AADSTS50079 – הסבר: המשמעות והשפעתה בענן של Microsoft

By Mirko Peters · 2026-04-20

אם ניסיתם פעם להתחבר ל-Microsoft 365 או ל-Entra ID ופתאום נתקלתם בחסימה עם הודעה על “AADSTS50079”, אתם לא לבד. השגיאה הזו…

Automatically translated with AI from the original post. Read the English original

Cover: Fix Conditional Access Loopholes in Microsoft 365

אם ניסיתם פעם להתחבר ל-Microsoft 365 או ל-Entra ID ופתאום נתקלתם בחסימה עם הודעה על “AADSTS50079”, אתם לא לבד. השגיאה הזו מופיעה כאשר ההתחברות שלכם דורשת אימות מרובה גורמים (MFA), אבל משהו חסר – בדרך כלל, לא נרשמתם לאימות, או שהמערכת לא מצליחה לבקש ממכם אותו כראוי.

בעולם הענן של Microsoft, קודי AADSTS הם הרבה יותר ממספרים אקראיים – הם מסבירים בדיוק מדוע הגישה נחסמה. AADSTS50079 מתריע במיוחד שתהליך האימות נעצר משום שפרטי ההזדהות לבדם כבר אינם מספיקים. עם הידוק האבטחה שמתרחש בארגונים רבים, במיוחד עם מדיניות גישה מותנית ודרישות MFA מוגברות, השגיאה הזו מופיעה בכל מקום.

למשתמשים, פגיעה ב-AADSTS50079 פירושה שלא ניתן להיכנס עד שמבצעים שלבי אבטחה מסוימים. לצוותי IT ותמיכה, מדובר באחת הסיבות הנפוצות ביותר לפניות למוקד התמיכה. הבנה של משמעות הקוד ושל הסיבות להופעתו היא המפתח לתיקון מהיר – ולמניעת בעיות גדולות יותר בהמשך.

שורשי השגיאה AADSTS50079 ב-Microsoft 365 וב-Entra ID

תהיתם פעם מדוע נדמה ששגיאות אימות תמיד מופיעות ברגע הכי לא מתאים? AADSTS50079 היא תוצאה ישירה של הדחף לחיזוק הגנת הזהויות בפלטפורמות כמו Microsoft 365 ו-Entra ID. הסביבות האלה נשענות במידה רבה על כללים השולטים במי נכנס ואיך – בעיקר באמצעות Conditional Access ודרישות MFA.

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

השגיאה הזו משבשת גם התחברויות אינטראקטיביות (שבהן המשתמש פועל ישירות) וגם תהליכים ברקע (לא-אינטראקטיביים). ככל שארגונים מתמודדים עם יותר אוטומציה, שילובי אפליקציות ועבודה מרחוק, היא הפכה לנושא מרכזי בקו הראשון. למי שרוצה להעמיק בצד האבטחה, הדיונים על פערי אמון במדיניות Conditional Access ועל התפשטות מדיניות הזהויות ב-Entra ID ייתנו תמונה ברורה לגבי הסיבות להופעת השגיאות – זה לא מקרי, אלא תוצאה של שכבות כללי אימות ופערים מסוימים במוכנות המשתמשים.

בחלקים הבאים נראה בדיוק כיצד דרישות האבטחה האלה מפעילות את שגיאה 50079, ומדוע גם משתמשי קצה וגם אנשי IT ממשיכים להיתקל בה שוב ושוב.

כיצד מדיניות Conditional Access ו-MFA מובילים ל-AADSTS50079

מדיניות Conditional Access ב-Azure Active Directory (כיום Entra ID) פועלת כמו שומרי הסף במועדון – היא בודקת שהחשבון שלכם עומד בכל כללי הכניסה לפני שהיא מאפשרת גישה לאפליקציות. כאשר המדיניות דורשת MFA ואתם עדיין לא נרשמתם, AADSTS50079 נכנסת לתמונה ועוצרת את ההתחברות. זו לא תקלה; זו הדרך של הארגון להבטיח שרק מי שעומד בכללים יקבל גישה.

השגיאה הזו לא מופיעה רק משום ששכחתם להגדיר MFA יום אחד. היא בדרך כלל מופיעה כאשר מדיניות חדשה נכנסת לתוקף או מחמירה, והחשבון שלכם טרם עודכן. גם אם אתם מתחברים מאפליקציה או ממכשיר שנחשבים "מהימנים", אכיפת המדיניות עוצרת את התהליך ברגע שפרטי ההזדהות שלכם אינם תואמים לדרישות. חשבו על זה כשרשרת: אם חוליה אחת חלשה – רישום חסר, גורמי אימות שאינם מסונכרנים או מדיניות שהוחלה לאחרונה – AADSTS50079 מופיעה.

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

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

פערים ברישום משתמשים וכשלי התחברות לא אינטראקטיביים

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

זה נפוץ במיוחד בתרחישים "לא אינטראקטיביים", כמו סקריפט PowerShell או מחבר SaaS של צד שלישי שמנסה בשקט לרענן אסימון. בלי מישהו שיסיים את הגדרת ה-MFA או יענה להנחיות, האימות נכשל עם שגיאת רישום 50079. תוכלו לזהות את הבעיות האלה על ידי חיפוש כשלי התחברות חוזרים ביומני האבטחה או יומני הכניסה, לרוב תחת זהויות של "service principal" או אפליקציות שנפלו בין הכיסאות.

שלבי פתרון ל-AADSTS50079: פתרונות למשתמשים ולמנהלים

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

למשתמשים רגילים, המפתח הוא להשלים את הרישום לאימות רב-שלבי (MFA). בדרך כלל זה אומר פשוט לעקוב אחר ההנחיות כדי להגדיר את אפליקציית האימות, לאשר התראות או לרשום את הטלפון. עם זאת, מכשולים בפתרון בעיות, כמו בעיות במכשיר או תקלות בשליחת דואר אלקטרוני, יכולים להכשיל אנשים, ולכן הנחיות ברורות וידידותיות עושות הבדל גדול בהחזרת כולם לפעילות במהירות.

מנגד, למנהלים יש ארגז כלים רחב יותר. מעבר לאיפוס חשבונות והדרכת משתמשים בתהליך ה-MFA, מנהלים אחראים לבחון את תכנון מדיניות הגישה המותנית, לתקן כללים שהוחלו בצורה שגויה ולוודא שדרישות הרישום מתאימות לתהליך העבודה בארגון. באוטומציה ובאפליקציות, לעיתים צריך לעבור מהתחברות מבוססת משתמש לעבר זהויות מנוהלות (managed identities) או אימות מבוסס תעודות, כחלופות אמינות יותר. אם זה מוכר לכם, הצטרפו לדיונים על ממשל גישה מותנית ב-Entra ID כדי לקבל גישות אסטרטגיות יותר.

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

מדריך שלב אחר שלב למשתמשי קצה לתיקון AADSTS50079

השלימו את הרישום לאימות רב-שלבי (MFA).

כשמופיעה שגיאת 50079, לרוב תקבלו הוראות או קישור. לחצו עליו כדי להתחיל את תהליך הרישום ל-MFA.
בדרך כלל זה אומר להוסיף את אפליקציית Microsoft Authenticator לטלפון שלכם, לרשום את מספר הנייד שלכם, או לבצע את שני הדברים.

בצעו את תהליך רישום המכשיר.

הורידו את אפליקציית Microsoft Authenticator מחנות האפליקציות, אם עדיין לא עשיתם זאת.
התחברו עם חשבון העבודה או הלימודים שלכם וסרקו את קוד ה-QR שמציגה דף הרישום.
אם סריקת ה-QR נכשלת, נסו להקליד את הקוד ידנית.

אשרו את הנחיית האבטחה הראשונית.

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

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

לאחר סיום ההגדרה, לרוב תקבלו הודעה בסגנון "Enrolled Successfully". חזרו לאפליקציה או לפורטל והתחברו שוב.
אם תתבקשו לאימות מרובה גורמים (MFA) במהלך ההתחברות, אשרו זאת במכשיר הרשום שלכם. זה מאשר שההגדרה בוצעה כנדרש.

פתרון תקלות נפוצות.

אם התראות הדחיפה אינן מגיעות, בדקו את החיבור לאינטרנט במכשיר, את הגדרות ההתראות, ושהחשבון הנכון מחובר.
נתקעתם? נסו להסיר ולהוסיף מחדש את החשבון באפליקציית Authenticator, או פנו לצוות ה-IT לאיפוס או לעזרה בתקלות במכשיר.
אם השתמשתם ב-SMS ושיניתם מספר טלפון, יש ליידע את מנהל המערכת. הוא יוכל לאפס את שיטות האימות שלכם כדי להתחיל מחדש.

רוב המשתמשים מסיימים את הגדרת MFA תוך דקות ספורות. אם נתקלתם בקשיים, אין צורך להיבהל. פתרונות נפוצים כוללים הפעלה מחדש של המכשיר, התקנה מחדש של האפליקציה, או בקשה לאיפוס מצד מנהל המערכת. בין אם אתם עובדים ב-Windows, ב-Mac או במכשיר נייד, העיקר הוא להשלים את רישום שיטת ה-MFA ולאמת אותה.

פעולות ניהול למעקב אחר מדיניות גישה מותנית וציות ל-MFA

בדקו את מדיניות הגישה המותנית הפעילה.

היכנסו למרכז הניהול של Azure AD או Entra ID ובדקו אילו מדיניות דורשות MFA, ועבור מי.
שימו לב למדיניות שחלה על "All users" או על קבוצות מסוימות, שעלולה לכלול בטעות חשבונות שירות או לשבש אוטומציות.

בצעו ביקורת על רישום ה-MFA של המשתמשים.

השתמשו בדוחות של Azure AD כדי לראות אילו חשבונות טרם השלימו MFA. שקלו לשלוח תזכורות או לאכוף רישום במהלך ההתחברות.
בכשלים חוזרים, בדקו אם יש צורך לעדכן אימות מדור קודם או חשבונות שהוחרגו.

התאימו את היעד וההחרגות של המדיניות לפי הצורך.

אם אוטומציות או Service Principals נכשלים עם AADSTS50079, שקלו להחריג חשבונות שירות ידועים מהגישה המותנית. עדיף עוד להעביר אותם ל-Managed Identities או לאימות מבוסס תעודות.
שמרו על חברויות קבוצה מסודרות, כדי לוודא שהמדיניות חלה רק על המשתמשים המיועדים.

ליוו את המשתמשים בתהליך איפוס או שחזור של MFA.

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

עקבו אחר האפקטיביות של המדיניות ועדכנו אותה ככל שהארגון גדל.

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

שמרו על אבטחה של מחברי Power Platform ועל פיתוח על ידי משתמשים עסקיים.

ב-Power Automate ובכלים דומים, ודאו שהמחברים רשומים ושהם משתמשים באימות מאובטח, ולא רק בדוא"ל וסיסמה ישירים.
לקבלת הדרכה נוספת, עיינו במשאבי ממשל אבטחה של Power Platform, אם אתם תומכים במשתמשים עסקיים המשלבים עם Microsoft 365.

מנהלים שמשלבים תקשורת ברורה, היגיינה במדיניות ושימוש אסטרטגי באימות מודרני, בדרך כלל ימנעו מ-AADSTS50079 להפוך לכאב ראש יומיומי.

השוואה בין AADSTS50079 לשגיאות AADSTS נפוצות אחרות

AADSTS50079 (המשתמש/השירות דורש רישום ל-MFA)

שגיאה זו מופיעה כאשר ההתחברות נחסמת מכיוון שהחשבון חייב להשלים אימות מרובה גורמים (MFA), והמשתמש טרם נרשם.
השגיאה נפוצה ביותר לאחר שינויים במדיניות MFA או כאשר משתמשים עוברים להגנה מחמירה יותר.

AADSTS500212 (חשבון המשתמש נעול או מושבת)

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

AADSTS530032 (הגישה המותנית - נחסם על ידי מדיניות)

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

AADSTS50173 (הסיסמה פגה, נדרש שינוי)

שגיאה זו מופיעה כאשר תוקף הסיסמה של המשתמש פג או שיש לשנותה לפי מדיניות הספרייה. היא אינה קשורה ל-MFA, ולכן יש לאפס את הסיסמה כדי לפתור אותה.

AADSTS530004 (דרישת חוזק אימות לא התקיימה)

קוד זה מופיע כאשר מדיניות גישה מותנית דורשת אימות חזק יותר מזה שהמשתמש סיפק. יש לשדרג את ה-MFA או להשתמש בשיטה תואמת כדי לעקוף את השגיאה.

הצבת הקודים האלה זה לצד זה עוזרת לצמצם את תהליך פתרון הבעיות. אם השגיאה קשורה להגדרת MFA, סביר להניח ש-AADSTS50079 היא הגורם. במקרים של חסימה מוחלטת, סיסמאות שפגו או בעיות "חוזק מדיניות", הקודים האחרים הם הרמזים הטובים ביותר לפתרון מהיר.

תכנון מדיניות למניעת AADSTS50079 ב-Entra ID

מניעה תמיד עדיפה על מרוץ לתיקונים אחרי השבתה. כדי למנוע מ-AADSTS50079 לתפוס מקום מרכזי, צריך לתכנן מ-ההתחלה מדיניות Conditional Access ומדיניות אימות שמתאימות לצרכי כוח האדם וה-automation שלכם. זה לא אומר פשוט "לאכוף MFA בכל מקום". זה אומר לדעת אילו משתמשים, אפליקציות ורשתות באמת צריכים שלבים נוספים, ולאפשר גישה חלקה למיקומים או לשירותים מהימנים שדורשים אמינות.

פריסות Entra ID מודרניות מאפשרות להגדיר מדיניות על בסיס מיקומים מוגדרים (כתובות IP מהימנות), עמידה של מכשירים בדרישות וניקוד סיכון. בסביבות הטובות ביותר עוקבים באופן רציף אחר פעילות כניסה, ומשתמשים בתובנות כדי לסגור פערים לפני שמשתמשים מתוסכלים יציפו את קווי התמיכה. שאיבת השראה ממקורות כמו ניהול מחזור החיים של Conditional Access ושיטות עבודה מומלצות לאמון במדיניות עוזרת לארגונים להישאר צעד לפני חוב הזהות – אותם חריגים קטנים והגדרות מדור קודם שבסופו של דבר הופכים לכאבי ראש גדולים בהרבה.

בסעיפים הבאים תראו בדיוק איך לכוונן רשתות מהימנות, להגדיר הגדרות CA ולהשתמש בניטור כניסות כדי לוודא ש"נגיש" לא פירושו "לא מאובטח". תשומת לב מוקדמת תבטיח ש-AADSTS50079 יהפוך לטרדה נדירה ולא לחירום יומיומי.

הגדרת Conditional Access וכתובות IP מהימנות

הגדרת מיקומים מוגדרים:
הגדירו טווחי כתובות IP מהימנים למשרדי תאגיד מוכרים או ל-VPN בתוך Azure AD. ניתן להשתמש במיקומים אלה כדי לאפשר גישה חלקה בלי לבקש מכל משתמש MFA.
החילו מדיניות כוללנית ולא מצמצמת:
תכננו כללי Conditional Access שמכסים את כולם כברירת מחדל, ומאפשרים רק חריגים מוגבלים בזמן במקום החרגות רחבות מדי. גישה זו מצמצמת פערים ונעילות לא צפויות. לקריאה מפורטת ראו מקור זה על כוללנות מדיניות.
דרשו MFA רק עבור הכניסות המסוכנות ביותר:
במקום לאכוף MFA על כל כניסה, דרשו אותו ממשתמשים שנמצאים מחוץ למיקומים מהימנים או ממשתמשים שסומנו על ידי זיהוי סיכונים (למשל מיקומים לא מוכרים או התנהגות חשודה).
בדקו, נטרו וכווננו:
לפני הפריסה המלאה, בדקו את כללי ה-CA עם קבוצות קטנות, ואז נטרו את דפוסי הכניסה כדי לזהות חסימות בלתי מכוונות או זינוקים ב-50079. התאימו את הכללים לפי הצורך כדי לשמור על איזון.

מיקוד חכם של Conditional Access עוזר לרוב המשתמשים להימנע מבקשות MFA מיותרות, ומונע מ-AADSTS50079 לשבש את העבודה היומיומית המהימנה.

ביקורת וניטור פעילות כניסה לשגיאה 50079

בדיקת יומני כניסה של Azure AD:
היכנסו לפורטל Azure, עברו ליומני הכניסה של Azure AD וסננו לפי "Status: Failure" וקוד השגיאה "50079". כך תראו את המשתמשים, חשבונות השירות והאפליקציות שהושפעו לאחרונה.
בדיקת דפוסים לאורך זמן:
חפשו זינוקים בשגיאות 50079 לאחר פריסות מדיניות חדשות או שינויים בדירקטוריון – זה עשוי לחשוף צורך בהדרכה, פערים בתהליך ההטמעה או כשלים באוטומציה.
קישור לנתוני מדיניות Conditional Access:
כל רשומת יומן כניסה מציגה איזו מדיניות CA חסמה את הגישה. בדקו את הכרטיסייה "Conditional Access" כדי לאתר את אכיפת הכללים ולהתאים אותם לפי הצורך.
שימוש בכלי ביקורת לתובנות מעמיקות:
לקורלציה מתקדמת או לצרכי ציות, שקלו שימוש ב-Microsoft Purview Audit כדי לעקוב אחר פעילות משתמשים ולהצליב אותה עם כשלי כניסה. כך תוכלו לחשוף שורשי בעיות שמעבר לכניסות הבסיסיות.

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