2

Basically we have a service where we use a local account as its logon. it has all the proper permissions, and everything is working fine, service starts and runs and all is good. Then one day, after rebooting, the service fails to start. Logs show incorrect password. Our technicians resolve the issue by simply retyping the password into the "Log On" tab from the services.msc. Unfortunately we have not been able to root cause. I suspect that the password that is stored for the service is lost somehow. Does anyone know where the password hash might be stored so we can check it? The only activities that seem to be possibly related are patching with Microsoft security patches, but we have multiple servers running the same service, and we have never seen more than one at a time, and its usually a different one each time when this occurrs.

I believe this to be the same issue as this: Windows service fails to start with custom user until started once with local user But i was unable to add comments, and its really old.

UPDATE: We have linked this issue to the Logon as Service policy. The account is removed somehow from this setting. Retyping the password in the services console re-adds the account to this policy. We will now want any suggestions on how to root cause why the account is removed. We have enabled "audit policy change" and set to audit for both success and failure.

2 Answers 2

4

For those that are still looking for an answer to this. The issue is that you have a policy and that account is not setup to run as a service. When you re-type the password it grants the account Run as a service rights. Depending on the OS version you could run gpresult /H filename.html /F and look at the policies that are applied. Then add that account to the group policy granting the service account rights.

0

I don't have a definitive fix for you, but a simple troubleshooting step is to re-type the password for the service account, apply, then stop and restart the service. It should start just fine. If not, then there may be a permissions issue in writing the hash out to the SAM. You can use ProcessMonitor from http://sysinternals.com to help identify a permissions issue.

If the service does restart and the issue only occurs after a period of time or a reboot, then something is changing the password. For that you will have to enable auditing to see when/if it gets changed.

1
  • Chris, we have done precisely that, retype the password, and we are back to normal because that automatically adds the account back into the logon as service policy. We cannot reproduce the issue consistently so its challenging to run a procmon for extended periods. We have enabled auditing on what I believe is the correct setting,"audit policy change" is configured for success and failure.
    – Nick
    Commented Jan 24, 2013 at 21:30

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .