Windows LAPS — להפסיק סיסמת Administrator מקומית משותפת לכל המחשבים

בשטח ה-imaging יש “קיצור דרך קלאסי” שנמשך שנים. צורבים סיסמת Administrator מקומית משותפת על תמונת המאסטר ומפיצים אותה לכל המחשבים — כשנכנסים לתחזוקה פשוט עושים logon באותה סיסמה, ועל הנייר זה נשמע הגיוני. אבל היום זו בדיוק הנקודה שתוקפים מכוונים אליה ראשונה כ-“ייצור מפתחות-שכפול”. פריצה למחשב אחד הופכת מיד לפריצה לכולם.

המאמר הזה מיועד לאנשי IT בעסקים קטנים ובינוניים, ולמפתחים שמטפלים ב-imaging של מחשבים ובתחזוקה. הוא מסדר למה סיסמת Administrator מקומית משותפת מסוכנת, ואז מסביר על פי מקורות ראשוניים נכון לאוגוסט 2026 את Windows LAPS (Local Administrator Password Solution) המובנה במערכת ההפעלה: איך זה עובד, איך בוחרים לפי סביבה, איך מטמיעים, ואיפה נופלים בתפעול. זה המשך לסדרת האבטחה לצוות IT שכללה BitLocker, ביטול WSUS, Firewall ו-Certificate Store.

1. קודם כל, המסקנות

• סיסמת Administrator מקומית משותפת לכל המחשבים היא כר פורה ל-lateral movement שמפיצה פריצה ממחשב אחד לכל השאר. אם הסיסמה זהה, גם ה-NT hash זהה, ולכן hash שנשאב ממחשב אחד פותח את כל השאר ב-Pass-the-Hash.¹
• Windows LAPS היא תכונת מערכת שמגרילה סיסמת Administrator מקומית לכל מחשב ומסובבת אותה אוטומטית. Microsoft מציינת אותה בראש היתרונות כהגנה מ-Pass-the-Hash ומ-lateral movement.¹
• היא מובנית ב-Windows 10/11 אחרי עדכון 11 באפריל 2023, וב-Windows Server 2019/2022 ואילך. בניגוד ל-LAPS הישן (הפצת MSI), אין צורך בהתקנה נוספת. LAPS הישן הפך ל-deprecated מ-Windows 11 23H2 ואילך.¹
• יעד השמירה הוא Active Directory או Microsoft Entra ID — אחד מהם. מחשב domain-joined בלבד שומר ב-AD, Entra-joined בלבד שומר ב-Entra ID, ו-hybrid join בוחר אחד מהם. במחשב workgroup שאינו מצורף לאף אחד מהם אי אפשר להשתמש בזה.¹
• כברירת מחדל לא קורה דבר. ערך ברירת המחדל של BackupDirectory הוא “Disabled”, ורק אחרי שמציינים יעד במדיניות (GPO או Intune/CSP) זה מתחיל לרוץ.²
• לשמירה ב-AD נדרשות שלוש הכנות מראש. הרחבת schema (Update-LapsADSchema), הרשאת כתיבה למחשב עצמו (Set-LapsADComputerSelfPermission), ותכנון הרשאות עיון (Set-LapsADReadPasswordPermission).³
• עיון בסיסמה הוא Get-LapsADPassword / Get-LapsAADPassword, החלה מיידית היא Invoke-LapsPolicyProcessing, וסיבוב מיידי בצד המחשב הוא Reset-LapsPassword.⁴
• סיסמה שנעשה בה שימוש הופכת לחד-פעמית אוטומטית. אחרי authentication בחשבון המנוהל, כברירת מחדל אחרי 24 שעות רצים איפוס + sign-out (PostAuthenticationActions).²

ב-diagram, solid line מציינת relation שתמיד מתקיים ו-dashed line מציינת relation מותנה (התנאים מופיעים בהסבר של כל relation ב-detail page). הרשימה המלאה של ה-relations (סה”כ 31, כולל evidence ו-certainty) וההגדרות של ה-concepts המרכזיים נמצאות ב-detail page של ה-knowledge map (ביפנית). Data: JSON-LD / Turtle

