«الجهاز نفسه» ليس بيئة التنفيذ نفسها ── حدود المستخدم التي تفصل AppData وHKCU وDPAPI وبيانات الاعتماد

يقرأ التطبيق ملفّ إعداده عند التشغيل من مستكشف الملفّات، لكن Task Scheduler يبلّغ «غير موجود». حوّله إلى خدمة فلا يعود قادراً على فكّ تشفير كلمة المرور المحفوظة. المتصفّح على مكتبك مسجَّل الدخول، لكن في CI يعود إلى شاشة تسجيل الدخول.

مع هذا النوع من المشكلات، افحص من يشغّل البرنامج، وكيف قبل أن تنظر إلى الشيفرة. الملفّات والإعدادات الموجودة على الجهاز نفسه لا يمكن بالضرورة استخدامها بالطريقة نفسها من مستخدم تنفيذ مختلف.

سؤال هذه المقالة: لماذا ينكسر التطبيق ما إن يُحوَّل إلى مهمّة أو خدمة أو CI دون تغيير الشيفرة؟ إن أردت التحقيق من العَرَض فانتقل من الجدول التالي إلى الموضع المناسب.

مقدّمات هذه المقالة

1. الخلاصة أوّلاً

وحدة التقسيم الأساسية لبيئة تنفيذ Windows ليست الجهاز بل رمز الوصول وSID، أي «من يعمل البرنامج باسمه». ينتمي AppData وHKCU ومفتاح DPAPI وملفّ تعريف المتصفّح وبيانات الاعتماد إلى بيئة ذلك المستخدم.

الإعدادات وحالة تسجيل الدخول التي جهّزتها بنفسك بعد تسجيل دخول تفاعلي لا تُورَّث تلقائياً إلى SYSTEM أو حساب خدمة آخر. مجال وضع بيانات الجهاز كلّه هو ProgramData وHKLM، والمشاركة تتطلّب أيضاً تصميم صلاحيات وصول.

flowchart TB
    accTitle: عالمان داخل الجهاز نفسه
    accDescr: يشارك الجهاز نفسه HKLM وProgramData فقط، ولعالم SID الخاص بك وعالم SID آخر كلّ منهما AppData وخلية سجلّ ومفتاح DPAPI خاصّان، ولا يرى أحدهما الآخر عبر حدود المستخدم
    pc["الجهاز نفسه"] --> shared["مشترك: HKLM وProgramData"]
    pc --> wa["عالم SID الخاص بك"]
    pc --> wb["عالم SID آخر (SYSTEM وغيره)"]
    wa --> ra["AppData وHKCU ومفتاح DPAPI"]
    wb --> rb["AppData آخر وخلية أخرى ومفتاح آخر"]
    ra -.-|"حدود المستخدم: لا يرى أحدهما الآخر"| rb

الشكل 1: حتّى على الجهاز نفسه، إن اختلف مستخدم التنفيذ صارت AppData والسجلّ والمفاتيح شيئاً آخر.

لكن تساوي SID لا يعني حتماً البيئة نفسها. أكّد أيضاً نوع تسجيل دخول المهمّة، وتحميل ملفّ التعريف في IIS، وفرق جلسة تسجيل الدخول بترقية UAC. ترقية الحساب نفسه لا تجعل HKCU والخزينة لمستخدم آخر؛ المهم فصل الحدود التي تتغيّر.

فيما يلي مستخدم التنفيذ كفرضية (الفصل 2)، والحدود الخمس (الفصول 3–7)، والفحص حسب شكل التشغيل (الفصل 8)، والتصميم والتحقيق (الفصل 9).

في المخطّط، يشير الخطّ المتّصل إلى علاقة قائمة دائماً، ويشير الخطّ المتقطّع إلى علاقة مشروطة (شروط قيامها مذكورة في شرح كلّ علاقة في الصفحة التفصيليّة). القائمة الكاملة للعلاقات (المجموع 33، مع الأدلّة ودرجة اليقين) وتعريفات المفاهيم الرئيسة مجمّعة في صفحة تفاصيل خريطة المعرفة (باليابانية). البيانات: JSON-LD / Turtle

2. الفرضية: «من يعمل باسمه» يقرّر كلّ شيء

2.1 أكّد SID والرمز لا اسم المستخدم

معرّف Windows للمستخدم ليس اسم المستخدم بل SID (معرّف الأمان). تحمل العملية رمز وصول، ويتضمّن SID مستخدم التنفيذ. عند التفكير في حكم ACL للملفّ، وكيان السجلّ، ومفتاح التشفير، هذا الفاعل هو نقطة الانطلاق.

لأوّل فحص استخدم whoami /user. لا نتيجة طرفك أنت، بل النتيجة في بيئة التنفيذ التي تحدث فيها المشكلة.

> whoami /user

معلومات المستخدم
----------------

اسم المستخدم      SID
=============== =============================================
desktop\you     S-1-5-21-3623811015-3361044348-30300820-1001

