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

「以 LocalSystem 執行的服務，在稽核中被指出權限過大。到底該改成什麼？」「為了連接共用資料夾而使用網域使用者，但密碼一到期服務就停掉。」── 這兩種都是典型的諮詢，發生在服務的執行帳戶不是設計判斷，而是被「碰巧能跑的設定」原樣固定下來的時候。

選擇執行帳戶時，要把在這台電腦裡能做什麼、從目的端看起來是誰、密碼由誰管理分開來思考。把本機權限調強，和能夠通過驗證連上共用資料夾，並不是同一件事。¹²

本文的結論是：在單一電腦內就能完成的業務服務以虛擬帳戶為第一候選，網域內需要服務專屬身分時則以 gMSA 為第一候選。以「不讓服務持有人用密碼」的組態為基本，網域使用者留作最後手段。不過不要把既有服務一律立刻變更，而是要確認所需權限與移轉時的影響。³⁴

本文的讀者是中小企業的資訊人員與 Windows 應用程式開發者。原文依 2026 年 8 月當下的 Microsoft Learn 所做的說明，本文按選定 → 本機權限 → 網路身分 → 導入 gMSA → 切換與稽核的順序整理。服務本身怎麼做，請參閱「Windows 服務的建立與維運」。

1. 先做選擇：6 種帳戶與 4 個問題

1.1 比較的軸線是「權限、身分、密碼管理」

服務啟動時，服務控制管理員（SCM）會以設定好的帳戶登入。登入成功後會把存取權杖指派給服務處理程序，之後對檔案與管道的存取，都以該權杖與存取控制清單（ACL）比對來判定。所謂選擇執行帳戶，就是決定要交給服務的權杖裡有什麼。¹

表中以 PC$ 進行的網路驗證以網域環境為前提。在工作群組中無法使用同樣的方法。另外，LocalSystem 也有 WRP 保護區域等限制。請不要把「幾乎不受限」理解成字面上的無限制。⁵⁶²⁷

使用 LocalSystem、LocalService、NetworkService、虛擬帳戶時，使用者不需要為服務設定與管理密碼。相對地，使用網域使用者或本機使用者的組態，儲存在 SCM 裡的密碼的到期與變更要由人管理。gMSA 的密碼本身雖然存在，但把管理交給 AD。¹⁸

1.2 選定按 4 個問題推進

先確認是否要以 Windows 驗證連接其他電腦，若需要，再依序判斷是否加入網域、電腦層級的身分是否夠用、應用程式是否支援 gMSA。

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["專用使用者+緩解措施"]

圖 1：在本機就能完成的話就用虛擬帳戶。網域內 PC$ 的粒度不夠時，就往 gMSA 前進。工作群組則要另外設計認證資料。

既有由 LocalService 承擔的本機處理，以及由 NetworkService 承擔的電腦層級存取，沒有理由就不必全部換掉。新做選擇時，以能同時兼顧低權限與服務層級隔離的虛擬帳戶為基本。

圖中實線表示始終成立的關係，虛線表示附帶條件的關係（成立條件寫在詳細頁面中各關係的說明中）。關係的完整清單（共 19 條，附依據與可信度）以及主要概念的定義，彙整在知識地圖詳細頁面（日文）。資料：JSON-LD / Turtle

2. 決定電腦內的權限：以虛擬帳戶為基本

2.1 LocalService 與 NetworkService 的網路身分不同

LocalService 與 NetworkService 是為低權限服務準備的內建帳戶。兩者在本機都以大致相當於 Users 群組成員的最小權限執行。不同的是向遠端出示的認證資料。⁶³

不會走到網路上、或對方不要求身分時用 LocalService；網域內需要電腦的身分時用 NetworkService，兩者就是這樣分工。

不過要注意，兩者都是多個服務共用同一個帳戶。只要 ACL 授與的對象是那個共用帳戶，就無法逐一區分服務。若有 5 個服務以 LocalService 執行，授與該帳戶的資源，這 5 個全都存取得到。SQL Server 不支援 Local Service 的理由，也是因為共用帳戶無法與其他服務隔離。³

2.2 虛擬帳戶可以逐一服務授與 ACL

虛擬帳戶是從 Windows Server 2008 R2 / Windows 7 起可用的受管理本機帳戶。名稱是 NT SERVICE\<服務名稱>。不需要建立帳戶，也不需要設定密碼，每一個服務都有專屬的身分。在網域環境中的網路存取，使用電腦帳戶的認證資料。²

