关于服务账户的那些事——Active Directory与Azure AD/Entra ID安全
服务账户是介于普通用户账户和管理员账户之间的灰色地带，通常具有高权限。由于供应商文档要求或运维挑战（“只要能运行就行”），这些账户往往被过度授权。
我们可以通过查找具有Kerberos服务主体名称（SPN）的用户账户来发现服务账户（我称之为SPN扫描）。没有SPN的服务账户也可以通过查询AD账户中的’SVC’、‘Service’或常见供应商产品名称来发现。
以下PowerShell命令需要Active Directory PowerShell模块：
发现服务账户（具有SPN的用户账户）：
|
|
发现可能的AD管理员账户（AdminCount设置为1的用户账户）：
|
|
虽然域管理员是最常用的AD管理组，但还有其他几个组可能被使用。
可能包含服务账户的常见特权AD组：
| 组名 | 权限描述 |
|---|---|
| Administrators | 对AD域和域控制器的完全管理权限 |
| Domain Admins | 对加入域的计算机的完全管理权限（默认），以及对AD域和DC的完全管理权限（通过Administrators组成员身份） |
| Backup Operators | 默认具有备份和恢复Active Directory和域控制器的权限 |
| Server Operators | 能够登录到域控制器并在域控制器上执行某些管理操作 |
| Enterprise Admins | 对AD林中所有域和域控制器的完全管理权限（通过Administrators组成员身份）。还具有特殊的林管理权限，如DHCP。在单域林中，此组应保持为空直到需要时 |
| Schema Admins | 能够修改林的AD架构。此组应保持为空直到需要时 |
服务账户很少真正需要域管理员级别的权限。我审查了多个产品的供应商文档，发现有很多共同点。
最终出现了一个模式…
当我们为客户执行Active Directory安全评估时，几乎总是发现域管理员（有时是其他特权AD组）中的服务账户，并帮助客户（有时是供应商）找出如何减少服务账户的权限，以便将其从域管理员中移除。
域管理员（或其他AD管理组）中的常见服务账户：
-
Microsoft AGPM：用于管理AD中的组策略对象（GPO）。此账户不需要在域管理员或高特权AD组中。委托指南：https://blogs.technet.microsoft.com/askds/2008/12/16/agpm-least-privilege-scenario/
-
Altiris/ADBackup/Backup/BackupExec/CommVault/NetBackup等：备份AD（和/或域控制器）只需要在AD的备份操作员组中的成员身份。此组特定于Active Directory，不提供对域中其他系统的备份权限（默认）。这些账户不应需要域管理员成员身份。需要注意的是，在某些场景下，备份服务账户可能需要比备份操作员成员更多的权限，例如在AD中恢复用户属性时。这是更高级的恢复场景，AD备份账户应仅作为备份操作员组的成员（不是域管理员）开始。
-
Archive：通常是用于归档Exchange邮箱的Exchange服务账户。没有理由让Exchange相关服务账户成为特权AD组的成员。
-
AV/McAfee/Trend：AV服务账户永远不需要域管理员权限。
-
Azure：此账户可能用于Azure AD Connect（应由安装程序在域根上授予权限）或其他Azure用途。没有理由让此账户在域管理员中。
-
BES：这是Blackberry Enterprise Server服务账户，不需要域管理员权限（并且可能不再在网络上活动）。
-
CyberArk/Reconcile/SecretServer：CyberArk最初是企业密码库，现已将其产品扩展到其他安全控制。
-
Entrust/PKI：有特定的组用于PKI产品以启用证书操作。应使用这些组而不是域管理员。
-
Exchange/EXAdmin/Mail：Exchange服务账户永远不需要域管理员权限。
-
Fax：不。这永远不需要域管理员权限，应立即移除。
-
Imanami：Imanami提供组成员管理能力（ among others）和一些产品。这些服务账户应自定义委托到包含需要修改的对象的OU。
-
Landesk：Landesk用于计算机管理，不应在域管理员中。
-
Quest：有几个Quest产品可能需要在域控制器上具有特权权限。这些权限需要审查并确定是否适当。
-
PaloAlto：通常用于将域用户与计算机匹配，以识别个人到网络和互联网活动。有更好的方法配置需要执行此映射的系统，通常涉及读取域控制器安全日志：https://docs.paloaltonetworks.com/pan-os/7-1/pan-os-admin/user-id/create-a-dedicated-service-account-for-the-user-id-agent
-
Patch/Shavlik：许多补丁系统倾向于使用域管理员，因为它提供对每台计算机的管理权限。这不是最好的方法。按系统类型分开补丁，并确保每个类型有不同的服务账户：工作站、服务器、域控制器。
-
ServiceNow：所需权限取决于所需能力。确保遵循最小权限原则，并按计算机类型分开服务账户：工作站、服务器、域控制器。
-
Qualys/Nessus/Rapid7Scan/Scanner/VulnScan/VulnScanner：漏洞扫描系统服务账户通常放置在域管理员中，以便对域中的每台计算机具有管理权限。将扫描分成不同的扫描"桶"：使用VulnScan-wrk服务账户的工作站、使用VulnScan-srv服务账户的服务器、使用VulnScan-DC服务账户的域控制器。
-
SCCM/Management/Mgmt等：Microsoft System Center Management通常用于部署应用程序、更新系统设置、修补操作系统和应用程序等。
-
SCOM/Health/Insight/MOM/Management/Mgmt等：Microsoft System Center Operations Management是Microsoft提供的监控工具，通过事件日志和"管理包"监控系统和应用程序健康。通常有一个运行系统的标准服务账户，然后在域控制器上使用单独的"操作账户"，使分层服务器操作员能够"点击解决"域控制器上的问题，而无需成为域管理员成员。
-
SQL：没有理由让SQL ever在特权AD组（如DA）中。我们还发现在默认域管理员账户上配置了SQL服务主体名称（SPN），由于Kerberoasting的风险，这更糟。
-
Unity：Cisco服务账户永远不需要域管理员。Cisco在2018年底更新了Cisco服务账户的文档，因此请查看更新指南。
-
Varonis：Varonis主要用于跟踪Windows系统共享权限和访问。此服务账户可能放置在域管理员中以支持域控制器上的Varonis服务。可能有办法将此服务账户作为服务器操作员的成员运行。
-
VCenter/VMWare：没有理由让VMWare服务账户成为域管理员（或任何其他特权AD组）的成员。
-
VPN：没有好的理由让VPN服务账户在域管理员中。我们之前见过VPN相关服务账户在域管理员中，只是为了支持通过VPN连接且密码过期的用户。具有DA权限，VPN解决方案可以通知用户密码过期，请求新密码，并在AD中代表用户更新用户的AD账户密码。VPN服务账户不需要域管理员权限来代表用户更改密码。这些权限可以轻松委托到包含将通过VPN连接的用户的OU。
我们在ADSecurity.org有一个Kerberos服务主体名称（SPN）列表，定期更新（一年几次），将已知SPN映射到应用程序。这是在网络上发现部署的企业应用程序的好方法。
结论 供应商说他们的服务账户需要在域管理员中并不是一个要求。推回并询问所需的具体权限。任何"需要"域控制器权限的服务账户应受到严格限制——没有服务账户应仅为了DC安装而获得域管理员成员身份。任何可以在域控制器上安装/运行代码的系统/代理都可以升级到域管理员，这包括管理该系统的所有账户。
以下项目可以自定义委托而没有太多问题，这比将服务账户添加到域管理员更好：
- 将计算机添加到域（通过DC GPO上的用户权限分配 facilitated）
- 委托用户权限——通过OU中用户对象上的自定义委托 facilitated
- 域控制器上的服务账户——质疑为什么这是必要的。如果是，这可以通过代理或使用作为服务器操作员（或如果需要，管理员）成员的服务账户来 facilitated
- 所有工作站上的本地管理员权限——创建一个称为"工作站本地管理员"（或类似）的组，并通过链接到包含工作站的OU的GPO使用受限组添加到本地管理员组
- 服务器上的本地管理员权限——创建一个称为"____服务器本地管理员"（或类似）的组，并通过链接到包含服务器的OU的GPO使用受限组添加到本地管理员组