C:\Users\you كيان ملفّ تعريف المستخدم المرتبط بذلك SID. يتضمّن الملفّ مجموعات مجلّدات مثل AppData وخلية سجلّ المستخدم NTUSER.DAT. يُنسَخ من الملفّ الافتراضي عند أوّل تسجيل دخول، لذا يبدأ ملفّ تعريف مستخدم آخر من حالة أوّلية مختلفة عن البيئة التي رتّبت إعداداتها.¹

flowchart TB
    accTitle: التدفّق من مسار التشغيل إلى الملفّ
    accDescr: أيّاً كان المسار، نقر مزدوج أو Task Scheduler أو خدمة أو IIS، تحمل العملية SID رمز الوصول، وتصير مجموعة ملفّ التعريف المرتبطة بذلك SID بيئة التنفيذ
    e1["نقر مزدوج"] --> tok["رمز العملية (SID)"]
    e2["Task Scheduler"] --> tok
    e3["خدمة وIIS"] --> tok
    tok --> prof["مجموعة الملفّ المرتبطة بـ SID"]
    prof -.-> note["SID آخر يعني ملفّ تعريف آخر بحالة أوّلية"]

الشكل 2: مسار التشغيل يقرّر ملفّ تعريف أيّ SID تتحمّله العملية.

2.2 لحسابات الخدمة أيضاً بيئة كلّ منها

في Windows حسابات مضمَّنة تعمل دون تسجيل دخول بشري. لكلّ منها بيئة تنفيذ مستقلّة.²

فرق مسار التشغيل، النقر المزدوج وTask Scheduler والخدمة وIIS، يصل إلى فرق بيئة أيّ فاعل تستخدم. لا تفترض أن الإعدادات والمفاتيح وبيانات الاعتماد التي جهّزتها بتسجيل دخولك التفاعلي موجودة في وجهة التنفيذ تلك أيضاً.

2.3 ثلاثة شروط تؤكّدها بعد «المستخدم نفسه»

لا تنتهِ بتأكيد SID؛ رتّب «ما الذي يختلف حتّى على الحساب نفسه» بهذه الثلاثة. المهمّات في الفصل 8، وIIS في الفصلين 4–5، والترقية في الفصل 7.

3. الحدود 1: AppData ── متغيّر البيئة نفسه يشير إلى مكان آخر

العَرَض النموذجي أن ملفّ الإعداد يختفي ما إن تصير مهمّة. قد لا يكون فشل حلّ المسار، بل الحلّ إلى مسار صحيح لمستخدم آخر وعدم وجود الملفّ هناك.

3.1 تقسيم AppData والفرق حسب مستخدم التنفيذ

AppData مجلّد تحت ملفّ تعريف المستخدم. تنقسم الاستخدامات كما يلي.¹⁰

حتّى إن فتحت %APPDATA% بالشيفرة نفسها، تتغيّر الوجهة حسب مستخدم التنفيذ.

الملفّ الذي حفظه المستخدم A غير موجود في جهة SYSTEM. خطأ «ملفّ الإعداد غير موجود» وحده يصعب فهمه، لذا في التحقيق انظر إلى المسار الذي فُتح فعلاً لا اسم متغيّر البيئة.

flowchart TB
    accTitle: حلّ %APPDATA% يتغيّر حسب المستخدم
    accDescr: حتّى عندما تفتح الشيفرة نفسها %APPDATA%، إن كان مستخدم التنفيذ أنت حُلّ تحت C:\Users، وإن كان SYSTEM حُلّ تحت systemprofile حيث لا يوجد ملفّ إعدادك
    code["الشيفرة نفسها: افتح %APPDATA%"] --> q{"من مستخدم التنفيذ؟"}
    q -->|"أنت"| a["C:\Users\you\AppData\Roaming"]
    q -->|"SYSTEM"| b["AppData تحت systemprofile"]
    b -.-> miss["الملفّ الذي يُفترض وضعه غير موجود"]

الشكل 3: متغيّر البيئة لا يكذب، لكن وجهة الحلّ تتغيّر بالرمز.

3.2 لـ PATH أيضاً فرق لكلّ مستخدم

متغيّرات بيئة النظام مشتركة للجهاز، لكن متغيّرات بيئة المستخدم لكلّ مستخدم. إن لم يجد أمر أضفته إلى PATH الخاص بك من خدمة، أكّد هذا الفرق أيضاً.

يُقرَّر مكان الحفظ بـ «من يقرأ البيانات». إعداد ذلك المستخدم فقط إلى AppData، وبيانات يشترك فيها كلّ المستخدمين أو الخدمات تحت %ProgramData% مع تصميم ACL للأخيرة. لاختيار أدق انظر «أين ينبغي وضع البيانات المحلّية لتطبيق Windows».

