## 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
```text
(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/pst_jzoh7YHV8Lm1t_W5KLNijQ