how to provision a service account in active directory

TL;DR

Create the account in a dedicated Service Accounts OU with a descriptive name, set a long random password that never expires (or better, a managed service account), grant only the permissions the app needs, document the owner and purpose, and add it to the password-rotation schedule.

The error

(New service needed; no error. Proactive provisioning request.)

Steps

1. Create the account in the designated Service Accounts OU, not the Users OU. Expected: account created with "User cannot change password" and "Password never expires" per your service-account policy, or use a group Managed Service Account (gMSA) instead.
2. Set a 32+ character random password and store it in the privileged vault. Expected: vault entry created. Never email the password.
3. Add the account only to the groups the application requires. Expected: minimal membership. Start with nothing and add per the app's documented needs.
4. Set delegation carefully: if the app needs Kerberos delegation, constrain it to the specific services. Expected: constrained delegation configured. Unconstrained delegation on service accounts is a classic attack path.
5. Document in the ticket/CMDB: owner, purpose, app, expiry/review date. Expected: record complete. Every service account needs an owner or it becomes permanent mystery access.

When to use

• New application, script, or integration needs AD authentication
• Replacing a shared human account used by a service

When not to use

• Human access (provision a user account instead)
• Cloud-only workloads (use a managed identity in Entra ID)

Compatibility

• Windows Server Active Directory; gMSA needs 2012+ forest functional level

Variants

App supports gMSA

Prefer it: the password is managed by AD automatically and never known to humans.

Vendor insists on domain admin for the service account

Push back. Grant the specific rights the app needs; domain admin service accounts are how breaches spread.

Why it happens

Services need identities to authenticate, but human-account practices (expiring passwords, interactive logon) break automation. Service accounts exist to give automation a stable, least-privilege identity.

Edge cases

• Service accounts are prime Kerberoasting targets: use long passwords and monitor for unusual ticket requests.
• Review service accounts quarterly; orphaned ones from dead projects are common.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstjzoh7YHV8Lm1tW5KLNijQ