flowchart TB
    accTitle: وجهة الحفظ يقرّرها القارئ
    accDescr: البيانات التي يقرأها ذلك المستخدم فقط تُوضَع في AppData أو HKCU، والبيانات المشتركة بين كلّ المستخدمين أو الخدمات في ProgramData أو HKLM، والأخيرة تترافق مع تصميم ACL
    q{"من يقرأ تلك البيانات"} -->|"ذلك المستخدم فقط"| f1["AppData وHKCU"]
    q -->|"كلّ المستخدمين والخدمات"| f2["ProgramData وHKLM"]
    f1 -.-> w1["أعد النظر إن حوّلت لاحقاً إلى خدمة"]
    f2 -.-> w2["صمّم صلاحية الكتابة وACL"]

الشكل 4: «لا يُقرأ بعد التحويل إلى خدمة» نتيجة تخطّي هذا الفرع عند التصميم.

4. الحدود 2: HKCU ── «المستخدم الحالي» يتغيّر حسب المستدعي

العَرَض النموذجي أن معلومات الترخيص التي كتبها المثبّت لا تُوجد من الخدمة. حتّى إن كان اسم جهة الكتابة والقراءة كليهما HKCU فليسا بالضرورة الكيان نفسه.

4.1 HKCU اسم بديل لخلية المستخدم

HKEY_CURRENT_USER (HKCU) ليس خلية مستقلّة بل اسماً بديلاً يُحوَّل إلى الكيان حسب مستخدم المستدعي. في عملية مستخدم عادية يشير إلى مفتاح ذلك SID تحت HKEY_USERS. محتواه هو NTUSER.DAT المحمَّل عند تسجيل الدخول.¹

الاستثناء HKCU\Software\Classes، وكيانه ملفّ خلية آخر UsrClass.dat. يُوضَع هذا الملفّ تحت %LOCALAPPDATA%\Microsoft\Windows.¹¹

يرتبط HKCU لـ LocalSystem بالمستخدم الافتراضي (HKEY_USERS\.DEFAULT). إن كتب مثبّت شُغِّل بحساب مسؤول إلى HKCU وقرأته خدمة SYSTEM اختلفت الوجهة.³

flowchart TB
    accTitle: كيان الاسم البديل HKCU
    accDescr: عندما يفتح التطبيق HKCU يُحوَّل في عمليتك إلى مفتاح SID الخاص بك تحت HKEY_USERS، وفي عملية LocalSystem إلى مفتاح المستخدم الافتراضي، فتختفي القيمة التي كتبها المثبّت
    app["شيفرة التطبيق: افتح HKCU"] --> alias["HKCU اسم بديل للكيان"]
    alias -->|"عمليتك"| ha["SID الخاص بك تحت HKEY_USERS"]
    alias -->|"عملية SYSTEM"| hd["HKEY_USERS\\.DEFAULT"]
    hd -.-> gone["القيمة التي يُفترض كتابتها غير موجودة"]

الشكل 5: حتّى مع الاسم نفسه HKCU، إن تغيّر المستخدم تغيّر الكيان الذي تقرأ منه وتكتب إليه.

ضع إعدادات الجهاز كلّه في HKLM. لا توصي Microsoft بالوصول إلى HKCU من خدمة. إن احتجت قراءة إعدادات مستخدم فتمثّل ذلك المستخدم ثم استخدم RegOpenCurrentUser.¹²

4.2 أكّد أيضاً ما إذا حُمِّل الملفّ

إضافة إلى حساب التنفيذ، قد يصير ما إذا حُمِّل الملفّ مشكلة أيضاً.

يعمل مجمّع تطبيقات IIS افتراضياً دون تحميل ملفّ تعريف المستخدم. بتمكين loadUserProfile يصير ممكناً استخدام AppData والخلية تحت الملفّ.⁷ يرتبط هذا الإعداد أيضاً بوجهة حفظ مفاتيح DPAPI وASP.NET Core Data Protection في الفصل التالي.

إعداد المهمّة «عدم حفظ كلمة المرور» يُؤكَّد على حدة كـ قيد نوع تسجيل الدخول. حتّى مع تحديد المستخدم نفسه لا تصل S4U إلى الشبكة أو EFS. فرق التكوين المفصَّل ملخَّص في الفصل 8.⁶

5. الحدود 3: DPAPI ── التشفير معلَّق بـ «مفتاح المستخدم»

مقابل مشكلة AppData وHKCU «مكان البحث مختلف»، يحدث في DPAPI أن الملفّ يُقرأ لكن لا يمكن فكّ تشفير المحتوى. مثال التحويل إلى خدمة لتطبيق يستخدم كلمات مرور محفوظة فيصير CryptographicException هذا.

5.1 إن اختلف صاحب المفتاح الرئيسي تعذّر فكّ التشفير

DPAPI (Data Protection API) وظيفة تشفير يقدّمها Windows للتطبيقات. باستدعاء CryptProtectData أو ProtectedData.Protect في .NET يمكن حماية البيانات دون أن يحمل التطبيق مفتاح التشفير في الشيفرة.¹³

