"אותו מחשב" אינו אותה סביבת הרצה — גבול המשתמש שמפריד AppData, HKCU, DPAPI ו-Credentials

האפליקציה קוראת את קובץ התצורה כשמפעילים מ-File Explorer, אבל Task Scheduler מדווח שהוא “לא נמצא”. הופכים אותה לשירות והיא כבר לא יכולה לעשות decrypt לסיסמה השמורה. הדפדפן על השולחן מחובר, אבל ב-CI הוא חוזר למסך ה-login.

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

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

הנחות המאמר

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

יחידת הבסיס שמחלקת סביבת הרצה ב-Windows אינה המחשב אלא ה-access token וה-SID, כלומר “מי התהליך רץ כ.” AppData, HKCU, מפתחות DPAPI, profiles של דפדפן ו-credentials שייכים לסביבה של המשתמש הזה.

ההגדרות ומצב ה-sign-in שהכנתם תחת ה-logon האינטראקטיבי שלכם לא עוברים אוטומטית ל-SYSTEM או לחשבון שירות אחר. האזורים לנתונים ברמת המכונה הם ProgramData ו-HKLM, ושיתוף דרכם עדיין דורש לתכנן את הרשאות הגישה.

flowchart TB
    accTitle: שני עולמות בתוך אותו מחשב
    accDescr: אותו מחשב חולק רק HKLM ו-ProgramData, בעוד העולם של ה-SID שלכם והעולם של SID אחר לכל אחד יש AppData, hive של Registry ומפתחות DPAPI משלו, בלתי נראים זה לזה מעבר לגבול המשתמש
    pc["אותו מחשב"] --> shared["משותף: HKLM ו-ProgramData"]
    pc --> wa["העולם של ה-SID שלכם"]
    pc --> wb["העולם של SID אחר (SYSTEM וכו')"]
    wa --> ra["AppData, HKCU, מפתחות DPAPI"]
    wb --> rb["AppData אחר, hive אחר, מפתחות אחרים"]
    ra -.-|"גבול המשתמש: בלתי נראים זה לזה"| rb

איור 1: באותו מחשב, משתמש הרצה אחר פירושו AppData אחר, Registry אחר ומפתחות אחרים.

עם זאת, אותו SID אינו מבטיח אותה סביבה. בודקים גם את סוג ה-logon של המשימה, את טעינת ה-profile ב-IIS, ואת ההבדל ב-logon session שיוצרת העלאת UAC. elevation בתוך אותו חשבון לא הופך את HKCU או את הכספת למשתמש אחר; מה שחשוב הוא לחשוב בנפרד אילו גבולות משתנים.

שאר המאמר מתקדם בסדר הזה: משתמש ההרצה כהנחה (פרק 2), חמשת הגבולות (פרקים 3 עד 7), הבדיקה לפי צורת הרצה (פרק 8), ותכנון וחקירה (פרק 9).

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

2. הנחה: “מי זה רץ כ” מחליט הכל

2.1 בודקים את ה-SID ואת ה-token, לא את שם המשתמש

המזהה ש-Windows משתמש בו כדי לזהות משתמש אינו שם המשתמש אלא ה-SID (security identifier). תהליך מחזיק access token, וה-token מכיל את ה-SID של משתמש ההרצה. ה-principal הזה הוא נקודת ההתחלה בכל פעם שחושבים על בדיקות ACL של קבצים, על ה-Registry הפיזי מאחורי alias, או על מפתחות הצפנה.

משתמשים ב-whoami /user לבדיקה הראשונה. מאשרים את התוצאה בסביבת ההרצה שבה הבעיה קורה, לא במסוף שלכם.

> whoami /user

USER INFORMATION
----------------

User Name       SID
=============== =============================================
desktop\you     S-1-5-21-3623811015-3361044348-30300820-1001

C:\Users\you הוא הצורה על הדיסק של ה-user profile הקשור ל-SID הזה. profile מורכב מקבוצת תיקיות כמו AppData ומ-hive ה-Registry של המשתמש NTUSER.DAT. כי הוא מועתק מ-profile ברירת המחדל ב-logon הראשון, profile של משתמש אחר מתחיל ממצב התחלתי שנפרד מהסביבה שהגדרתם.¹

