‏Entra ID Attribute Mapping

By Mirko Peters · 2026-04-24 · Updated 2026-07-18

‏איתור תקלות במיפוי מאפיינים ב-Entra ID ופתרון בעיות של ערכים שאינם תואמים, עוגני מקור, היקף סנכרון וסנכרון היברידי של Active Directory.

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

‏מיפוי מאפיינים הוא מה ששומר על הסדר בבית הדיגיטלי שלכם: הוא הדבק שמחבר את האנשים הנכונים למשאבים, למדיניות ולהרשאות הנכונים, בין אם אתם מפעילים Active Directory מקומי, ‏Microsoft Entra ID, או שילוב של השניים. כשמיפויי המאפיינים אינם תקינים, כל השאר נפגע גם כן: משתמשים ננעלים, דוחות ציות הופכים לסיוטי ביקורת, ותהליכי עבודה שלמים נעצרים.

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

‏כשלים נפוצים במיפוי מאפיינים בסנכרון Microsoft Entra ID ו-AD

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

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

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

‏מאפיין הדואר אינו מתעדכן במהלך הסנכרון

1. ‏בדיקת תצורת המחבר
2. ‏אם מאפיין הדואר אינו מסתנכרן, הדבר הראשון שכדאי לבדוק: האם המחברים שלכם פועלים כראוי? ב-AD Connect מקומי חייב להיות מוגדר שמאפיין "mail" נכלל בהיקף הסנכרון של אובייקטי המשתמשים שמעניינים אתכם. אם הוא מסונן החוצה, הענן לעולם לא מקבל את הערך. לכן התחילו בעורך כללי הסנכרון וודאו שהמאפיין "mail" ממופה ומופעל.
3. ‏סינון מאפיינים והיקף
4. ‏לעיתים מישהו הגדיר סינון מאפיינים או כללי היקף מתוך רצון "לשמור על סדר". הבעיה היא שאותם מסננים עלולים לחתוך את הדואר מצינור הסנכרון שלכם. בדקו את כל מסנני ההיקף המותאמים אישית, וטלו את הסינון ממאפייני הדואר הקריטיים לפני שהם נופלים לקורבנות.
5. ‏סדר עדיפויות של מאפיינים וקונפליקטים בין מקורות מרובים
6. ‏אם יש לכם יותר ממערכת אחת במשחק (כמו מערכת משאבי אנוש שמזינה את המידע על המשתמשים ל-AD, או ספריית SaaS אחרת), ייתכן שאתם מתמודדים עם התרחיש הקלאסי של "הכותב האחרון מנצח". Entra ID משתמש בסדר עדיפויות של מאפיינים, ולכן אם מקור אחר טוען לסמכות על הדואר, ערך ה-AD שלכם יתעלם. הגדירו את סדר העדיפויות של מערכות המקור וקבעו כללי קדימות ברורים, כך שהערך הנכון ינצח בכל פעם.
7. ‏שחיתות או שגיאות בכללי מחבר
8. סנכרון שבור של כללים או מחברים שהושבתו חלקית אינם נדירים; הם מופיעים לאחר שדרוגים לא שלמים או הפסקות חשמל פתאומיות. בדקו ב-Synchronization Service Manager את יומני השגיאות ואת השגיאות "stopped-extension-dll-exception" או "attribute-not-flowed" הקשורות לדואר.
9. בעיות במצב האובייקט (מחיקות רכות, סינון, אובייקטים מיושנים)
10. לפעמים האובייקט עצמו נמצא במצב לא תקין: הוא מסונן, נמחק באופן רך או מוכפל. אם אובייקט ה-AD המקומי מסונן לפני הטרנספורמציה, או מסומן כמחוק, השינויים לא ייכתבו ל-Entra ID.

• שלבים לפתרוןפתחו את Synchronization Rules Editor ואמתו את מיפוי תכונת הדואר.
• בדקו סינון תכונות הן בכללים והן בהיקף המחבר.
• אמתו את סדר הקדימות של התכונות בלוגיקת המיפוי שלכם. העבירו את AD לראש הרשימה אם הוא מקור האמת שלכם.
• הפעילו מחדש בדיקות תקינות ובצעו סנכרון דלתא בכפייה כדי לראות אם השינויים עוברים.
• אם שום דבר אחר לא עובד, רעננו ידנית את האובייקט ב-Synchronization Service Manager ובדקו את היומנים.

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

עדכון מאפיינים של Exchange כמו proxyAddresses ו-HiddenFromAddressListEnabled

