اختيار حساب خدمة ويندوز — LocalSystem والحسابات الافتراضية وgMSA

«خدمة داخليّة كنّا نشغّلها بحساب LocalSystem “إلى حين” وُسِمت في تدقيق أمني بـ “امتياز مفرط”. إلى ماذا نغيّرها؟» «الخدمة لم تستطع الوصول إلى مجلد مشترك، فنشغّلها بمستخدم نطاق. عندما تنتهي صلاحية كلمة المرور تتوقّف الخدمة، فجعلناها بلا انتهاء وكتبناها بنصّ صريح في دليل التشغيل.» — بين الاستشارات حول خدمات ويندوز لدى العملاء، هاتان ثابتتان.

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

flowchart TB
    accTitle: ثلاثة أمور يقرّرها حساب تسجيل الدخول
    accDescr: الخدمة تعمل دائماً في سياق أمن حساب ما، وذلك الحساب يقرّر كلّ ما يمكنها فعله محلّياً ومن تبدو من الجهة الأخرى للشبكة ومن يدير كلمة المرور
    acct["حساب تسجيل دخول الخدمة"] --> local["ما يمكنها فعله محلّياً"]
    acct --> net["من تبدو من الجهة الأخرى للشبكة"]
    acct --> pwd["من يدير كلمة المرور"]

الشكل 1: اختيار حساب تسجيل الدخول قرار تصميم يثبّت معاً الامتيازات المحلّية وهويّة الشبكة وإدارة كلمة المرور.

هناك ستّة اختيارات فعليّة — LocalSystem وLocalService وNetworkService وحساب افتراضي (NT SERVICE\<اسم-الخدمة>) ومستخدم نطاق وgMSA (حساب خدمة مُدار جماعي). موجّهة إلى موظّفي تقانة المعلومات في المنشآت الصغيرة والمتوسّطة ومطوّري تطبيقات ويندوز، تنظّم هذه المقالة امتيازات هذه الستّ وهويّتها الشبكيّة وإدارة كلمات المرور في جدول واحد وتلخّص تدفّق قرار، استناداً إلى مصادر Microsoft Learn الأوّليّة حتّى أغسطس 2026.

كيف تُبنى الخدمة نفسها (الاختيار بين جدولة المهامّ وخدمة، والتنفيذ بـ .NET Worker Service) يعالجه «كيفيّة إنشاء خدمات Windows وتشغيلها». تتركّز هذه المقالة على «حساب تسجيل الدخول» حيث تقع أكثر الحوادث.

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

