בחירת חשבון שירות Windows — LocalSystem, חשבונות וירטואליים ו-gMSA

«שירות פנימי שהרצנו בינתיים כ-LocalSystem סומן בביקורת אבטחה כ״הרשאה מופרזת״. למה לשנות אותו?» «השירות לא הצליח לגשת לתיקייה משותפת, אז אנחנו מריצים אותו כמשתמש דומיין. כשהסיסמה פגה השירות נעצר, אז הפכנו אותה ללא תפוגה וכתבנו אותה בגלוי בספר ההפעלה.» — בין ייעוצים סביב שירותי Windows של לקוחות, שתי אלה הן קלאסיקה.

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

flowchart TB
    accTitle: שלושה דברים שחשבון ההתחברות מחליט
    accDescr: שירות רץ תמיד בהקשר האבטחה של חשבון כלשהו, והחשבון מחליט את כל מה שהוא יכול לעשות מקומית, כמי הוא נראה מהצד הרחוק של הרשת, ומי מנהל את הסיסמה
    acct["חשבון ההתחברות של השירות"] --> local["מה הוא יכול לעשות מקומית"]
    acct --> net["כמי הוא נראה מהצד הרחוק של הרשת"]
    acct --> pwd["מי מנהל את הסיסמה"]

איור 1: בחירת חשבון ההתחברות היא החלטת עיצוב שקובעת יחד הרשאות מקומיות, זהות רשת וניהול סיסמה.

יש למעשה שישה בחירות — LocalSystem, LocalService, NetworkService, חשבון וירטואלי (NT SERVICE\<שם-השירות>), משתמש דומיין ו-gMSA (חשבון שירות מנוהל קבוצתי). מיועד לאנשי IT בעסקים קטנים ובינוניים ולמפתחי יישומי Windows, המאמר מסדר את ההרשאות, זהות הרשת וניהול הסיסמאות של השישה בטבלה אחת ומסכם זרימת החלטה, על בסיס מקורות ראשוניים של Microsoft Learn נכון לאוגוסט 2026.

איך בונים את השירות עצמו (בחירה בין מתזמן המשימות לשירות, מימוש ב-.NET Worker Service) מכוסה ב«How to Build and Operate Windows Services». המאמר הזה מתרכז ב«חשבון ההתחברות», שם קורות רוב התאונות.

1. קודם המסקנה

• בספק, חשבון וירטואלי הוא המועמד הראשון לשירות שמסתיים בתוך מכונה אחת, ו-gMSA הוא המועמד הראשון לשירות שניגש למשאב בתוך הדומיין בזהות ייחודית לשירות. גם Microsoft נותנת הנחיה להשתמש בחשבון מנוהל (MSA / חשבון וירטואלי) בכל מקום אפשרי.¹²
• אל תבחרו LocalSystem כי «זה עובד». האסימון כולל SYSTEM ו-BUILTIN\Administrators ומחזיק הרשאות חזקות כמו SeDebugPrivilege, ולכן השתלטות מאבדת כמעט הכול במכונה הזו. שברירת המחדל של sc.exe create היא LocalSystem הוא כר הגידול של התאונה הזו.³⁴
• ההבדל בין LocalService ל-NetworkService הוא זהות הרשת. ההרשאות המקומיות מינימליות לשניהם, אבל לצד הרחוק LocalService נראה אנונימי ו-NetworkService נראה כחשבון המחשב.⁵
• **חשבון וירטואלי (NT SERVICE\<שם-השירות>) הוא ברירת המחדל המודרנית שיכולה להפריד זהות לכל שירות בלי צורך בניהול סיסמה.** אפשר לציין «NT SERVICE\\שם-השירות» ישירות ב-ACL, וחשבון השירות המוגדר כברירת מחדל של SQL Server הוא זה גם כן.[^understand-service-accounts][^sql-service-accounts]
• כש-LocalSystem, NetworkService או חשבון וירטואלי יוצאים לרשת הם הופכים לחשבון המחשב (DOMAIN\שם-המחשב$). מתן PC$ ב-ACL של תיקייה משותפת או SQL Server לעיתים קרובות מאפשר לוותר על משתמש דומיין.³⁶
• תצורה שמשתמשת במשתמש דומיין לשירות הופכת לחוב גם בתפעול סיסמאות וגם מול Kerberoasting. SCM מתחבר עם הסיסמה המאוחסנת, ולכן תפוגה הופכת לכישלון הפעלה, ו«לעולם לא יפוג + פתק גלוי» שמונע זאת הופمع למתנה לתוקף.⁷⁸
• gMSA גורם ל-Active Directory לייצר ולסובב את הסיסמה אוטומטית. הדרישות הן דומיין ומפתח שורש KDS, ומגדירים את השירות ל-«DOMAIN\שם-החשבון$» עם שדה הסיסמה ריק. חלק מהיישומים אינם תומכים בכך, ולכן צריך לאמת מראש.⁹¹⁰
• שינוי החשבון משנה את הנחות הפרופיל, %TEMP% ו-DPAPI. נתונים שהוגנו ב-DPAPI של החשבון הישן אינם ניתנים לפענוח בחשבון החדש.
• מלאי המצב הנוכחי ניתן לאישור מחשבונות ההתחברות של רשימת השירותים וממזהה אירוע 4624 (סוג התחברות 5).¹¹

במשפט אחד, מסקנת המאמר: הפכו תצורה ש«אינה נותנת לשירות סיסמה אנושית» (חשבונות מובנים, חשבון וירטואלי, gMSA) לברירת המחדל, וטפלו במשתמש דומיין כמוצא אחרון.

2. התמונה הגדולה של הבחירות — שישה חשבונות התחברות בטבלה אחת

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

flowchart TB
    accTitle: מה SCM עושה בהפעלת שירות
    accDescr: SCM מתחבר כחשבון שהוגדר, בהצלחה יוצר אסימון גישה ומקצה אותו לתהליך השירות, ולאחר מכן גישה למשאבים מוכרעת בהתאמת האסימון ל-ACL
    scm["SCM"] --> logon["התחברות כחשבון שהוגדר"]
    logon --> token["יצירת אסימון גישה"]
    token --> proc["הקצאתו לתהליך השירות"]
    proc --> access["גישה לקובץ או לצינור"]
    access --> check{"האם ה-ACL מתירה?"}
    check -->|כן| ok["הגישה מצליחה"]
    check -->|לא| deny["הגישה נדחית"]

איור 2: כל גישת משאב של השירות מוכרעת בהתאמת האסימון ש-SCM יצר בהפעלה ל-ACL.

ל-LocalSystem, LocalService, NetworkService ולחשבון וירטואלי אין כלל מושג של סיסמה. היחידים שמתחברים עם סיסמה מאוחסנת ב-SCM (= תפוגה ודליפה אפשריות) הם משתמש דומיין ומשתמש מקומי.⁷³

להלן נחפור בטבלה שורה אחר שורה.