لكن ذلك لا يلغي الحاجة إلى مفتاح. يُستخدم مفتاح رئيسي يديره نظام التشغيل. في نطاق CurrentUser يُحمى مفتاح رئيسي لكلّ مستخدم مولَّد عشوائياً بمفتاح مشتق من بيانات اعتماد تسجيل الدخول، ويُحفَظ تحت الملفّ.¹⁴

flowchart TB
    accTitle: سلسلة مفاتيح DPAPI
    accDescr: يُحمى المفتاح الرئيسي للمستخدم المولَّد عشوائياً بمفتاح مشتق من بيانات اعتماد تسجيل الدخول، ويشفّر ذلك المفتاح الرئيسي سرّ التطبيق، ولا يمكن فكّ تشفير النصّ المشفَّر نفسه بمفتاح رئيسي لمستخدم آخر
    pwd["بيانات اعتماد تسجيل الدخول"] -->|"حماية بمفتاح مشتق"| mk["مفتاحك الرئيسي"]
    mk -->|"تشفير"| sec["سرّ التطبيق (كلمات مرور محفوظة وغيرها)"]
    mk2["مفتاح رئيسي لمستخدم آخر"] -.->|"لا يمكن فكّ التشفير"| sec
    mk -.-> loc["وجهة الحفظ تحت الملفّ"]

الشكل 6: لا تشفّر البيانات مباشرة من بيانات الاعتماد؛ تُحمى المفتاح الرئيسي بمفتاح مشتق من بيانات الاعتماد.

التالي مثال أدنى: بيانات شفّرها المستخدم A وُضعت في مكان مشترك، ثم حُاول فكّ التشفير بمستخدم آخر. حتّى مع مشاركة مكان الحفظ لا يتغيّر فاكّ تشفير CurrentUser.

# في جلسة المستخدم A: شفّر بنطاق 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)
$enc = [Convert]::FromBase64String((Get-Content C:\ProgramData\demo.bin))
[Security.Cryptography.ProtectedData]::Unprotect($enc, $null, "CurrentUser")
# ← CryptographicException: البيانات غير صالحة في الحالة الحالية

5.2 اختر النطاق ممّن ينبغي أن يفكّ التشفير

سرّ يقرؤه الخدمة والمستخدم التفاعلي كلاهما يُصمَّم من البداية بـ LocalMachine مع ACL ملفّ، أو يُشغَّل بحساب من شفّره. لا تغيّر النطاق لمجرد محو خطأ فكّ التشفير؛ قرّر لمن تسمح بفكّ التشفير. على جهاز مشترك انتبه أيضاً إلى خطر أن تكون الحماية على مستوى الجهاز أوسع ممّا ينبغي.¹⁵

flowchart TB
    accTitle: اختيار نطاق DPAPI
    accDescr: إن كان الفاعل الذي ينبغي أن يفكّ التشفير ذلك المستخدم فقط فاختر نطاق CurrentUser، وإن كان فاعلين عدّة على الجهاز نفسه فاختر نطاق LocalMachine وضيّق القرّاء بـ ACL الملفّ
    q{"من ينبغي أن يفكّ التشفير"} -->|"ذلك المستخدم فقط"| cu["نطاق CurrentUser"]
    q -->|"فاعلون عدّة على الجهاز نفسه"| lm["نطاق LocalMachine"]
    cu -.-> r1["فشل فكّ التشفير عند تشغيل مستخدم آخر"]
    lm -.-> r2["ضيّق القرّاء بـ ACL الملفّ"]

الشكل 7: النطاق يُختار كتصميم لفاكّ التشفير، لا كـ «ما عمل مصادفة».

5.3 «تغيير» كلمة المرور و«إعادة تعيينها» مختلفان

المفتاح الذي يحمي المفتاح الرئيسي يعتمد على بيانات اعتماد تسجيل الدخول. عندما يغيّر المستخدم كلمة مروره بنفسه يُحمى المفتاح الرئيسي من جديد بمفتاح مشتق من كلمة المرور الجديدة، فيُورَّث قدرة فكّ التشفير.

أمّا عندما يعيد المسؤول تعيين كلمة مرور حساب محلّي فقد يتعذّر فكّ تشفير نصوص مشفَّرة سابقة. حتّى مع الحساب نفسه يلزم تأكيد طريقة تغيير بيانات الاعتماد.¹⁴

5.4 في ASP.NET Core أيضاً أكّد وجهة حفظ المفتاح

قد تعتمد على هذه الحدود حتّى دون استدعاء DPAPI مباشرة. يحفظ ASP.NET Core Data Protection حلقة المفاتيح المستخدمة لحماية مصادقة ملفات تعريف الارتباط وغيرها في مكان حسب البيئة.¹⁶

أكّد loadUserProfile وsetProfileEnvironment وشكل الاستضافة معاً، وافهم في أيّ تكوين تُوضَع المفاتيح. المهم ليس «يمكن البدء» فقط بل إمكان استخدام المفتاح نفسه بعد إعادة التشغيل أيضاً.

