שיעור 02: ניהול משתמשים ואבטחת נתונים

**חלק א': מאגר ידע למדריך **

1. משתמשים ותיקיות

תיאוריה והיסטוריה (High-Level Theory & History)

מערכת ההפעלה macOS, בהיותה מבוססת בבסיסה על ליבת UNIX (Darwin), תוכננה מהיסוד כמערכת הפעלה חסונה מרובת משתמשים (Multi-User). לכל משתמש במערכת מוקצה מרחב מבודד ופרטי לחלוטין המכונה תיקיית הבית (Home Folder). מערכת macOS תומכת באופן מובנה במספר סוגי חשבונות עיקריים, שכל אחד מהם מותאם לרמות גישה ודרישות תפעוליות ספציפיות:

• מנהל מערכת (Administrator) (מנהל מערכת): המשתמש הראשון שנוצר במהלך שלב ה-Setup Assistant. חשבון זה מחזיק בהרשאות-על לבצע שינויים גלובליים במערכת, להתקין תוכנות בתיקיית ה-/Applications המשותפת, להגדיר ממשקי רשת, ולנהל חשבונות משתמשים אחרים.
• משתמש רגיל (Standard) (משתמש רגיל): מורשה להתקין אפליקציות אך ורק בתוך תיקיית הבית האישית שלו (~/Applications), לשנות הגדרות אסתטיות וסביבת עבודה אישית, ולהריץ תוכנות מותקנות. משתמשים רגילים מוגבלים באופן קטגורי משינוי קבצי מערכת קריטיים או ביצוע משימות ניהול גלובליות ללא אימות באמצעות סיסמת מנהל.
• Guest (אורח): חשבון מוגבל ביותר וזמני. המערכת מוחקת באופן מוחלט את כל תוכן תיקיית הבית של האורח מיד עם התנתקותו (Logout) מהמערכת. חשבון זה יעיל במיוחד להשאלת ה-Mac לגורם חיצוני בצורה בטוחה ללא סיכון של חשיפת נתונים. בנוסף, ניתן להגביל חשבונות אורח בקפדנות באמצעות בקרת הורים כדי לחסום גישה לאתרי אינטרנט למבוגרים ולהגביל שימוש באפליקציות.
• Sharing Only (שיתוף בלבד): חשבון ייעודי נטול תיקיית בית, המיועד אך ורק לאפשר גישה מרחוק לתיקיות משותפות ברשת (לדוגמה, דרך פרוטוקול SMB). משתמשי Sharing Only חסומים במפורש מהתחברות לממשק המשתמש הגרפי (GUI) המקומי.

[!TIP] הערת היסטוריה: בעבר הרחוק, macOS ניהלה חשבונות משתמשים דרך מערכת קבצים פשוטה או מסדי נתונים ישנים מסוג NetInfo (מורשת של NeXTSTEP). המעבר ל-OpenDirectory חולל מהפכה בניהול משתמשים מקומיים ורשתיים, ואיפשר אינטגרציה חלקה עם שרתי LDAP ו-Active Directory.

ארכיטקטורה טכנית (Deep Technical Architecture)

תיקיית הבית ב-macOS ממוקמת באופן שיטתי תחת הנתיב /Users. כל תיקיית בית מבוצרת באמצעות הרשאות ברמת POSIX, מה שמבטיח שרק המשתמש המיועד (ומשתמש ה-root הכל-יכול) שומרים על גישת קריאה וכתיבה לתוכנה.