3. מה לא בסדר ב-LocalSystem

3.1. חזק עוד יותר מ«הפעלה כמנהל»

LocalSystem (שם תצוגה Local System, NT AUTHORITY\SYSTEM) הוא חשבון מוגדר מראש ש-SCM משתמש בו, והוא מחזיק הרשאות נרחבות במחשב המקומי. האסימון כולל את ה-SID של NT AUTHORITY\SYSTEM ושל BUILTIN\Administrators, והוא יכול לגשת לרוב האובייקטים במערכת. יתרה מזו, SeDebugPrivilege, שיכול לנפות באגים בתהליכים אחרים, ו-SeTcbPrivilege, שפועל כחלק ממערכת ההפעלה, מופעלים כברירת מחדל.³

הכוח הזה שם נרדף לגודל הנזק בהשתלטות. אם לשירות שרץ כ-LocalSystem יש פגיעות אחת להרצת קוד שרירותית, תוקף מגיע בנשימה אחת לקריאה ולשיבוש קבצי כל משתמש במכונה (ל-SYSTEM יש שליטה מלאה כברירת מחדל ב-NTFS⁵), לקריאת זיכרון תהליכים אחרים דרך SeDebugPrivilege, ולגניבת אישורים ותנועה רוחבית משם (נקודת מוצא ל-Pass-the-Hash וכדומה). שרשרת גניבת האישורים והתנועה הרוחבית מכוסה ב«NTLM and Kerberos Explained with Diagrams» וב«A Practical Guide to Windows LAPS».

flowchart TB
    accTitle: הנזק כשמשתלטים על שירות LocalSystem
    accDescr: אם לשירות שרץ כ-LocalSystem יש פגיעות אחת להרצת קוד שרירותית, תוקף מגיע לקריאה ולשיבוש קבצי כל משתמש, לקריאת זיכרון תהליכים אחרים ולגניבת אישורים ותנועה רוחבית
    vuln["פגיעות אחת להרצת קוד שרירותית"] --> sys["התוקף מקבל הרשאות SYSTEM"]
    sys --> files["קריאה ושיבוש קבצים"]
    sys --> mem["קריאת זיכרון תהליכים אחרים"]
    sys --> cred["גניבת אישורים"]
    cred --> lateral["תנועה רוחבית למכונה אחרת"]

איור 3: פגיעות אחת בשירות LocalSystem מאפשרת לתוקף להגיע בנשימה אחת להשתלטות על המכונה כולה ולנקודת מוצא לתנועה רוחבית.

3.2. למה עדיין בוחרים בו

הסיבה פשוטה: זו ברירת המחדל, ודחיית גישה לעולם לא מופיעה. ברירת המחדל כשמשמיטים obj= ב-sc.exe create היא LocalSystem,⁴ ורבים מדוגמאות הקוד הישנות ותבניות המתקינים עדיין מניחים LocalSystem. כי אפשר להישאר חופשיים משגיאות הרשאה בפיתוח, קיימת המבנה שמייצר בהמוניו «עבד, אז השאירו». גם התיעוד של Microsoft עצמה קובע שרוב השירותים אינם זקוקים לרמת הרשאה גבוהה כזו, ושאם אינכם זקוקים לה כדאי לשקול LocalService או NetworkService.³

flowchart TB
    accTitle: המבנה שמשאיר את LocalSystem נבחר
    accDescr: ברירת המחדל של sc.exe create היא LocalSystem, ודוגמאות ותבניות ישנות גם הן מניחות LocalSystem, ולכן אין דחיית גישה בפיתוח ותצורה של עבד אז השאירו מיוצרת בהמונים
    def["ברירת המחדל של sc.exe create"] --> lsys["נוצר כ-LocalSystem"]
    old["דוגמאות ותבניות ישנות"] --> lsys
    lsys --> noerr["אין דחיית גישה בפיתוח"]
    noerr --> asis["עבד, אז השאירו"]
    asis --> mass["שירותים בהרשאה מופרזת מיוצרים בהמונים"]

איור 4: ברירת המחדל וחוויית פיתוח «בלי דחיית גישה» מייצרים בהמוניו שירותים קפואים כ-LocalSystem.

3.3. ההבדל מ-TrustedInstaller — גם LocalSystem אינו בלתי מוגבל

לקרוא ל-LocalSystem «החשבון החזק ביותר של Windows» אינו מדויק. הגנת משאבי Windows (WRP) מאז Windows Vista מתירה שינויים בקבצי מערכת, תיקיות ומפתחות רישום חשובים רק ל-TrustedInstaller (שירות מתקין המודולים של Windows), ואפילו SYSTEM או מנהל מקבלים דחיית גישה בשכתוב.¹² «אתם זקוקים להרשאה מ-TrustedInstaller» של Explorer הוא המנגנון הזה. להפך, LocalSystem יכול להגיע כמעט לכל דבר מחוץ לאזור המוגן ב-WRP, ובדרך כלל אין סיבה לתת זאת לשירות עסקי.

flowchart TB
    accTitle: הקשר בין האזור המוגן ב-WRP ל-TrustedInstaller
    accDescr: שינויים בקבצי מערכת ובמפתחות רישום חשובים ש-WRP מגן עליהם מותרים רק ל-TrustedInstaller, ואפילו SYSTEM או מנהל מקבלים דחיית גישה
    ti["TrustedInstaller"] -->|יכול לשנות| wrp["קבצי מערכת מוגנים ב-WRP וכדומה"]
    sysadm["SYSTEM ומנהלים"] -->|דחיית גישה| wrp
    sysadm -->|כמעט הכול מותר| other["מחוץ לאזור המוגן ב-WRP"]

איור 5: גם LocalSystem אינו בלתי מוגבל; שינויים באזור המוגן ב-WRP מותרים רק ל-TrustedInstaller.

3.4. מקרים שבהם LocalSystem סביר

מה שסביר באופן חריג הוא שירות שההרשאות הנדרשות שלו חורגות מראש ממחלקת מנהל — עבודה צמודה עם מנהל התקן, הפעלת יסוד האבטחה של מערכת ההפעלה, ניהול שירותים או הפעלות אחרים וכדומה. תוכנה כמו סוכן גיבוי או EDR חלה. גם אז כדאי לאשר שיש נתיב קוד שמשתמש בהרשאה הזו באמת, ולשקול אם אפשר להפריד את העבודה שזקוקה להרשאה (איך להבחין, ראו «When Do You Actually Need Administrator Privileges on Windows?»).

4. LocalService ו-NetworkService — חשבונות מובנים בהרשאה מינימלית

LocalService (NT AUTHORITY\LOCAL SERVICE, SID: S-1-5-19) ו-NetworkService (NT AUTHORITY\NETWORK SERVICE, SID: S-1-5-20) הם חשבונות מובנים שהוכנו לשירותים בהרשאה נמוכה. שניהם מחזיקים רק הרשאות מינימליות מקומית, ויכולים מעט יותר מחבר בקבוצת Users.⁵¹