flowchart TB
    accTitle: מנתיב ההפעלה עד ה-profile
    accDescr: בין אם הופעל ב-double-click, ב-Task Scheduler או בשירות או IIS, התהליך מחזיק את ה-SID ב-access token שלו, וקבוצת נתוני ה-user profile הקשורה ל-SID הזה הופכת לסביבת ההרצה שלו
    e1["double-click"] --> tok["token של התהליך (SID)"]
    e2["Task Scheduler"] --> tok
    e3["שירות או IIS"] --> tok
    tok --> prof["קבוצת profile הקשורה ל-SID"]
    prof -.-> note["SID אחר פירושו profile אחר במצב התחלתי"]

איור 2: הנתיב שבו תהליך מופעל קובע את ה-profile של איזה SID הוא נושא בזמן הריצה.

2.2 לחשבונות שירות יש לכל אחד סביבה משלו

ל-Windows יש חשבונות מובנים שרצים בלי שבן אדם מתחבר. לכל אחד מהם יש סביבת הרצה עצמאית.²

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

2.3 שלושה תנאים לבדוק אחרי “אותו משתמש”

לא עוצרים בבדיקת ה-SID; משתמשים בשלושת אלה כדי לסדר מה שונה גם עם אותו חשבון. משימות מכוסות בפירוט בפרק 8, IIS בפרקים 4 ו-5, ו-elevation בפרק 7.

3. גבול 1: AppData — אותו משתנה סביבה מצביע למקום אחר

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

3.1 החלוקות של AppData ואיך משתמש ההרצה משנה אותן

AppData הוא תיקייה תחת ה-user profile. המטרות שלו מחולקות כך.¹⁰

גם כשאותו קוד פותח %APPDATA%, המיקום שהוא מפנה אליו משתנה עם משתמש ההרצה.

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

flowchart TB
    accTitle: איך %APPDATA% נפתר תלוי במשתמש
    accDescr: גם כשאותו קוד פותח %APPDATA%, הוא נפתר לנתיב תחת C:\Users אם משתמש ההרצה הוא אתם ותחת systemprofile אם הוא SYSTEM, וקובץ התצורה שלכם לא קיים באחרון
    code["אותו קוד: פותחים %APPDATA%"] --> q{"משתמש ההרצה?"}
    q -->|"אתם"| a["C:\\Users\\you\\AppData\\Roaming"]
    q -->|"SYSTEM"| b["AppData תחת systemprofile"]
    b -.-> miss["הקובץ ששמתם שם חסר"]

איור 3: משתני סביבה לא משקרים, אבל לאן הם נפתרים תלוי ב-token.

3.2 גם PATH שונה לפי משתמש

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

מחליטים על מיקום האחסון לפי מי קורא את הנתונים. הגדרות למשתמש הזה בלבד הולכות תחת AppData; נתונים שמשותפים לכל המשתמשים או לשירותים הולכים תחת %ProgramData%, ולאחרונים מתכננים את ה-ACLs. לדרך בחירה מפורטת, ראו “איך בוחרים איפה אפליקציית Windows שומרת נתונים מקומיים”.

flowchart TB
    accTitle: בוחרים את מיקום האחסון לפי הקוראים
    accDescr: נתונים שרק המשתמש הזה קורא הולכים ל-AppData או HKCU, נתונים שמשותפים לכל המשתמשים או לשירותים הולכים ל-ProgramData או HKLM, ולאחרונים מצטרף תכנון ACL
    q{"מי קורא את הנתונים האלה?"} -->|"רק המשתמש הזה"| f1["AppData, HKCU"]
    q -->|"כל המשתמשים, שירותים"| f2["ProgramData, HKLM"]
    f1 -.-> w1["שוקלים מחדש אם זה עשוי להפוך לשירות"]
    f2 -.-> w2["מתכננים הרשאות כתיבה ו-ACLs"]