1. הבנת כיוון זרימת התכונות והסמכותיות
2. בפריסות היברידיות, דעו איזו מערכת היא "מקור האמת" לתכונות הקשורות ל-Exchange, כמו proxyAddresses או HiddenFromAddressListEnabled. אם AD הוא הבעלים של התכונות האלה, אבל כלל מבוסס ענן דורס אותן, תגלו זאת מהר, כי העדכונים לא יגיעו ליעד המיועד.

• כשלי מיפוי נפוצים: proxyAddresses לא מתעדכן: שדה זה דורש טיפול זהיר. פורמט שגוי או תגיות SMTP/IAM חסרות גורמים לשגיאות סנכרון. שימו לב לכתובות לא תקינות, לכפילויות ולהבדלים באותיות רישיות וקטנות, שעלולים לשבש את הסנכרון.
• HiddenFromAddressListEnabled תקוע: דגל זה תלוי בהרחבת הסכמה וביצירת זרימה מפורשת. אם הסכמת AD אינה מורחבת (או שחסרים המיפויים הנכונים), הערכים לא יעברו מ-AD ל-Entra ID או בחזרה.

1. התנגשויות בכללי סנכרון והתאמה אישית
2. כללים מותאמים אישית לפעמים דורסים את ברירות המחדל בדרכים מתחבאות. אם מישהו שינה את המיפויים ב-Synchronization Rules Editor, יצר זרימות מותאמות או שינה את סדר הקדימות, ייתכן שזרימות ה-Exchange המקוריות אבדו. בדקו את כל כללי הסנכרון, במיוחד כאלה שמפנים מחדש או מדכאים תכונות Exchange.
3. דרישות ניהול Exchange היברידי
4. חלק מתכונות Exchange דורשות ניהול משתמשים באמצעות כלי Exchange, גם כאשר כל תיבות הדואר נמצאות בענן. כדי שהתכונות האלה יתעדכנו כראוי, הרחיבו את הסכמת AD באמצעות אשף התצורה ההיברידית של Exchange, ודאו שהניהול מתבצע דרך Exchange shell או ממשק GUI, ולא באמצעות כלי עריכת תכונות AD "גולמיים".

• שלבים והמלצות מומלצותאשרו הרחבות סכמה של Exchange וכללי מחברים עבור כל תכונות ה-Exchange.
• ודאו ש-proxyAddresses בפורמט הנכון (SMTP:primary@domain, smtp:aliases).
• מפו את HiddenFromAddressListEnabled עם סדר הקדימות הנכון ואמתו את כיוון הזרימה.
• תעדו את מודל המקור והיעד שלכם. היו ברורים לגמרי לגבי המקום שבו כל תכונה נמצאת ומנוהלת.
• כששינויים במיפוי נעשים, בדקו קבוצת פיילוט קטנה לפני פריסה לכל המשתמשים.

1. ביקורת יזומה וממשל
2. תעדו את כל השינויים במיפויי תכונות Exchange. כשהם יוצאים מסנכרון, קשה מאוד לאתר את הבעיות האלה. הגדירו בדיקות תקופתיות כדי לזהות סטיות בין AD, Entra ID ו-Exchange Online.

כשל בעדכון המאפיין showInAddressList בספריות יעד

• פערי תמיכה בסכמה: showInAddressList אינו נתמך תמיד במלואו בספריות בענן בלבד; ללא ההרחבות הנכונות, הסנכרון פשוט מדלג על המאפיין. ודאו שגרסאות הסכמה של Entra ID ושל AD המקומי מיושרות ומורחבות לפי הצורך.
• פיקוח על תצורת המיפוי: לפעמים המאפיין אינו ממופה, או שכלל סנכרון ברירת מחדל מוציא אותו. בדקו ועדכנו את Synchronization Rules Editor כך ש-showInAddressList ימופה נכון גם למערכת המקור וגם למערכת היעד.
• סדר העדכון חשוב: שינויים ב-AD או ב-Exchange אינם משתקפים אלא אם מבוצע סנכרון מלא או מופעלים טריגרים מפורשים. תמיד בצעו סנכרון דלתא בכפייה לאחר שינויים, או תזמנו סנכרונים מלאים תקופתיים כדי לתפוס עדכונים שהוחמצו.
• תאימות בין מערכות: חלקממערכות שאינן של Microsoft צורכות מאפיין זה אחרת, ולכן גם לאחר סנכרון מוצלח, יישומים במורד הזרם או ספרי הכתובות עשויים להזדקק לשגרות רענון משלהם.

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

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

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

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

אפשרויות מתקדמות של Active Directory לשינוי מיפויי מאפייני מקור

