We recently installed new software on 10 Windows PCs. The application connects to a folder on a server, and the vendor instructed us to save the server credentials in Windows Credential Manager for every user who runs the software.
For single-user PCs, I manually added credentials for both the server's IP address and DNS name. On shared PCs, I placed a script in the common Startup folder that runs:
cmdkey /add:192.168.160.6 /user:Prod /pass:Trees
cmdkey /add:Prodserver /user:Prod /pass:Trees
Both approaches initially worked, but after several days some users began receiving errors that the software could not connect to the server. This occurs on both scripted and manually configured PCs. Editing both Credential Manager entries and re-entering the same password fixes the problem temporarily, but the issue returns a few days later.
What could cause stored Windows credentials to stop working over time? Could slow network performance, software behavior, updates, account policies, or something on the server be invalidating them? What logs or settings should I check to identify the underlying cause?
3 Answers
Look for changes around the time the failures begin, such as Windows or .NET updates, password or account policies, expired credentials, locked accounts, SMB security changes, or the server restarting. Slow network speeds normally cause timeouts rather than permanently invalidating a saved credential, so I would not treat network performance as the primary suspect. If users see a login prompt, make sure they are not entering a different password and replacing the working stored credential.
Verify whether the users already have permission to the share. If they do not, determine whether the application is supposed to use a separate service account or alternate credentials. Having every user store the same server password under both an IP address and a hostname is fragile, and the software may not be using the credentials the way the vendor expects. If rerunning cmdkey or editing the entry fixes it without changing the password, the application may be caching or passing the credentials incorrectly.
It would also be useful to confirm whether this is an Active Directory environment or a peer-to-peer setup, since authentication and credential handling differ significantly.
Re-entering the password is probably only masking the real problem. Check the Windows event logs on the affected PCs and the security, authentication, and file-share logs on the server at the exact time of a failure. Those should help distinguish an invalid-password problem from a name-resolution, permissions, connectivity, or application error. Also check whether the application has its own log files.
That makes sense. I will compare the client and server logs when it happens instead of just resetting the entries again.
The intended workflow is for the application to connect to the server share in the background while the user signs into the application separately. I will check whether any updates or prompts appeared on the affected machines.