也就是說，它保留了 LocalService、NetworkService「不必管理密碼」的優點，同時消除了帳戶被共用的弱點。SQL Server 安裝程式預設使用 NT SERVICE\MSSQLSERVER 之類的帳戶，也是同一個思路。³

實務上的好處是可以在 ACL 中直接指定那個服務。不必增加群組的建立與密碼管理，就能設定成「把這個存放資料的資料夾的修改權限，授與這個服務」。

下面是把既有的 MyAppService 切換到虛擬帳戶的例子。執行前請先確認第 7 章的登入權利、資料存放位置與 DPAPI，並在驗證環境確認啟動與主要功能。

# 把服務的登入帳戶改為虛擬帳戶
# 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 的服務內容 →「登入」索引標籤，把帳戶名稱填成 NT SERVICE\服務名稱，並讓密碼欄位保持空白。虛擬帳戶與 MSA 不指定密碼。變更會在重新啟動服務後生效。³

即使在本機擁有專屬的身分，也不代表在網路另一端就能區分服務。這個限制會在第 3 章說明。

2.3 LocalSystem 不是因為「跑得動」而選，要依所需的特殊權限判斷

LocalSystem（NT AUTHORITY\SYSTEM，顯示名稱為本機系統）是 SCM 使用的預先定義帳戶。權杖中包含 NT AUTHORITY\SYSTEM 與 BUILTIN\Administrators 的 SID，具有廣泛的本機權限。SeDebugPrivilege、SeTcbPrivilege 等強大的特殊權限預設也是啟用的。⁵

這份強大同時也是被入侵時的損害規模。如果以 LocalSystem 執行的服務存在任意程式碼執行的漏洞，就可能成為讀取與竄改所有使用者檔案、讀取其他處理程序記憶體、竊取認證資料並橫向移動的起點。在 NTFS 上，SYSTEM 預設擁有完全控制。⁶ 認證資料竊取與橫向移動的關係，在「圖解NTLM與Kerberos」「Windows LAPS 實務指南」中也有處理。

即便如此，LocalSystem 仍持續被選用，是因為它是 sc.exe create 省略 obj= 時的預設值，而且在舊的範例與安裝程式範本中大量殘留。開發過程中不容易碰到權限錯誤，常常就變成「跑得動就先這樣」。但 Microsoft 也說明，絕大多數服務並不需要這種特殊權限等級，不需要時應考慮 LocalService 或 NetworkService。⁹⁵

即使是 LocalSystem，也不是什麼都能無條件變更。Windows Vista 之後的 Windows 資源保護（WRP）把重要系統檔案、資料夾與登錄機碼的變更限制給 TrustedInstaller（Windows Modules Installer 服務）。即使是 SYSTEM 或系統管理員，一般的改寫也會被拒絕存取。「您需要 TrustedInstaller 的權限」就是這個機制。⁷

即使有這個限制，LocalSystem 對業務服務而言權限過大這一點並沒有改變。合理的例外是與裝置驅動程式緊密搭配、操作作業系統的安全性基礎、管理其他服務或工作階段等，所需特殊權限本來就超過系統管理員等級的處理。備份代理程式與 EDR 之類，才會真的碰到這種必要性。

即使屬於例外，也要確認是否真的有用到特殊權限的程式碼路徑，能不能只把必要的部分分離出來。判斷方式請參閱「Windows 什麼時候需要系統管理員權限」。

3. 決定目的端看到的身分：PC$ 夠不夠用

3.1 只是連接共用資料夾的話，多數情況不需要網域使用者

在已加入網域的電腦上，使用 LocalSystem、NetworkService、虛擬帳戶的服務，對遠端會以 DOMAIN\電腦名稱$ 通過驗證。服務存取不了共用資料夾，有時只是因為目的端的 ACL 沒有允許這個 PC$。⁵²

這裡需要的不是把服務的本機權限調強，而是在目的端允許正確的身分。共用資料夾要同時設定共用權限與 NTFS 權限。

下面是在檔案伺服器端，給 APPSV01 上的服務授與修改權限的例子。在 GUI 選擇帳戶時，要在「物件類型」中包含「電腦」。

# 檔案伺服器端：給 APPSV01 上的服務授與共用資料夾的修改權限
# 共用權限與 NTFS 權限兩邊都需要授與
Grant-SmbShareAccess -Name "AppData" -AccountName "CORP\APPSV01$" -AccessRight Change -Force
icacls "D:\Shares\AppData" /grant "CORP\APPSV01$:(OI)(CI)M"