ההבדל בין השניים הוא נקודה אחת: כמי הם נראים מהצד הרחוק של הרשת.⁵

• LocalService: מתחבר לצד הרחוק באישורים אנונימיים. אינו יכול לגשת למשאב שדורש אימות.
• NetworkService: מציג לצד הרחוק את אישורי המחשב (בסביבת דומיין, DOMAIN\שם-המחשב$).

הפיצול הוא LocalService אם «אינו יוצא לרשת, או אם יוצא אינו זקוק לזהות», ו-NetworkService אם «אתם רוצים לגשת למשאב בתוך הדומיין בזהות המכונה».

flowchart TB
    accTitle: ההבדל בין LocalService ל-NetworkService
    accDescr: ההרשאות המקומיות מינימליות לשניהם, אבל לצד הרחוק LocalService מתחבר באישורים אנונימיים ו-NetworkService מציג את אישורי המחשב
    ls["LocalService"] --> anon["מתחבר באישורים אנונימיים"]
    anon -.-> ng["משאב שדורש אימות אינו אפשרי"]
    ns["NetworkService"] --> comp["מציג את אישורי המחשב"]
    comp -.-> pc["בסביבת דומיין נראה כ-PC$"]

איור 6: ההרשאות המקומיות הן אותו מינימום, אבל הזהות הנראית מהצד הרחוק של הרשת מתפצלת לאנונימי או חשבון מחשב.

אך לשניים האלה יש חולשה מנקודת מבט מודרנית. אותו חשבון משותף לשירותים רבים. אם חמישה שירותים רצים כ-LocalService, כל עוד ה-ACL הוא לפי חשבון, החמישה יכולים לגשת למשאבים זה של זה. SQL Server אינו תומך בחשבון Local Service מאותה סיבה: זה חשבון משותף ואי אפשר להפריד אותו משירותים אחרים.¹

flowchart TB
    accTitle: חשבון משותף אי אפשר להפריד
    accDescr: אם כמה שירותים חולקים את אותו LocalService, כל עוד ה-ACL לפי חשבון הם יכולים לגשת למשאבים זה של זה
    sva["שירות א"] --> acct["אותו LocalService"]
    svb["שירות ב"] --> acct
    svc["שירות ג"] --> acct
    acct --> mutual["יכולים לגשת למשאבים זה של זה"]
    mutual -.-> reason["כי ה-ACL לפי חשבון"]

איור 7: שירותים שחולקים את אותו חשבון אי אפשר להפריד ממשאבים זה של זה באמצעות ACL.

לפתור את «להישאר בהרשאה נמוכה אבל להפריד לכל שירות» הוא הנושא הבא, החשבון הווירטואלי.

5. חשבונות וירטואליים (NT SERVICE\<שם-השירות>) — ברירת המחדל המודרנית

5.1. אפשר לקבל זהות לכל שירות בלי סיסמה

חשבון וירטואלי הוא «חשבון מקומי מנוהל» הזמין מ-Windows Server 2008 R2 / Windows 7 ואילך. יש לו שלוש תכונות.⁶

• החשבון מנוהל אוטומטית; אין צורך ביצירה ולא בהגדרת סיסמה
• השם הוא NT SERVICE\<שם-השירות>, והוא הופך לזהות ייחודית לכל שירות
• בסביבת דומיין הוא יכול לגשת לרשת עם אישורי חשבון המחשב (DOMAIN\שם-המחשב$)

כלומר, הוא שומר את היתרון «אין ניהול סיסמה» של LocalService/NetworkService ומסיר את החיסרון «אי אפשר להפריד כי החשבון משותף». לכן גם התקנת SQL Server מגדירה כברירת מחדל חשבון וירטואלי כמו NT SERVICE\MSSQLSERVER.¹

flowchart TB
    accTitle: מה חשבון וירטואלי הופך לתואם
    accDescr: חשבון וירטואלי שומר את יתרון היעדר ניהול הסיסמה של LocalService ו-NetworkService, מסיר את חיסרון אי אפשר להפריד כי משותף, ויש לו זהות ייחודית לכל שירות
    merit["יתרון (אין ניהול סיסמה)"] -->|שמירה| va["חשבון וירטואלי"]
    demerit["חיסרון (אי אפשר להפריד כי משותף)"] -->|הסרה| va
    va --> ident["זהות ייחודית לכל שירות"]
    va --> auto["אין צורך ביצירה ולא בסיסמה"]

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

5.2. אפשר לכתוב «NT SERVICE\שם-השירות» ישירות ב-ACL

הנוחות המעשית היא שאפשר להוסיף רק את השירות הזה ל-ACL לפי שם. «רק השירות הזה יכול לכתוב לתיקיית הנתונים הזו» מתממש בלי ליצור קבוצה ובלי לנהל סיסמה.

# Change the service's logon account to a virtual account
# The value of obj= is "NT SERVICE\service-name". Do not specify a password
sc.exe config MyAppService obj= "NT SERVICE\MyAppService"

# Confirm the configuration (check SERVICE_START_NAME)
sc.exe qc MyAppService

# Grant modify rights on the data folder to this service only
icacls "C:\ProgramData\MyApp" /grant "NT SERVICE\MyAppService:(OI)(CI)M"

בממשק הגרפי, ב-services.msc פתחו את מאפייני השירות → לשונית «התחברות» → הזינו NT SERVICE\שם-השירות ב«חשבון זה», והשאירו את שדות הסיסמה ריקים (לחשבון וירטואלי או MSA, אי-ציון סיסמה הוא המפרט של SCM). אחרי השינוי הפעלה מחדש של השירות מיישמת אותו.

5.3. האילוץ — מחוץ למכונה זה לא «השירות הזה»

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

flowchart TB
    accTitle: זהות חשבון וירטואלי מתכווצת מחוץ למכונה
    accDescr: חשבון וירטואלי ייחודי לכל שירות בתוך המכונה מתכווץ גם לחשבון המחשב ברשת, והצד הרחוק אינו יכול לדעת איזה שירות זה
    vaa["חשבון וירטואלי א"] --> pc["חשבון מחשב PC$"]
    vab["חשבון וירטואלי ב"] --> pc
    pc --> remote["הזהות הנראית לצד הרחוק"]
    remote -.-> nodist["אי אפשר לדעת איזה שירות זה"]

איור 9: גם עם זהות ייחודית בתוך המכונה, מהצד הרחוק של הרשת כל שירות נראה כמו אותו PC$.

הרגע שבו האילוץ הזה — צורך בזהות ייחודית לשירות מהצד הרחוק של הרשת, צורך באותה זהות בכמה שרתים — הופך לבעיה הוא כשקוראים ל-gMSA (פרק 8).

6. זהות ביציאה לרשת — הפרקטיקה של חשבון המחשב (PC$)