1. התחילו בעורך כללי הסנכרון
2. פתחו את עורך כללי הסנכרון (SRE) שמגיע עם Microsoft Entra Connect. כאן שולטים באילו מאפייני מקור ב-AD ממופים לאילו יעדים ב-Microsoft Entra ID. זה הכרחי לכל לוגיקת סנכרון מותאמת אישית.
3. איתור הכלל הנכון והבנת הקדימות
4. כללי ברירת מחדל יכולים להיות "מהקופסה" או מותאמים אישית. כללים מותאמים אישית תמיד גוברים. מצאו את הכלל המשויך למאפיין שברצונכם לשנות, בדקו פעמיים את הקדימות שלו, וודאו שאינו מוסתר על ידי כלל אחר שמעליו ברשימה.
5. עריכה (או שכפול) והתאמת המיפוי
6. אם מדובר בכלל מובנה, אל תערכו אותו ישירות. שכפלו אותו וצרו גרסה מותאמת אישית. התאימו את מיפוי מאפיין המקור בעורך, וודאו שמאפיין היעד ב-Microsoft Entra ID מצביע על השדה המותאם אישית שלכם.
7. טיפול בהתנגשויות במיפוי מאפיינים
8. אם כמה מאפייני מקור יכולים לזרום לאותו יעד (למשל employeeID מ-AD, מ-Workday וסנכרון ידני), הגדירו קדימות בעורך, והוסיפו תנאים לכל כלל כדי למנוע התנגשויות או דריסות שגויות.
9. בדיקה ואימות
10. לפני הפריסה לייצור, הריצו סנכרונים מלאים ודלתא בדייר בדיקות. ודאו שהמאפיין החדש זורם כצפוי, על ידי בדיקה הן של מקור ה-on-prem והן של יעד הענן. בדקו את היומנים לאיתור שגיאות או עדכונים שדולגו.
11. תיעוד ועדכון מחלקות נוספות
12. בכל פעם שאתם משנים את לוגיקת המיפוי, עדכנו את רשומות ניהול השינויים והודיעו לצוותים במורד הזרם. זה מסייע בעמידה בדרישות הרגולציה ומונע "בעיות רפאים" מבלבלות כאשר מישהו נתקל במיפויי מאפיינים בלתי צפויים חודשים מאוחר יותר.

מיפוי UserPrincipalName מותאם אישית לדומיינים חלופיים

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

סנכרון בין דיירים ותרחישים שאינם נתמכים ב-Microsoft Entra

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

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

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

התנגשויות בהתאמת משתמשים בין דיירים בתצורת דייר היעד

1. משתמשים כפולים ומאפיינים חופפים
2. כאב ראש מרכזי בסנכרון בין דיירים הוא מצב שבו שני משתמשים משני מערכות מקור שונות מתאימים לאותו אובייקט בדייר היעד. זה בדרך כלל קורה כי מזהים ייחודיים כמו UserPrincipalName, mail או ObjectID חופפים, למשל בגלל חשבונות בדיקה ישנים, מיזוגים או הגירות לא עדכניות.
3. הבנת כללי התאמת משתמשים
4. Microsoft Entra ID מנסה "להתאים" אובייקטים נכנסים לחשבונות קיימים באמצעות מאפיינים הניתנים להגדרה (כמו UPN, mail או immutableID). אם מספר מועמדים עומדים בקריטריונים, מנוע הסנכרון לרוב מדלג, מפעיל התנגשות, או גרוע מכך, דורס נתונים.

• תהליך פתרון התנגשויותבדקו את ייחודיות המאפיינים בדייר המקור ובדייר היעד. נקו כפילויות או הסכימו על "מקור אמת" סמכותי.
• עדנו את כללי ההתאמה או הוסיפו מאפיינים מותאמים אישית (כמו employeeID, costCenter) כדי להפוך אובייקטים של משתמשים לייחודיים גלובלית.
• יישמו מוסכמות שינוי שם או הגדרת היקף כדי למנוע התנגשויות שמות (למשל הוספת קידומות או סיומות של דומיין).
• אם נמצאה התאמה, החליטו: מיזוג, שינוי שם או החרגה? תעדו כל חריגה לצורכי ביקורת ושחזור.
• הריצו סנכרוני פיילוט עם דיווח ורישום כדי לזהות התנגשויות לפני פריסה נרחבת.

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

הימנעות מתרחישי סנכרון לא נתמכים