2. למה סיסמת Administrator מקומית משותפת לכל המחשבים מסוכנת

קודם תופסים במדויק את מבנה האיום. מה קורה כשסיסמת חשבון ה-Administrator המקומי (Administrator המובנה, או חשבון תחזוקה שנוצר ב-imaging) זהה בכל המחשבים?

Windows אינו שומר את סיסמת החשבון המקומי כמו שהיא, אלא כ-NT hash שמחושב מהסיסמה. ובאימות NTLM, ה-hash עצמו הוא חומר האימות. כלומר, אם הסיסמה זהה, גם ה-hash זהה בכל המחשבים. תוקף שתופס הרשאות Administrator במחשב אחד באמצעות malware או תקיפה ממוקדת יכול לשלוף את ה-hash מהזיכרון או ממסד הנתונים המקומי (SAM). מכאן מתחיל העניין האמיתי: אפשר להשתמש ב-hash שנשלף לאימות בלי להחזיר אותו לסיסמה גלויה. זו התקפת Pass-the-Hash. בסביבת סיסמה משותפת, hash ממחשב אחד הופך ל-“מפתח-שכפול” לכל השאר, והפריצה מתפשטת הצידה בבת אחת. את מנגנון NTLM ואת הסיבה שאימות עובר עם hash בלבד מסביר המאמר “NTLM ו-Kerberos באיורים”.

flowchart TB
    accTitle: סיסמה משותפת מתפשטת ב-Pass-the-Hash
    accDescr: כש-NT hash זהה בכל המחשבים פריצה למחשב אחד מתפשטת לכולם, ו-LAPS שמפריד סיסמה לכל מחשב חוסם את הנתיב הזה
    subgraph BEFORE["סביבת סיסמה משותפת"]
        A1["פריצה ל-PC-01<br/>(malware / תקיפה ממוקדת)"] --> H["שליפת NT hash של ה-Administrator"]
        H -->|"Pass-the-Hash"| B1["PC-02"]
        H -->|"Pass-the-Hash"| B2["PC-03"]
        H -->|"Pass-the-Hash"| B3["…lateral movement לכל המחשבים"]
    end
    subgraph AFTER["אחרי הטמעת LAPS"]
        C1["פריצה ל-PC-01"] --> H2["שליפת ה-hash של PC-01"]
        H2 -->|"כי הסיסמה שונה לכל מחשב"| STOP["במחשבים אחרים אי אפשר<br/>לאמת עם ה-hash הזה (חוסם lateral<br/>movement דרך Administrator מקומי)"]
    end

איור 1: סיסמה משותפת הופכת hash אחד למפתח לכל המחשבים; LAPS חוסם את הנתיב הזה בסיסמה שונה לכל מחשב.

כיוון הטיפול ברור: סיסמת Administrator מקומית שונה לכל מחשב, ומשנים אותה באופן קבוע. אז hash שנדלף ממחשב אחד לא יעבוד באחרים, ונתיב ה-lateral movement של שימוש חוזר בחשבון Administrator מקומי נחסם (שימו לב: זה לא חוסם נתיבים אחרים כמו גניבת domain credentials במחשב שנפרץ). אבל לעשות את זה ידנית אינו מציאותי. להגריל עשרות סיסמאות, לנהל inventory, ולעדכן במחזור — עלות התפעול הזו בדיוק היא הסיבה שהקיצור של סיסמה משותפת שרד. את “ההפרדה והשינוי המחזורי האוטומטי”, יחד עם שמירה בטוחה ב-directory, לוקחת על עצמה מערכת ההפעלה ב-Windows LAPS. Microsoft עצמה מציינת בראש יתרונות Windows LAPS את “ההגנה מפני התקפות Pass-the-Hash והתקפות lateral-traversal”.¹

לגבי הבסיס של ניהול הרשאות — לא לעבוד ביום-יום בחשבון Administrator, ולצמצם את שימושי חשבון התחזוקה — ראו גם “מתי באמת נדרשות הרשאות Administrator ב-Windows”.

3. מהו Windows LAPS — ההבדל מ-LAPS הישן