איור 4: “אי אפשר לקרוא את זה ברגע שזה הפך לשירות” הוא התוצאה של דילוג על הענף הזה בזמן התכנון.

4. גבול 2: HKCU — “המשתמש הנוכחי” משתנה עם הקורא

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

4.1 HKCU הוא alias ל-hive של המשתמש

HKEY_CURRENT_USER (HKCU) אינו hive עצמאי; הוא alias שמנותב למיקום פיזי לפי המשתמש הקורא. בתהליך משתמש רגיל הוא מצביע למפתח של ה-SID הזה תחת HKEY_USERS. התוכן שלו הוא ה-NTUSER.DAT שנטען ב-logon.¹

החריג הוא HKCU\Software\Classes, שהמיקום הפיזי שלו הוא קובץ hive נפרד, UsrClass.dat. הקובץ הזה חי תחת %LOCALAPPDATA%\Microsoft\Windows.¹¹

ה-HKCU של LocalSystem משויך למשתמש ברירת המחדל (HKEY_USERS\.DEFAULT). כש-installer שרץ תחת חשבון administrator כותב ל-HKCU ושירות SYSTEM קורא מ-HKCU, שניהם מפנים למקומות שונים.³

flowchart TB
    accTitle: מה ה-alias HKCU באמת
    accDescr: כשאפליקציה פותחת HKCU, היא מנותבת למפתח ה-SID שלכם תחת HKEY_USERS בתהליך שלכם ולמפתח משתמש ברירת המחדל בתהליך LocalSystem, כך שהערך שה-installer כתב כבר לא נראה
    app["קוד האפליקציה: פותחים HKCU"] --> alias["HKCU הוא alias למפתח האמיתי"]
    alias -->|"התהליך שלכם"| ha["ה-SID שלכם תחת HKEY_USERS"]
    alias -->|"תהליך SYSTEM"| hd["HKEY_USERS\\.DEFAULT"]
    hd -.-> gone["הערך שכתבתם לא קיים"]

איור 5: גם תחת אותו שם HKCU, משתמש אחר פירושו hive אחר נקרא ונכתב.

שמים הגדרות ברמת המכונה ב-HKLM. Microsoft לא ממליצה לגשת ל-HKCU משירות. אם צריך לקרוא הגדרות של משתמש, עושים impersonation למשתמש הזה ואז משתמשים ב-RegOpenCurrentUser.¹²

4.2 בודקים גם אם ה-profile נטען

מעבר לחשבון ההרצה, גם אם ה-profile נטען יכול להיות הבעיה.

IIS application pools רצים בלי לטעון user profile כברירת מחדל. הפעלת loadUserProfile הופכת את AppData ואת ה-hive תחת ה-profile לזמינים.⁷ ההגדרה הזו משפיעה גם על איפה נשמרים מפתחות DPAPI ו-ASP.NET Core Data Protection של הפרק הבא.

ההגדרה “Do not store password” של משימה נבדקת בנפרד, כמגבלה של סוג logon. גם עם אותו משתמש שצוין, S4U logon לא יכול להשתמש ברשת או ב-EFS. ההבדלים הקונקרטיים בין תצורות מסוכמים בפרק 8.⁶

5. גבול 3: DPAPI — ההצפנה נעולה עם “המפתח של המשתמש”

בעוד AppData ו-HKCU הם בעיות של הסתכלות במקום אחר, DPAPI מייצר בעיה שבה אפשר לקרוא את הקובץ אבל אי אפשר לעשות decrypt לתוכן. הפיכת אפליקציה שמשתמשת בסיסמה שמורה לשירות וקבלת CryptographicException היא דוגמה אחת.

5.1 בעל master key אחר פירושו אין decryption

DPAPI (Data Protection API) הוא מתקן ההצפנה ש-Windows מספק לאפליקציות. קריאה ל-CryptProtectData או ל-ProtectedData.Protect של .NET מאפשרת לאפליקציה להגן על נתונים בלי לשאת מפתח הצפנה בקוד שלה עצמה.¹³

