חשבונות שירות ב-Windows: LocalSystem, virtual accounts ו-gMSA

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

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

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

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

יש למעשה שישה בחירות — LocalSystem, LocalService, NetworkService, virtual account (NT SERVICE\), domain user ו-gMSA (group Managed Service Account). המאמר מיועד לאנשי IT בעסקים קטנים ובינוניים ולמפתחי Windows. הוא מסדר את ההרשאות, זהות הרשת וניהול הסיסמאות של השישה בטבלה אחת ומסכם זרימת החלטה, על בסיס מקורות ראשוניים של Microsoft Learn נכון לאוגוסט 2026.

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

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

• אם מתלבטים: שירות שנגמר בתוך מכונה אחת — virtual account; שירות שצריך זהות ייחודית למשאבים בתוך ה-domain —‏ gMSA, כמועמד ראשון. גם Microsoft מנחה להשתמש בחשבונות מנוהלים (MSA / virtual account) כשאפשר.¹²
• אל תבחרו LocalSystem כי «זה עובד». ה-token כולל SYSTEM ו-BUILTIN\Administrators, ויש לו הרשאות חזקות כמו SeDebugPrivilege; אם משתלטים עליו מאבדים כמעט את כל המכונה. ברירת המחדל של sc.exe create היא LocalSystem, וזה כר דשא לתאונה הזו.³⁴
• ההבדל בין LocalService ל-NetworkService הוא הזהות ברשת. ההרשאות המקומיות של שניהם מינימליות, אבל מול צד מרוחק LocalService נראה אנונימי ו-NetworkService נראה כ-computer account.⁵
• **Virtual account (NT SERVICE\) הוא ברירת המחדל המודרנית: בלי ניהול סיסמה, עם זהות נפרדת לכל שירות.** אפשר לציין «NT SERVICE\\שם-השירות» ישירות ב-ACL, וזה גם חשבון ברירת המחדל של SQL Server.[^understand-service-accounts][^sql-service-accounts]
• כש-LocalSystem, NetworkService ו-virtual account יוצאים לרשת, הם הופכים ל-computer account (DOMAIN\computer-name$). במקרים רבים מספיק לתת PC$ ל-ACL של shared folder או SQL Server, בלי domain user.³⁶
• הגדרה של domain user לשירות היא חוב גם בניהול סיסמה וגם ב-Kerberoasting. SCM מתחבר עם הסיסמה ששמר, תפוגה עוצרת את השירות, ו-«ללא תפוגה + תזכורת בגלוי» שמונעת את זה היא מתנה לתוקף.⁷⁸
• gMSA: Active Directory מייצר ומסובב את הסיסמה אוטומטית. התנאים הם domain ו-KDS root key; לשירות מגדירים «DOMAIN\account-name$» עם שדה סיסמה ריק. יש אפליקציות שלא תומכות — צריך לבדוק מראש.⁹¹⁰
• החלפת חשבון משנה את ההנחות על פרופיל, %TEMP% ו-DPAPI. נתונים שהוגנו ב-DPAPI של החשבון הישן לא ניתנים לפענוח בחשבון החדש.
• מיון המצב הנוכחי: logon account ברשימת השירותים, ואירוע 4624 (logon type 5).¹¹

במשפט אחד, ברירת המחדל היא תצורה בלי סיסמה אנושית לשירות (built-in, virtual account, gMSA); domain user הוא מוצא אחרון — זו מסקנת המאמר.

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

רקע קצר אחד. בהפעלת שירות, Service Control Manager (SCM) מתחבר עם החשבון שהוגדר, ובהצלחה יוצר access token ומשייך אותו ל-process של השירות. מכאן ואילך כל גישה למשאב — קובץ, pipe וכו’ — נשפטת מול ה-token הזה וה-ACL.⁷ כלומר בחירת logon account היא עיצוב של תוכן ה-token שעובר ל-process של השירות. שש האפשרויות, זו ליד זו.

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

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

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

להלן חופרים שורה-שורה בטבלה.

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

3.1. חזק עוד יותר מ-«Run as administrator»

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

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

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

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

3.2. למה בכל זאת ממשיכים לבחור בו

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

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

איור 4: ברירת המחדל וחוויית הפיתוח בלי access denied מייצרות שירותים שנשארים קפואים על LocalSystem.

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

לקרוא ל-LocalSystem «החשבון החזק ביותר ב-Windows» אינו מדויק. מ-Windows Vista ואילך Windows Resource Protection (WRP) מתיר שינוי של קבצי מערכת, תיקיות ומפתחות Registry חשובים רק ל-TrustedInstaller (שירות Windows Modules Installer); גם SYSTEM וגם Administrator מקבלים access denied.¹² «You need permission from TrustedInstaller» ב-Explorer הוא המנגנון הזה. ולהפך: LocalSystem מגיע כמעט לכל מה שמחוץ לאזור מוגן WRP, ובדרך כלל אין סיבה לתת את זה לשירות עסקי.

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

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

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

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