6.1. «שירות לא יכול לגשת לתיקייה משותפת» הוא אי-הבנה

במכונה שצורפה לדומיין, כששירות שרץ כ-LocalSystem, NetworkService או חשבון וירטואלי ניגש למשאב מרוחק, הוא מאומת כחשבון המחשב (DOMAIN\שם-המחשב$).³⁶ רבים מייעוצי הפתיחה «לא הצליח לגשת לתיקייה משותפת אז הפכנו אותו למשתמש דומיין» נפתרים למעשה בזה. ה-ACL של היעד פשוט לא התיר PC$.

flowchart TB
    accTitle: גישה מרוחקת כחשבון מחשב
    accDescr: שירות LocalSystem, NetworkService או חשבון וירטואלי במכונה שצורפה לדומיין מאומת מול הצד הרחוק כחשבון המחשב, ואם ה-ACL של היעד מתיר PC$ הוא יכול לגשת
    svc["שירות (LocalSystem, חשבון וירטואלי וכדומה)"] --> auth["אימות כ-PC$"]
    auth --> acl{"האם ה-ACL של היעד מתיר PC$?"}
    acl -->|כן| ok["הגישה לתיקייה משותפת או למסד נתונים מצליחה"]
    acl -->|לא| ng["הגישה נדחית"]

איור 10: בסביבת דומיין, מתן PC$ ב-ACL של היעד לבדו מקים גישה מרוחקת בלי משתמש דומיין.

המתן בצד שרת הקבצים זהה לפעולת ACL רגילה; ציינו שם-המחשב$ כשם החשבון (בתיבת בחירת האובייקטים של הממשק כללו «מחשבים» בסוגי האובייקטים).

# On the file-server side: grant a service on APPSV01 modify rights on the shared folder
# You need to grant both share permissions and NTFS permissions
Grant-SmbShareAccess -Name "AppData" -AccountName "CORP\APPSV01$" -AccessRight Change -Force
icacls "D:\Shares\AppData" /grant "CORP\APPSV01$:(OI)(CI)M"

SQL Server זהה: צרו את חשבון המחשב ככניסה ומחרוזת החיבור עוברת עם Integrated Security=true ובלי סיסמה.

-- On the DB-server side: permit Windows integrated authentication from a service on APPSV01
CREATE LOGIN [CORP\APPSV01$] FROM WINDOWS;

6.2. הכירו את גבולות גישת PC$

לגישה הזו שני גבולות.

1. הגרעיניות היא לכל מכונה. LocalSystem, NetworkService וכל שירות חשבון וירטואלי שרצים באותה מכונה נראים כולם כמו אותו PC$ מהצד הרחוק. אי אפשר «להתיר רק לשירות הזה» ביעד, וגם אי אפשר לבקר איזה שירות השתמש בחשבון הזה.²
2. אי אפשר להשתמש בה בסביבת קבוצת עבודה. חשבון מחשב הוא אובייקט Active Directory, ולכן למכונה שלא צורפה לדומיין אין אחד. צריך עיצוב שמטפל במפורש באישורי חשבון היעד.

כשרוצים לעבור את גבול 1, תשובת 2026 אינה משתמש הדומיין של הפרק הבא… אלא לדלג על הבעיה הזו ולהמשיך ל-gMSA.

flowchart TB
    accTitle: שני גבולות של גישת PC$
    accDescr: אימות כ-PC$ הוא בגרעיניות רמת מכונה ולכן אין היתר ולא ביקורת לכל שירות, ובקבוצת עבודה חשבון המחשב עצמו אינו קיים ולכן אי אפשר להשתמש
    pcs["גישת PC$"] --> lim1["גבול 1: לכל מכונה"]
    pcs --> lim2["גבול 2: אין קבוצת עבודה"]
    lim1 -.-> noaudit["אין היתר ולא ביקורת לכל שירות"]
    lim2 -.-> nocred["השתמשו באישורים מפורשים"]
    lim1 --> gmsa["מעבר לזה: gMSA"]

איור 11: כשרוצים לעבור את שני גבולות הגרעיניות ברמת מכונה ותנאי הדומיין, דלגו על משתמש הדומיין והמשיכו ל-gMSA.

7. בעיית השימוש במשתמש דומיין לשירות

7.1. הבעיה המבנית של הסיסמה

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

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

1. מתרחשת תאונת עצירת השירות בגלל תפוגה
2. כמניעת הישנות נקבע «הסיסמה לעולם לא תפוג»
3. הליך שינוי לעולם אינו מבוסס, ואותה סיסמה נכתבת בגלוי בספרי הפעלה, בתסריטים ובמתזמן המשימות של כמה שרתים
4. גם כשמישהו עוזב הסיסמה אינה משתנה (אם תשנו, לא תדעו מה ייעצר)

flowchart TB
    accTitle: הספירלה השלילית של הפעלה עם משתמש דומיין
    accDescr: הסיסמה פגה והשירות נעצר, «לעולם לא יפוג» נקבע כמניעת הישנות, סיסמה גלויה מתפשטת בספרי הפעלה ובתסריטים, וגם כשמישהו עוזב אי אפשר לשנות אותה
    expire["1. תפוגה עוצרת את השירות"] --> forever["2. «לעולם לא יפוג» נקבע כמניעה"]
    forever --> spread["3. סיסמה גלויה מתפשטת"]
    spread -.-> where["ספרי הפעלה, תסריטים, משימות"]
    spread --> stuck["4. גם כשמישהו עוזב אי אפשר לשנות"]

איור 12: החל מתאונת תפוגה, «לעולם לא יפוג» והתפשטות סיסמה גלויה מתקבעים.

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

7.2. Kerberoasting — חשבון שירות הופך למטרה

התקפה נוספת הספציפית לחשבון שירות של משתמש דומיין היא Kerberoasting. שירות שמקבל אימות Kerberos רושם SPN (שם ראשי שירות) בחשבון ההתחברות. כל משתמש מאומת בדומיין יכול לבקש כרטיס שירות לחשבון שיש לו SPN רשום, ולכן תוקף משיג את הכרטיס ומנסה כוח גס לא מקוון של הסיסמה. סיסמה של 10 עד 16 תווים שאדם החליט לא תעמוד בהתקפה הזו.

flowchart TB
    accTitle: זרימת Kerberoasting
    accDescr: כרטיס שירות לחשבון שירות שיש לו SPN רשום יכול להתבקש על ידי כל משתמש מאומת, ולכן תוקף משיג את הכרטיס ומנסה כוח גס לא מקוון של הסיסמה
    atk["משתמש מאומת בדומיין"] --> req["בקשת כרטיס ל-SPN"]
    req --> tkt["השגת כרטיס שירות"]
    tkt --> brute["כוח גס לא מקוון"]
    brute --> weak["כ-10 עד 16 תווים יישברו"]

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

