לדלג לתוכן

שיעור 13: תהליך האתחול

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

1. שרשרת האתחול: מ-Boot ROM דרך LLB ועד הקרנל במחשבי Apple Silicon

1. תיאוריה ברמת-על והיסטוריה (High-Level Theory & History)

מבחינה היסטורית, מחשבי מק מבוססי Intel השתמשו במערכת EFI (Extensible Firmware Interface) כדי לנהל את תהליך ה-Boot, ולטעון את קובץ ה-boot.efi ובסופו של דבר את הקרנל. תהליך זה, למרות שהיה פונקציונלי לאורך שנים רבות, היה רגיש מאוד לשינויים חיצוניים, Rootkits, ונוזקות Firmware. הצגת שבב ה-Apple T2 Security Chip במחשבי Intel המאוחרים יותר התחילה לשנות את הפרדיגמה הזו על ידי חיקוי תהליך האתחול המאובטח של מכשירי ה-iOS. במחשבי מק המצוידים ב-T2, השבב מבצע אתחול מאובטח מה-Boot ROM שלו כדי לאמת את מנהל האתחול iBoot. לאחר מכן, iBoot בודק את הקרנל והרחבות הקרנל (kexts), מאמת את קושחת ה-UEFI, וממפה אותה לזיכרון כדי שמעבד ה-Intel יוכל למשוך אותה דרך ה-eSPI. מעבד ה-Intel ממשיך לאחר מכן את שרשרת האמון, מאמת את מנהל האתחול Boot.efi, אשר בתורו מאמת את ה-immutablekernel לפני העברת השליטה ל-macOS.

עם המעבר המוחלט לארכיטקטורת Apple Silicon (מערכת על שבב - SoC), אפל שינתה לחלוטין את מודל האתחול והעתיקה באופן מלא את ארכיטקטורת האבטחה ממכשירי ה-iOS. המודל החדש והמודרני אינו מסתמך רק על תוכנה שטוענת תוכנה, אלא מבוסס לחלוטין על שרשרת אמון המעוגנת בחומרה (Hardware-Rooted Chain of Trust). כל שלב בודד בשרשרת זו חייב לבדוק את החתימה הקריפטוגרפית (Digital Signature) של הרכיב הבא לפני שהוא מעביר אליו את השליטה. אימות מוחלט זה מבטיח שהמערכת תריץ אך ורק קוד חתום ומאושר קריפטוגרפית על ידי אפל.

אנלוגיה היסטורית למדריך

מעניין לציין שבעידן ה-Classic Mac OS, ה-ROM היה צרוב פיזית בחומרה, ועבר ל-Open Firmware (מבוסס שפת Forth) שהעניק גישה אינטראקטיבית אבל היה "סיוט אבטחתי". המעבר ל-UEFI במחשבי אינטל הביא סטנדרטיזציה אבל השאיר חולשות. עם המעבר ל-Apple Silicon, אפל נטשה לחלוטין את UEFI לטובת מנגנון Secure Boot (iBoot) קפדני, אשר מייתר כליל את פתרונות אבטחת ה-Firmware הישנים.

2. ארכיטקטורה טכנית עמוקה (Deep Technical Architecture)

תהליך ה-Boot במחשבי Apple Silicon (שרשרת האתחול) מורכב משלבים קפדניים ובלתי ניתנים לשינוי:

  1. Boot ROM: זהו השלב הראשון המוחלט והוא צרוב פיזית (Hardcoded) בתוך ה-SoC במהלך הייצור (Read-Only). הוא מכיל את המפתח הציבורי של אפל (Apple Public Key) ומהווה את שורש האמון (Root of Trust). לא ניתן לשנות, לעדכן או להתעסק איתו. אם יש בו כשל קריטי, המכשיר נכנס למצב DFU.
  2. LLB (Low-Level Bootloader): ה-Boot ROM קורא את ה-LLB מהאחסון הפנימי, מוודא את חתימתו באמצעות המפתח הציבורי, ומריץ אותו. ה-LLB אחראי לאתחול בסיסי של החומרה ולטעינת רכיב ה-Secure Enclave.
  3. LocalPolicy (מדיניות מקומית): ה-LLB טוען את קובץ ה-LocalPolicy, אשר חתום על ידי ה-Secure Enclave Processor (SEP). קובץ זה מכתיב את תצורת המשתמש ואת מדיניות האבטחה בזמן הריצה (כגון Full Security מול Reduced Security).
  4. iBoot (Stage 2 Bootloader): ה-LLB מוודא וטוען את ה-iBoot. תפקידו של ה-iBoot הוא לטעון את סביבת ההתאוששות (Recovery Mode) במידה ונדרש, או לאמת את קרנל המערכת (macOS Kernel) ולטעון אותו מתוך ה-Sealed System Volume (SSV). iBoot קורא את ה-LocalPolicy כדי לקבוע אם מותר לטעון גרסאות ישנות של macOS או הרחבות קרנל צד-שלישי.
  5. macOS Kernel & SSV: הקרנל מאתחל את המערכת, מעגן (Mount) את ה-SSV ומוודא שעץ הגיבוב (Hash Tree) של APFS תואם את החותמת (Seal) של אפל. בתחילה, הקרנל רץ על ליבת מעבד יחידה לפני שהוא מפעיל את שאר הליבות ומשגר את ה-launchd.

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

