Home / server / Questions / 1166566
Accepted
tb1
Asked: 2024-10-14 22:30:39 +0800 CST

AD password reset / sync time requirements to flush out RC4

  • 772

We have an old AD user account with a static password that is used on several machines for a scheduled task and a service. I know gMSA is better and separately am in the process of getting that in place, but this account needs to be up for a little while longer.

Back to this account: I want to change the password to meet current password strength critera and ensure the AES hash, but I wasn't sure if I needed to change it 2x with a 10 hour pause in-between, or if I can just change it back-to-back and push out the password update to the affected endpoints.

If anyone can clarify the 2x, 10-hour gap reset method or whether it can be back-to-back for this purpose, I'd be grateful.

Thanks!

active-directory

2 Answers

  1. Best Answer

    Back to this account: I want to change the password to meet current password strength critera and ensure the AES hash, but I wasn't sure if I needed to change it 2x with a 10 hour pause in-between, or if I can just change it back-to-back and push out the password update to the affected endpoints.

    The 10 hour pause is meant to allow users' Kerberos tickets to expire as they have a 10-hour lifetime by default (in AD at least).

    Kerberos is a shared-key system, where an account's password hash directly acts as the symmetric key for ticket encryption, and when your users obtain tickets for a service, those are encrypted using the service account's key (as well as the user's key but that's besides the point).

    Changing a service account's password (that is, changing it twice to flush out AD's password history) will therefore make all already-issued tickets invalid and will prevent users who had such tickets from accessing the service – I'm not 100% sure how the Windows Kerberos implementation reacts, but KRB_AP_ERR_MODIFIED would be my first guess.

    So if you do this during the working day, where clients are likely to have already obtained tickets for the service, you should only change the password once at first (and deploy to servers), so that old tickets remain valid against the 'old' key1; then let old tickets expire on their own (approx ~10 hours or whatever other ticket lifetime is configured in your AD) and change the service password again.

    1 Note though that I'm very unsure about how password history works in AD (I'm more familiar with Unix Kerberos implementations), but I think this is right.

    • 2

  2. The krbtgt account is the account that requires two password changes, and thus must observe the minimum time between changes. That is due to AD allows the current and previous password for that account. (Similar to trust accounts).

    In summary: not required to change the password twice, and there could be impact when a password is reset if existing service tickets are in use.

    • 1