המענה היעיל הוא להפוך את הסיסמה לחוזק שאדם אינו יכול לנחש או לשבור. Microsoft גם מונה כפיית סיסמה ארוכה, ושימוש ב-gMSA שסיסמתו הופכת לערך אקראי ארוך שנוצר במכונה.⁸ אותו מסמך מזכיר גם שריון Kerberos (FAST), אך FAST מגן על נתוני אימות מוקדם ועל עמידות לזיוף KDC; הוא אינו מונע ממשתמש מאומת לבקש כרטיס שירות ל-SPN, ולכן אינו תחליף לחוזק הסיסמה של חשבון שירות. הקשר בין SPN ל-Kerberos והתנאים שבהם אימות נופל ל-NTLM מצוירים ב«NTLM and Kerberos Explained with Diagrams».

7.3. אם בכל זאת משתמשים במשתמש דומיין

אם אין ברירה אלא להשתמש במשתמש דומיין, מסיבות כמו שהיישום אינו תומך ב-gMSA, טפלו באלה כהקלה מינימלית.

• הפכו את הסיסמה ל-25 תווים או יותר שנוצרו באקראי, ואל תכתבו אותה בשום מקום מלבד כלי ניהול סיסמאות (ספרי הפעלה, תסריטים, Excel משותף)
• הפכו אותו לחשבון ייעודי לשירות ופצלו לכל שירות (אל תשתפו עם חשבון אנושי²)
• סרבו להתחברות אינטראקטיבית ולשולחן עבודה מרוחק, והתירו רק «התחברות כשירות»
• צמצמו את הקבוצות שהוא שייך אליהן (הוספה ל-Domain Admins אינה באה בחשבון)
• קבעו הליך סיבוב תקופתי ושימו את המקומות ששינוי ישפיע עליהם בפנקס

לעשות את כל זה פחות בטוח ופחות קל מהגירה ל-gMSA — זה הפרק הבא.

8. gMSA — להשאיר את ניהול הסיסמה ל-Active Directory

8.1. המנגנון וההשפעה

gMSA (חשבון שירות מנוהל קבוצתי) הוא חשבון דומיין שמשאיר את ניהול הסיסמה לבקר הדומיין. הסיסמה מחושבת על ידי בקר הדומיין ממפתח השורש של KDS (Key Distribution Service), ורק מארחים מותרים משיגים אותה.¹³

flowchart TB
    accTitle: איך gMSA מנהל את הסיסמה
    accDescr: בקר הדומיין מחשב את הסיסמה ממפתח השורש של KDS, רק מארחים מותרים משיגים אותה ומשתמשים בה להרצת השירות, והסיסמה מסתובבת אוטומטית כל 30 יום כברירת מחדל
    kds["מפתח שורש KDS"] --> dc["ה-DC מחשב את הסיסמה"]
    dc --> host["מארח מותר משיג אותה"]
    host --> svc["משמש להרצת השירות"]
    dc -.-> rot["סיבוב אוטומטי כל 30 יום כברירת מחדל"]

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

ההשפעות ברורות.⁹

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

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

8.2. דרישות

ל-gMSA יש תנאים מוקדמים.¹⁰

• סביבת דומיין Active Directory (אי אפשר בקבוצת עבודה)
• רמות פונקציונליות של דומיין ויער Windows Server 2012 ומעלה
• מפתח שורש KDS כבר נוצר
• שם ה-gMSA ייחודי ביער, לא רק בדומיין
• מרווח שינוי הסיסמה ניתן להגדרה רק ביצירה

יצירת מפתח השורש של KDS היא משימה חד-פעמית, אך עד 10 שעות אחרי היצירה אי אפשר ליצור gMSA, כי ממתינים לשכפול לכל בקר דומיין. זהו התקן בטיחות למנוע תאונת כשל בשליפת הסיסמה לפני שהשכפול הסתיים.¹⁴

flowchart TB
    accTitle: מיצירת מפתח השורש של KDS ליצירת gMSA
    accDescr: אחרי יצירת מפתח השורש של KDS ממתינים לשכפול לכל בקר דומיין, ולכן עד 10 שעות אי אפשר ליצור gMSA; אחרי שהשכפול הושלם אפשר ליצור אחד
    add["יצירת מפתח השורש של KDS"] --> wait["עד 10 שעות המתנה לשכפול"]
    wait -.-> why["התקן בטיחות למנוע תאונת כשל בשליפה"]
    wait --> done["השכפול לכל DC הושלם"]
    done --> ok["אפשר ליצור gMSA"]

איור 15: ההמתנה עד 10 שעות אחרי יצירת מפתח השורש היא זמן המתנה למנוע כשל בשליפה כל עוד השכפול לא הסתיים.

# Run as a domain administrator, on a domain controller (or an administrative
# workstation with the AD PowerShell module)

# Confirm whether a KDS root key exists, and create one if not (once per forest)
Get-KdsRootKey
Add-KdsRootKey -EffectiveImmediately   # Actually usable after up to 10 hours

8.3. ההליך מיצירה לתצורה

ההליך בארבעה שלבים: «① יצירת קבוצה שמותרת לשליפה → ② יצירת ה-gMSA → ③ התקנתו בשרתים → ④ הגדרתו בשירות».¹⁰

flowchart TB
    accTitle: ארבעת שלבי הכנסת gMSA
    accDescr: הכניסו בארבעה שלבים: יצירת קבוצה שמותרת לשליפת הסיסמה, יצירת ה-gMSA, התקנה בכל שרת, והגדרה כחשבון ההתחברות של השירות
    st1["① יצירת קבוצה שמותרת לשליפה"] --> st2["② יצירת ה-gMSA"]
    st1 -.-> add["הוסיפו את ה-PC$ של השרתים"]
    st2 --> st3["③ התקנה בכל שרת"]
    st3 -.-> test["אמתו שליפה בפקודת Test"]
    st3 --> st4["④ הגדרה בשירות"]

איור 16: מיצירת הקבוצה להגדרת השירות, הכנסת gMSA מתקדמת בארבעה שלבים.

# ① Create a security group permitted to retrieve the password,
#    and add the computer accounts of the servers that will run the service
New-ADGroup -Name "GG-SvcBatchHosts" -GroupScope Global
Add-ADGroupMember -Identity "GG-SvcBatchHosts" -Members "APPSV01$", "APPSV02$"
# Group membership is evaluated at computer logon, so
# restarting the target servers after adding is the reliable approach

# ② Create the gMSA
New-ADServiceAccount -Name "svc-batch" `
    -DNSHostName "svc-batch.corp.example.com" `
    -PrincipalsAllowedToRetrieveManagedPassword "GG-SvcBatchHosts"

# ③ On each server that will run the service, install the gMSA and validate
Install-ADServiceAccount -Identity "svc-batch"
Test-ADServiceAccount -Identity "svc-batch"   # True means retrieval is working

# ④ Set it as the service's logon account. Append $ to the name, and do not specify a password
sc.exe config MyBatchService obj= "CORP\svc-batch$"
Restart-Service MyBatchService

