什么是 Active Directory Service Accounts？

就像人类用户一样，计算机程序要正常运行也需要访问网络上的资源。不过，这两个群体——个人和程序——访问这些资源的方式有所不同。人类使用用户帐户，而计算机程序使用 Active Director 服务帐户。Active Directory 服务帐户使计算机服务和程序能够在不需要人工干预的情况下运行，这对于确保关键流程在幕后持续不间断地运转至关重要。尽管如此，和用户帐户一样，你仍然需要管理 Active Directory 服务帐户，否则它们可能会使你的组织暴露在网络攻击之下。

本指南将涵盖与 Active Directory 服务帐户相关的一切内容——从理解其重要性、AD 服务帐户的不同类型，到如何对它们进行管理。

了解服务账户

服务账户是一种 特权账户，允许应用程序或服务与操作系统以及其他网络资源进行交互。这些非人类账户通过为试图访问系统资源的计算机程序和服务分配身份与权限（特权）来运作，方式与用户账户类似。通常，服务账户有多种类型，包括 Managed Service Accounts、Group Managed Service Accounts、Local Service Accounts 等，后续指南中会进一步介绍。

请在以下文章中了解更多关于服务账户的信息：

• 无需使用特权来发现服务账户
• 4 种服务账户攻击及其防护方法

用户账户与服务账户的差异

用户账户与服务账户之间的首要且主要区别在于它们的创建方式。用户账户需要网络管理员创建并分配权限，而大多数（并非全部——有些可以手动创建）在作为服务或软件的一部分时会预先安装并配置好。

另一个关键差异在于它们如何运行以及如何被识别。对于用户账户，你可以识别与特定账户对应的个人，因为它们的设计目的是让人类能够访问系统资源。另一方面，服务账户并不与某个特定的人相关联，因为它们是为应用程序或服务等非人类实体创建的。

由于它们的运行方式以及在 Active Directory 环境中的角色不同，用户账户与服务账户在身份验证方面也有所区别。用户账户需要通过用户 ID 和密码进行手动登录，而服务账户则自主运行，因此不需要获得运行服务所需的权限。

服务账户的重要性

服务账户在多个方面都极其重要，尤其是在企业环境中。或许最重要的原因是它们在保障关键流程顺畅运行方面所起的作用。服务账户会自动化执行必需的（有时也是重复性的）任务，例如运行备份、管理数据库以及系统更新。通过这种方式，企业可以降低管理开销、提高效率，并根据需要灵活扩展或缩减规模。

服务账户还可以作为人类用户的代理，来执行企业可能认为敏感或需要更高权限的任务。这对于维护网络安全至关重要。通过将此类任务中的人为因素移除，组织就能够保护其网络免受与安全相关的事件侵害，因为只有经过授权的服务和应用才能执行某些任务。

一些常见的使用服务账户的服务和应用示例包括：

• Exchange Server
• SharePoint
• SQL Server
• Internet Information Services (IIS)

Active Directory 中的服务帐户类型

下面我们将详细探讨不同类型的 AD 服务帐户，包括它们的使用场景：

本地服务帐户

本地（内置）用户帐户是一种 Active Directory 服务帐户 在安装过程中会自动创建到计算机或单独的服务器上的帐户类型。 这些服务帐户通常不属于任何域，因此一般用于只需要访问本地资源的服务。

应用程序可以以其运行的本地用户帐户最常见的示例包括 Local System 帐户（或 System Account）、Local Service 帐户以及 Network Service 帐户。

域服务帐户

这些 AD 服务帐户通常被使用，并且非常适合需要访问共享资源的服务，例如数据库或文件服务器。它们会在 Active Directory 中创建，以便服务或应用程序能够通过网络访问各类资源。

托管服务帐户（Managed Service Accounts，MSAs）

