We've been using a custom authentication provider for GroupShare for a couple of years without any problems. As of this morning (that I know about) GroupShare is not granting us access.
Our custom authentication provider calls a different authentication API with the username and password, then returns a boolean result. We have a log file for our provider, and I can see in this log file entries such as this...
09:59:52:597929 | ValidateCredentials | userName = "[elided for security]", password =  characters..
09:59:56:074828 | ValidateCredentials | Returning "OK" for userName "[same as previous username]"
So our provider is returning a TRUE result for that request.
However, if I then look in Sdl.Application.log I can see...
2019-02-05 09:54:55.820#Sdl.StudioServer.Services.Core.Hosting.WindowsServiceHost#System.DirectoryServices.AccountManagement, Version=184.108.40.206, Culture=neutral, PublicKeyToken=b77a5c561934e089
2019-02-05 09:54:55.867#Sdl.StudioServer.Services.Core.Hosting.WindowsServiceHost#Supertext.GroupShare.AuthenticationProvider, Version=1.0.6694.17632, Culture=neutral, PublicKeyToken=c28cdb26c445c888
2019-02-05 09:54:59.439#Sdl.StudioServer.Authorization.AuthorizationServer.AuthServerClientCredentialsGrant#System.Security.SecurityException: Authentication failed for user '[SAME USERNAME AS OTHER LOG FILE]'.
at Sdl.StudioServer.Services.IdentityModel.UserManager.AuthenticateUser(String userName, String password)
at Sdl.StudioServer.Authorization.AuthorizationServer.AuthServerPasswordGrant.AuthorizeUser(String userName, String password)
The Zone of the assembly that failed was:
This hasn't happened before and there have been no updates to GroupShare or our authentication provider.
What could be causing this? A windows update?