ציר הזמן של האתחול וה-"Silent Phase" (השלב השקט) על פי חפירה לעומק של תהליך האתחול ב-macOS 26 Tahoe, הרישום הפותח בלוג המאוחד (Unified log) הוא הכרזת האתחול (=== system boot:). לאחר מכן יש פער של 5 שניות או יותר, הידוע כהשלב השקט (Silent Phase). במהלך זמן זה, ה-LLB וה-iBoot מתבצעים. הם אינם כותבים ללוג המאוחד אלא משאירים קטעי מידע קריפטיים הידועים בשם "פירורי לחם" (breadcrumbs). לאחר מכן, הקרנל כותב את הודעת הפתיחה הרגילה שלו (kprintf initialized).

במהלך שלב הקרנל, שעון המערכת מסונכרן וזמן שעון-הקיר מותאם. פתיחת ה-Data Volume (Data volume unlock) מתרחשת בערך 10-15 שניות לאחר תחילת האתחול כאשר חלון ההתחברות מוצג. כאשר FileVault מופעל, ל-macOS עדיין אין גישה ל-Data Volume בשלב זה. המשמעות היא שכל הקוד שהופעל עד כה הוא בלתי ניתן לשינוי (נעול בקושחה או ב-SSV). אין גישה ל-/Library או לקבצי משתמש. ברגע שהסיסמה מוזנת, ה-SEP שולח הודעה שהווליום נפתח, והמערכת עוברת לאתחול מרחב המשתמש (Userspace boot), בו רישומי הלוג מזנקים מ-1,000 לשנייה ליותר מ-5,000 לשנייה.

3. פקודות טרמינל, Plists ולוגים (Terminal Commands, Plists & Logs)

  • בדיקת מצב ה-Boot ורמת ה-Secure Boot הנוכחית: system_profiler SPSoftwareDataType

  • בדיקת חותמת ה-SSV של המערכת: diskutil apfs list (חפשו את השורה "Seal: Broken" או "Seal: Intact").

  • קריאת לוגים מתהליך האתחול והקרנל: log show --predicate 'subsystem == "com.apple.kernel"' --last boot

  • הערת פתרון תקלות: (הערה: אין פקודות טרמינל המאפשרות שינוי או גישה ישירה ל-Boot ROM, LLB או iBoot. רכיבים אלו סגורים לחלוטין למניעת שינוי זדוני "N/A").

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

אם שרשרת האתחול קורסת או מושחתת (למשל כשל בעדכון קושחה שפגע ב-LLB או ב-iBoot), המק לא ידלק בכלל וייכנס למצב DFU (Device Firmware Update). במצב זה, המק מתפקד כ"לבנה" פסיבית וממתין שמק אחר יתחבר אליו באמצעות כבל וידחוף אליו קובץ IPSW חתום מחדש בעזרת אפליקציית Apple Configurator (או Finder בגרסאות macOS מודרניות). התהליך נקרא Revive (תיקון קושחה ללא איבוד נתונים) או Restore (מחיקת כל הנתונים וצריבה מחדש של הקושחה), והוא המוצא היחידי להחייאת מק מבוסס Apple Silicon עם Boot Chain שבור.