Windows 托管服务帐户（Managed Service Accounts，MSAs）也称为独立托管服务帐户（Standalone Managed Service Accounts，sMSA）。它们是 Microsoft 在 Windows Server 2008 R2 或 Windows 7 中引入的较新帐户类型。这些帐户与域帐户类似，但有一项重大改进——密码会自动管理，并每 30 天重置一次。该改进消除了管理员手动管理密码的需求，从而提升安全性。

除了安全性之外，AD 托管服务帐户还提供其他管理方面的优势，包括：

• 与本地用户帐户不同，您无需管理服务主体名称（SPN）。
• 无需手动重置这些帐户的密码。
• 您可以创建域帐户，以便于管理本地计算机上的服务。

如何创建和管理 MSA：

在创建 MSA 帐户之前，您必须满足一些先决条件，包括：

• Windows Server 2008 R2 或 Windows 7
• 运行 ADPrep|Forest Prep
• Net Framework 3.5
• 适用于 Windows PowerShell 的 Active Directory 模块

满足以上先决条件后，请按照以下步骤进行：

1. 点击“开始”菜单并打开 PowerShell。
2. 在 PowerShell 控制台中运行以下命令：“Import-module ActiveDirectory” 以导入 Active Directory 模块。
3. 接下来，运行以下命令 “New-ADService Account -Name <AccountName> -enable $true” 将 <AccountName> 替换为你想要的账户名称。
4. 此步骤涉及将 MSA 与将运行该服务的计算机关联起来。为此，请运行以下命令 “Add-ADComputerServiceAccount -Identity <ComputerName> -ServiceAccount <AccountName>
5. 运行以下命令 “Install-ADServiceAccount -Identity <AccountName>” 在计算机上安装 MSA，并使其可供使用。

6. 最后，将服务配置为使用 MSA 进行身份验证。在服务的属性中，在“登录”选项卡下将 MSA 指定为账户。输入 MSA 名称时使用格式“DOMAIN\<AccountName>$”。

Group Managed Service Accounts (gMSAs)

这些服务帐户是 Managed Service Accounts 的扩展：它们支持相同的功能，但将功能扩展到多台服务器。此外，gMSA 仅在 Windows Server 2012 或更高版本中受支持。

如何创建和管理 gMSA

创建 gMSA 不需要满足任何功能级别或域要求。

1. 通过在 Active Directory PowerShell 模块中运行以下命令来创建 KDS root：“Add-KdsRootKey -EffectiveTime ((Get-Date).AddHours(-10))”
2. 打开 Powershell，运行以下命令以导入 Active Directory 模块：“Import-Module ActiveDirectory”
3. 运行以下命令：”New-ADServiceAccount -Name <AccountName> -DNSHostName <DNSHostName> -PrincipalsAllowedToRetrieveManagedPassword "<GroupName>” 以创建 gMSA。

在此示例中，“AccountName”将是 gMSA 的名称，而 “DNSHostName”是域控制器的名称，“GroupName”是被允许检索 gMSA 密码的组或计算机对象。

1. 通过运行以下命令，在每台将使用 gMSA 的服务器上安装该账户： “Install-ADServiceAccount”

2. 要验证你是否已在每台服务器上安装了 gMSA，并且其运行正常，请使用以下命令： “Test-ADServiceAccount <AccountName>”

常见挑战及应对方法

管理 AD 服务账户并非没有挑战。 在本节中，我们将探讨在处理服务账户时你应该预期会遇到哪些问题，以及如何通过采用最佳实践来应对这些挑战，从而确保服务账户保持安全并按其应有的方式运行。

密码管理问题

与 Active Directory 服务账户相关的最常见挑战之一，是缺乏 密码管理。与用户账户不同，服务账户很少会像密码轮换那样经历管理实践——也就是说，在一定时间后不断更改或重置密码。IT 团队之所以可能忽视这一点，并不是因为他们粗心：实际上恰恰相反。他们担心的是更改服务账户密码可能带来的后果，即会打断关键流程。

审计与监控服务账户的使用情况