זה לא הופך את המפתח למיותר, עם זאת. DPAPI משתמש ב-master key שמנוהל על ידי מערכת ההפעלה. ב-scope CurrentUser, master key אקראי לפי משתמש מוגן במפתח שנגזר מ-credentials של ה-logon ונשמר תחת ה-profile.¹⁴

flowchart TB
    accTitle: שרשרת המפתחות של DPAPI
    accDescr: ה-master key האקראי של המשתמש מוגן במפתח שנגזר מ-credentials של ה-logon, ה-master key הזה מצפין את ה-secrets של האפליקציה, ו-master key של משתמש אחר לא יכול לעשות decrypt לאותו ciphertext
    pwd["credentials של logon"] -->|"מגן דרך מפתח נגזר"| mk["ה-master key שלכם"]
    mk -->|"מצפין"| sec["secret של האפליקציה (סיסמה שמורה וכו')"]
    mk2["master key של משתמש אחר"] -.->|"לא יכול לעשות decrypt"| sec
    mk -.-> loc["נשמר תחת ה-profile"]

איור 6: הנתונים לא מוצפנים ישירות מה-credentials; מפתח שנגזר מה-credentials מגן על ה-master key.

הבא הוא דוגמה מינימלית שבה משתמש A מצפין נתונים, מניח אותם במיקום משותף, ומשתמש אחר מנסה לעשות decrypt. שיתוף מיקום האחסון לא משנה מי יכול לעשות decrypt תחת CurrentUser.

# בסשן של משתמש A: מצפינים ב-scope CurrentUser ושומרים למיקום משותף
Add-Type -AssemblyName System.Security
$bytes = [Text.Encoding]::UTF8.GetBytes("secret")
$enc = [Security.Cryptography.ProtectedData]::Protect($bytes, $null, "CurrentUser")
[Convert]::ToBase64String($enc) | Set-Content C:\ProgramData\demo.bin

# כמשתמש אחר (למשל, אחרי שהפכתם ל-SYSTEM עם PsExec), מנסים לעשות decrypt
$enc = [Convert]::FromBase64String((Get-Content C:\ProgramData\demo.bin))
[Security.Cryptography.ProtectedData]::Unprotect($enc, $null, "CurrentUser")
# → CryptographicException: הנתונים אינם תקפים במצב הנוכחי

5.2 בוחרים את ה-scope ממי אמור להיות מסוגל לעשות decrypt

secret שגם שירות וגם המשתמש האינטראקטיבי קוראים צריך להיות מתוכנן מההתחלה כ-LocalMachine משולב עם ACL על הקובץ, או שהתהליך צריך לרוץ תחת החשבון של מי שהצפין. לא משנים את ה-scope רק כדי שהשגיאת decryption תיעלם; מחליטים מי מורשה לעשות decrypt. במכונות משותפות, גם מודעים לסיכון שהגנה ברמת המכונה רחבה מדי.¹⁵

flowchart TB
    accTitle: איך בוחרים את ה-scope של DPAPI
    accDescr: בוחרים את ה-scope CurrentUser אם רק המשתמש הזה אמור להיות מסוגל לעשות decrypt ואת ה-scope LocalMachine אם כמה principals באותו מחשב צריכים, ומגבילים את הקוראים של האחרון עם ACL על הקובץ
    q{"מי אמור להיות מסוגל לעשות decrypt?"} -->|"רק המשתמש הזה"| cu["scope CurrentUser"]
    q -->|"כמה principals באותו מחשב"| lm["scope LocalMachine"]
    cu -.-> r1["decrypt נכשל כשרצים כמשתמש אחר"]
    lm -.-> r2["מגבילים קוראים עם ACL על הקובץ"]

איור 7: בוחרים את ה-scope כהחלטת תכנון על מי עושה decrypt, לא כ”מה שקרה לעבוד”.

5.3 “שינוי” סיסמה ו”איפוס” הם שונים

המפתח ששומר על ה-master key תלוי ב-credentials של ה-logon. כשמשתמשים משנים את הסיסמה שלהם עצמם, ה-master key מוגן מחדש במפתח שנגזר מהסיסמה החדשה, והיכולת לעשות decrypt עוברת.