• תיקיית Shared: ממוקמת בנתיב /Users/Shared, זוהי תיקייה קהילתית ייעודית. היא מתפקדת כ"אזור מפורז" (DMZ) שבו משתמשים שונים יכולים להחליף קבצים בצורה מאובטחת, או אזור שבו אפליקציות יכולות לאחסן נכסים גלובליים הנגישים לכלל המשתמשים המקומיים. התיקייה משתמשת בסכמת הרשאות ייחודית הנקראת Sticky Bit. מנגנון UNIX זה מונע במפורש ממשתמש אחד למחוק בזדון או בשוגג קבצים שנוצרו על ידי משתמש אחר בתוך המרחב המשותף.
• ניהול ספריית משתמשים (OpenDirectory): בסטייה מפרדיגמת ה-UNIX המסורתית של קובץ /etc/passwd, macOS מתזמרת את ניהול המשתמשים דרך שירותי הספריה המובנים והעוצמתיים שלה (OpenDirectory). רשומות משתמשים מקומיות נשמרות בקפידה כמסדי נתונים מסוג Property List (XML/Plist) הממוקמים בנתיב /var/db/dslocal/nodes/Default/users/.
• בקרת הורים ו-Screen Time: בגרסאות macOS המודרניות, בקרת ההורים (Parental Controls) שולבה לחלוטין בתוך תשתית ה-Screen Time. מנהלי מערכת יכולים להחיל מגבלות גרגולריות כגון 'Downtime' (הגבלת שימוש בשעות מסוימות), 'App Limits' (הגבלת זמן שימוש יומי באפליקציות מסוימות כמו משחקים או טלוויזיה), 'Communication Limits' (הגבלת אנשי קשר ב-FaceTime וב-Messages), והגבלות 'Content & Privacy' (סינון אתרים בוטים ואכיפת דירוגי משחקים מותאמי גיל). הגדרות Screen Time מסתנכרנות בצורה חלקה בין מכשירי ה-iOS וה-macOS של הילד דרך iCloud.

פקודות מסוף והגדרות (Terminal Commands, Plists & Logs)

• מסוף הפקודות (Terminal) Commands:
  • הצגת רשימת כל המשתמשים המקומיים דרך Directory Services: dscl . -list /Users
  • בדיקת מטא-דאטה מפורט עבור משתמש ספציפי: dscl . -read /Users/username
  • בחינת הרשאות תיקיית /Users (לזיהוי ה-Sticky Bit בתיקיית Shared, המסומן באות 't' במחרוזת ההרשאות): ls -la /Users
• Plists:
  • מטא-דאטה גולמי של משתמש (כולל תמונת החשבון, נתיב תיקיית הבית וה-UID) נשמר בפורמט XML בנתיב: /var/db/dslocal/nodes/Default/users/username.plist. (הגישה דורשת הרשאות sudo).
• Logs:
  • ביקורת על אירועי התחברות ופעולות החלפת משתמשים: log show --predicate 'process == "loginwindow"' --info

מקרי קצה ופתרון תקלות (Edge Cases & Troubleshooting)

• אובדן סיסמת מנהל מערכת: אם מנהל המערכת היחיד מאבד את סיסמתו, שינויים גלובליים במערכת נעצרים לחלוטין. הפתרון מצריך אתחול למצב macOS Recovery, פתיחת טרמינל, והרצת הפקודה resetpassword כדי להפעיל את אשף איפוס הסיסמה המובנה. (הערה: בארכיטקטורות Apple Silicon, הליך זה דורש אימות חלופי, כגון סיסמת Apple Account או אישור ממשתמש אחר בעל Secure Token).
• התנגשויות הרשאות בתיקייה משותפת: לעיתים, אפליקציות צד-שלישי כותבות קבצים לתיקיית ה-Shared עם הרשאות שגויות, ובכך מונעות ממשתמשים רגילים גישה. התיקון המוחלט הוא לאפס את ההרשאות בתיקייה זו באמצעות פקודת chmod או דרך חלונית 'Get Info' ב-Finder, תוך החלת השינויים במפורש על כל הפריטים הכלולים (Apply to enclosed items).

---

2. ניהול סודות

תיאוריה והיסטוריה (High-Level Theory & History)

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

[!TIP] הערת היסטוריה: למנגנון ה-Keychain יש היסטוריה עשירה, שהחלה בשנת 1993 במערכת System 7.1.1. התשתית המודרנית של SecKeychain הוצגה ב-OS X 10.2 (2002). עם זאת, רק ב-2013 הוכרז ה-Data Protection Keychain, שאיפשר סנכרון ענן מאובטח (iCloud Keychain). היסטורית, משתמשים הסתמכו על אפליקציית 'Keychain Access' התועלתנית, שהייתה פונקציונלית אך מרתיעה עבור משתמשים שאינם טכניים.

החל מ-macOS Sequoia (גרסה 15) ובהתבססות משמעותית ב-macOS Tahoe (גרסה 26), אפל ניתקה באגרסיביות את חוויית המשתמש מ-System Settings המסורבל ומאפליקציית Keychain Access המיושנת. הם הציגו אפליקציה ייעודית ומעוצבת שנקראת פשוט אפליקציית Passwords. אפליקציה זו משמשת ככספת מרכזית לסיסמאות רגילות, Passkeys, קודי אימות דו-שלבי (2FA), ואישורי Wi-Fi. היא כוללת התראות אבטחה פרואקטיביות עבור נתונים שנפרצו ומאפשרת יצירה מאובטחת של קבוצות סיסמאות משותפות (Shared Password Groups) עבור משפחות או צוותים.

