How do you handle old service accounts when moving away from RC4?

Start by checking whenCreated and pwdLastSet on the account. A password last set before AES support was available is a useful warning sign, but the dates alone don't prove which keys exist or which encryption types are actually being used.

Review the account's encryption type settings and Kerberos events, then test in an environment that resembles production. A password reset after AES support is in place can generate AES keys, but the service and its configuration also need to support AES.

Resetting to the same known password may be a way to generate AES keys without updating every stored credential, assuming policy allows it. That is a compatibility workaround, not password rotation. It leaves the old secret and its associated exposure in place, so I'd treat it as a temporary step and plan a real change.

The hard part is often finding everywhere the account is used. Coordinate with the teams responsible for services, IIS app pools, databases and application configuration before changing anything. Map the dependencies, test a rollout and have a rollback plan.

If the password is unknown, a same-password reset isn't an option. Look for authorized access to existing configuration and prepare to update each dependency to a new credential. Waiting for an update to expose the problem is a pretty rough migration plan.

Consider group managed service accounts where the applications and infrastructure support them. They can reduce the burden of managing shared service account passwords, though switching an established application may take testing and coordination. They aren't a drop-in fix for every dependency.

Don't assume an RC4-derived password hash means any password can be recovered in a few minutes. Offline guessing speed depends on the password and the resources available. RC4 service tickets do make password guessing a concern, though, which is another reason to replace old secrets rather than just preserve them.