לעומת זאת, כש-admin מאפס את הסיסמה של חשבון מקומי, ciphertext מהעבר עשוי כבר לא להיות ניתן ל-decrypt. גם עם אותו חשבון, צריך לבדוק איך ה-credentials שונו.¹⁴

5.4 בודקים איפה המפתחות נשמרים גם ב-ASP.NET Core

גם קוד שמעולם לא קורא ל-DPAPI ישירות יכול להיות תלוי בגבול הזה. ASP.NET Core Data Protection שומר את ה-key ring שמשמש להגן על cookie authentication ודומים במיקום שתלוי בסביבה.¹⁶

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

בחירת scope ומתי להשתמש ב-Credential Manager במקום מכוסים בפירוט ב-“Secrets ביישומי Windows: DPAPI במקום plaintext ב-config”.

6. גבול 4: profiles של דפדפן — “מחובר” שייך למשתמש

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

6.1 יש שני גבולות: מיקום אחסון ומפתח

ה-profile של דפדפן מבוסס Chromium כמו Chrome או Edge חי כברירת מחדל בתיקיית User Data תחת %LOCALAPPDATA%. היסטוריה, cookies, הרחבות, סיסמאות שמורות וכן הלאה שייכים לסביבה של משתמש Windows הזה.¹⁷

cookies וסיסמאות שמורות מוצפנים במפתח הצפנה בתוך ה-profile, והמפתח עצמו מוגן ב-DPAPI. העתקת התיקייה למשתמש אחר או למכונה אחרת לכן נכשלת ב-decrypt כי המפתח לא תואם.

Chrome האחרון מניח App-Bound Encryption מעל זה. decrypt של המפתח עובר דרך שירות שרץ עם הרשאות SYSTEM, שמאמת לא רק את המשתמש אלא גם את זהות האפליקציה המבקשת.¹⁸ זה חל על דפדפנים מבוססי Chromium; המצב שונה לדפדפנים כמו Firefox שיש להם הגנת profile משלהם.

flowchart TB
    accTitle: שני הגבולות מאחורי מצב sign-in של דפדפן
    accDescr: ה-profile של הדפדפן חי תחת LOCALAPPDATA ושייך לגבול 1, ומפתח הצפנת ה-cookie מוגן ב-DPAPI ושייך לגבול 3, כך שגם ה-profile וגם המפתח לא עוברים למשתמש אחר
    prof["profile של דפדפן"] --> loc["נשמר תחת LOCALAPPDATA"]
    prof --> key["מפתח הצפנת cookie מוגן ב-DPAPI"]
    loc -.-> ci["משתמש ההרצה של CI מקבל profile ריק ונפרד"]
    key -.-> copy["אי אפשר לקחת בהעתקת התיקייה"]

איור 8: “לקחת את מצב ה-sign-in איתכם” נחסם גם על ידי גבול 1 וגם על ידי גבול 3.

6.2 באוטומציה, הופכים את הדרך שבה מצב sign-in נוצר למפורשת

Selenium ו-Playwright מופעלים כברירת מחדל עם profile זמני חד-פעמי. כך שגם תחת אותו משתמש, מצב ה-sign-in של הדפדפן היומיומי שלכם לא בשימוש אוטומטית.

גם אם מציינים תיקיית profile קבועה, בעיות מיקום האחסון והמפתח של הפרק הקודם נשארות ברגע שעוברים ל-job ב-CI או לשירות תחת משתמש אחר. התיקון אינו להעתיק profile מחובר אלא אחד מאלה.

• מקודדים את שלבי ה-sign-in לחשבון בדיקה.
• משתמשים במנגנון storage-state של כלי האוטומציה כדי לשמור ולשחזר cookies ודומים במפורש.

זה שמשתמש אחר לא יכול להשתמש ב-cookies עם העתקה בלבד אינו אי-נוחות; זה גם גבול אבטחה. מתכננים את האוטומציה על ההנחה שהגבול הזה קיים.

7. גבול 5: Credentials ותעודות — לכל משתמש יש כספת נפרדת