לשם LAPS יש היסטוריה, ובשטח אם לא מבהירים “על איזה LAPS מדברים” השיחה מתפזרת.

LAPS הישן (legacy Microsoft LAPS) הוא כלי התקנה נוספת שפרסמה Microsoft ב-2016.¹ מפיצים חבילת MSI לכל המחשבים, מתקינים Group Policy extension (CSE), ושומרים את הסיסמה בטקסט גלוי בתכונה ms-Mcs-AdmPwd של Active Directory — וזו הייתה בפועל התקן לאורך שנים.

Windows LAPS הוא מימוש נפרד, מובנה במערכת, כיורש. הוא כלול ב-Windows 10 אחרי עדכון 11 באפריל 2023, ב-Windows 11 21H2/22H2 וב-Windows Server 2019/2022, וב-Windows 11 23H2 ואילך וב-Windows Server 2025 ואילך הוא מגיע מההתחלה.¹ כלומר, אם מיישמים עדכונים כרגיל, Windows LAPS כבר נמצא במחשבי הארגון. נשאר רק להגדיר מדיניות.

הנקודה החשובה היא ש-Windows LAPS אינו תיקון של LAPS הישן אלא מימוש נפרד לגמרי, וגם תכונות ה-schema ב-AD שונות (msLAPS-*).⁴ כדי לעזור במעבר מ-LAPS הישן קיים גם “מצב emulation” שבו Windows LAPS מפרש את הגדרות ה-GPO הישנות, אבל יש לו מגבלות רבות (פרק 6) ואין סיבה להשתמש בו בהטמעה חדשה.

4. לאן נשמרת הסיסמה — טבלת החלטה לפי סביבה

Windows LAPS “מגבה” את הסיסמה שנוצרה ל-directory. יעד השמירה נקבע לפי מצב ה-join של המחשב, ואי אפשר לשמור גם ב-AD וגם ב-Entra ID.¹

בשמירה ב-AD הסיסמה נכתבת לתכונות אובייקט המחשב (בטקסט גלוי msLAPS-Password, בהצפנה msLAPS-EncryptedPassword, והתוקף msLAPS-PasswordExpirationTime).⁶ מתוכן, התכונות שכוללות סיסמה (msLAPS-Password ומשפחת msLAPS-Encrypted*) מסומנות כ-confidential, ואי אפשר לעיין בהן בהרשאת קריאה רגילה. לעומת זאת ל-msLAPS-PasswordExpirationTime אין סימון סודיות (SearchFlags: 0), וזו metadata שניתן לקרוא בהרשאת הקריאה כברירת מחדל.⁶ לשמירה מוצפנת ולהיסטוריית סיסמאות נדרש DFL 2016 ומעלה.³ שימו לב שערך ברירת המחדל של הגדרת ההצפנה (ADPasswordEncryptionEnabled) הוא Enabled.² ב-domain עם DFL ישן מ-2016 אי אפשר להצפין, ולכן אל תסמכו על מעבר אוטומטי לטקסט גלוי — משביתים הצפנה במפורש במדיניות ושומרים בטקסט גלוי עם הגנת ACL.³

בשמירה ב-Entra ID התצורה הסטנדרטית היא להפעיל “Local administrator password management” בצד ה-tenant, ואז להפיץ מדיניות מ-Intune דרך LAPS CSP. מבחינת רישיון, התכונה עצמה חינמית, לשמירה ב-AD אין דרישה נוספת, ושמירה ב-Entra ID זמינה מ-Microsoft Entra ID Free ומעלה.¹

שאין חלופה מובנית למחשב workgroup נובע מכך שאין directory לשמור אליה. בפועל מגדירים ב-imaging סיסמה שונה לכל מחשב ומנהלים inventory ב-password manager. אם ה-imaging כבר בסקריפט, משלבים בו יצירת סיסמה לפי מחשב (ראו “אוטומציית PC kitting עם winget + PowerShell”).

5. הטמעה בפועל — סביב תצורת AD+GPO

כאן עוקבים אחרי הצעדים בתצורת AD domain + GPO, שהיא הנפוצה במספר. את ההבדל מול Entra+Intune מסכמים בסוף.