גם בהגדרה מ-services.msc שם החשבון כמו CORP\svc-batch$ — צרפו $ בסוף והשאירו את שדות הסיסמה ריקים. אי אפשר להשתמש בחשבון ממשפחת MSA להתחברות אינטראקטיבית.¹ לאחר מכן תנו CORP\svc-batch$ ב-ACL של תיקייה משותפת או SQL Server במקום PC$, וגישת רשת בזהות ייחודית לשירות הושלמה, בלי סיסמה.

8.4. חלק מהיישומים אינם תומכים

כהסתייגות, לא כל תוכנה תרוץ כ-gMSA. דברים שמגדירים את זהות ההתחברות במנגנון סטנדרטי — שירות Windows, מאגר יישומים של IIS, משימת מתזמן המשימות — נתמכים בהרחבה, אך יש אילוצים כמו שאשכול כשל עצמו אינו תומך ב-gMSA, ויישום שפנימיותיו דורשות סיסמה אינו יכול להשתמש בו.¹⁰ Microsoft גם קובעת במפורש שיש לאשר התנהגות כ-gMSA בסביבת בדיקה לפני ייצור.⁹

flowchart TB
    accTitle: איך להבחין אם משהו תומך ב-gMSA
    accDescr: יישום שמגדיר זהות התחברות במנגנון סטנדרטי תומך ב-gMSA בהרחבה, אך אשכול כשל ויישום שפנימיותיו דורשות סיסמה אינם יכולים להשתמש, לכן אשרו בסביבת בדיקה לפני ייצור
    app["היישום היעד"] --> how{"איך מוגדרת ההתחברות?"}
    how -->|מנגנון סטנדרטי| okapp["gMSA נתמך"]
    okapp -.-> ex1["שירות, IIS, משימה"]
    how -->|סיסמה נדרשת| ngapp["gMSA אינו אפשרי"]
    ngapp -.-> ex2["אשכול כשל"]
    okapp --> test["בדיקה לפני ייצור"]

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

יש גם אחים: sMSA (חשבון שירות מנוהל עצמאי) לשרת יחיד, ו-dMSA (חשבון שירות מנוהל מואצל, שהוצג ב-Windows Server 2025, שקושר לזהות מכשיר כדי להתמודד עם גניבת אישורים). לבנייה חדשה קחו gMSA כקו בסיס ושקלו לפי הדרישות.⁶

9. עיצוב נלווה — זכויות התחברות, פרופיל, DPAPI וביקורת

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

9.1. הזכות «התחברות כשירות» (SeServiceLogonRight)

כדי להתחיל כשירות החשבון זקוק לזכות המשתמש «התחברות כשירות». ל-LocalSystem, LocalService ו-NetworkService היא מובנית, אך כל חשבון אחר (משתמש דומיין, gMSA וכדומה) זקוק להקצאה מפורשת.¹⁵

אם מגדירים מלשונית «התחברות» של ממשק services.msc, התוסף מעניק את הזכות אוטומטית. לעומת זאת CreateService / ChangeServiceConfig (ממשקי ה-API ש-sc.exe config קורא) אינם מאמתים שלחשבון שצוין יש את הזכות. הסיבה הטיפוסית לשירות שהוגדר בתסריט שנעצר בהפעלה עם «השירות לא הופעל בגלל כשל התחברות» היא זו. אל תסמכו על תופעת לוואי של כלי; כללו בהליך הפריסה, במפורש, הוספה ל«התחברות כשירות» במדיניות האבטחה המקומית (secpol.msc), או תצורה דרך GPO/Intune (בסביבה שמגדירה את הזכות במדיניות קבוצה, מתן מקומי נדרס כשהמדיניות חלה, ולכן גם זה דורש תשומת לב). להפך, המהלך הסטנדרטי לחשבון ייעודי לשירות הוא להגדיר יחד «דחה התחברות מקומית».

flowchart TB
    accTitle: ההבדל לפי נתיב התצורה של הזכות התחברות כשירות
    accDescr: ממשק services.msc מעניק את הזכות אוטומטית, אך ה-API ש-sc.exe config קורא אינו מאמת את הזכות, ולכן חשבון בלי הזכות עוצר את השירות בכשל התחברות בהפעלה
    gui["הגדרה ב-services.msc"] --> auto["הזכות ניתנת אוטומטית"]
    auto --> okgui["השירות יכול להתחיל"]
    cli["הגדרה ב-sc.exe config"] --> noval["הזכות אינה מאומתת"]
    noval --> has{"יש את הזכות?"}
    has -->|כן| okcli["השירות יכול להתחיל"]
    has -->|לא| stop["נעצר בכשל התחברות"]
    stop -.-> fix["תנו במפורש ב-secpol.msc או ב-GPO"]

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

9.2. הפרופיל, %TEMP% ו-HKEY_CURRENT_USER משתנים

SCM טוען את פרופיל המשתמש של החשבון בהפעלת השירות.⁷ לכן %TEMP%, %APPDATA% ו-HKEY_CURRENT_USER האמיתיים הם דבר אחר לכל חשבון התחברות, וכשמחליפים חשבון הגדרות ומטמון שנשמרו בפרופיל הישן נראים כאילו «נעלמו».

תשובת העיצוב פשוטה: שימו את נתוני השירות לא תחת הפרופיל אלא בנתיב מפורש כמו C:\ProgramData\<שם-היישום>, ותנו את ה-ACL לחשבון ההתחברות. כך שינוי חשבון אינו מגיע עם העברת נתונים.

flowchart TB
    accTitle: תלות בפרופיל ותשובת מיקום הנתונים
    accDescr: הפרופיל האמיתי הוא דבר אחר לכל חשבון התחברות, ולכן החלפת חשבון גורמת לנתוני הפרופיל הישן להיראות כאילו נעלמו, אך מיקום בנתיב מפורש ומתן ACL הופכים העברה למיותרת
    sw["החלפת חשבון ההתחברות"] --> newprof["נטען פרופיל אחר"]
    newprof --> lost["הנתונים הישנים נראים כאילו נעלמו"]
    lost -.->|תשובה| fix["שימו תחת ProgramData"]
    fix --> acl["תנו את ה-ACL לחשבון ההתחברות"]
    acl --> nomig["אין העברה גם כשהחשבון משתנה"]

איור 19: הימנעו מהפרופיל ושימו את הנתונים בנתיב מפורש, ושינוי חשבון כבר אינו מגיע עם העברת נתונים.

9.3. נתונים שהוגנו ב-DPAPI קשורים לחשבון

קל עוד יותר להחמיץ הוא DPAPI. נתונים שהוצפנו ב-DPAPI בהיקף משתמש (CryptProtectData או ProtectedData של .NET) ניתנים, בעיקרון, לפענוח רק באותו חשבון שהגן עליהם. ברגע שמחליפים חשבון אי אפשר לקרוא מחרוזת חיבור או מפתח API מאוחסנים — זה DPAPI שעושה את עבודתו נכון, אבל אם זה לא בהליך ההגירה זה הופך לאירוע.