credentials שנשמרו עם cmdkey לא בשימוש כשהמשימה רצה, והאימות נכשל. גם כאן, בודקים לא “זה נשמר במחשב” אלא “כאיזה משתמש זה נשמר.”

7.1 Credential Manager הוא כספת לפי משתמש הרצה

Credential Manager, שאפשר לבדוק עם cmdkey /list, הוא כספת לפי משתמש.¹⁹ credentials שמורים נמצאים על הדיסק, אבל הם מוגנים ב-DPAPI ומשמשים תוכניות שרצות כמשתמש הזה.²⁰

הכספת מחזיקה credentials שמורים לשרתי קבצים ולכונני רשת, tokens של Git ששמר git-credential-manager, סיסמאות שמורות לחיבורי RDP, secrets של אפליקציות שמשתמשות ב-Credential API, וכן הלאה.

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

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

flowchart TB
    accTitle: כספת ה-credentials היא לפי משתמש
    accDescr: הכספת שלכם מחזיקה credentials של Git, credentials שמורים לשרתי קבצים וסיסמאות RDP, אבל הכספת של משתמש הרצת השירות ריקה אלא אם מכניסים credentials, וזה מה ששגיאת האימות באמת
    you["הכספת שלכם"] --> g["credentials של Git"]
    you --> n["credentials שמורים לשרתי קבצים"]
    you --> r["סיסמאות RDP שמורות"]
    svc["כספת משתמש הרצת השירות"] -.-> empty["ריקה אלא אם הוכנסו = שגיאת האימות האמיתית"]

איור 9: “האימות עובד אצלי” הוא רק קיצור ל”הכספת שלי זמינה.”

7.2 לתעודות, בודקים את ה-store ואת הרשאות המפתח הפרטי בנפרד

לתעודה שמשמשת שירות, התכנון הבסיסי הוא store של LocalMachine יחד עם ה-ACL על המפתח הפרטי.²¹ ה-store של המשתמש חי פיזית תחת HKCU\Software\Microsoft\SystemCertificates, כך שהוא יושב בתוך גבול HKCU.²²

לפרטים, ראו “Certificate Store ב-Windows — CurrentUser או LocalMachine, לאן שמים”.

7.3 עם העלאת UAC, מפרידים “אותו חשבון” מ”חשבון אחר”

כשמשתמש administrator מתחבר עם UAC מופעל, נוצרים שני tokens מקושרים: token סטנדרטי עם הרשאות מוגבלות ו-token administrator מלא.⁸

mappings של כונני רשת הם לפי logon session. Z: עשוי להיות נראה ב-File Explorer ועדיין בלתי נראה לכלי שרץ כ-administrator.⁹

לא מניחים שכל “זה מפסיק לעבוד כשעושים elevate” הוא שינוי משתמש; קודם בודקים אם זה אותו חשבון.

flowchart TB
    accTitle: הפיצול בתוך משתמש אחד שיוצרת העלאת UAC
    accDescr: logon של administrator עם UAC מופעל יוצר שני tokens, token סטנדרטי ו-token elevated, וכונן רשת שממופה בצד ה-token הסטנדרטי אינו נראה לתהליך שרץ עם ה-token ה-elevated
    logon["logon של משתמש administrator"] --> t1["token סטנדרטי"]
    logon --> t2["token elevated"]
    t1 --> d1["כונן Z: ממופה כאן"]
    t2 -.->|"logon session נפרד"| d2["כלי elevated לא רואה את Z:"]

איור 10: elevation יוצר “עולם אחר לאותו משתמש.” הגבול אינו רק על ה-SID.

8. רשימת בדיקה לפי צורת הרצה

8.1 למשימות, מסתכלים על סוג ה-logon אחרי חשבון ההרצה

ב-Task Scheduler, מה זמין משתנה עם סוג ה-logon גם כשאותו משתמש צוין.⁶

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

פרטי ההגדרות מכוסים ב-“כשמשימות Task Scheduler לא רצות או יוצאות עם 0x1”.

