Service Account Password Rotation: Find Every Dependency

Changing a service account's password takes seconds; finding every service, task, app pool, keytab and script that still holds the old one is the part that causes outages and lockouts. A domain user account used as a service account is set and rotated manually, and its password is copied into the Service Control Manager, Task Scheduler, IIS configuration, SQL Server, Linux keytabs, mount credential files and application config. Miss one copy and the account locks out at 3am, taking every other consumer with it. This guide is the hands-on runbook for one account at a time on Windows and Linux: where the password hides, how to find each consumer from configuration and from authentication logs, the change sequence, verification, rollback and when to stop rotating and move to a managed account. It is for Windows and Linux administrators and identity operations teams. For programme-level rotation design, see Credential Rotation at Scale.

Key takeaways

The password lives in many places, not one. Services, scheduled tasks, IIS application pools, SQL Server services, keytabs, CIFS credential files and application configs each store their own copy.
Logs find what inventories miss. Domain controller events 4740 (Caller Computer Name) and 4771 (Client Address) show every host still presenting the account, including ones nobody documented.
Keytabs break silently. A Kerberos keytab holds keys derived from the password, so a password change makes every keytab for that account stale until it is regenerated and redeployed.
Plan the rollback before the change. Decide in advance whether you will restore the old password or fail over to a standby account, because a lockout cascade leaves no time to debate it.
The best rotation is the one Windows does for you. Where the consumer supports it, move to a gMSA, dMSA or virtual account and retire the manual runbook.

Where a service account password is stored

Microsoft describes a traditional user account running a service as an ordinary domain account that "follows Active Directory password policy and is managed manually by an administrator". Each consumer keeps its own copy, in its own store, changed with its own tool.

Consumer	Where the copy lives	How to change it	Takes effect
Windows service	Service Control Manager (logon account is the `StartName` of `Win32_Service`)	`Set-Service -Credential` (PowerShell 6.0 and later), services.msc or `sc.exe config`	Next service start
Scheduled task	Task Scheduler, stored when the task is set to run whether the user is logged on or not	`Set-ScheduledTask -User -Password` or the Task Scheduler console	Next run
IIS application pool	`processModel` with `identityType` SpecificUser, `userName` and `password`	IIS Manager or AppCmd.exe, which encrypt the password before writing it	Pool recycle
SQL Server and SQL Server Agent	Service logon account	SQL Server Configuration Manager, Log On tab	Service restart; databases on the instance are unavailable until it restarts
Linux Kerberos service	Keytab (for example `/etc/krb5.keytab` or a service-specific keytab)	Regenerate the keytab with the new key version and redeploy	Next ticket request
Linux CIFS mount	`credentials=` file with `username=`, `password=` and `domain=` lines, or `PASSWD` variables	Edit the file, remount	Next mount
systemd service	Unit file, environment file or, better, a systemd credential	Update the credential file or re-encrypt with `systemd-creds`	Service restart
Application and script	Connection strings, config files, ODBC DSNs, vaults, CI variables, mapped drives	Per application	Varies

Two practical notes from the vendor documentation. For IIS, Microsoft advises entering pool passwords through AppCmd.exe or IIS Manager so they are encrypted, rather than editing the XML by hand. For SQL Server, Microsoft documents account changes through SQL Server Configuration Manager and states that the Database Engine must restart, so schedule the change in a maintenance window. On failover clusters, make the change from the active node.

Find every dependency before the change

Use two independent methods and compare them: configuration discovery (what is set up to use the account) and authentication evidence (what actually presents the account). Anything that appears in the second list but not the first is the consumer that will lock you out.

Configuration discovery

Windows services: the logon account is a property of Win32_Service, so query Get-CimInstance Win32_Service and select Name and StartName across every server, filtering for the account's down-level or UPN name.
Scheduled tasks: enumerate tasks with Get-ScheduledTask and inspect each task's principal for the account. Include tasks deployed by Group Policy Preferences.
IIS: list application pools whose processModel.userName is the account, and check virtual directories configured to connect as a specific user.
SQL Server: check Database Engine, Agent, Reporting and Integration Services logon accounts, plus SQL Agent proxies and credentials that reference the account.
Linux: search /etc/fstab and credential files for the account name, list keytabs and their principals with klist -k (note the KVNO column), check User= lines and credential directives in systemd units and the crontabs of any local user mapped to the account.
Code and config: search repositories, configuration management (Ansible, Puppet, Group Policy) and vaults for the account name. See the Service Account Inventory Template.

