User authentication (AD) after password changes

Recently some of our users had a password reset of their AD credentials. After resetting their password they (via ADUC) they were unable to login to the environment overnight (roughly 9-10 hours).

I was able to get the authentication going again, but not after I tried both restarting the services (failed) and restarting the server (worked).

During this time, users that did not have a password reset were working fine. What is the standard way to handle this situation? Turning it off and on seems a bit heavy handed!

Product: BuildMaster
Version: 5.2.3

If you're using Windows Integrated Authentication, then there's some fairly complex, behind-the-scenes negotiation that goes on, and unfortunately we have no control over it. It all happens below the application stack (BuildMaster, ProGet, etc), at the IIS/HTTP.SYS level, and all the application receives is a LOGON_USER header if WIA was successful.

It shouldn't take a reboot, etc., after password resets... but if it did, there's probably a network/domain/ticketing configuration issue. Not sure how to diagnose/fix, but if rebooting it solved it, maybe that's the easiest route...

I assume the restart of the machine was not the resolving issue, but it was expedient early in the AM so my remote developers could deploy their packages. It was likely (more likely) related to needing to restart one of the services; but I restarted from the Front-End and am not sure if this restarts the appropriate ones.

I have done some tests and Buildmaster does seem to be reacting normally on password changes; but the theory is confusing nonetheless. When testing connectivity this morning, the user was able to log into TFS and our custom gatekeeper Oauth API which reside on the same server as the BuildMaster base.

I will monitor and if it occurs again I may come back at it; but it does not appear to be an issue now.

If it's a remote/vpn situation, that would make some sense. Something is likely caching tickets longer than it should be; the ELI5: Kerberos might give some insight into why this is really challenging to debug.

TFS does not uses WIA/Kerberos authentication (it has its own ticketing system for interoperability with VSO), and your OAUTH service definitely wouldn't use it.

I actually am at fault for not being thorough here; I jumped in without being diligent. I am not using Integrated, but using LDAP provider via forms in Buildmaster and it was this that was failing. My apologies!

Our custom OAUTH API gateway validates against ADFS prior to providing tokens, think of it as a custom Oauth2 token provider to provide SSO with Windows Auth. The whys and hows can be discussed offline if you want, though there are a few sites which explain this and the reasonings. This custom OAUTH Api/gateway worked at the time of Buildmaster not working.

Hence my confusion about why one was working and not the other. With that said, I will still continue to monitor. I will assume this was a "fluke" on the system side that is not worth troubleshooting.