5.1. הכנה מראש (פעם אחת)

בשמירה ב-AD מסיימים את הכנת ה-forest לפני שמפיצים מדיניות.³

# 1. הרחבת schema (פעם אחת ב-forest. מריצים בהרשאות Schema Admins)
Update-LapsADSchema

# 2. מעניקים למחשבים תחת ה-OU היעד הרשאה לעדכן את תכונת הסיסמה של עצמם
Set-LapsADComputerSelfPermission -Identity "OU=PCsPnimiim,DC=example,DC=co,DC=jp"

# 3. מעניקים לקבוצה שרשאית לעיין בסיסמה (Domain Admins יכולים כברירת מחדל)
Set-LapsADReadPasswordPermission -Identity "OU=PCsPnimiim,DC=example,DC=co,DC=jp" `
    -AllowedPrincipals @("EXAMPLE\HelpdeskAdmins")

# 4. מעניקים לקבוצה שרשאית לשנות תוקף סיסמה (פקיעה מיידית = הוראת איפוס)
#    (נדרש ל-Set-LapsADPasswordExpirationTime ב-5.4. ל-Domain Admins זה כברירת מחדל)
Set-LapsADResetPasswordPermission -Identity "OU=PCsPnimiim,DC=example,DC=co,DC=jp" `
    -AllowedPrincipals @("EXAMPLE\HelpdeskAdmins")

# 5. בודקים שאין מחזיקי הרשאות עיון בלתי צפויים (מפורט בפרק 6)
Find-LapsADExtendedRights -Identity "OU=PCsPnimiim,DC=example,DC=co,DC=jp"

כשמשתמשים בשמירה מוצפנת (DFL 2016 ומעלה, מופעל כברירת מחדל) נדרשת עוד הגדרה. הרשאת עיון והרשאת פענוח הן דבר שונה, וכברירת מחדל רק Domain Admins יכולים לפענח.³ אם רוצים שקבוצת הדלפק באמת תוכל למשוך סיסמאות, מציינים את אותה קבוצה (EXAMPLE\HelpdeskAdmins) גם ב-ADPasswordEncryptionPrincipal בצד המדיניות.² אם שוכחים את זה, גם אחרי שנתתם הרשאת עיון כמו למעלה מגיעים למצב “אפשר לקרוא את התכונה אבל אי אפשר לפענח”.

Update-LapsADSchema אינו אותו דבר כמו Update-AdmPwdADSchema של LAPS הישן, והתכונות שנוספות הן msLAPS-*. גם בסביבה שכבר הוטמע בה LAPS ישן, הרחבת ה-schema של Windows LAPS נדרשת מחדש.⁴ אם משתמשים ב-Central Store של GPO, תבניות Windows LAPS אינן מועתקות לשם דרך Windows Update, ולכן מעתיקים ידנית.² באותו זמן מעתיקים לא רק את %windir%\PolicyDefinitions\LAPS.admx אלא גם את משאב השפה LAPS.adml (לממשק עברי, תת-התיקייה he-IL) לתיקיית השפה המתאימה. בלי ADML, תצוגת מדיניות LAPS ב-GPMC נופלת לשגיאת משאבים.

5.2. הגדרת מדיניות

מיקום ההגדרה ב-GPO הוא “Computer Configuration > Policies > Administrative Templates > System > LAPS”.² ההגדרה החובה המינימלית היא יעד השמירה, וכל עוד BackupDirectory אינו “Active Directory” (ערך 2), Windows LAPS לא עושה דבר (ברירת המחדל היא “Disabled”).² ההגדרות העיקריות וערכי ברירת המחדל:

מה שקל לפספס כאן הוא Enabled/Disabled של החשבון המנוהל. Administrator המובנה מושבת כבר בהגדרת Windows.⁷ Windows LAPS מנהל סיסמה גם לחשבון שנשאר Disabled, אבל אינו מפעיל את החשבון.² כלומר בתצורה כברירת מחדל אפשר להגיע למצב “הסיסמה שמורה ב-directory, אבל אף אחד לא יכול להיכנס בחשבון הזה”. כדי להשתמש בו כנתיב שחזור בוחרים במפורש אחת מאלה: מפעילים את Administrator המובנה ומפעילים אותו, מנהלים חשבון תחזוקה מותאם שכבר פעיל, או ב-Windows 11 24H2 / Server 2025 ואילך מנהלים גם את מצב הפעילות עם הגדרות AutomaticAccountManagement.²