flowchart TB
    accTitle: הקשר בין נתונים מוגנים ב-DPAPI לשינוי חשבון
    accDescr: נתונים שהוגנו ב-DPAPI בהיקף משתמש ניתנים לפענוח רק באותו חשבון שהגן עליהם, ולכן אחרי שינוי חשבון ההתחברות צריך להזין סודות מחדש
    protect["הגנה ב-DPAPI בחשבון הישן"] --> data["מחרוזת חיבור מוגנת וכדומה"]
    data --> who{"איזה חשבון מפענח?"}
    who -->|אותו חשבון ישן| okdec["יכול לפענח"]
    who -->|החשבון החדש| ngdec["אינו יכול לפענח"]
    ngdec --> re["הזינו סודות מחדש"]

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

המענה הוא לכלול בתוכנית ההגירה את ההליך «הזינו סודות מחדש אחרי החלפת החשבון» (לעיצוב איפה לאחסן אותם ראו «שמירת מידע רגיש ביישומי Windows»). גם תצורה שיכולה להסתיים באימות משולב של Windows כ-gMSA או PC$ יכולה לבטל את אחסון הסוד עצמו. הסדר הנכון הוא לשקול «האם אפשר בלי לאחסן» לפני «איפה מאחסנים».

ואם השירות רוצה לעבד «בהרשאות המשתמש הקורא», משתמשים בהתחזות במקום לחזק את החשבון. לכך ראו «Handling Windows Impersonation Tokens Correctly».

9.4. ביקורת — הסתכלו על 4624 סוג התחברות 5

הפעלת שירות נרשמת ביומן אירועי האבטחה כמזהה אירוע 4624 (חשבון התחבר בהצלחה) עם סוג התחברות 5 (שירות: SCM הפעיל שירות). השדה «Virtual Account» באירוע מציין אם ההתחברות הייתה על ידי MSA / חשבון וירטואלי, ולכן אפשר להשתמש בו גם למעקב אחר שימוש בחשבונות מנוהלים.¹¹

flowchart TB
    accTitle: זרימת ביקורת הפעלת שירות
    accDescr: הפעלת שירות על ידי SCM נרשמת כמזהה אירוע 4624 סוג התחברות 5, ושדה Virtual Account יכול לזהות אם ההתחברות הייתה בחשבון מנוהל
    start["SCM מפעיל שירות"] --> ev["רישום מזהה אירוע 4624"]
    ev --> type5["סוג התחברות 5 (שירות)"]
    type5 --> vafield["שדה Virtual Account"]
    vafield --> watch["מעקב אחר חשבונות מנוהלים"]

איור 21: הפעלת שירות נרשמת כ-4624 מסוג התחברות 5, ואפשר אפילו לעקוב אחר שימוש בחשבונות מנוהלים.

למלאי המצב הנוכחי, צבירת חשבונות ההתחברות של רשימת השירותים היא השיטה המהירה.

# Aggregate which services are running as which account
Get-CimInstance Win32_Service |
    Group-Object StartName |
    Sort-Object Count -Descending |
    Select-Object Count, Name

# Inventory non-standard services running as LocalSystem (tell in-house / third-party by the path)
Get-CimInstance Win32_Service |
    Where-Object { $_.StartName -eq 'LocalSystem' -and $_.PathName -notlike '*\Windows\*' } |
    Select-Object Name, DisplayName, PathName

אם הפלט הזה מסדר «שירות עסקי שרץ כ-LocalSystem» ו«שירות שרץ כמשתמש דומיין», זרימת ההחלטה של הפרק הבא נקראת.

10. זרימת החלטה — החליטו בארבע שאלות

הנה התוכן עד כה כהליך בחירה. ענו על ארבע שאלות לפי הסדר.

flowchart TB
    accTitle: זרימת ההחלטה לחשבון ההתחברות
    accDescr: החליטו את חשבון ההתחברות בענות לפי הסדר על ארבע השאלות של גישת רשת, צירוף לדומיין, האם זהות רמת מכונה מספיקה, ותמיכה ב-gMSA
    q1{"אימות Win לעמית?"} -->|לא| va["חשבון וירטואלי"]
    va -.-> sys["LocalSystem אם נדרש"]
    q1 -->|כן| q2{"צורף לדומיין?"}
    q2 -->|לא| cred["הגנו על אישורים מאוחסנים"]
    q2 -->|כן| q3{"רמת מכונה מספיקה?"}
    q3 -->|כן| pcacl["חשבון וירטואלי + PC$"]
    q3 -->|לא| q4{"היישום תומך ב-gMSA?"}
    q4 -->|כן| gmsa["gMSA"]
    q4 -->|לא| du["משתמש + הקלות"]

איור 22: ענו על ארבע השאלות לפי הסדר ואיזו מששת הבחירות להשתמש בה מוכרעת.

שאלה 1: האם השירות ניגש למכונה אחרת ברשת (תיקייה משותפת, מסד נתונים, ממשק API וכדומה) באימות Windows?

אם לא, חשבון וירטואלי הוא ברירת המחדל. רק אם נדרשת הרשאה מקומית מיוחדת, אשרו את הצורך ואז שקלו LocalSystem.

שאלה 2: (אם ניגש) האם המכונה צורפה לדומיין?

בקבוצת עבודה אי אפשר להשתמש לא ב-PC$ ולא ב-gMSA. השתמשו בעיצוב שמטפל במפורש באישורי חשבון היעד (הגנו על האחסון ב-DPAPI או דומה), או שקלו צירוף לדומיין.

שאלה 3: (בדומיין) האם זהות רמת מכונה (PC$) מספיקה?

אם כן, חשבון וירטואלי (או NetworkService) + מתן PC$ ב-ACL של היעד הושלם. אם צריך זהות ייחודית לשירות, או זהות משותפת בכמה שרתים, עברו לשאלה 4.

שאלה 4: האם היישום תומך ב-gMSA?

אם כן (דברים שמגדירים התחברות במנגנון סטנדרטי — SCM, מאגר יישומים של IIS, מתזמן המשימות — בדרך כלל כן), gMSA. אל תשכחו בדיקת התנהגות בסביבת אימות. אם אינו נתמך בכל מקרה, השתמשו במשתמש דומיין ייעודי אחרי יישום כל הקלה בסעיף 7.3.

בטבלה זה כך.

11. סיכום