Authentication evidence

Event	Where	What it tells you
4624 successful logon	Member servers	Which hosts the account logs on to, with logon type (5 is a service logon, 4 is batch, used by scheduled tasks)
4768 and 4769 Kerberos ticket requests	Domain controllers	Every client address requesting a TGT or service ticket as the account
4771 Kerberos pre-authentication failed	Domain controllers only	Failure code 0x18 means wrong password; Client Address names the host still holding the old one
4625 failed logon	Member servers and workstations	NTLM or local failures with the bad password after the change
4740 account locked out	Domain controllers, member servers and workstations	Caller Computer Name is the computer the failed logons came from before the lockout
7038 and 7000 (System log, Service Control Manager)	The host running the service	The service could not log on with the configured password, or failed to start

Our recommendation is to collect at least 30 days of 4624, 4768 and 4769 events for the account before a planned rotation, so monthly and quarter-end jobs show up. Build a host list from those events and reconcile it with the configuration list. See the Active Directory Security Monitoring and Event IDs Guide.

Choose the rotation pattern

Pattern	How it works	Choose it when	Trade-off
In-place change	Reset the password, then update every consumer as fast as possible	Few consumers, all on hosts you control, tolerant of a short restart	Every consumer briefly holds the wrong password; one missed consumer causes a lockout
Alternating accounts	Two accounts with identical rights; move consumers to the standby, then reset the idle one	Many consumers or no maintenance window	Double the accounts to govern; both must stay in sync on group membership
Managed account migration	Replace the user account with a gMSA, dMSA or virtual account	Consumer is a Windows service, task or IIS pool that supports it	Requires testing per application; not every product supports managed accounts
Vault-driven rotation	A privileged access or secrets tool changes the password and pushes it to registered consumers	Large estates with a mature consumer inventory	Only as good as the registered dependency list

The alternating pattern and overlap design are covered in Credential Rotation at Scale; the template version of this procedure is in the Secrets Rotation Runbook Template.

The change runbook

