目前以 LocalSystem 執行的服務，應該立刻改掉嗎？

並非一律立刻變更才正確。先確認該服務是否真的需要 LocalSystem 級的本機權限（超出系統管理員的強特權）。若只是檔案讀寫與網路通訊，第一候選是改到虛擬帳戶（NT SERVICE\服務名稱）。移轉時請確認對所需資料夾與登錄機碼的存取授與、依賴設定檔或 DPAPI 的資料如何處理，以及是否具備「以服務身分登入」權利。在驗證環境確認啟動與主要功能後，再切換正式環境。

應該選虛擬帳戶還是 NetworkService？

新選時建議虛擬帳戶。兩者在網路上都顯示為電腦帳戶（DOMAIN\電腦名稱$），本機權限也都偏小。但 NetworkService 由多個服務共用，無法用 ACL 做到「只允許這個服務」。虛擬帳戶每個服務都有獨立身分，可在 ACL 上直接指定 NT SERVICE\服務名稱。SQL Server 等近年 Microsoft 產品的預設也是虛擬帳戶。

gMSA 能在工作群組環境（沒有網域）使用嗎？

不能。gMSA 是由 Active Directory 網域控制站產生並管理密碼的機制，前提是網域與建立 KDS 根金鑰。工作群組環境的基本做法是用虛擬帳戶或 LocalService/NetworkService 把本機處理做完。若需要存取另一台機器，就要改成明確使用目的端準備好的帳戶認證等其他設計。以電腦帳戶（PC$）進行的網路存取也只在網域環境成立。

改了服務的登入帳戶後，先前儲存的設定與認證就讀不到了。為什麼？

因為每個登入帳戶都綁定自己的使用者設定檔、%TEMP%、HKEY_CURRENT_USER 與 DPAPI 金鑰。尤其以使用者範圍 DPAPI（CryptProtectData 等）保護的資料，原則上只有當初保護它的同一個帳戶才能解密。存在設定檔底下（AppData 等）的檔案，對新帳戶也是另一條路徑。切換帳戶前，請規劃重新建立 DPAPI 保護資料的程序（例如重新輸入 API 金鑰）以及設定檔底下檔案的移轉。

只想讓服務存取共用資料夾，需要網域使用者嗎？

多數情況不需要。在網域環境中，以 LocalSystem、NetworkService 或虛擬帳戶執行的服務，會以電腦帳戶（DOMAIN\電腦名稱$）向遠端驗證。把該 PC$ 加到共用權限與 NTFS 權限即可讀寫。若要以服務專屬身分做存取控制，或在多台伺服器上需要同一身分，請考慮 gMSA 而不是網域使用者。

Windows 服務帳戶選定 ── LocalSystem、虛擬帳戶與 gMSA

2026年08月20日 00:30 · Go Komura · Windows, Windows 服務, 服務帳戶, gMSA, LocalSystem, 虛擬帳戶, 安全性, Active Directory, 最小權限

「我們『暫時』用 LocalSystem 跑的內部服務，在安全性稽核被點名『權限過大』。該改成什麼？」「服務存不到共用資料夾，所以用網域使用者在跑。密碼到期服務就停，於是設成永不到期，還把明文寫進操作手冊。」── 客戶 Windows 服務相關諮詢裡，這兩則是固定班底。

兩邊現場的共通點是：服務的登入帳戶被凍成「碰巧能跑的設定」，而不是設計決策。Windows 服務一定在某個帳戶的安全性內容中執行，那個帳戶決定它本機能做什麼、從網路另一端看起來是誰、密碼由誰管理。把這裡留在預設值，單一服務的弱點就直接變成整台機器被接管，明文密碼也散進操作手冊與指令碼。

flowchart TB
    accTitle: 登入帳戶決定的三件事
    accDescr: 服務一定在某個帳戶的安全性內容中執行，該帳戶決定本機能做什麼、從網路另一端看起來是誰、密碼由誰管理
    acct["服務的登入帳戶"] --> local["本機能做什麼"]
    acct --> net["從網路另一端看起來是誰"]
    acct --> pwd["密碼由誰管理"]

圖 1: 選定登入帳戶是同時決定本機權限、網路身分與密碼管理的設計決策。