• חשבון ההתחברות של שירות הוא החלטת עיצוב שמחליטה יחד הרשאות מקומיות, זהות רשת וניהול סיסמה. אל תשאירו בברירת המחדל (LocalSystem).
• LocalSystem מחזיק אסימון SYSTEM+Administrators והרשאות חזקות, והנזק בהשתלטות ממוזער. רוב השירותים העסקיים אינם זקוקים להרשאה הזו.
• LocalService ו-NetworkService שניהם בהרשאה נמוכה; ההבדל הוא זהות הרשת (אנונימי, או חשבון המחשב). כי החשבון משותף לכמה שירותים, עם זאת, אי אפשר להפריד אותם.
• חשבון וירטואלי (NT SERVICE\<שם-השירות>) הוא ברירת המחדל המודרנית שיכולה להפריד לכל שירות בלי צורך בניהול סיסמה. אפשר לציין ישירות ב-ACL, והתצורה היא רק שינוי שם חשבון ההתחברות.
• LocalSystem, NetworkService וחשבון וירטואלי יוצאים לרשת כ-DOMAIN\PC$ בסביבת דומיין. מתן PC$ ב-ACL של תיקייה משותפת או SQL Server לעיתים קרובות מאפשר לוותר על משתמש דומיין.
• שימוש במשתמש דומיין לשירות יש בעיות מבניות של עצירה מתפוגה, התפשטות סיסמה גלויה ו-Kerberoasting. אם משתמשים, נדרשים חשבון ייעודי + סיסמה אקראית ארוכה + הגבלות התחברות.
• gMSA הוא מנגנון שבו AD מייצר ומסובב את הסיסמה אוטומטית; הדרישות הן דומיין, רמה פונקציונלית 2012 ומעלה ומפתח שורש KDS. הגדירו את השירות ל-«DOMAIN\שם$» עם שדה הסיסמה ריק.
• כשמשנים חשבון, כללו את הזכות «התחברות כשירות», העברת הפרופיל ו-%TEMP%, והזנה מחדש של נתונים מוגנים ב-DPAPI בהליך ההגירה. ביקורת ניתן לאשר במזהה אירוע 4624 סוג התחברות 5.

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

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

• How to Build and Operate Windows Services ── From Choosing Between Task Scheduler and Services to Turning a BackgroundService into a Windows Service
• When Do You Actually Need Administrator Privileges on Windows? - UAC, Protected Areas, and How to Tell by Design
• Handling Windows Impersonation Tokens Correctly — Borrowing Privileges per Thread and Reverting Safely
• NTLM and Kerberos Explained with Diagrams — Why Authentication Falls Back to NTLM
• A Practical Guide to Windows LAPS — Retiring the Shared Local Administrator Password Across All PCs
• שמירת מידע רגיש ביישומי Windows - נמנעים מתצורה גלויה עם DPAPI

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

KomuraSoft LLC מטפלת בעיצוב חשבון התחברות ובהקשחת הרשאה מינימלית לשירותי Windows וליישומים תושבים, בהגירת שירותים קיימים שנבנו בהנחת LocalSystem לחשבון וירטואלי או ל-gMSA, ובחקירת כשלים שנגרמו מדחיית גישה, DPAPI והפרופיל אחרי שינוי חשבון. להתחיל משלב «סומנו בביקורת, אבל איננו יודעים מאיפה להתחיל» זה בסדר.

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

קישורי עיון

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

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

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

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

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

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

שאלות נפוצות

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

האם לשנות מיד שירות שהרצתי בינתיים כ-LocalSystem?

שינוי מיידי אינו תמיד התשובה הנכונה לכל מקרה. קודם ודאו אם השירות באמת זקוק להרשאות מקומיות ברמת LocalSystem (הרשאות חזקות מעבר למנהל). אם מדובר רק בקריאה וכתיבה של קבצים ובתקשורת רשת, המועמד הראשון הוא מעבר לחשבון וירטואלי (NT SERVICE\שם-השירות). במעבר ודאו מתן גישה לתיקיות ולמפתחות רישום נדרשים, איך מטפלים בנתונים שתלויים בפרופיל או ב-DPAPI, והאם קיימת הזכות "התחברות כשירות". ודאו הפעלה ופונקציות עיקריות בסביבת אימות, ואז החליפו ייצור.

לבחור חשבון וירטואלי או NetworkService?

לבחירה חדשה אנו ממליצים על חשבון וירטואלי. ברשת שניהם נראים כחשבון המחשב (DOMAIN\שם-המחשב$), ולשניהם הרשאות מקומיות קטנות. אך NetworkService משותף לכמה שירותים, ולכן אי אפשר להפריד ב-ACL ש"מתירה רק לשירות הזה". לחשבון וירטואלי זהות ייחודית לכל שירות, ואפשר לציין NT SERVICE\שם-השירות ישירות ב-ACL. מוצרי Microsoft עדכניים כמו SQL Server גם הם ברירת מחדל לחשבון וירטואלי.

אפשר להשתמש ב-gMSA בסביבת קבוצת עבודה (בלי דומיין)?

לא. gMSA הוא מנגנון שבו בקר דומיין של Active Directory מייצר ומנהל את הסיסמה, ודומיין ויצירת מפתח שורש KDS הם תנאים מוקדמים. בקבוצת עבודה הבסיס הוא לסיים עיבוד מקומי בחשבון וירטואלי או LocalService/NetworkService. אם צריך גישה למכונה אחרת, נדרש עיצוב אחר כמו שימוש מפורש באישורי חשבון שהוכן ביעד. גישת רשת כחשבון מחשב (PC$) גם היא תקפה רק בסביבת דומיין.

אחרי שהחלפתי את חשבון ההתחברות של השירות, אי אפשר לקרוא הגדרות ואישורים ששמרתי. למה?

כי כל חשבון התחברות קשור לפרופיל המשתמש שלו, ל-%TEMP%, ל-HKEY_CURRENT_USER ולמפתח DPAPI. במיוחד נתונים שהוגנו ב-DPAPI בהיקף משתמש (CryptProtectData וכדומה) ניתנים, בעיקרון, לפענוח רק באותו חשבון שהגן עליהם. קבצים שנשמרו תחת הפרופיל (AppData וכדומה) הם גם נתיב אחר מהחשבון החדש. לפני החלפת חשבון תכננו את הליך יצירת הנתונים המוגנים ב-DPAPI מחדש (הזנת מפתחות API מחדש וכדומה) והעברת קבצים תחת הפרופיל.

אם אני רוצה רק שהשירות יגש לתיקייה משותפת, האם צריך משתמש דומיין?

במקרים רבים לא. בסביבת דומיין שירות שרץ כ-LocalSystem, NetworkService או חשבון וירטואלי מאומת מול הצד הרחוק כחשבון המחשב (DOMAIN\שם-המחשב$). הוסיפו את ה-PC$ להרשאות השיתוף ולהרשאות NTFS של התיקייה המשותפת והוא יוכל לקרוא ולכתוב. אם אתם רוצים בקרת גישה בזהות ייחודית לשירות, או אותה זהות בכמה שרתים, שקלו gMSA במקום משתמש דומיין.

פרופיל הכותב

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

Go Komura

מנהל KomuraSoft LLC

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