文章目录
- 10.2.4 服务账户（Service accounts）：为什么“服务能不能运行”和“服务该以谁的身份运行”，是两个完全不同层级的问题？
- 1、为什么服务账户问题比普通应用更敏感？
- 2、三大内置服务账户：Windows 为什么不只给你一个 SYSTEM？
- 3、本地系统账户（LocalSystem）：为什么说它不是“管理员加强版”，而是系统级超强身份？
- 3.1 它是谁？
- 3.2 它为什么这么强？
- 第一，它属于本地 Administrators 组
- 第二，它可以启用几乎所有特权
- 第三，它对大量文件和注册表键拥有完全访问
- 3.3 它用的是哪个用户配置文件？
- 3.4 它在域环境里还会带上机器身份
- 3.5 它对网络资源并不是无限制通吃
- 4、网络服务账户（Network Service）：为什么它像“削弱版 SYSTEM，但还保留了网络身份”？
- 4.1 它存在的目的是什么？
- 4.2 它比 LocalSystem 弱在哪里？
- 4.3 它用的是自己的专属 profile
- 5、本地服务账户（Local Service）：为什么它更像“只在本机低权限活动，不代表机器去认证网络”？
- 5.1 它和 Network Service 的关系是什么？
- 5.2 它的组成员和 profile 在哪里？
- 5.3 哪些服务适合它？
- 6、三者放在一起看，才能真正理解服务账户设计逻辑
- 7、这一节最值得运维人员记住的实战启发
- 7.1 服务启动失败，不一定是程序坏了，可能是账户权限不够
- 7.2 服务权限过高，不一定立刻出故障，但会把风险推高
- 7.3 服务拿不到当前用户设置，可能不是没权限，而是 profile 不是那个用户的
- 7.4 网络访问异常，要分清“本机权限”和“网络身份”是两回事
- 8、我对这一节的理解：服务账户的本质，是 Windows 给后台能力画“权力边界”
- 9、总结提升
10.2.4 服务账户（Service accounts）：为什么“服务能不能运行”和“服务该以谁的身份运行”，是两个完全不同层级的问题？
如果说前面的Service characteristics解决的是：
“这个服务什么时候启动、怎么启动、失败后怎么处理。”
那么Service accounts这一节解决的就是另一个更关键、也更容易被低估的问题：
“这个服务启动以后，到底是以谁的安全身份去访问系统资源？”
《Windows Internals》这里开门见山地指出：服务的安全上下文（security context）对服务开发者和系统管理员都非常重要，因为它直接决定了该进程能够访问哪些资源。书中同时说明，很多内置服务都会运行在合适的服务账户下；而在安装服务时，安装程序或管理员往往会默认指定LocalSystem，这个账户非常强大；另外还有两个能力较弱的内置账户：Network Service和Local Service。
这句话其实已经点出了服务账户这一节的核心：
服务账户不是“登录名”那么简单，而是服务权限边界、资源可达范围、网络身份和风险暴露面的总开关。
也就是说，一个服务“能不能跑”，和它“跑起来以后能碰到什么资源”，根本不是同一个问题。
很多服务故障、很多服务安全风险，最终都不是出在 EXE 本身，而是出在：
- 账户太强，导致攻击面过大
- 账户太弱，导致资源访问失败
- 本地权限够了，但网络身份不对
- 能读取系统配置，却拿不到用户配置
- 能访问本机，却不能正确认证到其他机器
所以这一节真正要建立的认知是：
服务账户决定的，不只是进程归属，而是这个服务在 Windows 安全模型里“能走到哪里”。
1、为什么服务账户问题比普通应用更敏感？
普通交互式应用一般随当前登录用户运行，所以大家天然知道：
“我是谁，我就有什么权限。”
但服务不一样。
服务很多时候是在：
- 没有用户登录
- 系统刚启动
- 后台长期驻留
- 需要跨机器通信
- 需要接触系统级对象
的条件下运行。
因此，服务账户本质上是在替系统回答一个问题：
“这个后台能力，到底应该被赋予多大权力？”
书中明确说明，大多数内置服务会运行在适合自己的 Service account 下，而不是一律使用最强账户。原因很简单：如果所有服务都跑在最高权限下，那系统管理虽然方便，但安全面会急剧扩大。
所以，服务账户这一节的底层逻辑，不是“账户分类介绍”，而是：
Windows 在后台服务世界里，如何平衡“功能可用性”和“最小权限原则”。
2、三大内置服务账户：Windows 为什么不只给你一个 SYSTEM？
从 Windows 的设计看，最经典的内置服务账户主要有三个：
- LocalSystem
- Network Service
- Local Service
它们并不是平级替代关系，而是权限、能力和网络行为逐级收缩的三种运行身份。书中也正是围绕这三个账户来展开说明。
可以先用一句话粗略理解：
| 服务账户 | 本机权限 | 网络身份 | 风险级别 |
|---|---|---|---|
| LocalSystem | 非常强 | 可携带机器身份 | 最高 |
| Network Service | 较低 | 可用计算机账户做网络认证 | 中 |
| Local Service | 较低 | 基本只可匿名访问网络资源 | 更低 |
也就是说，Windows 并不是只提供一个“后台运行账号”，而是给出了不同安全强度的运行档位。
你选的不是一个名字，你选的是：
- 本机权限边界
- 网络访问方式
- 配置可见范围
- 潜在攻击后果
3、本地系统账户（LocalSystem）：为什么说它不是“管理员加强版”，而是系统级超强身份？
3.1 它是谁？
书中指出，LocalSystem就是很多核心 Windows 用户态系统组件运行所使用的同一个账户，包括：
- Session Manager
Smss.exe - Windows 子系统进程
Csrss.exe - 本地安全机构进程
Lsass.exe - 登录进程
Winlogon.exe
这说明一件很重要的事：
LocalSystem 不是某个普通服务专用的便利账户，而是系统核心组件本身就在使用的高权力身份。
所以一旦服务被配置成以 LocalSystem 运行，它获得的就不是“差不多够用的权限”，而是非常接近系统核心进程的能力范围。
3.2 它为什么这么强？
书中对 LocalSystem 的描述非常直白：
从安全角度看，LocalSystem 在本机上的安全能力比任何本地账户或域账户都更强。
它之所以强，主要体现在几个方面：
第一，它属于本地 Administrators 组
这意味着它天然拥有非常高的对象访问能力。书中表 10-9 也显示，LocalSystem 属于Administrators、Everyone、Authenticated Users，并处于System integrity level。
第二，它可以启用几乎所有特权
书中指出，LocalSystem 有权启用所有 privilege，甚至包括一些普通本地管理员通常不会被授予的能力，例如创建安全令牌。表 10-10 中列出的权限也远多于其他服务账户。
第三，它对大量文件和注册表键拥有完全访问
即便某些对象没有直接授予它完全控制，运行在 LocalSystem 下的进程还可以通过take-ownership privilege进一步取得访问权。
这三点放在一起，就能解释为什么：
把服务跑在 LocalSystem 下，功能上最省事，但安全上也最危险。
3.3 它用的是哪个用户配置文件？
书中还提到一个很多人容易忽略的点：
运行在 LocalSystem 下的进程使用的是默认用户配置文件HKU\.DEFAULT。因此，它们不能直接访问其他真实用户 profile 中存储的配置，除非显式调用LoadUserProfile。
这句话对运维和开发都很重要，因为它解释了很多“为什么服务拿不到当前用户设置”的问题。
也就是说，即使 LocalSystem 权限极高，它默认看到的也不是“某个登录用户的 HKCU”，而是自己的系统默认配置上下文。
所以要特别注意：
- 高权限不等于天然拥有用户级上下文
- LocalSystem 能碰很多系统对象
- 但它默认并不活在某个真实登录用户的配置空间里
这也是服务场景和普通用户应用场景非常不一样的地方。
3.4 它在域环境里还会带上机器身份
书中继续指出，当计算机属于 Windows 域时，LocalSystem 还会包含该计算机的 machine SID。这意味着：
运行在 LocalSystem 下的服务，在同一 forest 的其他机器上，可以自动使用这台机器的计算机账户完成身份验证。
这其实是一个非常关键的网络语义差异：
- 你以为它只是“本机最强账户”
- 但到了网络侧，它还会带着“这台机器”的身份去说话
所以 LocalSystem 的问题不只是“本机太强”，还包括：
它在网络中的行为也不再是普通匿名调用。
这也是为什么企业环境中，服务账户选型经常会影响：
- 远程共享访问
- 域内资源认证
- 跨机器命名管道调用
- 机器账户授权策略
3.5 它对网络资源并不是无限制通吃
书中也给了一个很有边界感的补充：
除非该机器账户被明确授予某些资源访问权限，否则 LocalSystem 进程访问网络资源时，主要能访问的是那些允许null session的资源。相关共享和命名管道可以通过：
HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters下的NullSessionPipes和NullSessionShares来控制。
这说明 LocalSystem 不是“网络随便通行证”，而是：
- 在本机极强
- 在网络上可带机器身份
- 但是否真正能访问远端对象，还取决于对方资源 ACL 和相关配置
4、网络服务账户（Network Service）：为什么它像“削弱版 SYSTEM，但还保留了网络身份”？
4.1 它存在的目的是什么？
书中对Network Service的定位非常明确：
它用于那些希望在网络上用计算机账户进行身份验证，但又不需要 LocalSystem 那么强本机能力的服务。
这句话特别值得细想，因为它说明 Network Service 的设计目标非常清晰：
保留“我代表这台机器去和别的机器说话”的能力，但削弱“我在本机上无所不能”的能力。
也就是说，它不是 LocalService 的网络加强版，也不是 LocalSystem 的轻量版，而是一个专门为“需要网络身份、但不该拿太高本机权限”的服务准备的中间档位。
4.2 它比 LocalSystem 弱在哪里？
书中指出，因为 Network Service不属于 Administrators 组，所以默认情况下它能访问的注册表键、文件夹和文件都会比 LocalSystem 少很多；同时，它拥有的 privilege 也更少。比如，一个被攻破的 Network Service 进程，通常无法去加载驱动，也不能任意打开其他进程。
这意味着它的一个核心优势是：
即使服务被利用，攻击者能借它进一步横向或纵向扩展的空间也更有限。
从系统安全设计角度看，这就叫典型的缩小爆炸半径。
4.3 它用的是自己的专属 profile
书中还特别给出了一条很实用的信息：
运行在 Network Service 下的进程会使用Network Service 自己的 profile，它的注册表部分加载到：
HKU\S-1-5-20而相关文件和目录位于：
%SystemRoot%\ServiceProfiles\NetworkService这一点对理解服务配置、分析服务残留文件、处理 profile 相关故障都很有帮助。
5、本地服务账户（Local Service）：为什么它更像“只在本机低权限活动，不代表机器去认证网络”？
5.1 它和 Network Service 的关系是什么？
书中给出的描述非常精炼：
Local Service 与 Network Service 几乎相同，最重要的区别在于，它只能访问允许匿名访问的网络资源。
这句话直接就把两者差异点钉死了：
- 两者在本机权限层面都比 LocalSystem 弱
- 两者 privilege 级别相近
- 真正拉开差距的是网络身份行为
也就是说：
- Network Service：需要在网络侧代表本机说话
- Local Service：基本不代表本机说话，更多是本机内低权限运行
5.2 它的组成员和 profile 在哪里？
书中说明，Local Service 与 Network Service 在 group membership 上非常接近，只是它属于Local Service group而不是Network Service group；同时它的 profile 会加载到：
HKU\S-1-5-19对应目录位于：
%SystemRoot%\ServiceProfiles\LocalService这也意味着在实际系统中，如果你看到服务读取或写入这些 profile 路径，不要以为是“普通用户 profile”，而要想到它可能是某个服务账户的独立配置空间。
5.3 哪些服务适合它？
书中举的例子包括：
- Remote Registry Service
- LmHosts service
前者允许远程访问本地注册表，后者负责 NetBIOS 名称解析。
这类服务的共同点通常是：
- 需要后台驻留
- 需要一定系统能力
- 但没有必要拿到 LocalSystem 那种过大的本机权限
- 也不需要在网络上以“本机账户”身份去大范围认证
所以 Local Service 的存在，本质上是在告诉你：
不是所有后台基础能力，都需要把自己做成“系统最强权限代理”。
6、三者放在一起看，才能真正理解服务账户设计逻辑
很多人平时会机械记忆：
- LocalSystem 最强
- Network Service 次之
- Local Service 更弱
但真正重要的，不是记结论，而是看出 Windows 的设计思路：
这张图对应的核心思想就是：
服务账户不是按名字选，而是按“本机权限需求”和“网络身份需求”两个维度选。
这也是为什么“默认用 SYSTEM 最省事”虽然短期上看方便，但从长期稳定性和安全性看，往往并不是最优解。
7、这一节最值得运维人员记住的实战启发
7.1 服务启动失败，不一定是程序坏了，可能是账户权限不够
如果服务需要访问某个注册表键、系统目录、命名管道或端口，而当前服务账户拿不到，就会表现成启动超时、初始化失败、功能异常。
7.2 服务权限过高，不一定立刻出故障，但会把风险推高
把本来只需要普通后台能力的服务一股脑跑在 LocalSystem 下，短期问题少，长期风险大。因为一旦该服务被利用，攻击者拿到的就是一个极强落点。
7.3 服务拿不到当前用户设置，可能不是没权限，而是 profile 不是那个用户的
LocalSystem 默认用HKU\.DEFAULT，Network Service 和 Local Service 也各自有独立的 profile。
所以服务访问不到“当前登录用户的 HKCU”并不奇怪，很多时候这是模型设计使然。
7.4 网络访问异常，要分清“本机权限”和“网络身份”是两回事
某服务在本机能读能写，不代表它在网络上就能正确认证；反过来，一个需要代表本机到别处认证的服务，也不一定需要 LocalSystem 那么高的本机权限。
这正是 Local Service 与 Network Service 分离出来的意义。
8、我对这一节的理解：服务账户的本质，是 Windows 给后台能力画“权力边界”
10.2.4 表面上看是在介绍三个账户，实际上真正讲的是一套很成熟的系统治理思想：
- 给后台服务足够的能力去完成工作
- 但不要无条件给它最高权限
- 把“本机能力”和“网络身份”拆开设计
- 把不同服务放到不同风险档位上运行
这套思路非常符合现代系统安全的基本原则：
能少给就少给，能拆开就拆开，能限制影响面就不要把所有能力绑死在一个超强身份上。
所以，如果要给这一节写一句最适合放在结尾的话，我会这样写：
服务账户的选择，本质上不是“这个服务用哪个账号启动”，而是“这个后台能力应该被允许拥有多大的系统权力和多强的网络身份”。
9、总结提升
这一节最核心的内容，可以压缩成下面几条：
- 服务账户决定服务进程能访问哪些资源，因此是服务设计和系统管理中的关键安全变量。
- LocalSystem权限极强，属于 Administrators，可启用大量 privilege，默认使用
HKU\.DEFAULT，在域环境下还能携带机器身份进行网络认证。 - Network Service本机权限明显弱于 LocalSystem，但仍可以在网络上以计算机账户身份进行认证，profile 位于
HKU\S-1-5-20和%SystemRoot%\ServiceProfiles\NetworkService。 - Local Service与 Network Service 类似，但网络侧基本只访问允许匿名访问的资源，profile 位于
HKU\S-1-5-19和%SystemRoot%\ServiceProfiles\LocalService。
所以，站在《Windows Internals》这一章的主线上看，10.2.4 真正想让你理解的不是“三个账户的定义”，而是 Windows 如何通过不同服务账户，把后台服务的权限边界做细、做弱、做分层。
下一段如果继续顺着写，最自然的衔接就是10.2.5 以其他账户运行服务（Running services in alternate accounts），因为前面讲的是内置服务账户，后面就顺势进入：那如果内置账户都不合适，服务还能不能跑在别的账号下？