實務上有六種選擇 ── LocalSystem、LocalService、NetworkService、虛擬帳戶（NT SERVICE\<服務名稱>）、網域使用者，以及 gMSA（群組受控服務帳戶）。本文面向中小企業資訊人員與 Windows 應用程式開發者，把這六種的權限、網路身分與密碼管理整理成一張表，並依 2026 年 8 月當下的 Microsoft Learn 一手資料整理到判斷流程。

服務本身怎麼做（與工作排程器的取捨、用 .NET Worker Service 實作）見「Windows 服務的建立與維運」。本文集中在出事最多的「登入帳戶」。

1. 先講結論

拿不定主意時，在單一機器內做完的服務以虛擬帳戶為第一候選；要以服務專屬身分存取網域內資源的服務以 gMSA 為第一候選。 Microsoft 也指導盡可能使用受控帳戶（MSA / 虛擬帳戶）。¹²
不要因為「能跑」就選 LocalSystem。 權杖含 SYSTEM 與 BUILTIN\Administrators，並持有 SeDebugPrivilege 等強特權，被接管就幾乎失去該機器上的一切。sc.exe create 預設是 LocalSystem，正是這類事故的溫床。³⁴
LocalService 與 NetworkService 的差別是網路身分。 本機權限兩者都最小，但對遠端來說 LocalService 是匿名，NetworkService 是電腦帳戶。⁵
**虛擬帳戶（NT SERVICE\<服務名稱>）是現代預設：不必管密碼，又能依服務分開身分。** 可在 ACL 上直接指定「NT SERVICE\\服務名稱」，SQL Server 的預設服務帳戶也是這個。[^understand-service-accounts][^sql-service-accounts]
LocalSystem、NetworkService 或虛擬帳戶走到網路上時，會變成電腦帳戶（DOMAIN\電腦名稱$）。 在共用資料夾或 SQL Server 的 ACL 授與 PC$，常常就能不用網域使用者。³⁶
把網域使用者用在服務上，會在密碼營運與 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	幾乎無限制（SYSTEM+Administrators）	電腦帳戶（PC$）	不需要（無密碼）	與作業系統一體運作的例外服務
LocalService	最小（Users 級）	匿名	不需要	不需要網路身分的本機處理
NetworkService	最小（Users 級）	電腦帳戶（PC$）	不需要	機器級身分就夠用的低權限處理
虛擬帳戶 NT SERVICE\<名稱>	最小 + 在 ACL 個別授與	電腦帳戶（PC$）	不需要（自動管理）	跑在單一伺服器上的業務服務預設
網域使用者	只限你授與的	該使用者本身	手動（到期、外洩、輪替都交給人）	不支援 gMSA 的應用程式的最後手段
gMSA	只限你授與的	該 gMSA 本身	AD 自動產生並輪替	網域環境需要服務專屬身分時

LocalSystem、LocalService、NetworkService、虛擬帳戶都 完全沒有密碼這個概念。用 SCM 儲存的密碼登入（= 可能到期與外洩）的只有網域使用者與本機使用者。⁷³

下面依列逐一深入。

3. LocalSystem 有什麼問題

3.1. 比「以系統管理員身分執行」更強

LocalSystem（顯示名稱 Local System，NT AUTHORITY\SYSTEM）是 SCM 使用的預先定義帳戶，在本機電腦持有廣泛權限。權杖含 NT AUTHORITY\SYSTEM 與 BUILTIN\Administrators 的 SID，可存取系統上大多數物件。此外，可偵錯其他處理程序的 SeDebugPrivilege，以及作為作業系統一部分運作的 SeTcbPrivilege，預設就已啟用。³

這份強大等同於被接管時的傷害規模。以 LocalSystem 執行的服務只要有一個任意程式碼執行弱點，攻擊者一口氣就能讀改該機器上所有使用者的檔案（SYSTEM 在 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. 為什麼還是被選