בעת פתרון בעיות הפעלה, משתמשים יכולים לגשת ל-Startup Options ב-Apple Silicon על ידי כיבוי המק, ולאחר מכן לחיצה ממושכת על כפתור ההפעלה עד שיופיע "Loading startup options". מכאן, הם יכולים לבחור כונן הפעלה אחר, לגשת ל-macOS Recovery, או להיכנס ל-Safe Mode (על ידי בחירת ווליום, לחיצה ממושכת על מקש Shift ולחיצה על "Continue in Safe Mode"). מחשבי מק מבוססי Intel ניגשים ל-Safe Mode על ידי הפעלה מחדש והחזקה מיידית של מקש ה-Shift.

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

2. Startup Security Utility: שינוי רמות האבטחה (Full Security מול Reduced Security) ולמה שנרצה להוריד אבטחה

1. תיאוריה ברמת-על והיסטוריה (High-Level Theory & History)

בעידן מחשבי אינטל עם שבב ה-T2, אפל הציגה את ה-Startup Security Utility כדי לאכוף Secure Boot ולמנוע אתחול מכוננים חיצוניים. עם המעבר ל-Apple Silicon, פרדיגמת האבטחה השתנתה: כעת, לכל Volume במערכת יכולה להיות מדיניות אבטחה מקומית (Local Policy) משלו. Startup Security Utility (כלי אבטחת האתחול), הנגיש אך ורק מתוך Recovery Mode, מאפשר למשתמש בעל הרשאות מיוחדות (Volume Owner) לשנות את רמת האבטחה של מערכת ההפעלה ולהתיר טעינה של רכיבי צד-שלישי שאינם חתומים ישירות על ידי אפל כחלק מהמערכת הבסיסית.

טריוויה למדריך

בעשור הראשון של Mac OS X בכלל לא הייתה מחיצת Recovery! רק ב-2011 (Lion) היא הוצגה לראשונה. היום ב-Apple Silicon קיימת מערכת 1TR (One True Recovery) שעולה ישירות מהחומרה ומייתרת את אינספור קיצורי המקלדת של העבר.

2. ארכיטקטורה טכנית עמוקה (Deep Technical Architecture)

במחשבי Apple Silicon קיימות שתי רמות אבטחה מרכזיות הקובעות כיצד שרשרת ה-Boot מתייחסת לקרנל:

  • אבטחה מלאה (Full Security - ברירת מחדל): מערכת ההפעלה מתנהגת בדיוק כמו מכשיר iOS. המק יאתחל אך ורק אם מערכת ההפעלה והקרנל חתומים בצורה מלאה על ידי אפל ללא שינויים. במצב זה נמנעת טעינת הרחבות קרנל צד-שלישי. מצב זה דורש חיבור לאינטרנט במהלך התקנה כדי להגיע לשרת החתימות של אפל (TSS) ולאחזר חתימה מותאמת אישית (APTicket) בהתבסס על ה-ECID של המק, מה שמונע מתקפות Rollback לגרסאות פגיעות.
  • אבטחה מופחתת (Reduced Security): מצב המאפשר למשתמש להתקין הרחבות קרנל (Kexts) חיצוניות או פרופילי MDM מתקדמים ללא חתימה מחמירה של אפל. שינוי למצב זה מעדכן את ה-Local Policy (הנשמר בקונטיינר ה-iSCPreboot ב-APFS) שמנחה את ה-iBoot להרשות טעינת Auxiliary Kernel Collection (אוסף קרנל עזר). הוא מוריד את הרף מול אפל, אך דורש אמון במנהל המקומי ומבטל בדיקות TSS מקוונות עבור הפעלת מערכות הפעלה ישנות.
  • Mac Sharing Mode: במצבי קצה שבהם המערכת פגומה והמשתמש זקוק לחלץ מידע דחוף, ניתן להפעיל מתוך סביבת ה-Recovery את Mac Sharing Mode (Target Disk Mode ההיסטורי). מצב זה מדלג על טעינת מערכת ההפעלה ומריץ שרת SMB וירטואלי מעל כבל Thunderbolt, כך שמק מארח יוכל להתחבר לכונן, לאמת סיסמה מול ה-Secure Enclave, ולהעתיק קבצים מה-Data Volume.

3. פקודות טרמינל, Plists ולוגים (Terminal Commands, Plists & Logs)

  • הצגת סטטוס האבטחה (Local Policy) (ב-Recovery): bputil -d

  • בדיקת מנגנוני ה-SIP ומדיניות ההגנה בסביבה החיה: csrutil status

  • בדיקת סטטוס הסכמת הרחבות הקרנל: spctl kext-consent status

  • הערת פתרון תקלות: לא קיימת פקודת טרמינל המאפשרת הורדת רמת האבטחה מתוך סביבת מערכת חיה. השינוי מחייב אתחול ל-Recovery Mode.

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

