เลือกบัญชีบริการ Windows — LocalSystem, บัญชีเสมือน และ gMSA

“บริการภายในที่เราเคยรันเป็น LocalSystem ถูกชี้ในตรวจความปลอดภัยว่า ‘สิทธิ์เกิน’ จะเปลี่ยนเป็นอะไร” “บริการเข้าถึงโฟลเดอร์แชร์ไม่ได้ จึงรันเป็นผู้ใช้โดเมน พอรหัสผ่านหมดอายุบริการหยุด จึงตั้งไม่ให้หมดอายุแล้วเขียนเป็นข้อความธรรมดาในรันบุ๊ก” — ในงานปรึกษาเรื่องบริการ Windows ของลูกค้า สองข้อนี้เป็นของประจำ

สิ่งที่ทั้งสองหน้างานมีร่วมกันคือ บัญชีล็อกออนของบริการถูกแช่แข็งเป็น “การตั้งค่าที่บังเอิญทำงานได้” ไม่ใช่การตัดสินใจออกแบบ บริการ Windows รันในบริบทความปลอดภัยของบัญชีใดบัญชีหนึ่งเสมอ และบัญชีนั้นตัดสินทั้งหมดว่าทำอะไรได้ในเครื่อง จากฝั่งไกลของเครือข่ายมันดูเป็นใคร และใครจัดการรหัสผ่าน ปล่อยเป็นค่าเริ่มต้นแล้วช่องโหว่ในบริการหนึ่งนำไปสู่การยึดทั้งเครื่องโดยตรง และรหัสผ่านข้อความธรรมดากระจายเข้าสู่รันบุ๊กและสคริปต์

flowchart TB
    accTitle: สามสิ่งที่บัญชีล็อกออนตัดสิน
    accDescr: บริการรันในบริบทความปลอดภัยของบัญชีใดบัญชีหนึ่งเสมอ และบัญชีนั้นตัดสินทั้งหมดว่าทำอะไรได้ในเครื่อง จากฝั่งไกลของเครือข่ายมันดูเป็นใคร และใครจัดการรหัสผ่าน
    acct["บัญชีล็อกออนของบริการ"] --> local["สิ่งที่ทำได้ในเครื่อง"]
    acct --> net["จากฝั่งไกลของเครือข่ายมันดูเป็นใคร"]
    acct --> pwd["ใครจัดการรหัสผ่าน"]

ภาพ 1: การเลือกบัญชีล็อกออนคือการตัดสินใจออกแบบที่ตัดสินสิทธิ์ท้องถิ่น ตัวตนเครือข่าย และการจัดการรหัสผ่านพร้อมกัน

มีตัวเลือกที่มีผลหกแบบ — LocalSystem, LocalService, NetworkService, บัญชีเสมือน (NT SERVICE\<ชื่อบริการ>), ผู้ใช้โดเมน และ gMSA (group Managed Service Account) มุ่งที่เจ้าหน้าที่ไอทีในธุรกิจขนาดกลางและเล็กและนักพัฒนาแอป Windows บทความนี้จัดสิทธิ์ ตัวตนเครือข่าย และการจัดการรหัสผ่านของทั้งหกไว้ในตารางเดียวและสรุปไหลตัดสินใจ จากแหล่งปฐมภูมิ Microsoft Learn ณ สิงหาคม 2026

วิธีสร้างบริการเอง (เลือกระหว่าง Task Scheduler กับบริการ การอิมพลีเมนต์ด้วย .NET Worker Service) อยู่ใน “วิธีสร้างและดำเนินงานบริการ Windows” บทความนี้โฟกัสที่ “บัญชีล็อกออน” ซึ่งเป็นจุดที่เกิดอุบัติเหตุมากที่สุด

1. ข้อสรุปก่อน

• เมื่อลังเล บัญชีเสมือนคือผู้สมัครอันดับแรกสำหรับบริการที่จบในเครื่องเดียว และ gMSA คือผู้สมัครอันดับแรกสำหรับบริการที่เข้าถึงทรัพยากรในโดเมนด้วยตัวตนเฉพาะบริการ Microsoft ก็ให้แนวทางใช้บัญชีที่จัดการ (MSA / บัญชีเสมือน) ทุกเมื่อที่ทำได้¹²
• อย่าเลือก LocalSystem เพราะ “มันทำงาน” โทเคนมี SYSTEM และ BUILTIN\Administrators และถือสิทธิ์แรงอย่าง SeDebugPrivilege ดังนั้นการถูกยึดเกือบเสียทุกอย่างบนเครื่องนั้น ค่าเริ่มต้นของ sc.exe create ที่เป็น LocalSystem คือแหล่งเพาะอุบัติเหตุนี้³⁴
• ความต่างของ LocalService กับ NetworkService คือตัวตนเครือข่าย สิทธิ์ท้องถิ่นน้อยสุดทั้งคู่ แต่ฝั่งไกล LocalService ดูเป็นนิรนาม และ NetworkService ดูเป็นบัญชีคอมพิวเตอร์⁵
• บัญชีเสมือน (NT SERVICE\<ชื่อบริการ>) คือค่าเริ่มต้นสมัยใหม่ที่แยกตัวตนต่อบริการได้โดยไม่ต้องจัดการรหัสผ่าน ระบุ “NT SERVICE\ชื่อบริการ” บน ACL ได้โดยตรง และบัญชีบริการค่าเริ่มต้นของ SQL Server ก็เป็นแบบนี้เช่นกัน⁶¹
• เมื่อ LocalSystem, NetworkService หรือบัญชีเสมือนออกสู่เครือข่าย มันกลายเป็นบัญชีคอมพิวเตอร์ (DOMAIN\ชื่อคอมพิวเตอร์$) การให้ PC$ บน ACL ของโฟลเดอร์แชร์หรือ SQL Server มักทำให้ไม่ต้องใช้ผู้ใช้โดเมน³⁶
• การตั้งค่าที่ใช้ผู้ใช้โดเมนกับบริการกลายเป็นหนี้ทั้งด้านการดำเนินงานรหัสผ่านและ Kerberoasting SCM ล็อกออนด้วยรหัสผ่านที่เก็บไว้ ดังนั้นหมดอายุกลายเป็นความล้มเหลวตอนเริ่ม และ “ไม่หมดอายุ + บันทึกข้อความธรรมดา” ที่เลี่ยงนั้นกลายเป็นของขวัญให้ผู้โจมตี⁷⁸
• gMSA ให้ Active Directory สร้างและหมุนรหัสผ่านอัตโนมัติ ข้อกำหนดคือโดเมนและคีย์ราก KDS และตั้งบริการเป็น “DOMAIN\ชื่อบัญชี$” โดยเว้นช่องรหัสผ่านว่าง บางแอปไม่รองรับ จึงต้องตรวจสอบล่วงหน้า⁹¹⁰
• การเปลี่ยนบัญชีเปลี่ยนสมมติฐานของโปรไฟล์ %TEMP% และ DPAPI ข้อมูลที่ปกป้องด้วย DPAPI ของบัญชีเก่าถอดรหัสด้วยบัญชีใหม่ไม่ได้
• สินค้าคงคลังของสถานะปัจจุบันยืนยันได้จากบัญชีล็อกออนของรายการบริการและจากเหตุการณ์ ID 4624 (ประเภทล็อกออน 5)¹¹