理由很單純：它是預設值，而且不會出現存取被拒。sc.exe create 省略 obj= 時預設是 LocalSystem，⁴ 許多舊範例程式與安裝程式範本仍假設 LocalSystem。開發期間可以遠離權限錯誤，於是大量產出「能跑就先這樣」的結構。Microsoft 自己的文件也寫道，多數服務不需要這麼高的權限層級，若不需要就應考慮 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 叫成「Windows 最強帳戶」並不準確。Windows Vista 起的 Windows 資源保護（WRP）只允許 TrustedInstaller（Windows Modules Installer 服務）變更重要的作業系統系統檔、資料夾與登錄機碼，連 SYSTEM 或系統管理員改寫都會存取被拒。¹² Explorer 的「您需要來自 TrustedInstaller 的權限」就是這個機制。反過來說，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 什麼時候需要系統管理員權限」）。

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. 可在 ACL 上直接寫「NT SERVICE\服務名稱」

實務上的方便是 可以依名稱只把該服務加進 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"

在 GUI 裡，於 services.msc 開啟服務內容 →「登入」索引標籤 → 在「此帳戶」輸入 NT SERVICE\服務名稱，密碼欄留空（虛擬帳戶或 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: 在網域環境，只要在目的端 ACL 授與 PC$，不必網域使用者也能建立遠端存取。

檔案伺服器端的授與與一般 ACL 操作相同；帳戶名稱指定 電腦名稱$（GUI 物件選擇對話方塊請把物件類型含「電腦」）。

# 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$ 做法的極限

這種做法有兩個極限。

粒度是整台機器。 同一機器上的 LocalSystem、NetworkService 與所有虛擬帳戶服務，從遠端看起來都是同一個 PC$。無法在目的端「只允許這個服務」，也無法稽核是哪個服務用了該帳戶。²
工作群組環境不能用。 電腦帳戶是 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 不管到期，所以 密碼到期登入就失敗，服務不會啟動。⁷

從那裡開始，現場常見的負向螺旋出現。

發生因到期而服務停止的事故
為防再發，設成「密碼永不到期」
變更程序從未建立，同一密碼以明文寫進多台伺服器的操作手冊、指令碼與工作排程器
即使有人離職也不改密碼（一改就不知道什麼會停）

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（服務主體名稱）。網域內任何已驗證使用者都能向已登錄 SPN 的帳戶要求服務票證，攻擊者取得票證後離線暴力破解密碼。人類決定的 10 到 16 字元密碼擋不住這次攻擊。

flowchart TB
    accTitle: Kerberoasting 的流程
    accDescr: 對已登錄 SPN 的服務帳戶的服務票證，任何已驗證使用者都能要求，攻擊者取得票證後離線暴力破解密碼
    atk["網域內已驗證的使用者"] --> req["要求該 SPN 的票證"]
    req --> tkt["取得服務票證"]
    tkt --> brute["離線暴力破解"]
    brute --> weak["大約 10 到 16 字元就會被破解"]

圖 13: 任何已驗證使用者都能要求票證，人類決定長度的密碼擋不住離線暴力破解。

有效對應是 把密碼做成人類猜不到也破解不了的強度。Microsoft 也列出強制長密碼，以及使用密碼為機器產生長隨機值的 gMSA。⁸ 同一文件也提到 Kerberos 裝甲（FAST），但 FAST 保護預先驗證資料與對抗 KDC 詐騙；它並不阻止已驗證使用者向 SPN 要求服務票證，因此不能替代服務帳戶的密碼強度。SPN 與 Kerberos 的關係、驗證退回 NTLM 的條件，圖解於「圖解NTLM與Kerberos」。

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 系列帳戶不能用於互動式登入。¹ 之後在共用資料夾或 SQL Server 的 ACL 授與 CORP\svc-batch$ 取代 PC$，以服務專屬身分的網路存取就完成了，而且不必密碼。

8.4. 有些應用程式不支援

要注意的是，不是每套軟體都能以 gMSA 執行。透過標準機制設定登入身分的 ── Windows 服務、IIS 應用程式集區、工作排程器工作 ── 支援面很廣，但也有限制，例如容錯移轉叢集本身不支援 gMSA，以及內部要求密碼的應用程式不能用。¹⁰ Microsoft 也明白寫道，正式上線前應在測試環境確認以 gMSA 執行的行為。⁹