• קינון רקורסיבי של קבוצות: Microsoft Entra ID אינה תומכת בקבוצות שמפנות לעצמן, במישרין או בעקיפין. שימו לב ללולאות קינון, שכן הן ישברו את הסנכרון.
• סוגי מאפיינים לא נתמכים: לא כל המאפיינים המותאמים אישית או המורכבים זורמים, במיוחד שדות מרובי ערכים או בינאריים. הישארו עם סוגים מתועדים ונתמכים.
• אובייקטים בספריה מחוץ להיקף: סנכרון של אובייקטים (כמו מחשבים או סוגי אנשי קשר מדור קודם) שאינם בתוך ההיקף שהגדרתם עלול לגרום לשגיאות קשות או לסטייה בלתי ניתנת לניהול.
• אי-תאימות סכימה בין מערכות: אם יש לכם הרחבות סכימה ב-AD שאינן נתמכות ב-Entra ID, המאפיינים האלה לא יסתנכרנו ועלולים לשבש את לוגיקת המיפוי.
• מחברים חיצוניים לא מוכרים: שימו לב למחברים או לסקריפטים של הקצאה שאינם מוסמכים על ידי Microsoft. בעיות תאימות ותמיכה שבורה הן שכיחות.

בעיות הקצאה והרשאה ב-Microsoft Entra ID Connect

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

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

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

משתמשים עם כניסה באמצעות SMS מדולגים במהלך ההקצאה

• מגבלת תכנון: Microsoft Entra Connect מדלג בכוונה על משתמשים שבהם מופעלת כניסה באמצעות SMS, בשל כללי הקצאה ספציפיים וסיכוני גישה.
• שיקולי אבטחה ומדיניות: החרגת משתמשים אלה מסייעת למנוע העלאת הרשאות בטעות ושומרת על בקרות מונעות מדיניות בתוקפן.
• פתרונות עוקפים: כדי לכלול משתמשים עם כניסה באמצעות SMS, בדקו ועדכנו את כללי ההקצאה, או שקלו להפעיל שיטות רישום חלופיות עבור חשבונות אלה.
• השפעה על הטמעות ללא סיסמה: ארגונים שמטמיעים אימות מבוסס טלפון חייבים לעקוב אחר המשתמשים שהוחמצו ולסגור פערי כיסוי באמצעות תהליכי מיפוי וניהול משתמשים מתואמים.

פתרון כשלי הרשאה ביישומי הקצאה מקומיים

1. אבחון היקפי הרשאות
2. ראשית, ודאו שלקונקטור ההקצאה או לחשבון השירות יש את כל ההרשאות הנדרשות הן בסביבה המקומית והן בסביבת הענן. הרשאות חסרות ברמת המדריך או היישום גורמות לכשלים שקטים או להודעות שגיאה כמו "insufficient privileges".
3. יישור עם בקרת גישה מבוססת תפקידים (RBAC)
4. בדקו את הקצאת התפקידים, לא רק ברמת המדריך כולו אלא גם עבור יחידות ארגוניות או קבוצות אבטחה ספציפיות שמנהלות אובייקטי זהות. הימנעו מהרשאות יתר על ידי יישום עקרון הרשאות מינימליות, אך ודאו שהקונקטור יכול לגשת לכל אובייקט במדריך שאמור לטפל בו.
5. רישום ביקורת וניטור
6. הפעילו נתיבי ביקורת לפעולות הקצאת משתמשים. השתמשו בפתרונות כמו Microsoft Purview Audit כדי לתעד שינויים, ניסיונות מוצלחים וכושלים, ולחקור התנהגות חריגה בהקצאה. לשיטות עבודה מומלצות, ראו מדריך זה לביקורת פעילות משתמשים עם Microsoft Purview.

• שלבי תיקוןבדקו את היקף הרשאות המדריך ועדכנו לפי הצורך כדי לאפשר את פעולות ההקצאה הנדרשות.
• ודאו שרשומות ה-Service Principals או אפליקציות הקונקטור רשומות כראוי ב-Entra ID, ושהאפליקציות התלויות מאשרות אותן במפורש.
• יישמו סקירות RBAC: הקצו, נטרו וחדשו תפקידי הקצאה באופן תקופתי כדי להפחית את הסיכון לסטייה או להצטברות הרשאות מיותרת.
• בדקו שינויים בסביבת פיתוח או סביבת בדיקות (staging) לפני העברה לייצור, כדי לאתר בעיות שנותרו.
• העלו כל שינוי בהרשאות והתעדו אותו, כך שמבקרי הציות ידעו מה שונה ומדוע.

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

הרחבת מיפויי מאפיינים ל-SQL ולמחברי NoSQL

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

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

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

אבחון כשלי חיבור ומיפוי מאפיינים במחבר SQL