5.3. אישור פעולה ושליפת הסיסמה

Windows LAPS מעבד מדיניות תקפה אחת לשעה. כשרוצים לבדוק בלי לחכות, מריצים עיבוד מיידי במחשב היעד.³

# בצד המחשב: עיבוד מדיניות מיידי (הקלאסיקה בבדיקה)
Invoke-LapsPolicyProcessing

# בצד המחשב: בדיקת התוצאה ב-Event Log
# 10003=תחילת עיבוד / 10004=הצלחה / 10005=כישלון / 10018=שמירה ב-AD הצליחה
Get-WinEvent -LogName "Microsoft-Windows-LAPS/Operational" -MaxEvents 20

את הסיסמה השמורה שולפים ממחשב ניהול בעל הרשאה.³

# שליפת סיסמה מ-AD (בלי -AsPlainText אפשר לטפל במחרוזת מוסתרת)
Get-LapsADPassword -Identity PC-0123 -AsPlainText

# דוגמת פלט: Account, Password, PasswordUpdateTime, ExpirationTimestamp,
#         Source (EncryptedPassword אם שמירה מוצפנת), AuthorizedDecryptor וכו'

לחובבי ממשק גרפי נוספה לשונית LAPS למאפייני המחשב ב-Active Directory Users and Computers, ומשם אפשר לעיין גם כן.¹

5.4. סיבוב מיידי

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

# ממחשב הניהול: שמים את התוקף ל"עכשיו", והעיבוד הבא יסובב
Set-LapsADPasswordExpirationTime -Identity PC-0123
# אם דוחפים עיבוד מיידי במחשב היעד, הסיסמה מתחלפת במקום
Invoke-LapsPolicyProcessing

# סיבוב מיידי ישירות על מחשב היעד
Reset-LapsPassword

5.5. ההבדל בתצורת Entra+Intune

בשמירה ב-Entra ID אין צורך בהרחבת schema או בהגדרת ACL כמו ב-AD.³ במקום זה חייבים להפעיל Local administrator password management ב-[Device settings] של tenant Microsoft Entra; בלי זה המחשב לא יוכל לשמור סיסמה.⁵ המדיניות מופצת מ-Intune דרך LAPS CSP, ואת הסיסמה שולפים במסך מרכז הניהול של Entra/Intune או ב-Get-LapsAADPassword דרך Microsoft Graph.⁵

# שליפת סיסמה שמורה ב-Entra ID דרך Graph (דוגמה לגישה delegated)
# מבקשים במפורש את ה-scopes הנדרשים בחיבור
Connect-MgGraph -Scopes "Device.Read.All","DeviceLocalCredential.Read.All"
Get-LapsAADPassword -DeviceIds PC-0123 -IncludePasswords -AsPlainText

מזהה Event השמירה המוצלחת הוא 10018 ב-AD, ו-10029 ב-Entra ID.⁸

6. מלכודות בתפעול

הטמעה אינה סוף הסיפור. אלה הנקודות שנופלים בהן בשטח.

6.1. הרשאות העיון רחבות יותר ממה שחשבתם

תכונת הסיסמה היא confidential ולכן אינה נראית בקריאה רגילה, אבל principal עם All Extended Rights על ה-OU היעד יכול לקרוא אותה. בסביבה שבה בעבר הואצלו הרשאות רחבות על ה-OU, קבוצות בלתי צפויות עלולות לקרוא סיסמאות. בהטמעה מריצים Find-LapsADExtendedRights, ואם מופיע מישהו מלבד SYSTEM ו-Domain Admins — בודקים מחדש את ההאצלה.³