flowchart TB
    accTitle: 如何判斷是否支援 gMSA
    accDescr: 透過標準機制設定登入身分的應用程式廣泛支援 gMSA，但容錯移轉叢集與內部要求密碼的應用程式不能用，因此正式上線前要在測試環境確認
    app["目標應用程式"] --> how{"登入怎麼設定？"}
    how -->|標準機制| okapp["支援 gMSA"]
    okapp -.-> ex1["服務、IIS、工作"]
    how -->|要求密碼| ngapp["不能用 gMSA"]
    ngapp -.-> ex2["容錯移轉叢集"]
    okapp --> test["正式上線前測試"]

圖 17: 透過標準機制設定登入的應用程式廣泛支援，但也有不支援的設計，正式上線前的驗證不可或缺。

還有兄弟帳戶：單一伺服器的 sMSA（獨立受控服務帳戶），以及 Windows Server 2025 導入、綁定裝置身分以對抗認證竊取的 dMSA（委派受控服務帳戶）。新建時以 gMSA 為基準，再依需求考慮。⁶

9. 隨附設計 ── 登入權利、設定檔、DPAPI、稽核

還有四件會隨帳戶改變的事要記住。

9.1. 「以服務身分登入」權利（SeServiceLogonRight）

要以服務啟動，帳戶需要「以服務身分登入」使用者權利。LocalSystem、LocalService、NetworkService 內建就有，但 其他帳戶（網域使用者、gMSA 等）需要明確指派。¹⁵

若從 services.msc GUI 的「登入」索引標籤設定，嵌入式管理單元會自動授與此權利。另一方面，CreateService / ChangeServiceConfig（sc.exe config 呼叫的 API）並不驗證指定帳戶是否有此權利。用指令碼設定的服務在啟動時以「因登入失敗而無法啟動服務」停下，典型原因就是這個。不要依賴工具的副作用；把明確加入本機安全性原則（secpol.msc）的「以服務身分登入」，或透過 GPO/Intune 設定，寫進部署程序（若此權利由群組原則設定，原則套用時會覆寫本機授與，這一點也要注意）。反過來說，服務專用帳戶的標準動作是一併設定「拒絕本機登入」。

flowchart TB
    accTitle: 「以服務身分登入」權利因設定路徑而異
    accDescr: services.msc GUI 會自動授與權利，但 sc.exe config 呼叫的 API 不驗證權利，沒有權利的帳戶會在啟動時因登入失敗而停下
    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 或 .NET 的 ProtectedData）加密的資料，原則上只有當初保護它的同一個帳戶才能解密。一改帳戶，存好的連線字串或 API 金鑰就讀不到 ── 那是 DPAPI 在正確做事，但若不在移轉程序裡就會變成事故。

flowchart TB
    accTitle: DPAPI 保護資料與帳戶變更的關係
    accDescr: 以使用者範圍 DPAPI 保護的資料只能由當初保護它的同一個帳戶解密，因此變更登入帳戶後需要重新輸入祕密
    protect["用舊帳戶做 DPAPI 保護"] --> data["受保護的連線字串等"]
    data --> who{"哪個帳戶在解密？"}
    who -->|同一個舊帳戶| okdec["能解密"]
    who -->|新帳戶| ngdec["不能解密"]
    ngdec --> re["重新輸入祕密"]

圖 20: DPAPI 保護的資料綁在當初保護它的帳戶上，帳戶切換後需要重新輸入。

對應是把「帳戶切換後重新輸入祕密」寫進移轉計畫（儲存在哪裡的設計見「Windows 應用程式不要把機密資訊以明文存進設定檔的最佳實踐」）。此外，能用 gMSA 或 PC$ 以 Windows 整合式驗證做完的組態，可以根本不必儲存祕密。正確順序是先考慮「能否不存」，再考慮「存在哪裡」。

若服務想「以呼叫者的權限」處理，不要把帳戶變得更強，而是用模擬。那見「正確處理 Windows 偽裝權杖」。

9.4. 稽核 ── 看 4624 登入類型 5

服務啟動會以事件識別碼 4624（帳戶已成功登入）的 登入類型 5（Service：SCM 啟動了服務） 寫入安全性事件記錄。事件中的「Virtual Account」欄位指出登入是否由 MSA / 虛擬帳戶進行，也可用來監看受控帳戶的使用。¹¹