אם משתמש נכנס לכלי אבטחת האתחול ומנסה לשנות ל-Reduced Security אך המערכת מסרבת לקבל את הסיסמה שלו (או שהמשתמש לא מופיע ברשימה), המשמעות היא שהמשתמש אינו "Volume Owner". אין לו Secure Token צמוד לחשבון, ולכן ה-Secure Enclave אינו מכיר בו כגורם מוסמך לעריכת ה-Local Policy. בנוסף, שינוי של רמת אבטחה מחייב פעמים רבות חיבור אינטרנט זמין מכיוון שה-iBoot מנסה "לצלצל הביתה" לשרתי החתימות של אפל (Tatsu Signing Server - TSS) כדי לחתום קריפטוגרפית על המדיניות החדשה. ללא אינטרנט בסביבת ה-Recovery, השינוי עשוי להיכשל.

3. הרחבות קרנל (Kexts): למה אפל הורגת אותן ואיך מתקינים אותן בכל זאת במק מודרני

1. תיאוריה ברמת-על והיסטוריה (High-Level Theory & History)

הרחבות קרנל (Kernel Extensions או Kexts) הן פיסות קוד נמוכות הנטענות ישירות לתוך מרחב הליבה של macOS (Ring 0), ומעניקות להן שליטה מוחלטת ואקסלוסיבית על חומרת המערכת והרשת. היסטורית, כלים ארגוניים כמו אנטי-וירוס, פיירוולים חכמים (VPN), ודרייברים לחומרה עשו שימוש כבד ב-Kexts. הבעיה הבסיסית עם ארכיטקטורה זו היא שבאג קטן אחד בקוד של Kext מביא לקריסת המערכת כולה (Kernel Panic), ו-Kext זדוני מוביל להשתלטות עוינת מוחלטת.

כיום, אפל מבצעת Deprecation אקטיבי (הוצאה משימוש) של Kexts לטובת System Extensions הרצות בצורה בטוחה במרחב המשתמש (User Space) הרגיל. אם System Extension קורסת, האפליקציה נכשלת, אך המק ממשיך לפעול. עם זאת, עדיין קיימות תוכנות שורשיות המחייבות טעינת Kext.

פרספקטיבה היסטורית למדריך

מעניין לציין שבעידן ה-Classic Mac OS לא היה ל-Mac קרנל של ממש (במובן המודרני), ולכן גם לא היו Kernel Panics - המערכת פשוט הייתה קורסת כולה וקופאת. המעבר לארכיטקטורת קרנל ב-Mac OS X הוליד את ה-Kernel Panic המפורסם, כאשר דווקא תוספי הקרנל (Kexts) הפכו לעקב אכילס המרכזי של יציבות המערכת עד היום.

2. ארכיטקטורה טכנית עמוקה (Deep Technical Architecture)

במערכות macOS מודרניות (כמו macOS 26 Tahoe), התקנת Kext היא אירוע מורכב ביותר. תחילה, המערכת חייבת להיות מוגדרת תחת Reduced Security. כאשר מתקינים Kext, ה-macOS לא מכניסה אותו ישירות לתוך הקרנל המקורי החתום של המערכת (אשר נעול בתוך ה-SSV). במקום זאת, המערכת מרכיבה קולקציית ליבה נפרדת הנקראת Auxiliary Kernel Collection (AKC).

במהלך ה-Boot, ה-iBoot קורא את ה-Local Policy. אם אישור ה-Kext קיים שם, הוא טוען את ה-AKC במקביל לקרנל המקורי. ארכיטקטורה מבודדת זו מבטיחה שאם מנהל המערכת מחליט להחזיר את האבטחה ל-Full Security, ה-AKC מפסיק להיטען מידית והמחשב חוזר למצבו הבתולי ללא כל קוד ליבה צד-שלישי.

3. פקודות טרמינל, Plists ולוגים (Terminal Commands, Plists & Logs)

  • הצגת Kexts פעילים שאינם של אפל: kmutil showloaded --list-only | grep -v com.apple

  • ניקוי מערך ההכנה של ה-AKC (כלי פתרון תקלות עמוק ב-Terminal): sudo kmutil clear-staging

  • הצגת הרחבות מערכת מודרניות (המחליפות של Kexts): systemextensionsctl list

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

