הבנת שגיאת AADSTS90002 – Tenant Not Found

By Mirko Peters · 2026-04-20

אם אתם רואים את השגיאה AADSTS90002, היא בעצם הדרך של Microsoft לומר: "היי, אני לא מוצא את הדייר שלכם!" השגיאה מופיעה בעיקר בסביבות Microsoft 365, Azure Active Directory או Entra ID כשמנסים להתחבר או לחבר שירות, אבל הדייר לא נמצא. במילים פשוטות: המערכת לא מוצאת שום דייר שתואם לפרטים שסיפקתם לה.

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

אם אתם רואים את השגיאה AADSTS90002, היא בעצם הדרך של Microsoft לומר: "היי, אני לא מוצא את הדייר שלכם!" השגיאה מופיעה בעיקר בסביבות Microsoft 365, Azure Active Directory או Entra ID כשמנסים להתחבר או לחבר שירות, אבל הדייר לא נמצא. במילים פשוטות: המערכת לא מוצאת שום דייר שתואם לפרטים שסיפקתם לה.

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

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

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

כך מתקנים את שגיאת AADSTS90002 שלב אחר שלב

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

לאחר מכן, ודאו שהדייר קיים בפועל ופעיל. לפעמים דיירים נמחקים, מושעים, או שהמנוי המשויך אליהם מתיישן. היכנסו למרכז הניהול של Microsoft, או בקשו מהמנהל ה-IT לעשות זאת, ובדקו את סטטוס הדייר, המנויים הפעילים ואם הרישיון שלכם עדיין בתוקף. זה בדרך כלל הרגע שבו מישהו מבין: "אה, הדייר הזה בוטל ברבעון שעבר!"

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

אוטומציות, Service Principals וצינורות CI/CD יכולים לגרום גם הם לשגיאה הזו. אם הסקריפטים או האפליקציות שלכם מתחילים פתאום להיכשל, ודאו שאישורי ה-Service Principal שלכם לא פגו או בוטלו. זה נפוץ: חידוש שנשכח או רישום שנמחק מפעילים כשל בחיפוש הדייר בזרימות עבודה לא אינטראקטיביות.

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

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

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

שאלות נפוצות ותשובות בנושא בעיות Tenant Not Found

אם אי פעם תהיתם מה פשרה של השגיאה AADSTS90002, אתם לא לבד. אנשים שואלים הרבה, במיוחד כשהדייר "אמור" להתקיים, אבל Microsoft ממשיכה להודיע אחרת. בואו נעבור על השאלות והחששות הנפוצים ביותר לגבי השגיאה הידועה הזו.

קודם כל: "למה אני רואה 'Tenant Not Found' כשאני יודע שהדייר שלי קיים?" בדרך כלל הסיבה נעוצה בפרטים קטנים, כמו שימוש בשם דומיין ישן או עם שגיאת הקלדה, אי התאמה באזור, או הגדרות מטמון בדפדפן או באפליקציה. לפעמים ה-DNS לוקח זמן להתעדכן לאחר שינויים בדייר. תמיד בדקו שוב את פרטי הכניסה, ונסו לנקות את המטמון או את ה-DNS לפני שמתעסקים בבעיות הגדולות.

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

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

למי שמפעיל אוטומציות או עובד עם CI/CD, סודות לקוח שפג תוקפם או הרשאות של service principal שבוטלו הם אשמים נפוצים. כדאי להפוך להרגל ביקורת קבועה של ה-service principals, חידוש אישורים לפני שפגו, ושמירת יומנים (logs) בהישג יד כדי לזהות במהירות כשלונות בזיהוי הדייר.

אל תשכחו גם מתקלות ברשת. בעיות DNS ופרוקסי, או כללי חומת אש נוקשים החוסמים את נקודות הקצה של זיהוי של Microsoft, יכולים לחקות שגיאת "tenant not found". אם השגיאה הזו מופיעה פתאום, בדקו תמיד עם צוות ה-IT אם בוצעו לאחרונה שינויים ברשת.