ארכיטקטורה טכנית (Deep Technical Architecture)

• מסדי נתונים של Keychain: ארכיטקטורת ה-Keychain הכוללת מחולקת למספר מסדי נתונים נפרדים:
  • Login Keychain: (~/Library/Keychains/login.keychain-db) - מאכסן את הסודות האישיים של המשתמש. הוא מתוכנן להיפתח באופן סינכרוני עם סיסמת החשבון המקומית.
  • System Keychain: (/Library/Keychains/System.keychain) - שומר סודות ברמת המערכת (למשל, סיסמאות Wi-Fi ארגוניות הנחוצות לקישוריות רשת לפני התחברות).
  • iCloud Keychain: למרות המינוח, לא מדובר בקובץ מקומי יחיד אלא במנגנון סנכרון מתוחכם במיוחד בעל הצפנה מקצה-לקצה (E2EE). הוא מבטיח שסודות מסוימים מתוך ה-Login Keychain (והפריטים החדשים של הפלטפורמה באפליקציית Passwords) ישוכפלו בצורה מאובטחת על פני כל סביבת המכשירים המהימנים של המשתמש.
• אינטגרציה של אפליקציית Passwords: אפליקציית Passwords החדשה מתפקדת כממשק לקוח מתוחכם המשתלב עמוקות עם תשתית ה-iCloud Keychain. כדי לגשת לתוכנה, האפליקציה מחייבת אימות ביומטרי (Touch ID) או סיסמת מערכת, ובכך מספקת שכבת הגנה משנית וקריטית מעבר לבידוד הסטנדרטי של תיקיית הבית.

פקודות מסוף והגדרות (Terminal Commands, Plists & Logs)

• מסוף הפקודות (Terminal) Commands:
  • מניפולציה בשורת הפקודה של keychains: security
  • רשימת כל ה-keychains הפעילים במערכת: security list-keychains
  • איתור תעודה ספציפית בתוך keychain: security find-certificate -a /Library/Keychains/System.keychain
• Plists: N/A - סודות מאוחסנים במכוון בתוך מסדי נתונים מוצפנים (.keychain-db) ולא ברשימות מאפיינים מסוג XML בטקסט גלוי, כדי לשמור על שלמות קריפטוגרפית.
• Logs:
  • פתרון תקלות בשגיאות של שירות האבטחה וכשלים בפתיחת סודות: log show --predicate 'subsystem == "com.apple.securityd"'

מקרי קצה ופתרון תקלות (Edge Cases & Troubleshooting)

• Out of Sync Keychain (בעיית ה"קפיצות התמידיות"): זוהי בעיית IT ארגונית קלאסית ועקשנית. היא מתרחשת כאשר סיסמת המחשב של המשתמש משתנה על ידי כוח חיצוני (למשל, שרת MDM, חיבור Active Directory, או ספק זהויות צד-שלישי) אך מסד הנתונים המקומי login.keychain-db נכשל בקליטה וסנכרון מול הסיסמה החדשה הזו. כתוצאה מכך, המשתמש מופצץ בהתראות מערכת בלתי פוסקות המבקשות את סיסמת ה-keychain הישנה שלו. התיקון כרוך בפתיחת אפליקציית Keychain Access הישנה, שינוי ידני של סיסמת ה-keychain כדי שתתאים לסיסמת ההתחברות החדשה, או, במקרים קטסטרופליים שבהם הסיסמה הישנה נשכחה, מחיקה ויצירה מחדש של ה-keychain (דבר שמוביל לאובדן בלתי הפיך של סודות ישנים שלא סונכרנו ל-iCloud).

---

3. העידן ללא סיסמה ואבטחה

תיאוריה והיסטוריה (High-Level Theory & History)

מונעת על ידי קואליציית FIDO העולמית, אפל פועלת באגרסיביות לחיסול הסיסמאות המסורתיות לטובת Passkeys (מפתחות גישה). Passkey מחליף מחרוזת טקסט פגיעה בזוג מפתחות קריפטוגרפיים מאובטחים במיוחד (הכוללים מפתח ציבורי ומפתח פרטי). המפתח הפרטי נשאר קבור לצמיתות בתוך חומרת המכשיר ואינו משודר לעולם. כדי לאמת זהות מול אתר או שירות, המשתמש פשוט מבצע בדיקה ביומטרית (Touch ID או Face ID).