اختيار النطاق والتمييز عن Credential Manager مشمولان بتفصيل في «حفظ المعلومات السرّية لتطبيقات Windows - تجنّب الإعدادات بنصّ واضح بـ DPAPI».

6. الحدود 4: ملفّ تعريف المتصفّح ── «مسجَّل الدخول» ملك المستخدم

على المكتب أنت مسجَّل الدخول، لكن تشغيل المتصفّح في CI يعيد شاشة تسجيل الدخول. تُرتَّب هذه المشكلة بفصل مكان حفظ الملفّ ومفتاح التشفير.

6.1 حدودان: مكان الحفظ والمفتاح

ملفّ تعريف متصفّحات قائمة على Chromium مثل Chrome وEdge يكون افتراضياً في مجلّد User Data تحت %LOCALAPPDATA%. التاريخ وملفات تعريف الارتباط والإضافات وكلمات المرور المحفوظة تنتمي إلى بيئة مستخدم Windows ذلك.¹⁷

تُشفَّر ملفات تعريف الارتباط وكلمات المرور المحفوظة بمفتاح تشفير داخل الملفّ، والمفتاح نفسه محمي بـ DPAPI. لذا حتّى مع نسخ المجلّد إلى مستخدم آخر أو جهاز آخر لا يطابق المفتاح ويتعذّر فكّ التشفير.

يضيف Chrome الحديث أيضاً App-Bound Encryption (تشفيراً مربوطاً بالتطبيق). يجعل فكّ تشفير المفتاح عبر خدمة بامتياز SYSTEM، ويتحقّق ليس من المستخدم فقط بل من معرّف التطبيق الذي طلب أيضاً.¹⁸ هذا حديث سلالة Chromium؛ لمتصفّحات مثل Firefox بحماتها الخاصّة لملفّ التعريف الظروف مختلفة.

flowchart TB
    accTitle: حدودان يسندان حالة تسجيل دخول المتصفّح
    accDescr: ملفّ تعريف المتصفّح تحت LOCALAPPDATA وينتمي إلى الحدود 1، ومفتاح تشفير ملفات تعريف الارتباط محمي بـ DPAPI وينتمي إلى الحدود 3، لذا لا يُورَّث الملفّ ولا المفتاح إلى مستخدم آخر
    prof["ملفّ تعريف المتصفّح"] --> loc["المكان تحت LOCALAPPDATA"]
    prof --> key["مفتاح تشفير ملفات تعريف الارتباط محمي بـ DPAPI"]
    loc -.-> ci["ملفّ تعريف آخر فارغ لمستخدم تنفيذ CI"]
    key -.-> copy["لا يُحمَل بنسخ المجلّد"]

الشكل 8: «أخذ حالة تسجيل الدخول معك» يُمنَع بالحدود 1 والحدود 3 كليهما.

6.2 في الأتمتة صرّح بطريقة صنع حالة تسجيل الدخول

ينشئ Selenium وPlaywright افتراضياً ملفّ تعريف مؤقّتاً يُستخدم مرّة ويُشغَّلان به. لذا حتّى مع المستخدم نفسه لا تُستخدم حالة تسجيل دخول المتصفّح المعتاد تلقائياً.

حتّى مع تحديد دليل ملفّ تعريف دائم، عند النقل إلى CI أو خدمة لمستخدم آخر تبقى مشكلة مكان الحفظ والمفتاح في القسم السابق. التدبير ليس نسخ ملفّ تعريف مسجَّل الدخول، بل أحد التالي.

• كتابة خطوات تسجيل الدخول لحساب اختبار في الشيفرة.
• التصريح بحفظ ملفات تعريف الارتباط واستعادتها بآلية حالة التخزين لأداة الأتمتة.

أن مستخدماً آخر لا يستطيع استخدام ملفات تعريف الارتباط بالنسخ وحده ليس إزعاجاً فحسب بل حدود أمنية أيضاً. تصميم الأتمتة يفترض وجود تلك الحدود.

7. الحدود 5: بيانات الاعتماد والشهادات ── الخزينة لكلّ مستخدم على حدة

بيانات اعتماد حُفظت بـ cmdkey لا تُستخدم عند تشغيل المهمّة فيصير خطأ مصادقة. هنا أيضاً أكّد لا «حُفظ على الجهاز» بل «بأيّ مستخدم حُفظ».

7.1 Credential Manager خزينة لكلّ مستخدم تنفيذ

Credential Manager الذي يؤكَّد بـ cmdkey /list خزينة لكلّ مستخدم.¹⁹ بيانات الاعتماد المحفوظة على القرص، لكنّها محمية بـ DPAPI ويستخدمها برنامج يعمل بذلك المستخدم.²⁰

تدخل الخزينة بيانات اعتماد محفوظة لخادم ملفّات أو محرّك شبكة، ورموز Git التي حفظها git-credential-manager، وكلمات مرور اتصال RDP المحفوظة، وأسرار تطبيقات تستخدم Credential API.