在 SQL Server 上，把電腦帳戶註冊為 Windows 登入的思路也一樣。連接字串使用 Integrated Security=true，服務端不必持有網域使用者的密碼就能連線。

-- 資料庫伺服器端：允許來自 APPSV01 上服務的 Windows 整合式驗證
CREATE LOGIN [CORP\APPSV01$] FROM WINDOWS;

這只是資料庫伺服器端建立 Windows 登入那一段的例子。在目的端授與必要權限的原則，和共用資料夾沒有不同。

3.2 用 PC$ 無法做到逐一服務的授權與稽核

虛擬帳戶的身分是電腦本機的，網域並不認得它。走上網路後會收斂成 PC$，因此光靠帳戶無法區分請求來自同一台電腦上的哪個服務。¹⁰⁴

flowchart TB
    accTitle: 虛擬帳戶的身分在電腦之外會收斂
    accDescr: 在電腦內每個服務各有專屬的虛擬帳戶，走上網路後會收斂成電腦帳戶，遠端分不出是哪個服務
    vaa["虛擬帳戶A"] --> pc["電腦帳戶PC$"]
    vab["虛擬帳戶B"] --> pc
    pc --> remote["遠端看到的身分"]
    remote -.-> nodist["分不出是哪個服務"]

圖 2：即使在電腦內能逐一服務隔離，目的端看到的仍是同一個 PC$。本機的隔離和網路上的隔離是兩個不同的判斷。

這種做法有兩個極限。

想在多台伺服器之間共用同一身分時，各台電腦不同的 PC$ 或虛擬帳戶同樣不夠。在網域內一旦需要服務專屬、多台伺服器共通的身分，就要比網域使用者更早考慮 gMSA，這是本文的方針。gMSA 同樣不是能在工作群組中使用的東西。

4. gMSA 的角色：擁有專屬身分，把密碼管理交給 AD

4.1 把密碼的產生、發佈與更新和人切開

gMSA（群組受管理服務帳戶）是把密碼管理交給網域控制站的網域帳戶。網域控制站從 KDS（金鑰發佈服務）的根金鑰計算出密碼，只有獲准的主機才能取得並用於服務。⁸

flowchart TB
    accTitle: gMSA 的密碼管理機制
    accDescr: 網域控制站從 KDS 的根金鑰計算出密碼，只有獲准的主機能取得並用於執行服務，密碼預設每 30 天自動輪替
    kds["KDS 根金鑰"] --> dc["DC 計算密碼"]
    dc --> host["獲准的主機取得"]
    host --> svc["用於執行服務"]
    dc -.-> rot["預設每 30 天自動輪替"]

圖 3：即使人不知道密碼，也能用獲准主機取得、會自動更新的認證資料來維運服務。

這些就是比手動管理的網域使用者更優先選擇 gMSA 的理由。¹¹ 若把 Windows LAPS 理解成把本機系統管理員密碼的管理自動化，而 gMSA 負責服務帳戶的密碼管理，就比較容易掌握兩者的定位。兩者是針對不同對象的機制。

4.2 不要省略應用程式的支援確認

gMSA 廣泛支援 Windows 服務、IIS 應用程式集區、工作排程器等以標準機制設定登入身分的項目。但是，並非所有應用程式都能使用。內部要求輸入密碼的做法就無法使用，容錯移轉叢集本身也不支援 gMSA，這類限制都存在。¹⁰

一旦列為候選，就要在投入正式環境之前，於測試環境確認「能以 gMSA 啟動」與「能存取必要的資源」。這也是 Microsoft 要求的步驟。¹¹

相關的選項還有給單一伺服器用的 sMSA（獨立受管理服務帳戶），以及 Windows Server 2025 導入的 dMSA（委派受管理服務帳戶）。dMSA 把驗證與裝置識別綁在一起，是用來對抗認證資料竊取的機制。新的組態以 gMSA 為基本，再依需求一併考慮這些選項。²

5. 導入 gMSA：從前提確認到服務設定

5.1 要先確認的需求

gMSA 名稱與變更間隔也是導入前要決定的事項。等帳戶建好才思考，就得重做一次。¹⁰

5.2 確認 KDS 根金鑰，沒有就建立

建立 KDS 根金鑰在一個樹系中只需做一次。先確認既有的金鑰，只在尚未建立時才新增。

# 以網域系統管理員身分，在網域控制站（或裝有 AD PowerShell 模組
# 的管理用電腦）上執行

# 確認有沒有 KDS 根金鑰，沒有就建立（一個樹系只做一次）
Get-KdsRootKey
Add-KdsRootKey -EffectiveImmediately   # 實際能用最多要等 10 小時之後