[!TIP] הערת היסטוריה: בסיס החומרה עבור Passkeys, ה-Secure Enclave, הוצג לראשונה ב-iPhone 5s (2013) עבור עיבוד Touch ID והגיע ל-Mac ב-2017 עם שבב האבטחה T2. אבטחה אמיתית מחייבת מעבד עזר מבודד, המנותק לחלוטין מהמעבד הראשי, כדי לסכל נוזקות מתקדמות החולצות נתונים מהזיכרון.

ברמת מערכת הקבצים המקומית, אבטחת הנתונים מנוהלת על ידי גישה היברידית: הרשאות POSIX קלאסיות של UNIX, המורחבות על ידי תשתית רשימות בקרת גישה (ACLs) מתקדמות. בנוסף, macOS מעסיקה מערכות אבטחה חזקות כגון System Integrity Protection (SIP), Sandboxing, ו-Transparency, Consent, and Control (TCC) כדי להגן על פרטיות המשתמש.

ארכיטקטורה טכנית (Deep Technical Architecture)

• Passkeys: ב-macOS, ה-Passkeys מיוצרים קריפטוגרפית ומגובים חומרתית ישירות על ידי ה-Secure Enclave. כאשר Passkey מונפק עבור שירות, רק המפתח הציבורי משותף עם השרת. במהלך התחברויות עוקבות, השרת מנפיק "אתגר" קריפטוגרפי. ה-Secure Enclave, לאחר אימות ביומטרי מוצלח, "חותם" על האתגר הזה באמצעות המפתח הפרטי המבודד. מכיוון שארכיטקטורה זו משולבת עמוקות עם iCloud Keychain, ה-Passkey מסונכרן באופן חלק ומאובטח (מוצפן מקצה לקצה) על פני כל סביבת האפל של המשתמש. (הערה: בסביבות ארגוניות קפדניות, מדיניות MDM יכולה לאסור שיתוף Passkeys דרך AirDrop כדי למנוע זליגת אישורים).
• POSIX & ACL:
  • POSIX: מגדיר זכויות גישה בסיסיות (קריאה, כתיבה, ביצוע) עבור שלוש ישויות נפרדות: Owner (בעלים), Group (קבוצה) ו-Everyone (כולם).
  • ACL (Access Control Lists): כאשר רמת הפירוט של POSIX אינה מספקת (למשל, הענקת גישת קריאה לעובד א' וגישת כתיבה לעובד ב' עבור אותו קובץ בדיוק), מערכת הקבצים מנצלת ACLs. אלו הם סטים של הרשאות מתקדמות מבוססות חוקים המאוחסנות כ-Extended Attributes במבנה מערכת הקבצים APFS, הניתנים לניהול דרך חלונית 'Get Info' ב-Finder או ב-Terminal.
• Privacy & Security (TCC): שקיפות, הסכמה ובקרה (TCC) היא תשתית ה-macOS המגדירה מיקומים ספציפיים (כמו ~/Desktop, ~/Documents, ~/Downloads, ו-iCloud Drive) ומשאבים (כמו מצלמה ומיקרופון) כפרטיים. TCC פועל מחוץ למאפייני הקובץ, תוך שימוש במערכת מבוססת כללים המוחלת על כל אפליקציה. אם אפליקציה מנסה לגשת לתיקייה מוגנת, TCC מבקש את הסכמת המשתמש. אם ההסכמה נדחית, האפליקציה נחסמת, ללא קשר להרשאות POSIX או ACL. ניתן להעניק גישה מלאה לכונן (Full Disk Access) בהגדרות המערכת כדי לעקוף חלק מהמגבלות הללו עבור כלי ניהול.
• System Integrity Protection (SIP) & Sandboxing: SIP מגן על קבצי מערכת ותיקיות ליבה מפני שינוי, אפילו על ידי משתמש ה-root, ובכך מפחית משמעותית את השפעתן של נוזקות. Sandboxing מגביל אפליקציות לסביבות המיועדות להן, ומצמצם את יכולתן ליצור אינטראקציה עם המערכת הרחבה יותר או עם אפליקציות אחרות ללא זכויות מפורשות.