בנוסף, הפעלת שמירה מוצפנת (ADPasswordEncryptionEnabled) מפרידה בין הרשאת עיון להרשאת פענוח. מי שקיבל רק הרשאת עיון לא יכול לפענח סיסמה מוצפנת; כברירת מחדל רק Domain Admins יכולים לפענח, ולשינוי מציינים קבוצה ב-ADPasswordEncryptionPrincipal.³ צמצום בסגנון “הדלפק יכול לפענח רק סיסמאות של ה-OU שלו” מתכננים בשתי השכבות האלה.

6.2. מנגנון “השתמש וזרוק” ומגבלותיו — PostAuthenticationActions

אם סיסמה שהדלפק משך נשארת על פתק או בצ’אט, אין טעם. Windows LAPS מזהה authentication בחשבון המנוהל, ואחרי grace period (PostAuthenticationResetDelay, כברירת מחדל 24 שעות) מריץ ניקיון אוטומטי. הפעולה כברירת מחדל היא “איפוס סיסמה ו-sign-out”.²

יש שתי נקודות זהירות. ראשית, grace period 0 משבית את התכונה עצמה.² שנית, ה-trigger הוא “authentication” ולא “עיון בסיסמה”. אם רק משכתם סיסמה מה-directory ולא השתמשתם בה, האיפוס האוטומטי לא רץ. את הסיסמה שעיינתם בה, בין שהשתמשתם ובין שלא, מפוגגים בסיום העבודה עם Set-LapsADPasswordExpirationTime — ואת זה מקבעים בנוהל.

6.3. שימוש במקביל ומעבר מ-LAPS הישן

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

• במחשב שחלה עליו ולו מדיניות Windows LAPS אחת, Windows LAPS עצמו מתעלם תמיד ממדיניות LAPS הישן (עדיפות ל-Windows LAPS).⁹ אבל זה רק צד הפרשנות של Windows LAPS. אם ה-CSE של LAPS הישן (Group Policy extension) עדיין מותקן, ה-CSE הישן ממשיך לעבד את ה-GPO הישן באופן עצמאי. אם משאירים את המחשב ביעד ההחלה של ה-GPO הישן ומפעילים מדיניות Windows LAPS, שניהם מסובבים את אותו חשבון — ניהול כפול.
• “מצב emulation” שבו Windows LAPS מעבד הגדרות GPO של LAPS הישן פועל רק במחשבים שבהם לא מותקן ה-CSE של LAPS הישן. הוא משתמש בהנחות הישנות (schema ישן, ACL ישן) ואי אפשר להשתמש בתכונות חדשות כמו הצפנה או שמירה ב-Entra.⁹
• אחרי עדכון מערכת בלבד, מחשב שנותרה בו GPO של LAPS הישן עלול להתחיל לרוץ במצב emulation בלי כוונה. כדי למנוע שינוי סיסמה בלתי צפוי מיד אחרי imaging, אפשר לכבות emulation במפתח תצורה מקומי עם BackupDirectory=0.⁹

המעבר הוא בסדר “מוציאים את ה-OU היעד מהחלת GPO של LAPS הישן (או מסירים את ה-CSE הישן) → מחילים מדיניות Windows LAPS → מפרקים את שארית ה-GPO וה-CSE הישנים”: קודם מורידים את הניהול הישן ואז מפעילים את החדש, כך שלכל מחשב תמיד ברור תחת איזה ניהול הוא. בסדר ההפוך (קודם מדיניות Windows LAPS) מתקבל הניהול הכפול במחשבים שנותר בהם ה-CSE הישן.

6.4. Audit — להשאיר “מי ראה ומתי”

ברגע שסיסמאות Administrator מקומי נשמרות במרוכז, היסטוריית העיון היא יעד audit. פעולת המחשב נרשמת כולה בערוץ ייעודי ב-Event Log (“Applications and Services Logs > Microsoft > Windows > LAPS > Operational”): תחילת עיבוד 10003 / הצלחה 10004 / כישלון 10005, שמירה מוצלחת 10018 (AD) / 10029 (Entra), ותוכן המדיניות החלה 10021-10023.⁸ בצד AD מגדירים audit על ה-OU היעד עם Set-LapsADAuditing ורושמים גישה לתכונת הסיסמה ב-Security log של domain controller.⁴ בשמירה ב-Entra ID עוקבים ב-audit logs ובדוחות בצד Entra.¹