תרחיש נפוץ בארגונים: משתמש מתקין כלי אבטחה ישן מבוסס Kext. התוכנה נראית מותקנת, אך היא לא פועלת בפועל מכיוון שהמשתמש לא נכנס ל-Recovery Mode להוריד את רמת האבטחה ולא אישר אותה באופן ידני ב-System Settings. במקרה שהמשתמש כן אישר, וה-Kext תקול ויוצר Kernel Panic מיד עם האתחול, המחשב ייכנס ללולאת הפעלות מחדש (Boot Loop). הפתרון המיידי הוא לבצע אתחול ל-Safe Mode. Safe Mode מדלג אוטומטית על טעינת ה-AKC ומעלה רק את הקרנל הנקי של אפל. משם, מנהל ה-IT יכול להסיר את התוכנה התקולה או לבטל את אישור ה-Kext.

4. תיבול ארגוני: אבטחת ה-Firmware, ניהול מפתחות שחזור מוסדיים במצב Boot, והגבלת משתמשים מלשנות רמת אבטחה

1. תיאוריה ברמת-על והיסטוריה (High-Level Theory & History)

בסביבה ארגונית מנוהלת, ה-IT אינו יכול לסמוך על כך שמשתמשים ייכנסו ידנית למצב Recovery, ישנו הגדרות בכלי אבטחת האתחול (Startup Security Utility), ויאשרו הרחבות ליבה (Kexts) או יורידו את רמת האבטחה ל-Reduced Security. יתרה מזאת, הארגון חייב לוודא שמשתמשי קצה — ואפילו מנהלים מקומיים (Local Admins / Volume Owners) — אינם יכולים לפרמט את הכונן או לבצע מניפולציות ב-Boot ללא פיקוח.

בעידן מחשבי Intel, מנהלי IT (וגם משתמשים פרטיים) השתמשו בסיסמת קושחה (Firmware Password) מקומית דרך ה-FirmwarePasswordUtility כדי למנוע גישה לתפריט האתחול (Option key) ולמצב Recovery. עם המעבר ל-Apple Silicon, סיסמת הקושחה הישנה בוטלה לחלוטין.

במקומה, אפל פיתחה מנגנון אבטחה ארגוני בלעדי: Recovery Lock (באמצעות פקודת ה-MDM SetRecoveryLockCommand).

הבדל קריטי: פיצ'ר ארגוני בלעדי ל-MDM (לא זמין ללקוח פרטי!)

בניגוד ל-Firmware Password הישן במחשבי Intel — שבו כל לקוח פרטי יכול היה להגדיר סיסמה מקומית מתוך ה-Recovery — ב-Apple Silicon אין שום אפשרות ללקוח פרטי או עצמאי להגדיר סיסמת קושחה או נעילת Recovery! היכולת לנעול את ה-RecoveryOS ב-Apple Silicon קיימת אך ורק דרך מערכת MDM ארגונית באמצעות פקודת SetRecoveryLock. לקוח פרטי שמחזיק מק עצמאי אינו יכול להפעיל נעילה זו כלל.

2. ארכיטקטורה טכנית עמוקה (Deep Technical Architecture)

ארכיטקטורת הנעילה והניהול השקט ב-Apple Silicon נשענת על שני עמודי תווך ארגוניים משלימים:

