1

I know the question is awkwardly phrased, and I also realize there are going to be multiple factors in this that don't lead to a single definitive answer.

I seem recall in the past, having services that were started up and frankly "just kept running", until the service (or server) was restarted -- and only then was it discovered that we missed updating a password.

I'm looking into an incident where a windows service failed recently. Based on some other questionable information, one of the assumptions being made is that a password change was made to the service account, and that when the password change occurred, that caused the service to fail. A problem in clearing this up is I'm being brought into this days later, when a lot of primary logs (Windows event logs, domain controller logs) are no longer directly available, and we are relying on downstream logs (SIEM)s that are not always reliable.

One thing I'm trying to point out, is that even assuming a password change occurred (which is unproven do to the log issue above) -- hanging the password of a domain service account does not immediately "break" the service, that authentications have a certain lifetime, and that lifetime can be much longer than expected. (Kerberos ticket lifetime, etc.) But honestly, while I know this generally, I'm not concretely clear on the factors here. I also believe that authorization can continue for quite some time, even with the underlying password change.

Can someone help me clarify this? What things can I look at in my windows environment how long a service would "survive" a password change.

dave_the_dev
  • 131
  • 3

0 Answers0