สรุปบทความนี้ในประโยคเดียว: ทำให้การตั้งค่าที่ “ไม่ให้รหัสผ่านของคนแก่บริการ” (บัญชีในตัว บัญชีเสมือน gMSA) เป็นค่าเริ่มต้น และถือผู้ใช้โดเมนเป็นทางเลือกสุดท้าย

2. ภาพรวมของตัวเลือก — บัญชีล็อกออนหกแบบในตารางเดียว

ทบทวนหนึ่งก้าวก่อน ตอนบริการเริ่ม Service Control Manager (SCM) ล็อกออนเป็นบัญชีที่ตั้งไว้ และเมื่อสำเร็จจะสร้าง access token แล้วกำหนดให้โพรเซสบริการ หลังจากนั้นการเข้าถึงทรัพยากรทุกครั้ง — ไฟล์ ไปป์ และคล้ายกัน — ถูกตัดสินโดยจับคู่โทเคนนี้กับ ACL⁷ ดังนั้นการเลือกบัญชีล็อกออนคือ การออกแบบที่ตัดสินเนื้อหาของโทเคนที่ส่งให้โพรเซสบริการ นี่คือหกตัวเลือก

flowchart TB
    accTitle: สิ่งที่ SCM ทำตอนบริการเริ่ม
    accDescr: SCM ล็อกออนเป็นบัญชีที่ตั้งไว้ เมื่อสำเร็จสร้าง access token และกำหนดให้โพรเซสบริการ หลังจากนั้นการเข้าถึงทรัพยากรถูกตัดสินโดยจับคู่โทเคนกับ ACL
    scm["SCM"] --> logon["ล็อกออนเป็นบัญชีที่ตั้งไว้"]
    logon --> token["สร้าง access 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 ที่ทำหน้าที่เป็นส่วนของ OS ถูกเปิดเป็นค่าเริ่มต้น³

ความแรงนี้เทียบเท่าขนาดความเสียหายเมื่อถูกยึด หากบริการที่รันเป็น LocalSystem มีช่องโหว่รันโค้ดตามอำเภอใจหนึ่งจุด ผู้โจมตีในลมหายใจเดียวถึงการอ่านและแก้ไขไฟล์ของผู้ใช้ทุกคนบนเครื่องนั้น (SYSTEM มี Full Control เป็นค่าเริ่มต้นบน NTFS⁵) การอ่านหน่วยความจำของโพรเซสอื่นผ่าน SeDebugPrivilege และการขโมยข้อมูลรับรองแล้วเคลื่อนที่ด้านข้างจากที่นั่น (จุดเริ่มของ Pass-the-Hash และคล้ายกัน) ลูกโซ่การขโมยข้อมูลรับรองและการเคลื่อนที่ด้านข้างเหมือนที่ครอบคลุมใน “อธิบาย NTLM และ Kerberos ด้วยแผนภาพ” และ “คู่มือปฏิบัติ Windows LAPS”

flowchart TB
    accTitle: ความเสียหายเมื่อบริการ LocalSystem ถูกยึด
    accDescr: หากบริการที่รันเป็น LocalSystem มีช่องโหว่รันโค้ดตามอำเภอใจหนึ่งจุด ผู้โจมตีถึงการอ่านและแก้ไขไฟล์ของผู้ใช้ทุกคน อ่านหน่วยความจำโพรเซสอื่น และขโมยข้อมูลรับรองแล้วเคลื่อนที่ด้านข้าง
    vuln["ช่องโหว่รันโค้ดตามอำเภอใจหนึ่งจุด"] --> sys["ผู้โจมตีได้สิทธิ์ SYSTEM"]
    sys --> files["อ่านและแก้ไขไฟล์"]
    sys --> mem["อ่านหน่วยความจำโพรเซสอื่น"]
    sys --> cred["ขโมยข้อมูลรับรอง"]
    cred --> lateral["เคลื่อนที่ด้านข้างไปเครื่องอื่น"]

ภาพ 3: ช่องโหว่หนึ่งจุดในบริการ LocalSystem ให้ผู้โจมตีในลมหายใจเดียวถึงการยึดทั้งเครื่องและจุดเริ่มเคลื่อนที่ด้านข้าง

3.2. ทำไมยังถูกเลือก

เหตุผลเรียบง่าย: มันคือค่าเริ่มต้น และ access-denied ไม่ปรากฏ ค่าเริ่มต้นเมื่อละ obj= บน sc.exe create คือ LocalSystem⁴ และโค้ดตัวอย่างเก่ากับเทมเพลตตัวติดตั้งจำนวนมากยังสมมติ 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 Resource Protection (WRP) ตั้งแต่ Windows Vista อนุญาตการเปลี่ยนไฟล์ระบบ OS สำคัญ โฟลเดอร์ และคีย์รีจิสทรีเฉพาะ TrustedInstaller (บริการ Windows Modules Installer) และแม้ SYSTEM หรือผู้ดูแลระบบก็ได้ access denied ตอนเขียนทับ¹² “คุณต้องได้รับอนุญาตจาก TrustedInstaller” ของ Explorer คือกลไกนี้ พูกลับกัน LocalSystem ถึงเกือบทุกอย่างนอกพื้นที่ที่ WRP ปกป้อง และโดยปกติไม่มีเหตุผลให้สิ่งนั้นแก่บริการธุรกิจ

flowchart TB
    accTitle: ความสัมพันธ์ระหว่างพื้นที่ที่ WRP ปกป้องกับ TrustedInstaller
    accDescr: การเปลี่ยนไฟล์ระบบสำคัญและคีย์รีจิสทรีที่ WRP ปกป้องอนุญาตเฉพาะ TrustedInstaller และแม้ SYSTEM หรือผู้ดูแลระบบก็ได้ access denied
    ti["TrustedInstaller"] -->|เปลี่ยนได้| wrp["ไฟล์ระบบที่ WRP ปกป้องและคล้ายกัน"]
    sysadm["SYSTEM และผู้ดูแลระบบ"] -->|Access denied| wrp
    sysadm -->|เกือบทุกอย่างได้รับอนุญาต| other["นอกพื้นที่ที่ WRP ปกป้อง"]

ภาพ 5: LocalSystem ก็ไม่ไร้ขีดจำกัด การเปลี่ยนพื้นที่ที่ WRP ปกป้องอนุญาตเฉพาะ TrustedInstaller

3.4. กรณีที่ LocalSystem สมเหตุสมผล

สิ่งที่สมเหตุสมผลเป็นพิเศษคือบริการที่ สิทธิ์ที่ต้องการเกินระดับผู้ดูแลระบบตั้งแต่แรก — ทำงานใกล้ชิดกับไดรเวอร์อุปกรณ์ ดำเนินงานฐานความปลอดภัยของ OS จัดการบริการหรือเซสชันอื่น และคล้ายกัน ซอฟต์แวร์อย่างเอเจนต์สำรองหรือ EDR เข้าข่าย แม้ตอนนั้นก็คุ้มที่จะยืนยันว่ามีเส้นทางโค้ดที่ใช้สิทธิ์นั้นจริง และพิจารณาว่างานที่ต้องการสิทธิ์แยกได้หรือไม่ (วิธีแยก ดู “เมื่อใดที่คุณต้องการสิทธิ์ผู้ดูแลระบบบน Windows จริง ๆ”)

4. LocalService และ NetworkService — บัญชีในตัวที่มีสิทธิ์น้อยที่สุด

LocalService (NT AUTHORITY\LOCAL SERVICE, SID: S-1-5-19) และ NetworkService (NT AUTHORITY\NETWORK SERVICE, SID: S-1-5-20) เป็นบัญชีในตัวที่เตรียมสำหรับบริการสิทธิ์ต่ำ ทั้งคู่ถือสิทธิ์น้อยสุดในเครื่อง และทำได้น้อยกว่าสมาชิกกลุ่ม Users ไม่มาก⁵¹

ความต่างของทั้งคู่มีจุดเดียว: จากฝั่งไกลของเครือข่ายพวกมันดูเป็นใคร⁵

• LocalService: เชื่อมต่อฝั่งไกลด้วย ข้อมูลรับรองนิรนาม เข้าถึงทรัพยากรที่ต้องยืนยันตัวตนไม่ได้
• NetworkService: นำเสนอ ข้อมูลรับรองของคอมพิวเตอร์ ให้ฝั่งไกล (ในสภาพแวดล้อมโดเมน คือ DOMAIN\ชื่อคอมพิวเตอร์$)

การแยกคือ LocalService หาก “ไม่ออกสู่เครือข่าย หรือถ้าออกก็ไม่ต้องการตัวตน” และ NetworkService หาก “ต้องการเข้าถึงทรัพยากรในโดเมนด้วยตัวตนของเครื่อง”

flowchart TB
    accTitle: ความต่างของ LocalService กับ NetworkService
    accDescr: สิทธิ์ท้องถิ่นน้อยสุดทั้งคู่ แต่ฝั่งไกล LocalService เชื่อมด้วยข้อมูลรับรองนิรนาม และ NetworkService นำเสนอข้อมูลรับรองของคอมพิวเตอร์
    ls["LocalService"] --> anon["เชื่อมด้วยข้อมูลรับรองนิรนาม"]
    anon -.-> ng["ทรัพยากรที่ต้องยืนยันตัวตนเป็นไปไม่ได้"]
    ns["NetworkService"] --> comp["นำเสนอข้อมูลรับรองของคอมพิวเตอร์"]
    comp -.-> pc["ในสภาพแวดล้อมโดเมนดูเป็น PC$"]

ภาพ 6: สิทธิ์ท้องถิ่นเท่ากันที่น้อยสุด แต่ตัวตนที่มองจากฝั่งไกลของเครือข่ายแยกเป็นนิรนามหรือบัญชีคอมพิวเตอร์

ทั้งคู่มีจุดอ่อนจากมุมสมัยใหม่ บัญชีเดียวกันถูกหลายบริการใช้ร่วม หากห้าบริการรันเป็น LocalService ตราบที่ ACL เป็นต่อบัญชี ทั้งห้าเข้าถึงทรัพยากรของกันและกันได้ SQL Server ไม่รองรับบัญชี Local Service ด้วยเหตุเดียวกัน: เป็นบัญชีร่วมและแยกจากบริการอื่นไม่ได้¹

flowchart TB
    accTitle: บัญชีร่วมแยกไม่ได้
    accDescr: หากหลายบริการใช้ LocalService เดียวกัน ตราบที่ ACL เป็นต่อบัญชี พวกมันเข้าถึงทรัพยากรของกันและกันได้
    sva["บริการ A"] --> acct["LocalService เดียวกัน"]
    svb["บริการ B"] --> acct
    svc["บริการ C"] --> 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 ตามชื่อได้ “เฉพาะบริการนี้เขียนโฟลเดอร์ข้อมูลนี้ได้” ทำให้จริงได้โดยไม่สร้างกลุ่มและไม่จัดการรหัสผ่าน

# เปลี่ยนบัญชีล็อกออนของบริการเป็นบัญชีเสมือน
# ค่าของ obj= คือ "NT SERVICE\ชื่อบริการ" อย่าระบุรหัสผ่าน
sc.exe config MyAppService obj= "NT SERVICE\MyAppService"

# ยืนยันการตั้งค่า (ตรวจ SERVICE_START_NAME)
sc.exe qc MyAppService

# ให้สิทธิ์แก้ไขบนโฟลเดอร์ข้อมูลเฉพาะบริการนี้
icacls "C:\ProgramData\MyApp" /grant "NT SERVICE\MyAppService:(OI)(CI)M"

ใน GUI ที่ services.msc เปิดคุณสมบัติของบริการ → แท็บ “Log On” → ใส่ NT SERVICE\ชื่อบริการ ใน “This account” และ เว้นช่องรหัสผ่านว่าง (สำหรับบัญชีเสมือนหรือ MSA การไม่ระบุรหัสผ่านคือข้อกำหนดของ SCM) หลังเปลี่ยน การเริ่มบริการใหม่จะนำไปใช้

5.3. ข้อจำกัด — นอกเครื่องมันไม่ใช่ “บริการนั้น”

ตัวตนของบัญชีเสมือนเป็นท้องถิ่นเครื่องและโดเมนไม่รู้จัก บนเครือข่ายมันยุบเป็นบัญชีคอมพิวเตอร์ดังที่อธิบายภายหลัง ดังนั้น ฝั่งไกลแยกไม่ได้ว่า “เป็นบริการใด” และคุณก็แชร์ตัวตนเดียวกันข้ามหลายเซิร์ฟเวอร์ไม่ได้¹⁰

flowchart TB
    accTitle: ตัวตนบัญชีเสมือนยุบนอกเครื่อง
    accDescr: บัญชีเสมือนที่เฉพาะต่อบริการในเครื่องก็ยุบเป็นบัญชีคอมพิวเตอร์บนเครือข่าย และฝั่งไกลแยกไม่ได้ว่าเป็นบริการใด
    vaa["บัญชีเสมือน A"] --> pc["บัญชีคอมพิวเตอร์ PC$"]
    vab["บัญชีเสมือน B"] --> 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 ทั่วไป ระบุ ชื่อคอมพิวเตอร์$ เป็นชื่อบัญชี (ในกล่องเลือกออบเจ็กต์ของ GUI ให้รวม “Computers” ในประเภทออบเจ็กต์)

# ฝั่งไฟล์เซิร์ฟเวอร์: ให้บริการบน APPSV01 สิทธิ์แก้ไขบนโฟลเดอร์แชร์
# ต้องให้ทั้งสิทธิ์แชร์และสิทธิ์ NTFS
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 โดยไม่มีรหัสผ่าน

-- ฝั่งเซิร์ฟเวอร์ฐานข้อมูล: อนุญาตการยืนยันตัวตนรวม Windows จากบริการบน 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. ไม่เคยตั้งขั้นตอนการเปลี่ยน และรหัสผ่านเดียวกันถูกเขียนเป็นข้อความธรรมดาในรันบุ๊ก สคริปต์ และ Task Scheduler ของหลายเซิร์ฟเวอร์
4. แม้มีคนออก รหัสผ่านก็ไม่เปลี่ยน (ถ้าเปลี่ยน ไม่รู้ว่าอะไรจะหยุด)

flowchart TB
    accTitle: วงจรลบของการดำเนินงานด้วยผู้ใช้โดเมน
    accDescr: รหัสผ่านหมดอายุและบริการหยุด ตั้งไม่หมดอายุเพื่อกันเกิดซ้ำ รหัสผ่านข้อความธรรมดาแพร่เข้าสู่รันบุ๊กและสคริปต์ และแม้มีคนออกก็เปลี่ยนไม่ได้
    expire["1. หมดอายุทำให้บริการหยุด"] --> forever["2. ตั้งไม่หมดอายุเพื่อกันเกิดซ้ำ"]
    forever --> spread["3. รหัสผ่านข้อความธรรมดาแพร่"]
    spread -.-> where["รันบุ๊ก สคริปต์ งาน"]
    spread --> stuck["4. แม้มีคนออกก็เปลี่ยนไม่ได้"]

ภาพ 12: เริ่มจากอุบัติเหตุหมดอายุ การไม่หมดอายุและการแพร่ของรหัสผ่านข้อความธรรมดาถูกตรึง

Microsoft ยังชี้ว่าการตั้งค่าที่ใช้บัญชีโดเมนกับบริการกินความพยายามดำเนินงานมากในการจัดการรหัสผ่านและ SPN ด้วยมือ และการบำรุงรักษาอาจนำไปสู่การหยุดบริการ¹

7.2. Kerberoasting — บัญชีบริการถูกเล็ง

การโจมตีอีกแบบที่เฉพาะกับบัญชีบริการผู้ใช้โดเมนคือ Kerberoasting บริการที่รับการยืนยันตัวตน Kerberos ลงทะเบียน SPN (service principal name) บนบัญชีล็อกออน ผู้ใช้ที่ยืนยันตัวตนแล้วในโดเมนทุกคนขอตั๋วบริการไปยังบัญชีที่มี SPN ลงทะเบียนได้ ดังนั้นผู้โจมตีได้ตั๋วแล้วลอง brute-force รหัสผ่านออฟไลน์ รหัสผ่าน 10 ถึง 16 ตัวอักษรที่คนตัดสินจะต้านการโจมตีนี้ไม่ได้

flowchart TB
    accTitle: ไหลของ Kerberoasting
    accDescr: ตั๋วบริการไปยังบัญชีบริการที่มี SPN ลงทะเบียนถูกผู้ใช้ที่ยืนยันตัวตนแล้วขอได้ ดังนั้นผู้โจมตีได้ตั๋วแล้วลอง brute-force รหัสผ่านออฟไลน์
    atk["ผู้ใช้ที่ยืนยันตัวตนแล้วในโดเมน"] --> req["ขอตั๋วสำหรับ SPN"]
    req --> tkt["ได้ตั๋วบริการ"]
    tkt --> brute["Brute-force ออฟไลน์"]
    brute --> weak["ราว 10 ถึง 16 ตัวอักษรจะถูกแกะ"]

ภาพ 13: ผู้ใช้ที่ยืนยันตัวตนแล้วทุกคนขอตั๋วได้ และรหัสผ่านความยาวที่คนตัดสินจะต้าน brute-force ออฟไลน์ไม่ได้

การตอบที่มีผลคือ ทำให้รหัสผ่านแข็งแรงถึงระดับที่คนเดาหรือแกะไม่ได้ Microsoft ยังระบุการบังคับรหัสผ่านยาว และการใช้ gMSA ที่รหัสผ่านกลายเป็นค่าสุ่มยาวที่เครื่องสร้าง⁸ เอกสารเดียวกันยังกล่าวถึง Kerberos armoring (FAST) แต่ FAST ปกป้องข้อมูลก่อนยืนยันตัวตนและความทนต่อการปลอม KDC มันไม่กันผู้ใช้ที่ยืนยันตัวตนแล้วขอตั๋วบริการไปยัง SPN จึงไม่ใช่สิ่งแทนความแข็งแรงของรหัสผ่านบัญชีบริการ ความสัมพันธ์ของ SPN กับ Kerberos และเงื่อนไขที่การยืนยันตัวตนตกไป NTLM ถูกวาดใน “อธิบาย NTLM และ Kerberos ด้วยแผนภาพ”

7.3. หากยังใช้ผู้ใช้โดเมน

หากไม่มีทางเลือกนอกจากใช้ผู้ใช้โดเมน ด้วยเหตุเช่นแอปไม่รองรับ gMSA ให้ถือสิ่งต่อไปนี้เป็นการลดผลกระทบขั้นต่ำ

• ทำให้รหัสผ่านเป็น 25 ตัวอักษรขึ้นไปที่สุ่มสร้าง และอย่าเขียนที่ไหนนอกเครื่องมือจัดการรหัสผ่าน (รันบุ๊ก สคริปต์ Excel ร่วม)
• ทำให้เป็นบัญชีเฉพาะบริการและแยกต่อบริการ (อย่าใช้ร่วมกับบัญชีคน²)
• ปฏิเสธล็อกออนเชิงโต้ตอบและ Remote Desktop และอนุญาตเฉพาะ “Log on as a service”
• ย่อกลุ่มที่สังกัดให้เล็กสุด (เพิ่มเข้า Domain Admins อยู่นอกโต๊ะ)
• ตั้งขั้นตอนหมุนเป็นระยะและ ใส่จุดที่การเปลี่ยนจะกระทบลงสมุดบัญชี

ทำทั้งหมดนี้ยังปลอดภัยน้อยและง่ายน้อยกว่าการย้ายไป gMSA — นั่นคือบทถัดไป

8. gMSA — มอบการจัดการรหัสผ่านให้ Active Directory

8.1. กลไกและผล

gMSA (group Managed Service Account) คือบัญชีโดเมนที่มอบการจัดการรหัสผ่านให้ตัวควบคุมโดเมน รหัสผ่านถูกตัวควบคุมโดเมนคำนวณจากคีย์ราก KDS (Key Distribution Service) และเฉพาะโฮสต์ที่ได้รับอนุญาตเท่านั้นที่ได้¹³

flowchart TB
    accTitle: วิธีที่ gMSA จัดการรหัสผ่าน
    accDescr: ตัวควบคุมโดเมนคำนวณรหัสผ่านจากคีย์ราก KDS เฉพาะโฮสต์ที่ได้รับอนุญาตที่ได้แล้วนำไปรันบริการ และรหัสผ่านถูกหมุนอัตโนมัติทุก 30 วันเป็นค่าเริ่มต้น
    kds["คีย์ราก KDS"] --> dc["DC คำนวณรหัสผ่าน"]
    dc --> host["โฮสต์ที่ได้รับอนุญาตได้มัน"]
    host --> svc["ใช้รันบริการ"]
    dc -.-> rot["หมุนอัตโนมัติทุก 30 วันเป็นค่าเริ่มต้น"]

ภาพ 14: ตัวควบคุมโดเมนรับหน้าที่สร้าง แจก และอัปเดตรหัสผ่าน และคนดำเนินงานได้โดยไม่รู้รหัสผ่าน

ผลชัดเจน⁹

• รหัสผ่านสุ่ม 240 ไบต์ที่สร้างแบบสุ่ม: brute-force และการโจมตีพจนานุกรมกลายเป็นไม่สมจริง และความทน 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 ชั่วโมงหลังสร้างคีย์รากคือเวลารอเพื่อกันการดึงล้มเหลวขณะจำลองยังไม่เสร็จ

# รันในฐานะผู้ดูแลโดเมน บนตัวควบคุมโดเมน (หรือสถานีงาน
# บริหารที่มีโมดูล AD PowerShell)

# ยืนยันว่ามีคีย์ราก KDS หรือไม่ และสร้างถ้ายังไม่มี (ครั้งเดียวต่อฟอเรสต์)
Get-KdsRootKey
Add-KdsRootKey -EffectiveImmediately   # ใช้ได้จริงหลังสูงสุด 10 ชั่วโมง

8.3. ขั้นตอนจากการสร้างถึงการตั้งค่า

ขั้นตอนสี่ระยะ: “① สร้างกลุ่มที่ได้รับอนุญาตให้ดึง → ② สร้าง gMSA → ③ ติดตั้งบนเซิร์ฟเวอร์ → ④ ตั้งบนบริการ”¹⁰

flowchart TB
    accTitle: สี่ระยะของการนำ gMSA เข้า
    accDescr: นำเข้าสี่ระยะ สร้างกลุ่มที่ได้รับอนุญาตให้ดึงรหัสผ่าน สร้าง gMSA ติดตั้งบนแต่ละเซิร์ฟเวอร์ และตั้งเป็นบัญชีล็อกออนของบริการ
    st1["① สร้างกลุ่มที่ได้รับอนุญาตให้ดึง"] --> st2["② สร้าง gMSA"]
    st1 -.-> add["เพิ่ม PC$ ของเซิร์ฟเวอร์"]
    st2 --> st3["③ ติดตั้งบนแต่ละเซิร์ฟเวอร์"]
    st3 -.-> test["ตรวจสอบการดึงด้วยคำสั่ง Test"]
    st3 --> st4["④ ตั้งบนบริการ"]

ภาพ 16: จากการสร้างกลุ่มถึงการตั้งบริการ การนำ gMSA เข้าดำเนินในสี่ระยะ

# ① สร้างกลุ่มความปลอดภัยที่ได้รับอนุญาตให้ดึงรหัสผ่าน
#    และเพิ่มบัญชีคอมพิวเตอร์ของเซิร์ฟเวอร์ที่จะรันบริการ
New-ADGroup -Name "GG-SvcBatchHosts" -GroupScope Global
Add-ADGroupMember -Identity "GG-SvcBatchHosts" -Members "APPSV01$", "APPSV02$"
# สมาชิกภาพกลุ่มถูกประเมินตอนคอมพิวเตอร์ล็อกออน ดังนั้น
# การเริ่มเซิร์ฟเวอร์เป้าหมายใหม่หลังเพิ่มคือแนวทางที่แน่นอน

# ② สร้าง gMSA
New-ADServiceAccount -Name "svc-batch" `
    -DNSHostName "svc-batch.corp.example.com" `
    -PrincipalsAllowedToRetrieveManagedPassword "GG-SvcBatchHosts"

# ③ บนแต่ละเซิร์ฟเวอร์ที่จะรันบริการ ติดตั้ง gMSA และตรวจสอบ
Install-ADServiceAccount -Identity "svc-batch"
Test-ADServiceAccount -Identity "svc-batch"   # True หมายความว่าการดึงทำงาน

# ④ ตั้งเป็นบัญชีล็อกออนของบริการ ต่อ $ ที่ชื่อ และอย่าระบุรหัสผ่าน
sc.exe config MyBatchService obj= "CORP\svc-batch$"
Restart-Service MyBatchService

เมื่อตั้งจาก services.msc เช่นกัน ชื่อบัญชีเป็นแบบ CORP\svc-batch$ — ต่อ $ ที่ท้าย และเว้นช่องรหัสผ่านว่าง บัญชีตระกูล MSA ใช้สำหรับลงชื่อเข้าใช้เชิงโต้ตอบไม่ได้¹ หลังจากนั้น ให้ CORP\svc-batch$ บน ACL ของโฟลเดอร์แชร์หรือ SQL Server แทน PC$ และ การเข้าถึงเครือข่ายด้วยตัวตนเฉพาะบริการ เสร็จ โดยไม่มีรหัสผ่าน

8.4. บางแอปไม่รองรับ

ในฐานะข้อควรระวัง ไม่ใช่ซอฟต์แวร์ทุกชิ้นจะรันเป็น gMSA ได้ สิ่งที่ตั้งตัวตนล็อกออนผ่านกลไกมาตรฐาน — บริการ Windows พูลแอป IIS งาน Task Scheduler — รองรับกว้าง แต่มีข้อจำกัดอย่าง failover clustering เองไม่รองรับ gMSA และแอปที่ภายในเรียกรหัสผ่านใช้ไม่ได้¹⁰ Microsoft ยังระบุชัดว่าคุณควรยืนยันพฤติกรรมในฐานะ gMSA ในสภาพแวดล้อมทดสอบก่อนโปรดักชัน⁹

flowchart TB
    accTitle: แยกว่าอะไรรองรับ gMSA
    accDescr: แอปที่ตั้งตัวตนล็อกออนผ่านกลไกมาตรฐานรองรับ gMSA กว้าง แต่ failover clustering และแอปที่ภายในเรียกรหัสผ่านใช้ไม่ได้ จึงยืนยันในสภาพแวดล้อมทดสอบก่อนโปรดักชัน
    app["แอปเป้าหมาย"] --> how{"ล็อกออนถูกตั้งอย่างไร"}
    how -->|กลไกมาตรฐาน| okapp["รองรับ gMSA"]
    okapp -.-> ex1["บริการ IIS งาน"]
    how -->|เรียกรหัสผ่าน| ngapp["gMSA ไม่ได้"]
    ngapp -.-> ex2["Failover clustering"]
    okapp --> test["ทดสอบก่อนโปรดักชัน"]

ภาพ 17: แอปที่ตั้งล็อกออนผ่านกลไกมาตรฐานรองรับกว้าง แต่บางการออกแบบไม่รองรับ ดังนั้นการตรวจสอบก่อนโปรดักชันขาดไม่ได้

ยังมีพี่น้อง: sMSA (standalone Managed Service Account) สำหรับเซิร์ฟเวอร์เดียว และ dMSA (delegated Managed Service Account เปิดใน Windows Server 2025 ซึ่งผูกกับตัวตนอุปกรณ์เพื่อต้านการขโมยข้อมูลรับรอง) สำหรับการสร้างใหม่ ให้ถือ gMSA เป็นฐานแล้วพิจารณาตามข้อกำหนด⁶

9. การออกแบบประกอบ — สิทธิ์ล็อกออน โปรไฟล์ DPAPI และการตรวจสอบ

อีกสี่สิ่งที่เปลี่ยนตามบัญชี ที่ต้องจำ

9.1. สิทธิ์ “Log on as a service” (SeServiceLogonRight)

เพื่อเริ่มในฐานะบริการ บัญชีต้องมีสิทธิ์ผู้ใช้ “Log on as a service” LocalSystem, LocalService และ NetworkService มีในตัว แต่ บัญชีอื่น (ผู้ใช้โดเมน gMSA และคล้ายกัน) ต้องกำหนดอย่างชัดเจน¹⁵

หากตั้งจากแท็บ “Log On” ของ GUI services.msc สแนปอินให้สิทธิ์นี้อัตโนมัติ ในทางกลับกัน CreateService / ChangeServiceConfig (API ที่ sc.exe config เรียก) ไม่ตรวจว่าบัญชีที่ระบุมีสิทธิ์นี้ สาเหตุทั่วไปที่บริการที่ตั้งด้วยสคริปต์หยุดตอนเริ่มด้วย “บริการไม่เริ่มเนื่องจากความล้มเหลวของล็อกออน” คือสิ่งนี้ อย่าพึ่งผลข้างเคียงของเครื่องมือ ให้ใส่ในขั้นตอนดีพลอยอย่างชัดเจน การเพิ่มเข้า “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 เรียกไม่ตรวจสิทธิ์ ดังนั้นบัญชีที่ไม่มีสิทธิ์หยุดบริการด้วยความล้มเหลวของล็อกออนตอนเริ่ม
    gui["ตั้งใน services.msc"] --> auto["สิทธิ์ถูกให้อัตโนมัติ"]
    auto --> okgui["บริการเริ่มได้"]
    cli["ตั้งด้วย sc.exe config"] --> noval["สิทธิ์ไม่ถูกตรวจ"]
    noval --> has{"มีสิทธิ์หรือไม่"}
    has -->|ใช่| okcli["บริการเริ่มได้"]
    has -->|ไม่| stop["หยุดด้วยความล้มเหลวของล็อกออน"]
    stop -.-> fix["ให้ชัดเจนด้วย secpol.msc หรือ GPO"]

ภาพ 18: GUI ให้สิทธิ์อัตโนมัติ แต่การตั้งด้วยสคริปต์ไม่ตรวจ จึงต้องใส่การให้ชัดเจนในขั้นตอน

9.2. โปรไฟล์ %TEMP% และ HKEY_CURRENT_USER เปลี่ยน

SCM โหลดโปรไฟล์ผู้ใช้ของบัญชีนั้นตอนบริการเริ่ม⁷ ดังนั้น %TEMP% %APPDATA% และ HKEY_CURRENT_USER ที่แท้จริงเป็นสิ่งต่างกันต่อบัญชีล็อกออน และเมื่อคุณสลับบัญชี การตั้งค่าและแคชที่บันทึกในโปรไฟล์บัญชีเก่าดูเหมือน “หายไป”

การตอบด้านการออกแบบเรียบง่าย: วางข้อมูลของบริการไม่ใต้โปรไฟล์ แต่บนเส้นทางชัดเจนอย่าง C:\ProgramData\<ชื่อแอป> และให้ ACL นั้นแก่บัญชีล็อกออน แบบนั้นการเปลี่ยนบัญชีไม่มาพร้อมการย้ายข้อมูล

flowchart TB
    accTitle: การพึ่งโปรไฟล์และการตอบด้านการวางข้อมูล
    accDescr: โปรไฟล์ที่แท้จริงเป็นสิ่งต่างกันต่อบัญชีล็อกออน ดังนั้นการสลับบัญชีทำให้ข้อมูลโปรไฟล์เก่าดูเหมือนหายไป แต่การวางข้อมูลบนเส้นทางชัดเจนและให้ ACL ทำให้ไม่ต้องย้าย
    sw["สลับบัญชีล็อกออน"] --> newprof["โปรไฟล์อื่นถูกโหลด"]
    newprof --> lost["ข้อมูลเก่าดูเหมือนหายไป"]
    lost -.->|การตอบ| fix["วางใต้ ProgramData"]
    fix --> acl["ให้ ACL แก่บัญชีล็อกออน"]
    acl --> nomig["ไม่ต้องย้ายแม้บัญชีเปลี่ยน"]

ภาพ 19: หลีกโปรไฟล์และวางข้อมูลบนเส้นทางชัดเจน การเปลี่ยนบัญชีก็ไม่มาพร้อมการย้ายข้อมูลอีก

9.3. ข้อมูลที่ปกป้องด้วย DPAPI ผูกกับบัญชี

สิ่งที่พลาดง่ายกว่าอีกคือ DPAPI ข้อมูลที่เข้ารหัสด้วย DPAPI ขอบเขตผู้ใช้ (CryptProtectData หรือ ProtectedData ของ .NET) ตามหลักถอดรหัสได้เฉพาะบัญชีเดียวกันที่ปกป้อง ช่วงที่คุณเปลี่ยนบัญชี สตริงเชื่อมต่อหรือคีย์ API ที่เก็บไว้ไม่ได้อ่านอีก — นั่นคือ DPAPI ทำงานถูกต้อง แต่ถ้าไม่อยู่ในขั้นตอนการย้ายมันกลายเป็นเหตุการณ์

flowchart TB
    accTitle: ความสัมพันธ์ระหว่างข้อมูลที่ปกป้องด้วย DPAPI กับการเปลี่ยนบัญชี
    accDescr: ข้อมูลที่ปกป้องด้วย DPAPI ขอบเขตผู้ใช้ถอดรหัสได้เฉพาะบัญชีเดียวกันที่ปกป้อง ดังนั้นหลังเปลี่ยนบัญชีล็อกออนคุณต้องกรอกความลับใหม่
    protect["ปกป้อง DPAPI ด้วยบัญชีเก่า"] --> data["สตริงเชื่อมต่อที่ปกป้องและคล้ายกัน"]
    data --> who{"บัญชีใดกำลังถอดรหัส"}
    who -->|บัญชีเก่าเดียวกัน| okdec["ถอดรหัสได้"]
    who -->|บัญชีใหม่| ngdec["ถอดรหัสไม่ได้"]
    ngdec --> re["กรอกความลับใหม่"]

ภาพ 20: ข้อมูลที่ปกป้องด้วย DPAPI ผูกกับบัญชีที่ปกป้อง และหลังสลับบัญชีคุณต้องกรอกใหม่

การตอบคือใส่ในแผนการย้ายขั้นตอน “กรอกความลับใหม่หลังสลับบัญชี” (สำหรับการออกแบบว่าเก็บที่ไหน ดู “การเก็บความลับในแอป Windows”) อีกทั้งการตั้งค่าที่จบด้วยการยืนยันตัวตนรวม Windows ในฐานะ gMSA หรือ PC$ ตัดการเก็บความลับเองได้ ลำดับที่ถูกคือพิจารณา “เราไม่เก็บได้ไหม” ก่อน “เราเก็บที่ไหน”

และหากบริการต้องการประมวลผล “ด้วยสิทธิ์ของผู้ใช้ที่เรียก” คุณใช้การปลอมตัวแทนการทำให้บัญชีแรงขึ้น สำหรับเรื่องนั้น ดู “จัดการโทเคนการปลอมตัวของ Windows ให้ถูกต้อง”

9.4. การตรวจสอบ — มอง 4624 ประเภทล็อกออน 5

การเริ่มบริการถูกบันทึกในบันทึกเหตุการณ์ Security เป็นเหตุการณ์ ID 4624 (An account was successfully logged on) ด้วย ประเภทล็อกออน 5 (Service: SCM เริ่มบริการ) ฟิลด์ “Virtual Account” ในเหตุการณ์บอกว่าล็อกออนโดย MSA / บัญชีเสมือนหรือไม่ จึงใช้เฝ้าการใช้บัญชีที่จัดการได้เช่นกัน¹¹

flowchart TB
    accTitle: ไหลของการตรวจสอบการเริ่มบริการ
    accDescr: SCM เริ่มบริการถูกบันทึกเป็นเหตุการณ์ ID 4624 ประเภทล็อกออน 5 และฟิลด์ Virtual Account ระบุได้ว่าล็อกออนโดยบัญชีที่จัดการหรือไม่
    start["SCM เริ่มบริการ"] --> ev["บันทึกเหตุการณ์ ID 4624"]
    ev --> type5["ประเภทล็อกออน 5 (Service)"]
    type5 --> vafield["ฟิลด์ Virtual Account"]
    vafield --> watch["เฝ้าบัญชีที่จัดการ"]

ภาพ 21: การเริ่มบริการถูกบันทึกเป็น 4624 ประเภทล็อกออน 5 และคุณติดตามการใช้บัญชีที่จัดการได้ด้วย

สำหรับสินค้าคงคลังของสถานะปัจจุบัน การรวมบัญชีล็อกออนของรายการบริการคือวิธีเร็ว

# รวมว่าบริการใดรันเป็นบัญชีใด
Get-CimInstance Win32_Service |
    Group-Object StartName |
    Sort-Object Count -Descending |
    Select-Object Count, Name

# สินค้าคงคลังบริการนอกมาตรฐานที่รันเป็น LocalSystem (แยกภายใน / บุคคลที่สามจากเส้นทาง)
Get-CimInstance Win32_Service |
    Where-Object { $_.StartName -eq 'LocalSystem' -and $_.PathName -notlike '*\Windows\*' } |
    Select-Object Name, DisplayName, PathName

หากผลลัพธ์นี้เรียง “บริการธุรกิจที่รันเป็น LocalSystem” และ “บริการที่รันเป็นผู้ใช้โดเมน” ไหลตัดสินใจของบทถัดไปถูกเรียก

10. ไหลตัดสินใจ — ตัดสินด้วยสี่คำถาม

นี่คือเนื้อหาจนถึงตอนนี้ ในรูปขั้นตอนการเลือก ตอบสี่คำถามตามลำดับ

flowchart TB
    accTitle: ไหลตัดสินใจของบัญชีล็อกออน
    accDescr: ตัดสินบัญชีล็อกออนโดยตอบตามลำดับสี่คำถามว่ามีการเข้าถึงเครือข่ายหรือไม่ เข้าร่วมโดเมนหรือไม่ ตัวตนระดับเครื่องพอหรือไม่ และการรองรับ gMSA
    q1{"Win auth ไปยังคู่หรือไม่"} -->|ไม่| va["บัญชีเสมือน"]
    va -.-> sys["LocalSystem หากจำเป็น"]
    q1 -->|ใช่| q2{"เข้าร่วมโดเมนหรือไม่"}
    q2 -->|ไม่| cred["ปกป้องข้อมูลรับรองที่เก็บ"]
    q2 -->|ใช่| q3{"ระดับเครื่องพอหรือไม่"}
    q3 -->|ใช่| pcacl["บัญชีเสมือน + PC$"]
    q3 -->|ไม่| q4{"แอปรองรับ gMSA หรือไม่"}
    q4 -->|ใช่| gmsa["gMSA"]
    q4 -->|ไม่| du["ผู้ใช้ + การลดผลกระทบ"]

ภาพ 22: ตอบสี่คำถามตามลำดับแล้วตัวเลือกใดในหกแบบที่คุณควรใช้ถูกตัดสิน

คำถาม 1: บริการนั้นเข้าถึงเครื่องอื่นบนเครือข่าย (โฟลเดอร์แชร์ ฐานข้อมูล API และคล้ายกัน) ด้วยการยืนยันตัวตน Windows หรือไม่

ถ้าไม่ บัญชีเสมือน คือค่าเริ่มต้น เฉพาะเมื่อต้องการสิทธิ์ท้องถิ่นพิเศษ ให้ยืนยันความจำเป็นนั้นแล้วจึงพิจารณา LocalSystem

คำถาม 2: (หากเข้าถึง) เครื่องเข้าร่วมโดเมนหรือไม่

ในเวิร์กกรุ๊ป ทั้ง PC$ และ gMSA ใช้ไม่ได้ ใช้การออกแบบที่จัดการข้อมูลรับรองของบัญชีปลายทางอย่างชัดเจน (ปกป้องที่เก็บด้วย DPAPI หรือคล้ายกัน) หรือพิจารณาเข้าร่วมโดเมน

คำถาม 3: (ในโดเมน) ตัวตนระดับเครื่อง (PC$) พอหรือไม่

ถ้าพอ บัญชีเสมือน (หรือ NetworkService) + ให้ PC$ บน ACL ปลายทาง ก็เสร็จ หากต้องการตัวตนเฉพาะบริการ หรือตัวตนร่วมข้ามหลายเซิร์ฟเวอร์ ไปคำถาม 4

คำถาม 4: แอปรองรับ gMSA หรือไม่

ถ้ารองรับ (สิ่งที่ตั้งล็อกออนผ่านกลไกมาตรฐาน — SCM พูลแอป IIS Task Scheduler — โดยทั่วไปรองรับ) 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\ชื่อ$” โดยเว้นช่องรหัสผ่านว่าง
• เมื่อเปลี่ยนบัญชี ให้ใส่สิทธิ์ “Log on as a service” การย้ายโปรไฟล์และ %TEMP% และการกรอกข้อมูลที่ปกป้องด้วย DPAPI ใหม่ในขั้นตอนการย้าย การตรวจสอบยืนยันด้วยเหตุการณ์ ID 4624 ประเภทล็อกออน 5

ครั้งหน้าเมื่อติดตั้งบริการ ให้หยุดครู่หนึ่งบนหน้าจอตั้งค่าล็อกออนแล้วถามสิ่งนี้อีก ในฐานะใคร และไกลแค่ไหน บริการนี้ควรเข้าถึงได้ คำตอบควรเป็นแถวใดแถวหนึ่งของตารางตัดสินใจในบทความนี้

บทความที่เกี่ยวข้อง

• วิธีสร้างและดำเนินงานบริการ Windows ── จากการเลือกระหว่าง Task Scheduler กับบริการถึงการทำให้ BackgroundService เป็นบริการ Windows
• เมื่อใดที่คุณต้องการสิทธิ์ผู้ดูแลระบบบน Windows จริง ๆ - UAC พื้นที่ที่ปกป้อง และวิธีแยกตามการออกแบบ
• จัดการโทเคนการปลอมตัวของ Windows ให้ถูกต้อง — ยืมสิทธิ์ต่อเธรดและคืนอย่างปลอดภัย
• อธิบาย NTLM และ Kerberos ด้วยแผนภาพ — ทำไมการยืนยันตัวตนจึงตกไป NTLM
• คู่มือปฏิบัติ Windows LAPS — เลิกรหัสผ่านผู้ดูแลระบบท้องถิ่นร่วมทั้งเครื่อง
• การเก็บความลับในแอป Windows - หลีกการตั้งค่าข้อความธรรมดาด้วย DPAPI

ด้านให้คำปรึกษาที่เกี่ยวข้อง

KomuraSoft LLC รับออกแบบบัญชีล็อกออนและการเสริมสิทธิ์น้อยที่สุดสำหรับบริการ Windows และแอปประจำเครื่อง การย้ายบริการที่มีอยู่ที่สร้างบนสมมติฐาน LocalSystem ไปบัญชีเสมือนหรือ gMSA และการสอบสวนความล้มเหลวจาก access denied, DPAPI และโปรไฟล์หลังเปลี่ยนบัญชี เริ่มจากขั้น “ถูกชี้ในตรวจ แต่ไม่รู้จะเริ่มที่ไหน” ก็ได้

• พัฒนาแอป Windows
• ตรวจสอบบั๊กและหาสาเหตุ
• ที่ปรึกษาเทคนิคและรีวิวการออกแบบ
• ติดต่อเรา

ลิงก์อ้างอิง

บทความที่เกี่ยวข้อง

บทความล่าสุดที่มีแท็กเดียวกัน เพื่อเจาะลึกหัวข้อใกล้เคียง

หัวข้อที่เกี่ยวข้อง

หน้าเหล่านี้วางหัวข้อไว้ในบริบทที่กว้างขึ้นของบริการและการตัดสินใจ

บริการที่เกี่ยวข้องกับหัวข้อนี้

บทความนี้เกี่ยวข้องโดยตรงกับบริการต่อไปนี้

คำถามที่พบบ่อย

คำถามที่มักพบในการปรึกษาเกี่ยวกับหัวข้อของบทความนี้

ควรเปลี่ยนบริการที่รันเป็น LocalSystem มาตลอดทันทีหรือไม่

การเปลี่ยนทันทีไม่ใช่คำตอบที่ถูกสำหรับทุกกรณี ก่อนอื่นให้ยืนยันว่าบริการนั้นต้องการสิทธิ์ท้องถิ่นระดับ LocalSystem จริงหรือไม่ (สิทธิ์แรงเกินผู้ดูแลระบบ) หากเป็นเพียงอ่าน/เขียนไฟล์และสื่อสารเครือข่าย การย้ายไปบัญชีเสมือน (NT SERVICE\ชื่อบริการ) คือผู้สมัครอันดับแรก ตอนย้ายให้ยืนยันการให้สิทธิ์เข้าถึงโฟลเดอร์และคีย์รีจิสทรีที่ต้องใช้ วิธีจัดการข้อมูลที่พึ่งโปรไฟล์หรือ DPAPI และว่ามีสิทธิ์ "Log on as a service" หรือไม่ ยืนยันการเริ่มและฟังก์ชันหลักในสภาพแวดล้อมตรวจสอบ แล้วจึงสลับโปรดักชัน

ควรเลือกบัญชีเสมือนหรือ NetworkService

สำหรับการเลือกใหม่ เราแนะนำบัญชีเสมือน บนเครือข่ายทั้งคู่ปรากฏเป็นบัญชีคอมพิวเตอร์ (DOMAIN\ชื่อคอมพิวเตอร์$) และทั้งคู่มีสิทธิ์ท้องถิ่นเล็ก NetworkService อย่างไรก็ตามถูกหลายบริการใช้ร่วม จึงแยกด้วย ACL ที่ "อนุญาตเฉพาะบริการนี้" ไม่ได้ บัญชีเสมือนมีตัวตนเฉพาะต่อบริการ และระบุ NT SERVICE\ชื่อบริการบน ACL ได้โดยตรง ผลิตภัณฑ์ Microsoft รุ่นใหม่เช่น SQL Server ก็ใช้บัญชีเสมือนเป็นค่าเริ่มต้นเช่นกัน

ใช้ gMSA ในสภาพแวดล้อมเวิร์กกรุ๊ป (ไม่มีโดเมน) ได้หรือไม่

ไม่ได้ gMSA เป็นกลไกที่ตัวควบคุมโดเมน Active Directory สร้างและจัดการรหัสผ่าน โดเมนบวกการสร้างคีย์ราก KDS เป็นเงื่อนไข ในเวิร์กกรุ๊ปพื้นฐานคือจบการประมวลผลท้องถิ่นด้วยบัญชีเสมือนหรือ LocalService/NetworkService หากต้องเข้าถึงเครื่องอื่น ต้องออกแบบอย่างอื่น เช่นใช้ข้อมูลรับรองของบัญชีที่เตรียมไว้ที่ปลายทางอย่างชัดเจน การเข้าถึงเครือข่ายในฐานะบัญชีคอมพิวเตอร์ (PC$) ก็ใช้ได้เฉพาะในสภาพแวดล้อมโดเมน

หลังเปลี่ยนบัญชีล็อกออนของบริการ การตั้งค่าและข้อมูลรับรองที่บันทึกไว้ไม่ได้อ่านอีก ทำไม

เพราะแต่ละบัญชีล็อกออนผูกกับโปรไฟล์ผู้ใช้ %TEMP% HKEY_CURRENT_USER และคีย์ DPAPI ของตนเอง โดยเฉพาะข้อมูลที่ปกป้องด้วย DPAPI ขอบเขตผู้ใช้ (CryptProtectData และคล้ายกัน) ตามหลักถอดรหัสได้เฉพาะบัญชีเดียวกันที่ปกป้อง ไฟล์ที่บันทึกใต้โปรไฟล์ (AppData และคล้ายกัน) ก็เป็นเส้นทางอื่นจากบัญชีใหม่ ก่อนสลับบัญชี ให้วางแผนขั้นตอนสร้างข้อมูลที่ปกป้องด้วย DPAPI ใหม่ (กรอกคีย์ API ใหม่ เป็นต้น) และการย้ายไฟล์ใต้โปรไฟล์

ถ้าต้องการให้บริการเข้าถึงโฟลเดอร์แชร์อย่างเดียว ต้องใช้ผู้ใช้โดเมนหรือไม่

ในหลายกรณี ไม่ต้อง ในสภาพแวดล้อมโดเมน บริการที่รันเป็น LocalSystem, NetworkService หรือบัญชีเสมือนยืนยันตัวตนกับฝั่งไกลในฐานะบัญชีคอมพิวเตอร์ (DOMAIN\ชื่อคอมพิวเตอร์$) เพิ่ม PC$ นั้นเข้าสิทธิ์แชร์และสิทธิ์ NTFS ของโฟลเดอร์แชร์แล้วอ่านเขียนได้ หากต้องการควบคุมการเข้าถึงด้วยตัวตนเฉพาะบริการ หรือตัวตนเดียวกันบนหลายเซิร์ฟเวอร์ ให้พิจารณา gMSA แทนผู้ใช้โดเมน

โปรไฟล์ผู้เขียน

หน้าแนะนำผู้เขียนบทความ

Go Komura

ผู้แทนของ KomuraSoft LLC

เชี่ยวชาญด้านการพัฒนาซอฟต์แวร์ Windows ที่ปรึกษาเทคนิค และการตรวจสอบบั๊ก โดยเฉพาะโปรเจกต์ที่มีระบบเดิมและบั๊กที่ทำซ้ำได้ยาก