即使指定了 -EffectiveImmediately，也不一定建立後立刻就能用。因為要等待複寫到所有網域控制站，建立後最多有 10 小時的等待時間，其間無法建立 gMSA。這是為了避免在複寫還不完整時就去取得密碼而出問題。請把這段時間也納入導入計畫。¹²

5.3 限縮允許取得密碼的主機，並設定 gMSA

步驟分為 4 個階段。前半是 AD 端的設定，後半是執行服務的各台伺服器端的作業。¹⁰

執行下面的例子之前，也要一併設定 7.1 的「以服務方式登入」權利。sc.exe config 執行成功，和服務能夠登入，是兩回事。

# ① 建立允許取得密碼的安全性群組，
#    並把執行服務的伺服器的電腦帳戶加進去
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 系列的帳戶無法用於互動式登入。³

在目的端的共用資料夾與 SQL Server 上，改以 CORP\svc-batch$ 取代 PC$ 授與必要的權限。這樣就形成了不必由人管理密碼、以服務專屬身分進行網路存取的組態。不要只做完 Test-ADServiceAccount 的取得確認就收工，請一直驗證到實際服務的主要功能。

6. 網域使用者是最後手段：要用就把緩解措施配齊

6.1 避開到期，反而把另一種風險固定下來

把網域使用者或本機使用者指派給服務後，SCM 會儲存密碼，並在每次啟動時用它登入。但是，SCM 不管理到期。儲存的密碼一旦到期，登入就會失敗，服務也就無法啟動。¹

接著就出現惡性循環：為了避免到期出問題而改成永不到期，同一組密碼以明文留在多台伺服器的操作手冊、指令碼與工作裡，最後因為「不知道改了之後哪裡會停」，即使有人離職也不敢變更。

Microsoft 也指出，在服務上使用網域帳戶的組態，密碼與 SPN 的手動管理會耗費維運工時，而維護作業本身可能導致服務停止。只是設成永不到期，並不能消除管理上的問題。³

6.2 擁有 SPN 的帳戶也會成為 Kerberoasting 的目標

接受 Kerberos 驗證的服務，會在執行帳戶上註冊 SPN（服務主體名稱）。由於網域內已通過驗證的使用者都能要求該服務票證，攻擊者取得票證後在離線狀態嘗試暴力破解密碼，這就是 Kerberoasting。

對策不是依賴人訂的 10 到 16 個字元左右的密碼，而是使用長的隨機產生密碼。Microsoft 也列出強制使用長密碼，以及使用機器產生的超長隨機值的 gMSA。¹³

同一份文件提到的 Kerberos Armoring（FAST），保護的是預先驗證資料以及對 KDC 假冒的抵抗力。它並不會阻止已通過驗證的使用者向 SPN 要求服務票證，因此無法取代服務帳戶的密碼強度。SPN 與 Kerberos，以及切換到 NTLM 的條件，請參閱「圖解NTLM與Kerberos」。

6.3 不支援的應用程式，就把專用帳戶與維運措施成套落實

若因為應用程式不支援 gMSA 等理由，不得不使用專用網域使用者，就要把下列緩解措施全部落實。

把服務的身分與人的帳戶切開，也是重要的原則。⁴ 與其讓人持續做這些管理，不如把有支援的服務移到 gMSA，這樣更安全、維運也更輕，這就是優先選擇 gMSA 的理由。

7. 切換與稽核：不是改個帳戶名稱就結束

7.1 確認「以服務方式登入」的權利

要以服務方式啟動，帳戶需要 SeServiceLogonRight（以服務方式登入）。LocalSystem、LocalService、NetworkService 內建就有，但以其他帳戶執行時，就要確認這項權利的指派。¹⁴

要在部署程序中明確寫出以本機安全性原則（secpol.msc）或 GPO、Intune 設定權利。不依賴工具的副作用很重要。對服務專用帳戶，還要一併搭配拒絕互動式登入。

7.2 確認設定檔底下的資料與 ACL

SCM 會在服務啟動時載入該帳戶的使用者設定檔。因此 %TEMP%、%APPDATA%、HKEY_CURRENT_USER 的實體會因帳戶而異。切換之後設定與快取看起來像「不見了」，是因為參照的是與舊帳戶不同的設定檔。¹

對策是把服務的資料放到 C:\ProgramData\<應用程式名稱> 這種明確的路徑，並對執行帳戶授與 ACL。只要脫離依帳戶區分的設定檔，下次變更帳戶時就不必再搬一次存放位置。已經存在設定檔底下的資料，請把移轉納入切換計畫。

