Skip to content
stellvia.dev

Service Account Design and Operations

This guide covers service account types, password management, and permission delegation through OUs and ACLs. It also considers whether accounts can be audited continuously after they are created.

Why manage service accounts?

Section titled “Why manage service accounts?”
  • Service accounts are identities that people do not log into, so leaked or reused credentials can be harder to detect.
  • Without strict least privilege, a compromise can expand lateral movement and its effect across the domain.
  • Password rotation and audit trails (event logs and Kerberos ticket auditing) are hard to add later if they are not included in the initial design.

Examples

  • A legacy shared service account is left with Domain Admin rights, with no logon history recorded on every DC.
  • A SQL Server account is reused across servers, allowing a compromise of one server to spread to all of them.

Common misconceptions

  • “A service needs high privileges”: RBAC and least privilege are often sufficient.
  • “Nobody uses it, so it needs no auditing”: Actions through a service also need auditing. Logs are necessary to detect unusual behavior.

Considerations

  • Decide on audit policies (logons and privilege use) early. Extending GPOs later can have a broad impact.
  • Prefer automatically managed accounts (gMSAs) over manual password management.

Types of service accounts

Section titled “Types of service accounts”
  • User-based service account: Reuses a standard user account. It is flexible, but manual password management creates significant risk.
  • MSA (Managed Service Account): Automatically manages the password for one host. It does not support multiple hosts.
  • gMSA (Group Managed Service Account): Supports multiple hosts, assumes Kerberos, and automatically manages the password. It is the main current option.
  • For a new design, a gMSA is generally the first practical choice.

Examples

  • User-based: Share svc-sql01 across servers and manually register setspn -S MSSQLSvc/sql.contoso.com:1433 svc-sql01.
  • MSA: Configure svc-iis$ only for IIS01 and run Install-ADServiceAccount on that one server.
  • gMSA: Share webpool$ across an IIS farm; each server retrieves the password automatically.

Common misconceptions

  • “An MSA can be used on multiple servers”: An MSA is intended for one host. Choose a gMSA for multiple hosts.
  • “A gMSA solves everything outside Kerberos”: gMSAs are designed for Kerberos authentication. The benefits are limited for NTLM-only services.

Considerations

  • If user-based accounts remain, manage their SPNs with duplicate checks (setspn -S).
  • Ensure the domain meets gMSA functional level requirements (generally 2012 or later). DC time synchronization is also essential.

dMSAs and delegation design

Section titled “dMSAs and delegation design”
  • A dMSA is not a “new account type,” but an operating model for delegating who creates gMSAs and in which OUs and on which hosts they are used.
  • Central AD administrators separate duties by delegating “gMSA creation and password retrieval rights by OU or group.”

Examples

  • A central team delegates gMSA creation directly under OU=Apps,DC=contoso,DC=com to an application operations team. Only the IIS-Farm group receives password retrieval rights.
  • OUs are separated by production line, and ACLs let each line’s operators manage only gMSAs in their own OU.

Common misconceptions

  • “A dMSA is distinct from a gMSA”: It is a gMSA in substance; the delegation design, naming, and request workflow differ.
  • “Delegation makes everything safe”: Delegating rights over a broadly scoped OU still grants too much access. OU design must be considered alongside delegation.

Considerations

  • If OUs are broad, such as “one OU per site,” delegation cannot be granular enough to realize the benefits of dMSAs. Consider dividing OUs by purpose.
  • Document delegation scope, naming rules, and request and review workflows. Make changes traceable through audit logs, such as group-change events 4728/4732.

AD directory structure: DC, OU, and CN

Section titled “AD directory structure: DC, OU, and CN”
  • DC (Domain Component): Represents the domain name hierarchically in LDAP. It is the tree root (for example, DC=contoso,DC=com).
  • OU (Organizational Unit): An administrative unit that separates GPO application, permission delegation, and operational boundaries.
  • CN (Common Name): Identifies an actual object. Users, computers, groups, and gMSAs can all be represented with CNs.

Examples

  • Administrator account: CN=Administrator,CN=Users,DC=contoso,DC=com
  • Computer: CN=PC01,OU=Clients,OU=Tokyo,DC=contoso,DC=com
  • gMSA: CN=webpool$,OU=ServiceAccounts,OU=Apps,DC=contoso,DC=com
  • SQL service account: CN=svc-sql01,OU=DB,OU=ServiceAccounts,DC=contoso,DC=com

Diagram: AD hierarchy (DC/OU/CN)

Section titled “Diagram: AD hierarchy (DC/OU/CN)”

Note: CN=Users is a container. Although its RDN is a CN, it is a special object that can contain child objects such as CN=Administrator. CN= only indicates the type of name; it does not determine whether the object can have children like an OU (containers and OUs can have children, while ordinary objects generally cannot).

Common misconceptions

  • “The Users container is the same as an OU”: CN=Users is a container and is not a target for delegation or GPOs. Move objects to a dedicated OU if they need to be managed.
  • “CNs are only for users”: Many objects, including computers and gMSAs, use CNs.

Considerations

  • An OU hierarchy that is too deep complicates GPO application and replication checks. Balance administrative units with delegation units.
  • Scripts handling LDAP paths are case-insensitive, but the exact spelling and structure of OUs and CNs must be checked carefully.

OU ACLs and permission delegation