حتّى إن وُجدت في خزينتك بعد تسجيل دخول تفاعلي، فليست في خزينة حساب تنفيذ الخدمة أو المهمّة. جهّز إعداداً يُدخل بيانات الاعتماد اللازمة في سياق حساب التنفيذ نفسه. إن نجح git pull على مكتبك فقط فأكّد أيضاً فرق الخزينة المستخدمة.

لكن مهمّة تكوين S4U لا تُحَلّ بإدخال بيانات الاعتماد وحدها. أكّد نوع تسجيل الدخول أوّلاً، وانظر في تكوين يحفظ كلمة المرور أو التحويل إلى حساب خدمة. ترتيب الإجراءات مرتَّب في الفصل 8.

flowchart TB
    accTitle: خزينة بيانات الاعتماد لكلّ مستخدم
    accDescr: خزينتك تحتوي بيانات اعتماد git وبيانات اعتماد خادم الملفّات المحفوظة وكلمة مرور RDP، بينما خزينة مستخدم تنفيذ الخدمة فارغة ما لم تُدخَل بيانات اعتماد، وتلك حقيقة خطأ المصادقة
    you["خزينتك"] --> g["بيانات اعتماد git"]
    you --> n["بيانات اعتماد خادم الملفّات المحفوظة"]
    you --> r["كلمة مرور RDP المحفوظة"]
    svc["خزينة مستخدم تنفيذ الخدمة"] -.-> empty["فارغة إن لم تُدخَل = حقيقة خطأ المصادقة"]

الشكل 9: «المصادقة تمرّ على المكتب» اختصار لـ «خزينتك متاحة» فحسب.

7.2 للشهادات افصل المخزن وصلاحيات المفتاح الخاص

الشهادات المستخدمة في خدمة تُصمَّم أساساً بمخزن LocalMachine وACL المفتاح الخاص معاً.²¹ كيان مخزن المستخدم تحت HKCU\Software\Microsoft\SystemCertificates، لذا داخل حدود HKCU.²²

للتفاصيل انظر «دليل عملي لمخزن شهادات Windows ── المستخدم أم الحاسوب، أين تضع».

7.3 في ترقية UAC افصل «الحساب نفسه» عن «حساب آخر»

عند تسجيل دخول مستخدم مسؤول مع تفعيل UAC يُنشأ رمزان مرتبطان: رمز قياسي مقيَّد الصلاحيات، ورمز مسؤول كامل.⁸

تعيين محرّك الشبكة لكلّ جلسة تسجيل دخول. قد يظهر Z: في مستكشف الملفّات ولا يظهر من أداة شُغِّلت كمسؤول.⁹

لا تحكم على «لا يعمل بعد الترقية» كلّه كتغيير مستخدم؛ أكّد أوّلاً ما إذا كان الحساب نفسه.

flowchart TB
    accTitle: انقسام داخل المستخدم نفسه تولّده ترقية UAC
    accDescr: تسجيل دخول مسؤول مع تفعيل UAC يصنع رمزين، قياسياً ومُرقّى، ومحرّك الشبكة المعيَّن في جهة الرمز القياسي لا يظهر من عملية الرمز المُرقّى
    logon["تسجيل دخول مستخدم مسؤول"] --> t1["رمز قياسي"]
    logon --> t2["رمز مُرقّى"]
    t1 --> d1["محرّك Z: المعيَّن هنا"]
    t2 -.->|"جلسة تسجيل دخول أخرى"| d2["Z: لا يظهر من الأداة المُرقّاة"]

الشكل 10: الترقية تصنع «عالم آخر للمستخدم نفسه». الحدود ليست حديث SID وحده.

8. قائمة تحقّق حسب شكل التشغيل

8.1 في المهمّات انظر إلى نوع تسجيل الدخول بعد حساب التنفيذ

حتّى مع تحديد المستخدم نفسه في Task Scheduler يتغيّر ما يمكن استخدامه بنوع تسجيل الدخول.⁶

لمهمّة لا تُستخدم فيها بيانات الاعتماد المحفوظة أكّد أوّلاً قيد S4U. لا تجعل إدخال بيانات اعتماد في الخزينة مع بقاء S4U تدبيراً. انظر في تكوين يحفظ كلمة المرور أو التحويل إلى حساب خدمة، وعندئذ إن لزم أدخل في خزينة حساب التنفيذ.

تفاصيل الإعداد مشمولة في «تشغيل دفعات أعمال بثبات بـ Task Scheduler».

flowchart TB
    accTitle: المحور الثاني: نوع تسجيل دخول المهمّة
    accDescr: تكوين تشغيل Task Scheduler يملك أنواع تسجيل دخول رمز تفاعلي وحفظ كلمة المرور وS4U، وفي S4U لا تُحفَظ كلمة المرور ولا يُوصَل إلى الشبكة وEFS
    task["تكوين تشغيل المهمّة"] --> lt{"نوع تسجيل الدخول"}
    lt -->|"رمز تفاعلي"| it["يعمل في الجلسة أثناء تسجيل الدخول"]
    lt -->|"حفظ كلمة المرور"| pw["يمكن استخدام بيانات الاعتماد بلا تفاعل"]
    lt -->|"S4U (بلا حفظ كلمة المرور)"| s4u["لا يصل إلى الشبكة وEFS"]