不只是必要的資料夾，登錄等的權限也要確認。把帳戶改成低權限之後，要驗證原本以 LocalSystem 權限為前提的處理會不會失敗。

7.3 DPAPI 保護的資料，光搬檔案是接不過來的

以使用者範圍的 DPAPI（CryptProtectData、.NET 的 ProtectedData 等）保護的資料，原則上只有用保護當時的同一個帳戶才能解密。一旦變更執行帳戶，已儲存的連接字串與 API 金鑰就讀不出來了。

因此，除了設定檔的檔案移轉之外，還要準備切換後重新輸入機密資訊的程序。即使這是 DPAPI 正確保護的結果，沒有事先準備仍會變成服務的故障。存放位置的設計請參閱「Windows 應用程式的機密資訊保存」。

如果連線用 gMSA 或 PC$ 的 Windows 整合式驗證就能完成，那麼連儲存機密資訊這件事本身都可以省掉。先想「能不能不儲存」，再想「要存在哪裡」，順序是這樣。

另外，想「以呼叫端使用者的權限來處理」時，不要把服務的執行帳戶調強，而要考慮偽裝（impersonation）。詳情在「正確處理 Windows 偽裝權杖」中說明。

7.4 用服務清單盤點，用記錄確認啟動時的身分

最初的盤點，可以統計服務清單中的執行帳戶。下面的例子會確認各帳戶的數量，以及路徑不在 Windows 資料夾內的 LocalSystem 服務。

# 統計哪些服務以哪個帳戶執行
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 或網域使用者執行，就回到第 1 章的判斷，確認所需的特殊權限，以及目的端需要的身分。用路徑篩選只當成找出候選的線索，最後請依服務實際的用途與處理內容來判斷。

服務的啟動可以用安全性事件記錄檔的 事件識別碼 4624、登入類型 5（Service） 確認。這表示 SCM 啟動服務時的登入。「虛擬帳戶」欄位會表示該次登入是否來自 MSA 或虛擬帳戶，因此也能用來監視受管理帳戶的使用情形。¹⁵

7.5 整理正式切換前的確認

不論是從 LocalSystem 移出，還是導入 gMSA，都要做完這些確認再切換正式環境。把最小權限化與必要功能持續運作成套確認，這是移轉的要點。

8. 總結

選定服務帳戶時，要把本機權限、網路身分、密碼管理分開來思考。就算 LocalSystem 是預設值，那也不構成使用它的理由。一般的業務服務以虛擬帳戶為基本，並授與必要的 ACL。只有在真的需要強大特殊權限時，才考慮 LocalSystem。⁵³

如果網域內的目的端只要有電腦層級的身分就夠，那麼虛擬帳戶等加上對 PC$ 的權限往往就足夠。需要服務專屬身分，或多台伺服器需要共通身分時，就選擇 gMSA，把密碼管理交給 AD。工作群組中 PC$ 與 gMSA 都不能用，需要另一套處理認證資料的設計。²¹⁰

需要網域使用者時，就把專用帳戶、長的隨機密碼、登入限制、最小權限、輪替與清冊配齊。切換時不只要改帳戶名稱，還要確認登入權利、設定檔與 DPAPI。

下次設定服務時要問的是：「這個服務應該以誰的身分、能存取到哪裡？」請依這個答案選擇帳戶，不要把「碰巧能跑的設定」原樣固定下來。

相關文章

• Windows 服務的建立與維運 ── 從工作排程器的取捨到 BackgroundService 服務化
• Windows 什麼時候需要系統管理員權限 - UAC、保護區、設計上的分辨方式
• 正確處理 Windows 偽裝權杖 - 執行緒層級的權限借用與安全還原方式
• 圖解NTLM與Kerberos ── 為什麼驗證會「回退」到NTLM
• Windows LAPS 實務指南 ── 停止在所有電腦共用同一組本機系統管理員密碼
• Windows 應用程式的機密資訊保存 - 用 DPAPI 避免明文設定

相關諮詢領域

小村軟體有限公司承接 Windows 服務與常駐應用程式的執行帳戶設計與最小權限化、把以 LocalSystem 為前提打造的既有服務移轉到虛擬帳戶或 gMSA，以及變更帳戶後因存取被拒、DPAPI、設定檔引起的問題調查。從「稽核被點名了，但不知道該從哪裡下手」這個階段開始也可以。

• 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 軟體開發、技術諮詢與故障調查為中心，在難以重現的故障調查與既有資產仍在運作的專案上具有優勢。