פקודות מסוף והגדרות (Terminal Commands, Plists & Logs)

• מסוף הפקודות (Terminal) Commands (POSIX & ACL):
  • הצגת הרשאות קבצים כולל ACLs (מסומן על ידי סיומת + במחרוזת ההרשאה): ls -le /path/to/file
  • שינוי בעלות על קובץ: sudo chown root:admin /path/to/file
  • שינוי הרשאות POSIX קלאסיות (פורמט אוקטלי): chmod 755 /path/to/file
  • הזרקת חוק ACL מתקדם: chmod +a "user:omer:allow read,write,append" /path/to/file
• Plists: N/A - הרשאות ACL מתבטאות כ-Extended Attributes בתוך מבנה ה-APFS, ולא ב-Plists.
• Logs:
  • מעקב אחר תהליכי האימות המורכבים של WebAuthn ו-Passkey: log show --predicate 'subsystem == "com.apple.AuthenticationServices"'

מקרי קצה ופתרון תקלות (Edge Cases & Troubleshooting)

• שלילת הרשאות בשוגג: מנהל מערכת עלול לשלול בטעות מעצמו את גישת הקריאה לקובץ קריטי דרך ACLs ב-Finder (מה שמוביל לתג "No Access"). מכיוון שהוא שומר על הרשאות ניהול, הוא יכול לפתור זאת על ידי פתיחת תיבת הדו-שיח 'Get Info', לחיצה על המנעול להעלאת הרשאות, ושחזור גישת ה-Read/Write שלו, או על ידי ביצוע פקודת sudo chmod.
• הגירת מכשירים ו-Passkeys חסרים: משתמש העובר ל-Mac חדש עשוי לגלות שה-Passkey הארגוני שלו חסר, למרות שהוא קיים ב-iPhone שלו. זה קורה בדרך כלל משום שסנכרון iCloud Keychain מושהה או מושבת ב-Mac החדש, או שחשבון ה-Apple הארגוני המנוהל אוסר לחלוטין על סנכרון אישורים או AirDrop. אימות מחדש והפעלת סנכרון בהגדרות ה-Apple Account לרוב משיבים את הגישה.
• TCC חוסם גישה: כלי שורת פקודה או סקריפט נכשל בקריאת קבצים בתיקיית ~/Desktop למרות הרשאות POSIX תקינות. זהו TCC בפעולה. על אמולטור המסוף (למשל, Terminal.app או iTerm2) לקבל במפורש 'Full Disk Access' או גישה ל-'Files and Folders' בהגדרות Privacy & Security.

---

4. תיבול ארגוני

תיאוריה והיסטוריה (High-Level Theory & History)

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

• Managed Apple Accounts (MAID): אלו הם חשבונות Apple הנמצאים בבעלות, מוקצים ונשלטים באופן אינהרנטי על ידי הארגון (דרך Apple Business Manager או Apple School Manager). הארגון מכתיב אילו שירותי ענן פעילים. לדוגמה, כדי למנוע דלף נתונים, ארגון יכול להשבית באגרסיביות את iCloud Mail, iCloud Photos ו-Private Relay בתוך ה-MAID, בעודו מאשר במפורש את iCloud Drive וסנכרון Passkeys ארגוניים.
• Platform SSO (Single Sign-On): טכנולוגיה זו מחליפה למעשה את תהליך ה-Active Directory binding השביר והמיושן (שבו מקי מקושרו ישירות לדומיין מקומי בארגון). Platform SSO מאפשר אינטגרציה עמוקה שבה מסך ההתחברות (Login Window) הטבעי של macOS מתקשר ישירות עם ספקי זהות (IdPs) מתקדמים בענן כגון Microsoft Entra ID או Okta. דבר זה מאפשר לעובד להשתמש באישורים התאגידיים המרכזיים שלו (או במפתח המגובה בחומרה של Secure Enclave) כדי לפתוח במקביל את חומרת ה-Mac ולהזדהות לתוך כל יישומי הענן הארגוניים בצורה חלקה.

ארכיטקטורה טכנית (Deep Technical Architecture)