4. LocalService ו-NetworkService —‏ built-in accounts ב-least privilege

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

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

• LocalService: מתחבר למרוחק ב-anonymous credentials. אין גישה למשאב שדורש אימות.
• NetworkService: מציג למרוחק את credentials של המחשב (בסביבת domain: DOMAIN\computer-name$).

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

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

איור 6: גם כשההרשאות המקומיות זהות ומינימליות, הזהות מהצד הרחוק של הרשת מתפצלת לאנונימי מול computer account.

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

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

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

את «להישאר בהרשאה נמוכה, ולהפריד לפי שירות» פותר ה-virtual account בפרק הבא.

5. Virtual accounts (NT SERVICE\) — ברירת המחדל המודרנית

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

Virtual account הוא «managed local account» שזמין מ-Windows Server 2008 R2 / Windows 7 ואילך. שלוש תכונות.⁶

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

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

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

איור 8: Virtual account שומר את יתרון ה-built-in accounts ומבטל רק את החיסרון שאי אפשר להפריד בגלל שיתוף.

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

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

# Change the service logon account to a virtual account
# 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 on the data folder to this service only
icacls "C:\ProgramData\MyApp" /grant "NT SERVICE\MyAppService:(OI)(CI)M"

ב-GUI, ב-services.msc פותחים מאפייני השירות → לשונית «Log On» → ב-«This account» מזינים NT SERVICE\service-name ומשאירים את שדות הסיסמה ריקים (ב-virtual account וב-MSA המפרט של SCM הוא לא לציין סיסמה). אחרי השינוי עושים restart לשירות כדי שיחול.

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

זהות virtual account היא מקומית למכונה, וה-domain לא מכיר אותה. ברשת היא מצטמצמת ל-computer account כפי שיידון בהמשך, ולכן מהצד המרוחק אי אפשר להבחין «איזה שירות», ואי אפשר לחלוק אותה זהות בין כמה שרתים.¹⁰

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

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

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

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

6.1. «שירות לא יכול לגשת ל-shared folder» הוא אי-הבנה

במכונה מצורפת ל-domain, כששירות שרץ כ-LocalSystem, NetworkService או virtual account ניגש למשאב מרוחק, הוא מאומת כ-computer account (DOMAIN\computer-name$).³⁶ רוב הפניות בפתיחה מסוג «לא הצלחנו לגשת ל-shared folder אז הרצנו כ-domain user» נפתרות בזה. ה-ACL ביעד פשוט לא התיר PC$.

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

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

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

# On the file server: grant the service on APPSV01 modify on the share
# 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, אם יוצרים את ה-computer account כ-login, מחרוזת החיבור עוברת עם Integrated Security=true בלי סיסמה.

-- On the DB server: allow Windows integrated auth from the service on APPSV01
CREATE LOGIN [CORP\APPSV01$] FROM WINDOWS;

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

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

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

כשרוצים לעבור את גבול 1, התשובה של 2026 היא לא הפרק הבא על domain user… אלא לדלג על הבעיות שלו ולהתקדם ל-gMSA.

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

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

7. בעיית השימוש ב-domain user לשירות

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

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

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

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

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

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

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

7.2. Kerberoasting —‏ service account הופך למטרה

עוד מתקפה ייחודית ל-service account שהוא domain user היא Kerberoasting. שירות שמקבל אימות Kerberos רושם SPN (service principal name) על ה-logon account. כל משתמש מאומת ב-domain יכול לבקש service ticket לחשבון עם SPN רשום, ולכן תוקף משיג את הכרטיס ומנסה brute-force לסיסמה ב-offline. סיסמה אנושית של בערך 10–16 תווים לא עומדת במתקפה הזו.

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

איור 13: כל משתמש מאומת יכול לבקש כרטיס, וסיסמה באורך שאדם בוחר לא עומדת ב-brute-force offline.

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

7.3. אם בכל זאת משתמשים ב-domain user

אם האפליקציה לא תומכת ב-gMSA וחייבים domain user, קחו לפחות את ההקשחות הבאות.

• הסיסמה אקראית, 25 תווים ומעלה, ולא כותבים אותה מחוץ לכלי ניהול סיסמאות (ספר הפעלה, סקריפט, Excel משותף)
• חשבון ייעודי לשירות, וחשבון נפרד לכל שירות (לא לשתף עם חשבון אנושי²)
• לדחות interactive logon ו-Remote Desktop, ולהתיר רק «Log on as a service»
• לצמצם את הקבוצות (הוספה ל-Domain Admins מחוץ לדיון)
• לבנות נוהל סיבוב תקופתי, ולתעד ב-inventory לאן השינוי מגיע

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

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

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