7. סיכום

• סיסמת Administrator מקומית משותפת לכל המחשבים יוצרת מבנה שבו פריצה למחשב אחד מגיעה לכולם ב-Pass-the-Hash. הטיפול הוא הפרדה לכל מחשב וסיבוב אוטומטי, וזה מה ש-Windows LAPS עושה.
• Windows LAPS מובנה ב-Windows 10/11 אחרי עדכון אפריל 2023 וב-Windows Server 2019/2022 ואילך, בלי התקנה נוספת. LAPS הישן (הפצת MSI) הוא deprecated, ובחדש בוחרים רק ב-Windows LAPS.
• יעד השמירה הוא AD או Entra ID — אחד מהם — לפי מצב ה-join. במחשב workgroup אי אפשר להשתמש בזה, ולכן נדרש ניהול ידני לפי מחשב או שינוי צורת ה-join.
• כברירת מחדל זה כבוי. בתצורת AD מכינים הרחבת schema, הרשאת עדכון עצמי והרשאת עיון, ורק אחרי BackupDirectory ב-GPO זה מתחיל לרוץ.
• התפעול היומיומי נשען על PowerShell. שליפה: Get-LapsADPassword / Get-LapsAADPassword, החלה מיידית: Invoke-LapsPolicyProcessing, סיבוב מיידי: Reset-LapsPassword.
• המלכודות הן עיון בלתי צפוי דרך extended rights, העובדה ש-PostAuthenticationActions לא רץ מעיון בלבד, ניהול כפול עם LAPS הישן, ו-audit חסר. בהטמעה מקבעים בדיקת הרשאות ב-Find-LapsADExtendedRights ונוהל פקיעה אחרי עיון.

מאמרים קשורים

• מדריך מעשי ל-BitLocker — הצפנת כוננים שמתחילה בניהול מפתח השחזור
• NTLM ו-Kerberos באיורים — למה האימות “נופל” ל-NTLM
• מתי באמת נדרשות הרשאות Administrator ב-Windows - UAC, אזורים מוגנים, ואיך מבחינים בתכנון
• אוטומציית PC kitting עם winget + PowerShell — הפיכת ספר הריצה לניתן-להרצה
• מהו TPM ב-Windows — “כספת שלא מוציאה את המפתח” והפעלה מדודה
• לפני שמשליכים מחשב Windows — רשימת תיוג מעשית למחיקת נתונים, שחרור חשבון וגיבוי

תחומי ייעוץ קשורים

KomuraSoft LLC מטפלת בכתיבת סקריפטים לאוטומציית imaging של מחשבים, בארגון הגדרות אבטחת קצה כולל הטמעת Windows LAPS, ובתכנון מעבר מניהול סיסמה משותפת קיים. אפשר להתחיל משלב מוקדם כמו “יש לנו ספר imaging אבל הוא תלוי-אדם” או “רוצים LAPS אבל לא בטוחים בהרשאות AD”.

• פיתוח אפליקציות Windows
• ייעוץ טכני וסקירת תכנון
• יצירת קשר

מקורות

מאמרים קשורים

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

נושאים קשורים

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

שירותים הקשורים לנושא הזה

המאמר קשור ישירות לשירותים הבאים.

שאלות נפוצות

שאלות נפוצות בפניות בנושא המאמר.

כבר מפעילים את LAPS הישן (Microsoft LAPS שמופץ כ-MSI). צריך לעשות משהו?

כן — להתחיל לתכנן מעבר. LAPS הישן הפך ל-deprecated מ-Windows 11 23H2 ואילך, ובמערכות הפעלה חדשות התקנת ה-MSI עצמה נחסמת. במערכת הנוכחית (Windows 10/11 עם עדכון אפריל 2023, ו-Windows Server 2019/2022 ואילך) Windows LAPS כבר מובנה, ולכן אפשר לעבור בלי התקנה נוספת. בתקופת המעבר אפשר לתת ל-Windows LAPS להמשיך לעבד את המדיניות הישנה ב"מצב emulation של LAPS הישן", אבל יש מגבלות: זה לא עובד במחשבים שמותקן בהם ה-CSE של LAPS הישן, ואי אפשר להשתמש בתכונות חדשות כמו הצפנה או שמירה ב-Entra ID. תצורה שבה אותו חשבון מנוהל גם בישן וגם בחדש אינה נתמכת, לכן מעבירים מחשב-מחשב ומבהירים מי מנהל את החשבון.