flowchart TB
    accTitle: סוג ה-logon של משימה כציר שני
    accDescr: לתצורת הרצה של Task Scheduler יש סוג logon של interactive token, stored password או S4U, ועם S4U הסיסמה לא נשמרת והרשת ו-EFS אינם נגישים
    task["תצורת הרצת משימה"] --> lt{"סוג logon"}
    lt -->|"Interactive token"| it["רץ בסשן המחובר"]
    lt -->|"Stored password"| pw["credentials שמישים גם לא-אינטראקטיבית"]
    lt -->|"S4U (סיסמה לא נשמרת)"| s4u["לא מגיעים לרשת או ל-EFS"]

איור 11: גם עם אותו משתמש הרצה, איך הוא התחבר משנה מה זמין.

8.2 טבלת הבדיקה לפני שינוי יעד ההרצה

השורה האחרונה היא זהירות בכיוון ההפוך. כמה סשני RDP של אותו משתמש לא נותנים לכל סשן AppData ו-HKCU עצמאיים משלו. כאן הבעיה אינה שמשהו בלתי נראה, אלא שאותו דבר משותף ונכתב אליו.

9. הנחיות לתכנון ולחקירה

9.1 מחליטים על מיקומי אחסון והגדרה מה-principal שמשתמש בהם

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

9.2 חוקרים מ-principal ההרצה למיקום המופנה בפועל

flowchart TB
    accTitle: הליך חקירה לתקלות גבול משתמש
    accDescr: מאשרים את משתמש ההרצה עם whoami, מסתכלים על ה-token ב-Process Explorer, מזהים את הנתיבים ואת מפתחות ה-Registry שנקראו בפועל עם Process Monitor, ואם צריך משחזרים מהעולם של הצד השני עם psexec
    s1["מאשרים את משתמש ההרצה עם whoami /all"] --> s2["בודקים את ה-token ב-Process Explorer"]
    s2 --> s3["מזהים את הנתיבים והמפתחות בפועל עם ProcMon"]
    s3 --> s4["משחזרים מהעולם של הצד השני עם psexec"]
    s3 -.-> hint["נתיב profile לא צפוי הוא הרמז"]

איור 12: מאשרים את משתמש ההרצה, מסתכלים על הנתיבים ועל מפתחות ה-Registry בפועל, ואז משחזרים כ-principal ההרצה היעד.

כשהגדרות חסרות, חוזרים ל-AppData ול-HKCU; כשאפשר לקרוא את הקובץ אבל לא לעשות decrypt, ל-DPAPI; כשרק האימות נכשל, לכספת, לתעודות ולסוג ה-logon. לא שופטים מהודעת השגיאה לבדה; הקיצור הוא ליישר “מי השתמש באיזה מיקום, עם איזה מפתח או credentials.”

10. סיכום

“עובד אצלי” פירושו “עובד כמשתמש הזה, עם ה-profile הזה, עם המפתחות האלה ועם הכספת הזו.” גם כשאותו .exe מופעל באותו מחשב, הפיכה למשימה, לשירות או ל-job ב-CI צריכה להיות מטופלת כמעבר של סביבת ההרצה.

AppData ומשתני סביבה של המשתמש מפנים ל-profile של משתמש ההרצה, ו-HKCU באותו אופן מצביע ל-hive של המשתמש הזה. ה-scope CurrentUser של DPAPI תלוי ב-master key של המשתמש, וגם מצב sign-in של דפדפן ו-Credential Manager מושפעים מהגבול הזה.

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

בסקירות תכנון, שואלים את השאלה הבאה.

האם הקוד הזה נכון לא משנה כאיזה משתמש הוא רץ?

מספקים את מיקומי האחסון, המפתחות וה-credentials הנדרשים במפורש ל-principal ההרצה בפועל. מאשרים את העיקרון הזה לפני המעבר, ואפשר לצמצם, בשלב התכנון, את השבירה שבה “הקוד לא השתנה, ובכל זאת זה נשבר.”

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