flowchart TB
    accTitle: 稽核服務啟動的流程
    accDescr: SCM 啟動服務會記錄為事件識別碼 4624 登入類型 5，Virtual Account 欄位可識別是否為受控帳戶登入
    start["SCM 啟動服務"] --> ev["記錄事件識別碼 4624"]
    ev --> type5["登入類型 5（Service）"]
    type5 --> vafield["Virtual Account 欄位"]
    vafield --> watch["監看受控帳戶"]

圖 21: 服務啟動記錄為登入類型 5 的 4624，連受控帳戶的使用都能追蹤。

現況盤點的快方法是彙總服務清單的登入帳戶。

# 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{"對端要 Windows 驗證？"} -->|否| va["虛擬帳戶"]
    va -.-> sys["需要時用 LocalSystem"]
    q1 -->|是| q2{"已加入網域？"}
    q2 -->|否| cred["保護儲存的認證"]
    q2 -->|是| q3{"機器級就夠？"}
    q3 -->|是| pcacl["虛擬帳戶 + PC$"]
    q3 -->|否| q4{"應用程式支援 gMSA？"}
    q4 -->|是| gmsa["gMSA"]
    q4 -->|否| du["使用者 + 緩解"]

圖 22: 依序回答四個問題，六種選擇該用哪一種就定了。

問題 1：該服務是否以 Windows 驗證存取網路上的另一台機器（共用資料夾、資料庫、API 等）？

若否，虛擬帳戶是預設。只有需要特殊本機權限時，先確認需求再考慮 LocalSystem。

問題 2：（若有存取）機器是否已加入網域？

工作群組既不能用 PC$ 也不能用 gMSA。使用明確處理目的端帳戶認證的設計（用 DPAPI 等保護儲存），或考慮加入網域。

問題 3：（在網域內）機器級身分（PC$）夠用嗎？

夠用就 虛擬帳戶（或 NetworkService）+ 在目的端 ACL 授與 PC$ 即完成。若需要服務專屬身分，或跨多台伺服器的共同身分，進問題 4。

問題 4：應用程式支援 gMSA 嗎？

支援（透過標準機制設定登入的 ── SCM、IIS 應用程式集區、工作排程器 ── 一般支援）就用 gMSA。別忘了在驗證環境做行為檢查。再怎樣都不支援，就在套用 7.3 節全部緩解後使用 專用網域使用者。

做成表如下。

狀況	建議	備註
僅本機、一般權限	虛擬帳戶	把 ACL 授與 `NT SERVICE\<名稱>`
僅本機、需要超出系統管理員的權限	LocalSystem	先驗證權限需求
不需要網路身分的本機處理	LocalService	維持既有服務現狀時可接受
以機器身分存取網域內資源	虛擬帳戶（或 NetworkService）	在目的端 ACL 授與 `PC$`
以服務專屬身分存取網域內資源	gMSA	KDS 根金鑰 + 確認支援
多台伺服器同一身分（負載平衡等）	gMSA	虛擬帳戶做不到
不支援 gMSA 的應用程式 + 需要特定身分	專用網域使用者	需要 7.3 節的緩解
工作群組 + 需要遠端存取	保護並儲存明確認證	也考慮重新檢視設計

11. 總結

服務的登入帳戶是同時決定本機權限、網路身分與密碼管理的設計決策。不要留在預設（LocalSystem）。
LocalSystem 持有 SYSTEM+Administrators 權杖與強特權，被接管時傷害最大化。多數業務服務不需要這個權限。
LocalService 與 NetworkService 都是低權限；差別是網路身分（匿名，或電腦帳戶）。但帳戶由多個服務共用，因此分不開。
虛擬帳戶（NT SERVICE\<服務名稱>）是現代預設：不必管密碼又能依服務分開。可直接指定到 ACL，設定只需改登入帳戶名稱。
LocalSystem、NetworkService、虛擬帳戶在網域環境走上網路時是 DOMAIN\PC$。在共用資料夾或 SQL Server 的 ACL 授與 PC$，常常就能不用網域使用者。
把網域使用者用在服務上，有到期停擺、明文密碼擴散、Kerberoasting 這些結構性問題。若要用，需要專用帳戶 + 長隨機密碼 + 登入限制。
gMSA 是 AD 自動產生並輪替密碼的機制；要件是網域、功能等級 2012 或更高、KDS 根金鑰。服務設成「DOMAIN\名稱$」且密碼欄留空。
改帳戶時，把「以服務身分登入」權利、設定檔與 %TEMP% 的搬移、DPAPI 保護資料的重新輸入寫進移轉程序。稽核可用事件識別碼 4624 登入類型 5 確認。