对服务账户进行监控和审计对 IT 管理员来说是一个巨大的挑战。原因有多方面。首先，单个企业中的服务账户数量可能高得惊人，导致根本无法跟上其变化。尽管您可能能够监控其中一些账户，但其他账户可能会被遗漏，因为您根本不知道它们的存在。此外，还可能会出现问责方面的问题，因为这些账户本质上并未绑定到特定用户。

服务账户安全

与大多数 AD 账户一样，安全 仍然是服务账户的一项挑战。大多数服务账户拥有较高的权限和许可，因此一旦发生安全漏洞，它们就可能访问组织网络中大量资源。此外，如果未能建立清单或责任归属不清的服务账户太多，那么对每一个账户都进行保障可能会变得不可能。

孤立或未使用的服务账户

如果不加以控制，您的企业可能会成为众多组织中的一员：服务账户多得让人根本无法跟踪。这种情况可能发生在负责管理这些账户的员工离开组织、迁移到新系统，或者忘记删除临时服务账户的情况下。这些服务账户往往被忽视，并可能最终在您的网络中不断累积。

管理服务账户的最佳实践

你可以实施一些最佳实践来预防并应对上文讨论的挑战。其中一些最佳实践包括：

• 最小特权原则 (PoLP)：这意味着只授予服务账户执行其所需任务所需的（最低）权限。该最佳实践可最大程度降低未经授权的操作和访问风险。此外，如果发生安全漏洞，未经授权用户可能造成的损害量也会减少。
• 定期审查并更新权限： 在实施 PoLP 之外，你还应偶尔重新调整每个服务账户所持有的 权限 。这是因为，随着时间推移，不同的应用程序和服务的权限可能会发生变化，你需要确保它们的访问权限不会超过必要范围。
• 实施强密码策略：对于不会像传统域账户那样自动更改密码的服务账户，强密码策略例如使用复杂且足够长的密码、定期更换高权限服务账户的密码，以及安全地存储密码，都有助于降低发生泄露的可能性。
• 使用 MSA 和 gMSA 降低管理开销： MSA 和 gMSA 可自动化密码管理，并简化 SPN 配置。这会释放 IT 人员的时间，让他们专注于其他重要任务。
• 监控并审计服务账号活动： 创建服务账号后就不再关注，是一条通往灾难的配方（即发生安全漏洞）。因此，您必须制定对账号进行定期审计的策略，以便发现并阻止可疑行为。

清理未使用的服务账号

未使用的服务账号可能会给您的组织带来安全问题。正如已经确定的那样，这些账号中有些可能拥有非常高的权限，因此，如果攻击者获得其中某个账号的访问权限，就可能造成严重的损害。识别未使用或孤立的服务账号至关重要。您可以通过多种方式来做到这一点，包括：

• 使用 Privileged Access Management (PAM) 解决方案： 您可以借助类似 Netwrix 的解决方案，它们会扫描整个 IT 环境以发现所有现有的服务账号。通过账号列表，您可以找到任何未使用且不必要的账号，并将其移除。
• 利用搜索查询：您可以使用常见查询“Service Accounts not logged in for $days”，以识别在您的 AD 环境中未使用的旧服务账户。

安全移除未使用的服务账户步骤

移除旧的、未使用的账户需要您遵循多个步骤，以确保不会危及整个系统。不过，在您识别出未使用的服务账户之后：

1. 确认所识别的账户不再需要。为此，您可以使用以下 PowerShell 命令：“Get-ADUser -Identity <AccountName> -Properties LastLogonDate”
2. 与其立即删除服务账户，不如先将其禁用。这样您就可以验证：禁用该账户不会影响任何关键服务。
3. 在确认禁用服务帐户不会引发任何问题后，你可以通过运行以下 PowerShell 命令来将其删除：“Remove-ADUser -Identity <AccountName>”

用于管理服务帐户的工具与技术