Confirm scope and approvals. Record the account, owner, consumer list (configuration and log evidence), change window and rollback choice. Notify owners of every consumer.
Check lockout exposure. Note the lockout threshold that applies to the account (default domain policy or a fine-grained password policy). If a stale consumer could trip it within minutes, consider a temporary fine-grained policy for the change window, recorded and removed afterwards.
Generate and store the new password. Create it in your vault, long and random. Microsoft notes there is no service-account-specific minimum length: the domain policy or a fine-grained policy applies, so set one for service accounts.
Reset the password in Active Directory. Use a single writable domain controller and target consumers' updates after replication, or point your tooling at the same DC.
Update Windows consumers. Services with Set-Service -Credential or the console, scheduled tasks with Set-ScheduledTask -User -Password, IIS pools through IIS Manager or AppCmd, SQL Server through Configuration Manager. Restart or recycle each in a controlled order.
Regenerate keytabs. For accounts mapped to Kerberos principals for Linux or Java services, generate a new keytab with the new password and the correct key version number, specify AES encryption types explicitly (Microsoft's ktpass documentation advises always setting /crypto), deploy it securely and replace the old entries. See the Linux Service Accounts and Keytab Management Guide.
Update Linux files and units. CIFS credential files (root-readable only), systemd credentials, application configs; remount or restart.
Update applications and scripts. Connection strings, ODBC DSNs, vault entries consumed at runtime.
Verify. For each consumer, confirm a fresh successful logon (4624 or 4768) from its host after the change time, and that 4771 with 0x18 and 4625 failures for the account are zero over the next full job cycle.
Close. Update the inventory with any consumer found during the change, record the new rotation date and remove any temporary policy.

Rollback

Standby account: if you used alternating accounts, point failed consumers back at the account that still has the old, valid password. This is the cleanest rollback.
Password restore: if you must restore the previous password, confirm beforehand that your password history policy and tooling allow it, and keep the old value in the vault only for the change window.
Lockout cascade: unlock the account, then fix or temporarily stop the consumer named in 4740's Caller Computer Name before unlocking again, otherwise it relocks.

Store the new password better than the old one

Linux services: use systemd credentials rather than environment variables. Per the systemd documentation, credentials are exposed in $CREDENTIALS_DIRECTORY, accessible only to the service's user, not passed to child processes, held in non-swappable memory where possible, and LoadCredentialEncrypted= with systemd-creds encrypt can bind the secret to the machine's TPM2. SetCredential= places a value in a world-readable unit file and is only for non-sensitive data.
CIFS mounts: the mount.cifs documentation prefers a credentials file over plaintext in /etc/fstab and says to "protect any credentials file properly".
IIS: use the tools that encrypt the pool password; never paste it into applicationHost.config.
Scripts: read the password from a vault at runtime instead of embedding it. See the Service Account Security Guide.

When to stop rotating and migrate

Microsoft's service account documentation describes managed alternatives that remove manual rotation:

gMSA: Windows rotates the password every 30 days by default (set only at creation through ManagedPasswordIntervalInDays), and authorised hosts retrieve it. Suitable for services, tasks and IIS pools across several servers. See the Group Managed Service Accounts (gMSA) Guide and How to convert AD service accounts to gMSA.
dMSA: new in Windows Server 2025, a machine-linked account with randomised keys that can replace an existing service account and disables the old account's password.
Virtual accounts and ApplicationPoolIdentity: no password to manage; network access uses the computer account. Microsoft's IIS documentation notes ApplicationPoolIdentity has fewer rights than NetworkService, LocalService or LocalSystem.
Linux: where services authenticate to AD, a host keytab maintained by the domain join tooling can replace a user-account keytab. See the SSSD and Linux Active Directory Integration Guide.

Small estates: run this runbook by hand twice, then migrate whatever you can. Large estates: make "supports gMSA" a procurement requirement, register every remaining consumer in your vault tooling and rotate on a schedule.

Detection and measurement

Stale consumers: count of 4771 (0x18) and 4625 events for the account in the 7 days after a change (target zero).
Lockouts: 4740 events for service accounts; alert on every one, and on any Caller Computer Name outside the account's known hosts.
Inventory accuracy: consumers discovered during the change that were not in the inventory beforehand (target zero after two cycles).
Password age: percentage of user-based service accounts with a password older than your policy interval (our suggestion: 12 months at most for long, random, vaulted passwords, sooner on suspicion).
Migration progress: percentage of service consumers running as gMSA, dMSA or virtual accounts.

Common failure patterns

Trusting the CMDB alone. The undocumented quarter-end task on a forgotten server relocks the account a month later. Use authentication logs.
Forgetting keytabs. Linux and Java services keep working on cached tickets, then fail when tickets expire, hours after the change window closes.
Changing SQL accounts in services.msc. Use SQL Server Configuration Manager as Microsoft documents, and plan for the restart.
Interactive use of the service account. Someone's mapped drive or saved RDP credential holds the old password and causes lockouts. Block interactive logon for service accounts.
Never rotating because it is hard. A password unchanged for a decade is likely in scripts, wikis and ex-staff memories. See How to find and retire Active Directory service accounts with SPNs.

Framework mapping

Framework	Reference	What this runbook provides
NIST SP 800-53 Rev. 5	IA-5 Authenticator Management; IA-5(1) Password-based Authentication	Controlled change and protected storage of service account passwords
NIST SP 800-53 Rev. 5	CM-8 System Component Inventory; CM-3 Configuration Change Control	Consumer inventory and an approved change with rollback
NIST SP 800-53 Rev. 5	SI-4 System Monitoring	4740, 4771 and 4625 monitoring for stale consumers
NIST CSF 2.0	PR.AA-01 Identities and credentials for authorized users, services, and hardware are managed	Lifecycle management of a service credential
CIS Controls v8.1	Safeguard 5.5 Establish and Maintain an Inventory of Service Accounts	Dependency list kept current at each rotation
ISO/IEC 27001:2022	Annex A 5.17 Authentication information	Allocation and management of the service password

Practitioner checklist

Build the consumer list from configuration (services, tasks, IIS pools, SQL, keytabs, mounts, configs) and from 30 days of authentication logs, and reconcile the two.
Choose in-place, alternating or managed migration per account, and write down the rollback before the change.
Check the lockout threshold that applies to the account and decide how to handle it for the window.
Reset the password once, on a known domain controller, from a vault-generated value.
Update each consumer with its own documented tool and restart in a set order.
Regenerate and redeploy every keytab for the account with AES encryption types.
Verify fresh successful logons per consumer and zero 0x18 failures over a full job cycle.
Move Linux secrets into systemd credentials or protected credential files.
Record new consumers in the inventory and schedule the next rotation or migration.

Rotating a Windows or Linux Service Account Password: Find Every Dependency Before You Change It