الشكل 11: حتّى مع مستخدم التنفيذ نفسه يتغيّر ما يمكن استخدامه بطريقة تسجيل الدخول.

8.2 جدول فحص قبل تغيير وجهة التشغيل

الصفّ الأخير انتباه بالاتجاه المعاكس. حتّى مع جلسات RDP عدّة للمستخدم نفسه لا يستقلّ AppData وHKCU لكلّ جلسة. هنا ليست مشكلة «لا يُرى» بل «مشاركة الشيء نفسه والكتابة فيه».

9. إرشاد التصميم وتحقيق الأعطال

9.1 قرّر وجهة الحفظ والإعداد من الفاعل الذي يستخدم

إن وُجدت نيّة التحويل إلى خدمة لاحقاً فأدرج فاعل التنفيذ ذلك أيضاً بين القرّاء عند تقرير وجهة الحفظ. المبدأ ألّا تُدخل إلى التشغيل اعتماداً على «ما وُجد مصادفة في بيئة المطوّر».

9.2 التحقيق يتقدّم من فاعل التنفيذ إلى المرجع الفعلي

flowchart TB
    accTitle: إجراء تحقيق أعطال حدود المستخدم
    accDescr: أكّد مستخدم التنفيذ بـ whoami، وانظر إلى الرمز في Process Explorer، وحدّد المسار ومفتاح السجلّ اللذين قُرئا فعلاً بـ Process Monitor، وإن لزم فأعد الإنتاج من عالم الطرف الآخر بـ psexec
    s1["أكّد مستخدم التنفيذ بـ whoami /all"] --> s2["أكّد الرمز في Process Explorer"]
    s2 --> s3["حدّد المسار والمفتاح الفعليين بـ ProcMon"]
    s3 --> s4["أعد الإنتاج من عالم الطرف الآخر بـ psexec"]
    s3 -.-> hint["مسار ملفّ تعريف يختلف عن المتوقّع دليل"]

الشكل 12: أكّد مستخدم التنفيذ، وانظر إلى المسار ومفتاح السجلّ الفعليين، ثم أعد الإنتاج بفاعل التنفيذ المستهدف.

عند غياب الإعداد عُد إلى AppData وHKCU، وعندما يُقرأ الملفّ ويتعذّر فكّ التشفير إلى DPAPI، وعندما تفشل المصادقة وحدها إلى الخزينة والشهادات ونوع تسجيل الدخول. لا تحكم برسالة الخطأ وحدها؛ أقصر طريق مواءمة «من استخدم أين، بأيّ مفتاح أو بيانات اعتماد».

10. خلاصة

«يعمل على المكتب» يعني «يعمل بذلك المستخدم، وذلك الملفّ، وذلك المفتاح وتلك الخزينة». حتّى مع تشغيل الـ .exe نفسه على الجهاز نفسه يلزم معاملة التحويل إلى مهمّة أو خدمة أو CI كترحيل لبيئة التنفيذ.

يشير AppData ومتغيّرات بيئة المستخدم إلى ملفّ تعريف مستخدم التنفيذ، ويتّجه HKCU أيضاً إلى خلية ذلك المستخدم. يعتمد نطاق CurrentUser في DPAPI على المفتاح الرئيسي للمستخدم، وتتلقّى حالة تسجيل دخول المتصفّح وCredential Manager أيضاً أثر تلك الحدود.

علاوة على ذلك، حتّى مع SID نفسه تبقى فروق نوع تسجيل الدخول وتحميل الملفّ والجلسة بترقية UAC. وبالعكس، عندما تشارك جلسات عدّة للمستخدم نفسه AppData وHKCU فكّر في تعارض الكتابة.

في مراجعة التصميم أكّد السؤال التالي.

هل هذه شيفرة صحيحة أيّاً كان المستخدم الذي تعمل باسمه؟

جهّز وجهات الحفظ والمفاتيح وبيانات الاعتماد اللازمة صراحة لفاعل التنفيذ الفعلي. إن أكّدت هذا المبدأ قبل الترحيل قلّلت في مرحلة التصميم حوادث «لم أغيّر الشيفرة ومع ذلك انكسر».

مقالات ذات صلة

• حفظ المعلومات السرّية لتطبيقات Windows - تجنّب الإعدادات بنصّ واضح بـ DPAPI
• اختيار وجهة حفظ بيانات تطبيق Windows ── جدول قرار SQLite / JSON / السجلّ / Access
• مهام Task Scheduler لا تعمل أو تنتهي بـ 0x1 ── عزل السبب وتصميم تشغيل آمن
• اختيار حساب خدمة Windows ── التمييز بين LocalSystem والحساب الافتراضي وgMSA
• دليل عملي لمخزن شهادات Windows ── المستخدم أم الحاسوب، أين تضع