• מגבלות של Managed Apple Accounts: ל-MAIDs יש מגבלות ארכיטקטוניות המונעות ביצוע רכישות מסחריות ב-App Store, מכיוון שרישוי ארגוני חייב להיות מנוהל באופן מרכזי דרך תוכנית רכישת הכמויות (VPP) ולהיות מופץ דרך MDM. כאשר ארגון מפעיל Federated Authentication (אימות מאוחד), אשף ההגדרות של macOS מזהה את הדומיין של דוא"ל הארגון. הוא מפנה מיד את בקשת האימות אל ה-IdP הארגוני דרך פרוטוקולי SAML/OIDC. אינטגרציה עמוקה זו מבטיחה שהזהות הארגונית של העובד מקושרת באופן בלתי ניתן להפרדה לזהות ה-Apple שלו, מה שמבטל את תופעת ה"עייפות מסיסמאות" (Password Fatigue).
• הרחבת Platform SSO: ארכיטקטורה זו מחייבת שפלטפורמת ה-MDM תפרוס פרופיל תצורה ייעודי המכיל מטען מסוג Extensible Enterprise SSO. מטען זה מורה ל-macOS איזו אפליקציית צד-שלישי (למשל, Microsoft Company Portal) מורשית לשמש כמתווכת ה-SSO. במהלך ההתחברות, macOS מזרימה בצורה מאובטחת את אירוע האימות של מסך הנעילה למתווך זה. אם תכונת ה-Password Sync פעילה, תוסף ה-SSO אוכף בקפידה סנכרון בין סיסמת החשבון המקומי לסיסמת הענן, ובכך מקדים ומונע בעיות של חוסר סנכרון ב-Keychain.

פקודות מסוף והגדרות (Terminal Commands, Plists & Logs)

• מסוף הפקודות (Terminal) Commands:
  • ביקורת על הרחבות SSO מותקנות ואימות פריסת פיילוד: system_profiler SPConfigurationProfileDataType | grep -i SSO
  • אימות מדיניות מנוע ה-Extensible SSO: profiles show -type configuration
• Plists:
  • העדפות הרחבת SSO ממוקמות בדרך כלל בנתיב /Library/Managed Preferences/com.apple.ExtensibleEnterpriseSSO.plist (הנתיב עשוי להשתנות בהתאם למתודולוגיית פריסת ה-MDM).
• Logs:
  • אבחון בעיות קישוריות וכשלים באימות של Platform SSO מול ה-IdP: log show --predicate 'subsystem == "com.apple.PlatformSSO"'

מקרי קצה ופתרון תקלות (Edge Cases & Troubleshooting)

• התנהגות Platform SSO במצב לא מקוון (Offline): מקרה קיצון קריטי מתעורר כאשר עובד משנה את סיסמת ה-IdP בענן (למשל, דרך הסמארטפון שלו) ומיד לאחר מכן מנסה לפתוח את ה-Mac שלו בסביבה מנותקת לחלוטין מרשת (למשל, במהלך טיסה). מכיוון שה-Mac מנוהל על ידי Platform SSO אך חסר קישוריות רשת כדי לאמת את האישור החדש, על העובד לאמת את עצמו באמצעות הסיסמה הישנה שלו, אשר נותרת שמורה בבטחה במטמון (Cache) המקומי של המערכת. עם חידוש הגישה לרשת, הרחבת ה-SSO מזהה את תפוגת האסימון (Token), מבקשת מהמשתמש להזין את הסיסמה החדשה, ומעדכנת בצורה חלקה את המטמון המקומי ואת ה-Login Keychain, ובכך פותרת את הפער ללא התערבות מחלקת ה-IT.
• התנגשות דומיין ב-Managed Apple Accounts: לעיתים קרובות, ייתכן שעובד יצר היסטורית Apple ID אישי תוך שימוש בכתובת הדוא"ל הארגונית שלו. כאשר מחלקת ה-IT מפעילה Federated Authentication עבור דומיין זה, החשבון האישי נכנס למצב של "התנגשות". העובד מקבל התראות אוטומטיות המחייבות אותו להעביר את חשבונו האישי לכתובת דוא"ל אחרת (למשל, חשבון Gmail) בתוך תקופת חסד של 60 יום. לאחר 60 יום, אפל תדרוש חזרה את הדומיין הארגוני באופן בלעדי עבור ה-MAIDs של הארגון.

💡 עזרים ויזואליים להרצאה (Presentation Visuals)

[!NOTE] תמונות אלו ניתנות להקרנה בכיתה בעת הסבר על הנושא, או לשילוב במצגות.

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

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

---

דלג לאותו שלב בשיעור הבא ⬅️