• عند الشكّ، الحساب الافتراضي أوّل مرشّح لخدمة تكتمل داخل جهاز واحد، وgMSA أوّل مرشّح لخدمة تصل إلى مورد داخل النطاق بهويّة خاصّة بالخدمة. تعطي مايكروسوفت أيضاً التوجيه باستخدام حساب مُدار (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. لأنّك تستطيع البقاء حراً من أخطاء الامتياز أثناء التطوير، فبنية تنتج بالجملة «عمل، فاتركه» موجودة. وثائق مايكروسوفت نفسها تنصّ أيضاً على أنّ معظم الخدمات لا تحتاج مستوى امتياز بهذا الارتفاع، وأنّك إن لم تحتجه ينبغي أن تنظر في استخدام 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 «أقوى حساب في ويندوز» ليست دقيقة. حماية موارد ويندوز (WRP) منذ Windows Vista تسمح بتغييرات ملفات النظام والمجلدات ومفاتيح السجلّ المهمّة لـ TrustedInstaller فقط (خدمة مثبّت وحدات ويندوز)، وحتّى 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. حتّى حينها يستحقّ التأكيد أنّ هناك مسار شفرة يستخدم ذلك الامتياز فعلاً، والنظر في ما إذا كان يمكن فصل العمل الذي يحتاج الامتياز (لكيف تميّز، انظر «متى يصبح Windows admin privilege ضرورياً»).

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: بدءاً من حادثة انتهاء، يتثبّت عدم الانتهاء وانتشار كلمة مرور صريحة.

تشير مايكروسوفت أيضاً إلى أنّ تكويناً يستخدم حساب نطاق لخدمة يكلّف جهداً تشغيليّاً معتبراً في الإدارة اليدويّة لكلمة المرور و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: أيّ مستخدم مصادق عليه يمكنه طلب تذكرة، وكلمة مرور بطول قرّره إنسان لن تصمد أمام كسر بالقوّة الغاشمة دون اتّصال.

الردّ الفعّال جعل كلمة المرور بقوّة لا يستطيع إنسان تخمينها أو كسرها. تسرد مايكروسوفت أيضاً فرض كلمة مرور طويلة، واستخدام 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. ما يضبط هويّة تسجيل الدخول عبر آليّة قياسيّة — خدمة ويندوز ومجموعة تطبيقات IIS ومهمّة جدولة المهامّ — مدعوم على نطاق واسع، لكن هناك قيوداً مثل أنّ تجميع تجاوز الفشل نفسه لا يدعم gMSA، وتطبيقاً تطالب داخليّاته بكلمة مرور لا يمكنه استخدامه.¹⁰ تنصّ مايكروسوفت أيضاً بوضوح على أن تؤكّد السلوك كـ 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 (واجهات البرمجة التي يستدعيها sc.exe config) من أنّ الحساب المحدَّد لديه هذا الحقّ. السبب النموذجي لتوقّف خدمة مضبوطة بسكربت عند البدء بـ «لم تبدأ الخدمة بسبب فشل تسجيل الدخول» هو هذا. لا تعتمد على أثر جانبي لأداة؛ ضمّن في إجراء النشر، صراحة، الإضافة إلى «تسجيل الدخول كخدمة» في نهج الأمن المحلّي (secpol.msc)، أو الضبط عبر GPO/Intune (في بيئة تضبط هذا الحقّ بنهج المجموعة يُكتَب فوق منح محلّي عند تطبيق النهج، فيحتاج ذلك انتباهاً أيضاً). بالمقابل، الحركة القياسيّة لحساب مخصّص للخدمة ضبط «رفض تسجيل الدخول محلّياً» معه.

flowchart TB
    accTitle: الفرق حسب مسار ضبط حقّ تسجيل الدخول كخدمة
    accDescr: تمنح واجهة services.msc الحقّ تلقائياً، لكنّ واجهة البرمجة التي يستدعيها 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 مربوطة بالحساب الذي حماها، وبعد تبديل الحساب تحتاج إلى إعادة الإدخال.

الردّ تضمين في خطّة الترحيل إجراء «أعد إدخال الأسرار بعد تبديل الحساب» (لتصميم أين تخزّنها انظر «أفضل الممارسات في DPAPI لإبعاد الأسرار عن إعدادات النصّ الصريح في تطبيقات Windows»). أيضاً تكوين يمكن أن ينتهي بمصادقة ويندوز المتكاملة كـ gMSA أو PC$ يمكنه إلغاء تخزين السرّ نفسه. الترتيب الصحيح النظر في «هل يمكننا الاستغناء عن التخزين» قبل «أين نخزّنه».

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

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{"مصادقة ويندوز لندّ؟"} -->|لا| va["حساب افتراضي"]
    va -.-> sys["LocalSystem إن لزم"]
    q1 -->|نعم| q2{"منضمّ إلى النطاق؟"}
    q2 -->|لا| cred["احمِ بيانات الاعتماد المخزّنة"]
    q2 -->|نعم| q3{"مستوى الآلة يكفي؟"}
    q3 -->|نعم| pcacl["حساب افتراضي + PC$"]
    q3 -->|لا| q4{"هل يدعم التطبيق gMSA؟"}
    q4 -->|نعم| gmsa["gMSA"]
    q4 -->|لا| du["مستخدم + تخفيفات"]

الشكل 22: أجب عن الأسئلة الأربعة بالترتيب فيُقرَّر أيّ من الستّة ينبغي أن تستخدم.

السؤال 1: هل تصل تلك الخدمة إلى جهاز آخر على الشبكة (مجلد مشترك أو قاعدة بيانات أو واجهة برمجة وما شابه) بمصادقة ويندوز؟

إن لا، حساب افتراضي هو الافتراضي. فقط إن احتيج امتياز محلّي خاصّ، أكّد تلك الحاجة ثمّ انظر في 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.

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

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

• كيفيّة إنشاء خدمات Windows وتشغيلها ── من التمييز عن جدولة المهام إلى تحويل BackgroundService إلى خدمة
• متى يصبح Windows admin privilege ضرورياً - UAC والمناطق المحميّة وكيفيّة التمييز على مستوى التصميم
• التعامل الصحيح مع رموز انتحال الهويّة في Windows ── استعارة الصلاحيّات على مستوى مؤشّر الترابط والعودة الآمنة
• 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
• أفضل الممارسات في DPAPI لإبعاد الأسرار عن إعدادات النصّ الصريح في تطبيقات Windows

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

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

• تطوير تطبيقات ويندوز
• التحقيق في الأخطاء وتحليل السبب الجذري
• الاستشارات التقنيّة ومراجعة التصميم
• التواصل معنا

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

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

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

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

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

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

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

هل ينبغي أن أغيّر فوراً خدمة كنت أشغّلها مؤقّتاً بحساب LocalSystem؟

التغيير الفوري ليس دائماً الإجابة الصحيحة لكلّ حالة. أكّد أوّلاً ما إذا كانت تلك الخدمة تحتاج فعلاً امتيازات محلّية من فئة LocalSystem (امتيازات قويّة تتجاوز المسؤول). إن كانت قراءة الملفات وكتابتها والتواصل الشبكي فحسب، فأوّل مرشّح هو الانتقال إلى حساب افتراضي (NT SERVICE\اسم-الخدمة). عند الترحيل أكّد منح الوصول إلى المجلدات ومفاتيح السجلّ التي تحتاجها، وكيف تُعالَج البيانات التي تعتمد على الملفّ الشخصي أو DPAPI، وما إذا كان حقّ «تسجيل الدخول كخدمة» موجوداً. أكّد البدء والوظائف الرئيسة في بيئة تحقّق، ثمّ بدّل الإنتاج.

هل أختار الحساب الافتراضي أم NetworkService؟

للاختيار الجديد نوصي بحساب افتراضي. على الشبكة يظهر كلاهما كحساب الحاسوب (DOMAIN\اسم-الحاسوب$)، ولكليهما امتيازات محلّية صغيرة. غير أنّ NetworkService مشترك بين عدّة خدمات، فلا يمكن الفصل بـ ACL «تسمح لهذه الخدمة فقط». للحساب الافتراضي هويّة فريدة لكلّ خدمة، ويمكنك تحديد NT SERVICE\اسم-الخدمة مباشرة على ACL. منتجات مايكروسوفت الحديثة مثل 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 بدل مستخدم النطاق.

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

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

غو كومورا

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

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