Section titled “OU ACLs and permission delegation”
  • Windows/AD ACLs control “permissions to operate on objects.” They differ from network ACLs, which allow IP addresses and ports.
  • Common rights include Create/Delete Computer Object, Reset Password, Write on specific attributes, and gMSA password retrieval (Read msDS-ManagedPassword).
  • ACLs set on an OU are inherited by objects beneath it. Exceptions can block inheritance.

Examples

  • Delegate “create new computers” and “read gMSA passwords” directly under OU=Apps to an application operations group.
  • Delegate “reset passwords” and “disable accounts” under OU=Clients to the help desk, without inheriting those rights into the server OU.

Diagram: OU ACL inheritance

Section titled “Diagram: OU ACL inheritance”

Common misconceptions

  • “An ACL can control network traffic too”: AD ACLs govern only operations on objects. Firewalls and network ACLs control traffic.
  • “Using Domain Admin everywhere is safe”: Widespread use of high privileges makes auditing harder and increases the risk of mistakes. Split responsibilities through delegation.

Considerations

  • Extensive inheritance can propagate unintended rights to child OUs. Document exceptions and review them regularly.
  • Grant permissions through groups as a rule, avoiding direct grants to individual accounts.

Relationship to network concepts

Section titled “Relationship to network concepts”
  • An OU resembles a VLAN or segment as an “administrative boundary.” It divides operational permissions and policy application, not network traffic.
  • An AD ACL is about allowing or denying operations on objects, not an IP allow/deny rule in a network ACL.
  • A VRF (Virtual Routing and Forwarding) divides routing namespaces. It is not an exact match, but the idea of separating scopes to reduce collisions and impact can help explain the OU/ACL model.

Examples

  • Imagine separating OU=Apps like a VLAN and delegating application operations rights only there.
  • Allowing only a specific group to retrieve a gMSA password resembles allowing a particular port through a network ACL.

Common misconceptions

  • “Separating OUs also isolates network traffic”: This is an AD administrative boundary, not actual network segmentation. Design VLANs and firewalls as needed.
  • “A VRF provides the same function”: The aims are similar, but the implementations differ. OUs and ACLs separate directory operation rights.

Considerations

  • Network and AD teams should share an understanding of what is being separated. Misunderstanding can undermine the expected risk reduction.
  • If OU and network boundaries diverge, operational work and auditing become more complex; update their mapping regularly.

Operational and design points

Section titled “Operational and design points”
  • OU design trades off delegation and management cost: too broad and delegation is impossible; too fine and management grows costly. Divide by purpose, operating team, and security boundary.
  • Use role-based group design (RBAC) and naming rules, with regular reviews.
  • Before adopting gMSAs/dMSAs, decide delegation scope, auditing, and the request workflow. Also plan migration from existing user-based accounts.

Examples

  • OU design: Split OU=Servers into OU=Web, OU=DB, and OU=Mgmt and delegate each to its operations group.
  • Group naming: Include purpose, rights, and scope in names such as GRP-APP-WebOps-Admin and GRP-DBA-Operators.
  • gMSA migration: Replace an existing svc-iis with webpool$ (gMSA), switching IIS application pools in stages.

Common misconceptions

  • “Finer delegation is always safer”: Excessive fragmentation can make operations unworkable and push teams back toward using Domain Admin.
  • “A gMSA removes the need for auditing”: You still need to audit who may retrieve the password and where the account is used.

Considerations

  • Keep a change history for delegation settings and review them annually or quarterly. Check Group Policy delegation at the same time.
  • Include “SPN registration,” “adding/removing hosts for a gMSA,” and “cleanup at decommissioning” in the request workflow.
  • Parameterize target OUs and groups in automation scripts instead of hard-coding them to prevent misapplication.

Appendix

Section titled “Appendix”
  • Keep shared terminology and design and operational checkpoints in one place.

Example

  • Establish a process for consulting the glossary and checklist below during kickoffs and regular reviews.

Common misconception

  • “Terms and checklists can be added later”: Sharing them from the start provides a more consistent basis for design decisions.

Consideration

  • Adjust terminology to organizational standards and revisit it as product versions change.

Glossary

Section titled “Glossary”
  • MSA (Managed Service Account): An automatically managed service account for one host.
  • gMSA (Group Managed Service Account): An automatically managed service account for multiple hosts, designed around Kerberos.
  • dMSA (delegated Managed Service Account): A model for delegating gMSA creation and use rights, not a new kind of account.
  • DC (Domain Controller/Component): A server that manages the domain / a domain component of an LDAP path.
  • OU (Organizational Unit): A unit of administration, delegation, and GPO application.
  • CN (Common Name): An object’s name, including users, computers, groups, and gMSAs.
  • ACL (Access Control List): A list of permissions for operations on an object.
  • SID (Security Identifier): A unique identifier for a Windows security principal.
  • Kerberos: A ticket-based authentication protocol. gMSAs are designed around Kerberos.

Checklist (design and operations)

Section titled “Checklist (design and operations)”
  • Are OUs sized for the intended delegation (neither too broad nor too fine)?
  • Are group names and roles (RBAC) clear, with a defined review frequency and owner?
  • Are gMSA/dMSA delegation scopes and request workflows documented, with audit logging methods defined?
  • Is there a list of remaining user-based service accounts, a gMSA migration plan, and a deadline?
  • Are SPN management (duplicate checks), password rotation policy, and event logging and auditing configured?

References

Section titled “References”