下次安裝服務時，在登入設定畫面停一下，再問一次。這個服務應該以誰的身分、存取到多遠？ 答案應該是本文判斷表的某一列。

參考連結

Microsoft Learn, Configure Windows service accounts and permissions. SQL Server 的預設服務帳戶是虛擬帳戶（NT SERVICE\MSSQLSERVER 等）、指定虛擬帳戶或 MSA 時密碼欄留空、MSA 名稱結尾為 $ 且不能用於互動式登入、Local Service 是共用帳戶故分不開且 SQL Server 不支援、使用網域帳戶在密碼與 SPN 的手動管理上耗費力氣且維護可能導致服務停止，以及應一律以最小權限帳戶執行服務。 ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶
Microsoft Learn, Securing on-premises service accounts. 內部部署服務的優先順序是先 gMSA、不能用再用 sMSA、然後電腦帳戶、最後使用者帳戶；使用電腦帳戶時無法得知哪個服務在用該帳戶也不能稽核變更；以及服務帳戶的角色（識別、驗證並啟動服務）。 ↩ ↩² ↩³
Microsoft Learn, LocalSystem Account. LocalSystem 在本機電腦持有廣泛權限且權杖含 NT AUTHORITY\SYSTEM 與 BUILTIN\Administrators 的 SID、沒有密碼、向遠端伺服器出示電腦的認證、含 SE_DEBUG_NAME 與 SE_TCB_NAME 的特權清單，以及多數服務不需要這個權限層級、應考慮使用 LocalService/NetworkService。 ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶
Microsoft Learn, sc.exe config. 用 obj= 參數指定服務的登入帳戶、預設是 LocalSystem，以及使用 LocalSystem 以外的使用者帳戶時的 password= 參數。 ↩ ↩²
Microsoft Learn, Local accounts. SYSTEM（S-1-5-18）在 NTFS 磁碟區預設具有完全控制、NETWORK SERVICE（S-1-5-20）向遠端伺服器出示電腦的認證，以及 LOCAL SERVICE（S-1-5-19）本機權限最小、向網路出示匿名認證。 ↩ ↩² ↩³ ↩⁴
Microsoft Learn, Service accounts. 虛擬帳戶是不需密碼管理的自動管理本機帳戶、名稱為 NT SERVICE<SERVICENAME> 形式、在網域環境以電腦帳戶認證（\$）存取網路，以及在 sMSA、gMSA、dMSA、虛擬帳戶之間選擇的準則。 ↩ ↩² ↩³ ↩⁴
Microsoft Learn, Service User Accounts. 服務在使用者帳戶的安全性內容中執行、SCM 在啟動時登入帳戶並把存取權杖關聯到服務處理程序、SCM 載入使用者設定檔，以及 SCM 不管密碼到期，到期會讓登入失敗、服務無法啟動。 ↩ ↩² ↩³ ↩⁴ ↩⁵
Microsoft Learn, Protect SMB traffic from interception. 包含以 gMSA 作為服務帳戶保護（機器產生的長隨機密碼使暴力破解或字典攻擊不實際）、強制長密碼，以及提及 Kerberos 裝甲（FAST）等建議。 ↩ ↩²
Microsoft Learn, Secure group managed service accounts. gMSA 密碼是難以暴力破解或字典攻擊的 240 位元組隨機產生、Windows 作業系統每 30 天變更密碼故系統管理員不必規劃變更或停止服務、部署到伺服器陣列與更單純的 SPN 管理、若服務不支援 gMSA 就用 sMSA、再不行就用有強密碼管理的標準使用者帳戶，以及正式上線前應在測試環境確認以 gMSA 執行的行為。 ↩ ↩² ↩³
Microsoft Learn, Manage group Managed Service Accounts. gMSA 前提（網域/樹系功能等級 2012 或更高、建立 KDS 根金鑰）、gMSA 名稱必須在樹系內唯一、密碼變更間隔只能在建立時設定、用 New-ADServiceAccount 的 -PrincipalsAllowedToRetrieveManagedPassword 指定獲准取回密碼的群組、Install-ADServiceAccount/Test-ADServiceAccount 程序、虛擬帳戶身分是機器本機且網域認不出、容錯移轉叢集不支援 gMSA，以及 SCM、IIS 應用程式集區、工作排程器支援把登入設成 gMSA。 ↩ ↩² ↩³ ↩⁴ ↩⁵
Microsoft Learn, 4624(S): An account was successfully logged on. 建立登入工作階段時事件 4624 記錄在被存取的電腦上、登入類型 5 表示服務（SCM 啟動服務），以及「Virtual Account」欄位可識別 MSA 或虛擬帳戶的登入，可用來監看受控服務帳戶。 ↩ ↩²
Microsoft Learn, About Windows Resource Protection. Windows 資源保護（WRP）防止重要系統檔、資料夾與登錄機碼被取代、對 WRP 保護資源的完全存取限於 TrustedInstaller 且變更只能透過 Windows Modules Installer 服務的支援取代機制進行，以及試圖變更受保護資源的應用程式會收到存取被拒。 ↩
Microsoft Learn, Group Managed Service Accounts overview. gMSA 是把密碼管理交給 Windows 的網域帳戶、網域控制站從 Key Distribution Service（kdssvc.dll）共用祕密計算密碼且成員主機向網域控制站查詢目前與先前密碼，以及它讓伺服器陣列能以同一主體互相驗證。 ↩
Microsoft Learn, Create a Key Distribution Service (KDS) root key. 網域控制站開始產生 gMSA 密碼需要根金鑰、用 Add-KdsRootKey -EffectiveImmediately 建立的程序、建立後最多 10 小時因等待 AD 複寫收斂而不能建立 gMSA，以及複寫不完整可能讓密碼取回失敗。 ↩
Microsoft Learn, Policy CSP - UserRights: LogOnAsService. 「以服務身分登入」權利讓安全性主體能以服務登入、Local System、Local Service、Network Service 內建此權利、以其他帳戶執行的服務需要指派此權利，以及群組原則設定路徑。 ↩