PowerShell 已被证明是用于管理 AD 环境中服务帐户的强大工具。它提供了多种命令，你可以轻松快速地创建、修改和删除帐户。你也可以使用它来管理权限并自动化日常任务。

Netwrix 如何提供帮助

Active Directory 服务帐户虽然很有用，但如果管理不当，也可能对整个组织带来安全风险。这就是为什么依赖一种能够帮助你创建、管理并维护 AD 服务帐户最佳实践的解决方案至关重要。在 Netwrix，Active Directory 是我们的专长，因此你可以信赖我们来确保你的服务帐户安全。我们的 end-to-end Active Directory Security Solution 通过开展风险评估、实施保护 AD 环境的防护措施、立即响应威胁，并支持全面的 AD 恢复来发挥作用。

常见问题(FAQ)

如何在 Active Directory 中创建服务帐户？

在 Active Directory 中创建服务帐户很简单，但要安全地完成这一步，需要遵循经过验证的最佳实践。首先打开 Active Directory Users and Computers (ADUC)，导航到要创建帐户的组织单位，然后右键单击选择“New” > “User”。使用能够清晰标识服务及其用途的描述性名称，例如“SQL-Service-Account”或“Backup-Service-Account”。

设置强壮且复杂的密码，并符合贵组织的策略要求。仅在你已建立完善的密码轮换流程时，才勾选“Password never expires”选项；否则，你将承担安全风险。为该帐户配置特定服务所需的最小权限。这正是最小特权不再停留在理论层面，而是变得可落地。根据服务需求将该帐户分配到合适的安全组，但除非绝对必要，否则绝不要将其添加到特权组（privileged groups）。

请记住：攻击者不仅仅是在“入侵”，他们还会进行登录。配置不当且拥有过多权限的服务帐户会成为横向移动（lateral movement）的通道。 Data security that starts with identity 意味着要把服务帐户视为关键的安全资产，而不仅仅是功能上的必需品。

Active Directory 中什么是服务帐户？

Active Directory 中的服务帐户是一种专门的用户帐户，旨在运行服务、应用程序和自动化流程——而不是用于交互式用户登录。与普通用户帐户不同，服务帐户为需要在无需人工干预的情况下进行身份验证并访问网络资源的应用程序和服务提供安全上下文。

服务帐户主要分为四种类型：本地服务帐户在本地计算机上以有限权限运行；域服务帐户可以访问整个域中的网络资源；托管服务帐户（Managed Service Accounts, MSA）提供自动密码管理；组托管服务帐户（Group Managed Service Accounts, gMSA）将 MSA 的功能扩展到多台服务器。每种类型都适用于不同的安全与运维需求。

服务帐户与用户帐户之间的关键区别在于它们的用途和管理方式。服务帐户在后台持续运行，需要不同的安全考虑，并且通常需要对常规用户不需要的系统资源具备特定权限。它们对于在确保服务正常运行的同时维持最小权限原则至关重要。配置正确后，服务帐户可以在不损害您的安全态势的情况下提供必要的访问。

如何使用 PowerShell 在 Active Directory 中查找服务帐户？

PowerShell 提供了强大的工具，可用于识别并审计整个 Active Directory 环境中的服务账号。最有效的方法是结合多条命令，以便全面了解你的服务账号态势。

从这个基础命令开始：

      Get-ADUser -Filter {servicePrincipalName -like "*"} -Properties servicePrincipalName, lastLogon, passwordLastSet | Select-Object Name, servicePrincipalName, lastLogon, passwordLastSet
      

它会识别具有服务主体名称（Service Principal Names，SPNs）的账号，这些账号通常与服务相关联。

要进行更广泛的搜索（包含没有 SPN 的账号），请使用：

      Get-ADUser -Filter {Name -like "*service*" -or Name -like "*svc*" -or Description -like "*service*"} -Properties Description, lastLogon, passwordLastSet, memberOf | Select-Object Name, Description, lastLogon, passwordLastSet, memberOf
      