• Secrets ביישומי Windows: DPAPI במקום plaintext ב-config
• איך בוחרים איפה אפליקציית Windows שומרת נתונים מקומיים — טבלת החלטה ל-SQLite / JSON / Registry / Access
• כשמשימות Task Scheduler לא רצות או יוצאות עם 0x1 — בידוד הסיבה ותכנון תפעול אמין
• חשבונות שירות ב-Windows: LocalSystem, virtual accounts ו-gMSA
• Certificate Store ב-Windows — CurrentUser או LocalMachine, לאן שמים

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

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

• Windows Custom Software Development
• חקירת תקלות ואיתור גורמים
• שימוש חוזר בנכסים קיימים והעברתם
• יצירת קשר

קישורים

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

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

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

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

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

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

שאלות נפוצות

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

אפליקציה שעובדת כשמפעילים מ-File Explorer לא מוצאת את קובץ התצורה כשמפעילים מ-Task Scheduler. למה?

כי משתני סביבה כמו %APPDATA% נפתרים ל-profile של המשתמש שמריץ את התוכנית. כשהמשימה רצה כ-SYSTEM או כחשבון אחר, משתני הסביבה מצביעים ל-profile אחר (תחת systemprofile במקרה של SYSTEM), וקובץ התצורה ששמרתם לא קיים שם. בודקים את החשבון שהמשימה רצה כ, ושמים נתונים שצריכים להיות משותפים תחת ProgramData כתיקון הקבוע.

סיסמה שנשמרה עם ProtectedData.Protect כבר לא ניתנת ל-decrypt ברגע שהאפליקציה הפכה לשירות.

DPAPI ב-scope CurrentUser תלוי ב-master key של המשתמש שהצפין את הנתונים. אם השירות רץ כחשבון אחר, ה-master key הוא אחר, ולכן decryption נכשל עם CryptographicException. מתכננים מחדש secret שגם השירות וגם המשתמש האינטראקטיבי קוראים כך שישתמש ב-scope LocalMachine יחד עם ACL על הקובץ, או מריצים את השירות תחת החשבון של מי שהצפין.

מה קורה כשתהליך שרץ כ-SYSTEM קורא HKCU?

בתהליך LocalSystem, HKEY_CURRENT_USER משויך למשתמש ברירת המחדל (HKEY_USERS\.DEFAULT), כך שהערכים שהמשתמש האינטראקטיבי כתב ל-HKCU אינם נראים. שמים הגדרות ברמת המכונה ב-HKLM, ואם חייבים לקרוא הגדרות של משתמש, עושים impersonation למשתמש הזה ואז משתמשים ב-RegOpenCurrentUser.

אפשר להעתיק profile מחובר של Chrome/Edge למכונת CI ולהשתמש בו?

בדרך כלל לא. ה-profile של דפדפן מבוסס Chromium כמו Chrome או Edge חי תחת %LOCALAPPDATA% של המשתמש, ומפתח ההצפנה של cookies ושל סיסמאות שמורות מוגן ב-DPAPI של המשתמש הזה. העתקת התיקייה למשתמש אחר או למכונה אחרת נכשלת ב-decrypt כי המפתח לא תואם (דפדפנים כמו Firefox, שיש להם הגנת profile משלהם, הם סיפור אחר). לאוטומציה, מקודדים את שלבי ה-sign-in לחשבון בדיקה, או משתמשים במנגנון storage-state של כלי האוטומציה.

Credentials שנשמרו עם cmdkey לא בשימוש כשהמשימה רצה מ-Task Scheduler.

כי כספת Credential Manager נפרדת לכל משתמש, ומה ששמרתם נכנס לכספת של ה-logon האינטראקטיבי שלכם. בנוסף, משימה שמוגדרת עם "Do not store password" (S4U) רצה בלי network credentials, כך שהכנסת credentials לכספת לא עוזרת כל עוד היא נשארת על S4U. קודם שוקלים תצורה ששומרת את הסיסמה או מעבר לחשבון שירות, ורק אז, אם עדיין נחוץ, מכניסים את ה-credentials לכספת של חשבון ההרצה עצמו.

פרופיל הכותב

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

Go Komura

מנהל KomuraSoft LLC

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