gMSA (group Managed Service Account) הוא domain account שמשאיר ניהול סיסמה ל-domain controller. הסיסמה מחושבת בידי ה-DC ממפתח השורש של KDS (Key Distribution Service), ורק מארחים מורשים שולפים אותה.¹³

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

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

האפקט ברור.⁹

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

בני אדם מפעילים בלי לדעת את הסיסמה — קל לתפוס את המיקום אם חושבים על זה כעל מה ש-Windows LAPS עושה לסיסמת local Administrator, רק מול service account.

8.2. דרישות

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

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

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

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

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

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

# Check for a KDS root key and create one if missing (once per forest)
Get-KdsRootKey
Add-KdsRootKey -EffectiveImmediately   # actually usable after up to 10 hours

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

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

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

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

# ① Create a security group allowed 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
# reboot the target servers after adding them

# ② 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 and test the gMSA
Install-ADServiceAccount -Identity "svc-batch"
Test-ADServiceAccount -Identity "svc-batch"   # True means retrieval works

# ④ Set the service 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 אינם ניתנים ל-interactive sign-in.¹ אחר כך נותנים ל-ACL של shared folder או SQL Server את CORP\svc-batch$ במקום PC$, וגישת רשת בזהות ייחודית לשירות מושלמת בלי סיסמה.

8.4. חלק מהאפליקציות אינן תומכות

שימו לב: לא כל תוכנה רצה כ-gMSA. Windows service, IIS application pool, משימת Task Scheduler וכדומה — דברים שמגדירים זהות logon במנגנון סטנדרטי — תומכים בהרחבה, אבל יש אילוצים כמו failover clustering עצמו שאינו תומך ב-gMSA, ואפליקציה שבנויה לדרוש סיסמה מבפנים לא יכולה להשתמש.¹⁰ גם Microsoft כותבת במפורש לאשר התנהגות כ-gMSA בסביבת בדיקה לפני ייצור.⁹

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

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

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

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

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

9.1. הזכות «Log on as a service» (SeServiceLogonRight)

כדי לעלות כשירות, לחשבון צריכה להיות user right «Log on as a service». ל-LocalSystem, LocalService ו-NetworkService היא ניתנת built-in, אבל לכל חשבון אחר (domain user, gMSA וכו’) צריך להקצות במפורש.¹⁵

הגדרה מלשונית «Log On» ב-GUI של services.msc גורמת ל-snap-in להעניק את הזכות אוטומטית. לעומת זאת CreateService/ChangeServiceConfig (ה-API ש-sc.exe config קורא) לא בודקים אם לחשבון שצוין יש את הזכות. הסיבה הטיפוסית לשירות שהוגדר בסקריפט ונעצר בהפעלה עם «Logon failure» היא זו. אל תסתמכו על תופעת לוואי של הכלי; הכניסו במפורש לנוהל הפריסה הוספה ל-«Log on as a service» ב-Local Security Policy (secpol.msc), או הגדרה ב-GPO/Intune (בסביבה שבה הזכות הזו מוגדרת ב-Group Policy, הענקה מקומית נדרסת בהחלת המדיניות — שימו לב גם לזה). ולהפך: לחשבון ייעודי לשירות מקובל להגדיר גם «Deny log on locally».

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

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

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

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

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

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

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

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

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

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

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

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

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

9.4. ביקורת — הסתכלו על 4624, logon type 5

הפעלת שירות נרשמת ביומן האבטחה כאירוע 4624 (An account was successfully logged on) עם logon type 5 (Service: SCM התחיל שירות). השדה «Virtual Account» באירוע מציין אם זו התחברות של MSA/virtual account, ולכן אפשר להשתמש בו גם למעקב אחרי שימוש בחשבונות מנוהלים.¹¹

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

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

למיון המצב הנוכחי, הדרך המהירה היא לסכם את ה-logon account ברשימת השירותים.

# Summarize which services run as which account
Get-CimInstance Win32_Service |
    Group-Object StartName |
    Sort-Object Count -Descending |
    Select-Object Count, Name

# Find non-inbox services that run as LocalSystem (tell first-party/third-party by path)
Get-CimInstance Win32_Service |
    Where-Object { $_.StartName -eq 'LocalSystem' -and $_.PathName -notlike '*\Windows\*' } |
    Select-Object Name, DisplayName, PathName

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

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

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

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

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

שאלה 1: האם השירות ניגש למכונות אחרות ברשת (shared folder, DB, API וכו’) ב-Windows authentication?

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