مجالات الاستشارة ذات الصلة

تتعامل شركة كومورا سوفت ذ.م.م. مع تصميم بيئة التنفيذ المصاحب لتحويل تطبيقات الأعمال إلى خدمة أو مهمّة، وتحقيق أعطال من نوع «يعمل على المكتب لكن»، وتصميم إدارة المعلومات السرّية لتطبيقات Windows.

• تطوير تطبيقات Windows
• تحقيق الأعطال وتحليل الأسباب
• الاستفادة من الأصول القائمة ودعم الترحيل
• التواصل معنا

روابط مرجعيّة

مقالات ذات صلة

أحدث المقالات التي تشترك في نفس الوسوم. عمّق فهمك بمواضيع مرتبطة.

أين يتصل هذا الموضوع

ترتبط هذه المقالة بشكل طبيعي بصفحات الخدمات التالية.

الأسئلة الشائعة

أسئلة شائعة حول موضوع هذه المقالة.

تطبيق يعمل عند التشغيل من مستكشف الملفّات لا يجد ملفّ إعداده عند التشغيل من Task Scheduler. لماذا؟

لأن متغيّرات بيئة مثل %APPDATA% تُحَلّ إلى ملفّ تعريف المستخدم الذي يشغّل البرنامج. عندما تعمل المهمّة كـ SYSTEM أو كحساب آخر، تشير متغيّرات البيئة إلى ملفّ تعريف مختلف (تحت systemprofile في حالة SYSTEM)، وملفّ الإعداد الذي حفظته غير موجود هناك. أكّد الحساب الذي تعمل به المهمّة، وضع البيانات التي ينبغي مشاركتها تحت ProgramData كإصلاح دائم.

كلمة مرور حُفظت بـ ProtectedData.Protect لم يعد ممكناً فكّ تشفيرها ما إن صار التطبيق خدمة.

يعتمد DPAPI في نطاق CurrentUser على المفتاح الرئيسي للمستخدم الذي شفّر البيانات. إن عملت الخدمة بحساب مختلف فالمفتاح الرئيسي مختلف، فيفشل فكّ التشفير بـ CryptographicException. أعد تصميم سرّ يقرؤه الخدمة والمستخدم التفاعلي كلاهما ليستخدم نطاق LocalMachine مع ACL ملفّ، أو شغّل الخدمة بحساب من شفّره.

ماذا يحدث عندما تقرأ عملية تعمل كـ SYSTEM مفتاح HKCU؟

في عملية LocalSystem يرتبط HKEY_CURRENT_USER بالمستخدم الافتراضي (HKEY_USERS\.DEFAULT)، لذا لا تظهر القيم التي كتبها المستخدم التفاعلي في HKCU. ضع إعدادات الجهاز كلّه في HKLM، وإن وجب حتماً قراءة إعدادات مستخدم فتمثّل ذلك المستخدم ثم استخدم RegOpenCurrentUser.

هل يمكنني نسخ ملفّ تعريف Chrome/Edge مسجَّل الدخول إلى جهاز CI واستخدامه؟

عموماً لا. يعيش ملفّ تعريف متصفّح قائم على Chromium مثل Chrome أو Edge تحت %LOCALAPPDATA% للمستخدم، ومفتاح تشفير ملفات تعريف الارتباط وكلمات المرور المحفوظة محمي بـ DPAPI لذلك المستخدم. نسخ المجلّد إلى مستخدم آخر أو جهاز آخر يفشل في فكّ التشفير لأن المفتاح لا يطابق (المتصفّحات مثل Firefox التي تملك حماية ملفّ تعريف خاصّة قصّة مختلفة). للأتمتة، اكتب خطوات تسجيل الدخول لحساب اختبار، أو استخدم آلية حالة التخزين لأداة الأتمتة.

بيانات اعتماد حُفظت بـ cmdkey لا تُستخدم عندما تعمل المهمّة من Task Scheduler.

لأن خزينة Credential Manager منفصلة لكلّ مستخدم، وما حفظته ذهب إلى خزينة تسجيل دخولك التفاعلي. إضافة إلى ذلك تعمل مهمّة مضبوطة على «عدم حفظ كلمة المرور» (S4U) بلا بيانات اعتماد شبكة، لذا إدخال بيانات اعتماد في الخزينة لا يفيد ما دامت على S4U. انظر أوّلاً في تكوين يحفظ كلمة المرور أو التحويل إلى حساب خدمة، وعندئذ فقط إن لزم أدخل بيانات الاعتماد في خزينة حساب التنفيذ نفسه.

الملف الشخصي للمؤلف

صفحة الملف الشخصي لمؤلف المقالة.

غو كومورا

مؤسّس شركة كومورا سوفت ذ.م.م.

يركّز على تطوير برامج ويندوز، والاستشارات التقنية، والتحقيق في الأخطاء، ويتميّز في المشاريع التي تبقى فيها الأصول القديمة ناشطة، وفي تشخيص الأعطال التي يصعب تحديد سببها.