┌─────────────────────────────────────────────────────────────────────────────────┐
│               Enterprise Boot Security & Recovery Lock in macOS                 │
└─────────────────────────────────────────────────────────────────────────────────┘
                ┌──────────────────────────────────────────────┐
                │          MDM Server (Jamf / Intune)          │
                └───────┬──────────────────────────────┬───────┘
                        │                              │
        SetRecoveryLockCommand (PIN Escrow)   Bootstrap Token (Volume Owner Proxy)
                        │                              │
                        ▼                              ▼
          ┌───────────────────────────┐  ┌───────────────────────────┐
          │       Recovery Lock       │  │      Bootstrap Token      │
          │   Blocks Physical 1TR     │  │  Silent LocalPolicy Auth  │
          └─────────────┬─────────────┘  └─────────────┬─────────────┘
                        │                              │
        User Holds Power (1TR Boot)        MDM Pushes Kext / OS Policy
                        │                              │
                        ▼                              ▼
          ┌───────────────────────────┐  ┌───────────────────────────┐
          │ Black Screen + Lock Icon  │  │ LocalPolicy Updated in SEP│
          │   Requires MDM Passcode   │  │   No User Password Needed │
          └───────────────────────────┘  └───────────────────────────┘
  • מנגנון ה-Recovery Lock (com.apple.mdm.recoverylock):
    • כאשר שרת ה-MDM שולח את פקודת SetRecoveryLockCommand, המפתח מוצפן ונשמר ב-Secure Enclave.
    • בכל ניסיון של משתמש פיזי לאתחל ל-1TR (לחיצה ממושכת על כפתור ההפעלה ב-Apple Silicon עד להופעת Startup Options), המק מקפיץ מסך שחור עם סמל מנעול הדורש את סיסמת ה-Recovery Lock.
    • חסימה הרמטית: ללא הסיסמה הזו, המשתמש (אפילו אם הוא Admin מקומי או Volume Owner ב-macOS!) אינו יכול:
      1. להגיע למסך הבחירה של ה-Recovery או ה-Startup Options.
      2. לפתוח Terminal במצב Recovery.
      3. לגשת ל-Startup Security Utility כדי לשנות ל-Reduced Security או לאשר Kexts.
      4. להריץ Disk Utility כדי לפרמט את הכונן או להתקין מערכת מחדש דרך 1TR.
    • ה-MDM יכול לאמת את הסיסמה מרחוק באמצעות VerifyRecoveryLockPasswordCommand או לנקות אותה בעת עזיבת עובד באמצעות ClearRecoveryLockCommand.
  • מנגנון ה-Bootstrap Token (אישור שקט ברקע):
    • ה-Bootstrap Token פועל כמיופה כוח קריפטוגרפי של Volume Owner מול ה-Secure Enclave.
    • ניהול Kexts ללא משתמש: כאשר ה-MDM שולח פרופיל Kernel Extension Policy עם Team ID, ה-macOS נעזרת ב-Bootstrap Token כדי לאשר את ה-Kext ולבנות את ה-AKC ברקע, מבלי לדרוש כניסה פיזית ל-Recovery.
    • אכיפת Full Security: ה-MDM יכול לכפות Full Security ב-LocalPolicy ולמנוע מכל משתמש מקומי להוריד את רמת האבטחה.

3. פקודות טרמינל, Plists ולוגים (Terminal Commands, Plists & Logs)

  • בדיקת סטטוס ה-Bootstrap Token מול ה-MDM: sudo profiles status -type bootstraptoken
  • הפקדה יזומה של Bootstrap Token ע"י אדמין בעל Secure Token: sudo profiles install -type bootstraptoken
  • אימות סטטוס ה-Kext Consent ב-LocalPolicy: spctl kext-consent status
  • מעקב בלוגים אחר אימותי MDM ו-Bootstrap Token ב-ULS: log show --predicate 'subsystem == "com.apple.ManagedClient" and composedMessage contains "Bootstrap"' --info

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

  • Edge Case - משתמש נעול במסך Recovery Lock ששכח/אינו יודע את הסיסמה: משתמש קצה או טכנאי מנסה להיכנס ל-Recovery ומקבל מסך מנעול.
    • Troubleshooting: ה-Recovery Lock אינו מנוהל במק עצמו אלא נשלח משרת ה-MDM. על איש ה-IT לגשת לכרטיס המכשיר ב-MDM (כגון Jamf Pro או Microsoft Intune), לשלוף את ה-Recovery Lock Password מתוך מאגר ה-Escrow המוצפן, ולהקליד אותה במסך המנעול.
  • Edge Case - כשל באישורי Kexts שקטים עקב היעדר Bootstrap Token: ה-MDM שולח מדיניות Kernel Extension, אך ההתקנה נכשלת והמשתמש מתבקש לגשת ידנית ל-Recovery.
    • Troubleshooting: בדיקת סטטוס ה-Token ע"י sudo profiles status -type bootstraptoken. אם מופיע escrowed: NO, יש להריץ sudo profiles install -type bootstraptoken עם סיסמת מנהל מקומי להפקדת המפתח בשרת.

עזרים ויזואליים

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

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

Slide138_image169 Slide138_image49 Slide141_image170 Slide142_image171 Slide142_image172 Slide142_image173 Slide142_image174 Slide142_image175 Slide142_image176 Slide142_image177 Slide80_image19 Slide80_image93 26-Tahoe-Boot-Camp-scaled