שאלה 2: (אם ניגשים) האם המכונה מצורפת ל-domain?

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

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

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

שאלה 4: האם האפליקציה תומכת ב-gMSA?

אם כן (דברים שמגדירים זהות logon במנגנון סטנדרטי — SCM, IIS app pool, Task Scheduler וכו’ — בדרך כלל כן) → gMSA. אל תשכחו לאשר התנהגות בסביבת בדיקה. אם בכל זאת אין תמיכה, משתמשים ב-domain user ייעודי אחרי שמחילים את כל ההקשחות בפרק 7.3.

בטבלה זה נראה כך.

11. סיכום

• ה-logon account של השירות הוא החלטת עיצוב שקובעת יחד הרשאות מקומיות, זהות ברשת וניהול סיסמה. אל תשאירו את ברירת המחדל (LocalSystem) כמו שהיא.
• ל-LocalSystem יש token של SYSTEM+Administrators והרשאות חזקות; הנזק בהשתלטות מקסימלי. לרוב השירותים העסקיים ההרשאה הזו מיותרת.
• LocalService ו-NetworkService שניהם בהרשאה נמוכה; ההבדל הוא הזהות ברשת (אנונימי מול computer account). אבל החשבון משותף לכמה שירותים, ולכן אי אפשר להפריד.
• Virtual account (NT SERVICE\) הוא ברירת המחדל המודרנית: בלי ניהול סיסמה, עם הפרדה לפי שירות. אפשר לציין ישירות ב-ACL, וההגדרה היא רק שינוי שם ה-logon account.
• LocalSystem, NetworkService ו-virtual account יוצאים לרשת בסביבת domain כ-DOMAIN\PC$. במקרים רבים מתן PC$ ל-ACL של shared folder או SQL Server מספיק בלי domain user.
• שימוש ב-domain user לשירות נושא בעיות מבניות: עצירה בתפוגה, התפשטות סיסמה גלויה, ו-Kerberoasting. אם משתמשים, חובה חשבון ייעודי + סיסמה אקראית ארוכה + הגבלת logon.
• gMSA הוא מנגנון שבו AD מייצר ומסובב סיסמה אוטומטית; התנאים הם domain, functional level 2012 ומעלה, ו-KDS root key. לשירות מגדירים «DOMAIN\name$» עם שדה סיסמה ריק.
• בהחלפת חשבון מכניסים לנוהל המעבר את הזכות «Log on as a service», העברת פרופיל ו-%TEMP%, והזנה מחדש של נתונים מוגני DPAPI. ביקורת אפשר לאשר באירוע 4624 logon type 5.

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

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

• 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 מטפלת בעיצוב logon account ובהקשחת least privilege ל-Windows services ולאפליקציות resident, בהגירת שירותים קיימים שנבנו בהנחת LocalSystem ל-virtual account או ל-gMSA, ובחקירת כשלים שנגרמו מ-access denied, DPAPI והפרופיל אחרי שינוי חשבון. להתחיל משלב «סומנו בביקורת, אבל איננו יודעים מאיפה להתחיל» זה בסדר.

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

קישורי עיון

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

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

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

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

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

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

שאלות נפוצות

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

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

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

לבחור virtual account או NetworkService?

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

אפשר להשתמש ב-gMSA בסביבת workgroup (בלי domain)?

לא. gMSA הוא מנגנון שבו domain controller של Active Directory מייצר ומנהל את הסיסמה, ו-domain ויצירת KDS root key הם תנאים מוקדמים. ב-workgroup הבסיס הוא לסיים עיבוד מקומי ב-virtual account או LocalService/NetworkService. אם צריך גישה למכונה אחרת, נדרש עיצוב אחר כמו שימוש מפורש ב-credentials של חשבון שהוכן ביעד. גישת רשת כ-computer account (PC$) גם היא תקפה רק בסביבת domain.

אחרי שהחלפתי את ה-logon account של השירות, אי אפשר לקרוא הגדרות ו-credentials ששמרתי. למה?

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

אם אני רוצה רק שהשירות ייגש ל-shared folder, האם צריך domain user?

במקרים רבים לא. בסביבת domain שירות שרץ כ-LocalSystem, NetworkService או virtual account מאומת מול הצד הרחוק כ-computer account (DOMAIN\computer-name$). הוסיפו את ה-PC$ להרשאות השיתוף ולהרשאות NTFS של ה-shared folder והוא יוכל לקרוא ולכתוב. אם אתם רוצים בקרת גישה בזהות ייחודית לשירות, או אותה זהות בכמה שרתים, שקלו gMSA במקום domain user.

פרופיל הכותב

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

Go Komura

מנהל KomuraSoft LLC

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