共用相同標籤的最新文章。能以相近的主題延伸理解。

與本主題相關的服務

本文連結到以下服務頁面，歡迎從最接近的入口查看。

Windows 應用程式開發

支援包含常駐處理、設備連動、運作日誌與可維護結構的 Windows 桌面應用程式。

查看服務聯絡我們

常見問題

整理諮詢這個主題時常見的問題。

目前以 LocalSystem 執行的服務，應該立刻改掉嗎？: 並非一律立刻變更才正確。先確認該服務是否真的需要 LocalSystem 級的本機權限（超出系統管理員的強特權）。若只是檔案讀寫與網路通訊，第一候選是改到虛擬帳戶（NT SERVICE\服務名稱）。移轉時請確認對所需資料夾與登錄機碼的存取授與、依賴設定檔或 DPAPI 的資料如何處理，以及是否具備「以服務身分登入」權利。在驗證環境確認啟動與主要功能後，再切換正式環境。
應該選虛擬帳戶還是 NetworkService？: 新選時建議虛擬帳戶。兩者在網路上都顯示為電腦帳戶（DOMAIN\電腦名稱$），本機權限也都偏小。但 NetworkService 由多個服務共用，無法用 ACL 做到「只允許這個服務」。虛擬帳戶每個服務都有獨立身分，可在 ACL 上直接指定 NT SERVICE\服務名稱。SQL Server 等近年 Microsoft 產品的預設也是虛擬帳戶。
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

小村軟體有限公司代表

以 Windows 軟體開發、技術諮詢與故障調查為中心，在難以重現的故障調查與既有資產仍在運作的專案上具有優勢。

查看檔案聯絡我們

公開連結

ORCID GitHub LinkedIn X COM_BLAS COM_BigDecimal

回到部落格一覽