אחרי שהשתמשתי בסיסמה שנמשכה, אפשר להשאיר אותה כמו שהיא?

בתצורה כברירת מחדל הניקיון אוטומטי, אבל לא מיידי. ל-Windows LAPS יש PostAuthenticationActions: אחרי שמזהים authentication (logon) בחשבון המנוהל, אחרי grace period מתבצעת הפעולה. כברירת מחדל, 24 שעות אחרי ה-authentication מתבצעים איפוס סיסמה ו-sign-out. במילים אחרות, עד שזמן החסד נגמר אותה סיסמה עדיין תקפה — היא לא מתבטלת "ברגע השימוש". המנגנון גם מופעל רק כש"אימתו בסיסמה", לא כש"רק עיינו בה ב-directory". הדרך הבטוחה היא לפוגג במפורש בסיום העבודה. בשמירה ב-AD משתמשים ב-Set-LapsADPasswordExpirationTime (ה-cmdlet הזה ייעודי לשמירה ב-AD). בשמירה ב-Entra ID מריצים Reset-LapsPassword על המחשב עצמו, או משתמשים בפעולת סיבוב סיסמת ה-Administrator המקומית ב-Intune.

אפשר להשתמש בזה במחשב workgroup, בלי join ל-domain ובלי Entra ID?

לא. Windows LAPS זקוק ל-Active Directory או ל-Microsoft Entra ID כיעד שמירה, ולמחשב שאינו מצורף לאף אחד מהם אין יעד לגיבוי. אם ממשיכים ב-workgroup, החלופה המציאותית היא סיסמת Administrator מקומית שונה לכל מחשב וניהול ידני ב-inventory במקום בטוח (password manager וכו'). כשמספר המחשבים גדל, זה הזמן לשקול join ל-Entra ID (ו-Intune) או join ל-domain כדי ליהנות מניהול מרכזי כולל LAPS.

מי יכול לעיין בסיסמאות שנשמרו?

בשמירה ב-Active Directory, כברירת מחדל חברי Domain Admins יכולים לעיין, ולמשתמשים ולקבוצות אחרים מעניקים הרשאה במפורש עם Set-LapsADReadPasswordPermission. תכונת הסיסמה היא confidential, אבל principal עם All Extended Rights על ה-OU עדיין יכול לקרוא אותה, לכן חובה להריץ Find-LapsADExtendedRights בהטמעה ולוודא שאין מחזיקים בלתי צפויים. אם מפעילים הצפנה עם ADPasswordEncryptionEnabled (נדרש DFL 2016 ומעלה), אפשר לצמצם מי רשאי לפענח לקבוצה שמציינים ב-ADPasswordEncryptionPrincipal. בשמירה ב-Entra ID, כברירת מחדל תפקידים בעלי הרשאות גבוהות כמו Global Administrator יכולים לעיין, ולשליפה ב-Microsoft Graph נדרשת ההרשאה DeviceLocalCredential.Read.All.

צריך רישיון נוסף כדי להשתמש ב-Windows LAPS?

התכונה עצמה חינמית. Windows LAPS היא תכונת מערכת מובנית ב-Windows נתמך, ולשמירה ב-Active Directory אין דרישת רישיון נוספת. גם שמירה ב-Microsoft Entra ID זמינה מרישיון Microsoft Entra ID Free ומעלה. רישיונות Intune להפצת מדיניות, וכן תכונות נלוות של Entra/Intune, עשויים לדרוש רישיון נפרד — את זה כן בודקים.

פרופיל הכותב

עמוד היכרות עם כותב המאמר.

Go Komura

מנהל KomuraSoft LLC

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