• כשלי אימות: בדקו פעמיים את פרטי ההתחברות ל-SQL וההרשאות. לעיתים לחשבון השירות של המחבר אין רמת גישה נכונה, וזה מפיל את הסנכרונים.
• עמודות מחושבות וחוסר התאמה בסכמה: כאשר מאפייני מדריך מנסים להתמפות לעמודות מחושבות ב-SQL או לעמודות עם סוגי נתונים שונים, מופיעות שגיאות סנכרון. יישרו הן את תכנון הסכמה והן את סוגי הנתונים לפני המיפוי.
• ארכיטקטורת נתונים לקויה: נרמול חלש או היעדר מפתחות ייחודיים מובילים לרשומות כפולות ולסחיפת נתונים. השתמשו במפתחות ראשיים ובאינדקסים ברורים המתאימים למזהי האובייקטים במדריך.
• שגיאות במנוע הסנכרון: בדקו את הלוגים לחיפוש שגיאות "data type conversion" או "constraint violation". בדרך כלל הן מעידות על חוסר יישור עמוק יותר בין הגדרות האובייקטים במדריך לבין הציפיות של סכמת SQL.
• בדיקות ותכנון דוגמה: בנו טבלת דוגמה שמשקפת את הסכמה של המדריך, ואמתו את המיפויים על מספר חשבונות לפני שמרחיבים את משימות הסנכרון.

אתגרי מיפוי אובייקטים ב-NoSQL והמוטיבציה לאינטגרציה

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

שיטות עבודה מומלצות וצעדים הבאים לפתרון בעיות מיפוי מאפיינים

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

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

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

ספרי הפעלה לפתרון תקלות ושלבים מתועדים למיפוי תכונות

1. תעדוף ראשוני: כאשר מיפוי תכונה נכשל, זהו אם הבעיה נמצאת בערך המקור, בכלל המיפוי או במנוע הסנכרון. השתמשו בכלי הניווט שבעמוד כדי לעבור במהירות להליך הרלוונטי (למשל, תכונת הדואר או UPN).
2. ניתוח שורש הבעיה: בדקו לעומק את הלוגים, תצורות המיפוי והשינויים האחרונים. מפו את הזרימה מהמקור ליעד, ותעדו כל חריגה בפרק בעיות השירות.
3. הסלמה ותיעוד: אם הבעיה לא נפתרה ברמה הראשונה, העבירו אותה לרמה הבאה – לרוב למנהלי AD או Entra ID – ותעדו את כל שלבי פתרון התקלה לטובת בסיס הידע של הצוות ולביקורות עתידיות.
4. שמירה על איכות לאורך זמן: לאחר הפתרון, הטמיעו בדיקות וביקורות חוזרות כדי לשמור על איכות תכונות המדריך, ועדכנו את פרקי פתרון התקלות ככל שהבעיות והפתרונות מתפתחים.

מתן משוב וגישה לפרסומים מומלצים

• שליחת משוב על המוצר: השתמשו בכלי המשוב המובנה בפורטל של Microsoft Entra ID או Azure כדי לדווח על בעיות מיפוי, שיפורים או פערים בתיעוד.
• גילוי פרסומים מרכזיים: עברו באופן קבוע על פורטל התיעוד של Microsoft בנושא זהות ועל הבלוגים הטכניים המרכזיים כדי להתעדכן במידע האחרון על מיפוי זהויות והקצאה.
• מעורבות בקהילה: הצטרפו לפורומים של Microsoft Tech Community ולקבוצות LinkedIn רלוונטיות כדי לקבל טיפים לפתרון תקלות מהשטח ודיווחים עדכניים על בעיות.
• הישארות מעודכנים: עקבו אחר פידים של הודעות על עדכונים בסכמות, במחברים ובמיפויים – Microsoft משחררת שיפורים ואזהרות חשובות לעיתים קרובות.

כדאי גם להאזין לאלה

אם אתם חוקרים מיפוי תכונות ב-Entra ID, הפרקים הבאים מוסיפים הקשר מעשי לאבטחת זהות, ממשל ותפעול אמין של Microsoft 365.

• Conditional Access – Simply Explained — הבנה של האופן שבו זהות, מכשיר, מיקום ואותות סיכון מעצבים החלטות גישה.
• Privileged Identity Management – Simply Explained — כיצד הרשאות just-in-time ותהליכי אישור מפחיתים את החשיפה הניהולית.
• Microsoft Defender XDR – Simply Explained — חיבור אותות זהות לזיהוי, לחקירה ולתגובה לאירועים.
• Microsoft Teams Governance – Simply Explained — כיצד בעלות ברורה וכללי מחזור חיים הופכים שיתוף פעולה מאובטח לבר-קיימא.

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