它会根据命名约定和描述来筛选账号。

要识别可能存在风险的服务帐户，请运行：

      Get-ADUser -Filter {PasswordNeverExpires -eq $true -and Enabled -eq $true} -Properties passwordLastSet, lastLogon, memberOf | Where-Object {$_.memberOf -like "*Admin*"}
      

这会查找已启用、且密码不设置过期时间、并具有管理权限的帐户——正是那种需要更严格审查的帐户类型。

使用这些 PowerShell 命令定期审计，可帮助你在风险行为演变为数据泄露之前就发现问题。你无法管理看不见的东西——这些命令提供了维持正确的服务帐户“卫生”所需的可视性。

如何在 Active Directory 中创建托管服务帐户？

托管服务帐户（Managed Service Accounts，MSA）通过自动化密码管理并消除与密码相关的服务中断，较传统服务帐户带来显著的安全提升。创建 MSA 需要准备工作，但能在减少管理工作量的同时提供更强的安全性。

首先，请验证您的环境满足以下先决条件：

• 域功能级别为 Windows Server 2008 R2 或更高
• 服务将在 Windows Server 2008 R2 或更高版本上运行
• 已在域控制器上安装适用于 PowerShell 的 Active Directory 模块

使用 PowerShell 创建 MSA：

      New-ADServiceAccount -Name "MyServiceMSA" -DNSHostName "server.domain.com" -Enabled $true
      

将 “MyServiceMSA” 替换为你想要的帐户名称，并将 “server.domain.com” 替换为将使用此帐户的服务器的完全限定域名（FQDN）。

接下来，请在以提升权限（管理员权限）运行的 PowerShell 会话中执行以下命令，在目标服务器上安装 MSA：

      Install-ADServiceAccount -Identity "MyServiceMSA"
      

测试安装以确保所有内容都已正确配置：

      Test-ADServiceAccount -Identity "MyServiceMSA"
      

最后，通过将服务登录帐户设置为“Domain\MyServiceMSA$”（注意末尾的美元符号），并且不设置密码，来配置你的服务使用 MSA。系统会自动处理密码管理，默认情况下每 30 天轮换一次密码。该方法不再停留在“打勾确认”的流程上，而是借助实用且自动化的解决方案开始保护身份，从而同时降低风险与管理负担。

服务帐户 vs 用户帐户 — 该在何时使用哪一个？

在服务账号与用户账号之间做出选择，取决于用途、安全要求以及运维需求。了解何时使用每种类型对于维持安全规范和提升运行效率至关重要。

对于无需人工介入即可独立运行的自动化流程、服务、应用程序或计划任务，请使用服务账号。这些账号负责处理非交互式登录，并需要对特定资源保持一致且随时可用的访问。服务账号在以下场景中表现尤为出色：

• 数据库服务
• Web 应用程序
• 备份流程
• 监控工具
• 可在各系统间进行身份验证的集成服务

用户帐户用于需要对系统和应用进行交互式访问的人员（人类用户）。它们能够处理使用模式可变的情况、临时访问需求，以及必须将责任追溯和审计跟踪连接到特定个人的场景。当某个人需要：

• 进行交互式登录
• 访问电子邮件
• 以交互方式使用应用程序
• 执行需要人工判断的管理任务

从安全角度来看，服务账户应更严格地遵循最小特权原则，因为它们通常以较高权限运行并且长期持续工作。它们需要不同的监控方法——异常的活动模式可能意味着账户已被攻陷，而不只是正常使用差异。用户账户则需要其他控制措施，例如多因素认证、条件访问策略以及定期的访问审查。

关键原则是职责/用途匹配：服务账户用于服务，用户账户用于用户。将这些用途混用会产生安全漏洞和操作复杂性。Data security that starts with identity 的含义是，为合适的目的使用合适的账户类型，并为每种账户配套相应的控制措施。通过这种方式，在保持运营效率的同时减少攻击面。