We have a custom authentication provider that's been working for 2 years. We recently made a change in the web service it calls for authentication, with no problems at all on 2 dev machines.
Our QAS farm has 2 WFE's and 2 App Servers. Logins have stopped working after we deployed the update.
Like most custom authentication providers, we set the token through code. From our remote debugging we know that the user and password match up and that we're successfully setting the token. We use the code:
SecurityToken token = SPSecurityContext.SecurityTokenForFormsAuthentication(
new Uri(SPContext.Current.Web.Url), GDUtils.GetMembershipProvider(Context),
GDUtils.GetRoleProvider(), user.UserId, string.Empty, SPFormsAuthenticationOption.PersistentSignInRequest);
SPFederationAuthenticationModule.Current.SetPrincipalAndWriteSessionToken(token);
It may be a bit hard to follow with the calls to our custom classes, but you can see that we're creating a token for the login, and then saving it to the session. and most importantly - it's been working for 2 years. So I don't think this
is the problem.
After that we redirect to the root '/' url of the site using SPUtility.Redirect. This is where we get a threat.abordt exceptioon and are redirected back to the forms logon page. This is new and I think it's is a side effect of the authentication problems.
Below is what I'm seeing in the logs. Note that we know from our remote debugging that the provider is successfully validating the username and password a combination
xe (0x18B0)0x1200SharePoint FoundationTopologyaeaybMediumSecurityTokenServiceSendRequest: RemoteAddress: 'http://localhost:32843/SecurityTokenServiceApplication/securitytoken.svc' Channel: 'Microsoft.IdentityModel.Protocols.WSTrust.IWSTrustChannelContract' Action: 'http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/Issue'
MessageId: 'urn:uuid:bc487f7f-944b-4ed5-8e10-f612546fb693'
10/29/2015 14:39:17.55w3wp.exe (0x10EC)0x1124SharePoint FoundationTopologyaeax9MediumSecurityTokenServiceReceiveRequest: LocalAddress: 'http://servernameq.springswf.com:32843/SecurityTokenServiceApplication/securitytoken.svc' Channel: 'System.ServiceModel.Channels.ServiceChannel' Action: 'http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/Issue'
MessageId: 'urn:uuid:bc487f7f-944b-4ed5-8e10-f612546fb693'80011f6e-da67-4cd5-8d83-bd43b15ae019
10/29/2015 14:39:17.55w3wp.exe (0x10EC)0x1124SharePoint FoundationMonitoringnasqMediumEntering monitored scope (ExecuteSecurityTokenServiceOperationServer). Parent No80011f6e-da67-4cd5-8d83-bd43b15ae019
10/29/2015 14:39:17.55w3wp.exe (0x10EC)0x1124SharePoint FoundationClaims Authenticationaf3ymMediumToken Handler: Claims Forms Rebuild: Membership Provider 'MyCustomMembershipProvider' validation of user '0000187972' failed. User not found.80011f6e-da67-4cd5-8d83-bd43b15ae019
10/29/2015 14:39:17.55w3wp.exe (0x10EC)0x1124SharePoint FoundationClaims Authenticationfo1tMonitorableSTS Call: Failed to issue new security token. Exception: System.ServiceModel.FaultException`1[Microsoft.IdentityModel.Tokens.FailedAuthenticationException]: The security token username and password could
not be validated. (Fault Detail is equal to Microsoft.IdentityModel.Tokens.FailedAuthenticationException: The security token username and password could not be validated.).80011f6e-da67-4cd5-8d83-bd43b15ae019
10/29/2015 14:39:17.55w3wp.exe (0x10EC)0x1124SharePoint FoundationMonitoringb4lyMediumLeaving Monitored Scope (ExecuteSecurityTokenServiceOperationServer). Execution Time=4.3088576900136880011f6e-da67-4cd5-8d83-bd43b15ae019
10/29/2015 14:39:17.56w3wp.exe (0x18B0)0x1200SharePoint FoundationClaims Authenticationfsq7HighSPSecurityContext: Request for security token failed with exception: System.ServiceModel.FaultException: The security token username and password could not be validated. at Microsoft.IdentityModel.Protocols.WSTrust.WSTrustChannel.ReadResponse(Message
response) at Microsoft.IdentityModel.Protocols.WSTrust.WSTrustChannel.Issue(RequestSecurityToken rst, RequestSecurityTokenResponse& rstr) at Microsoft.IdentityModel.Protocols.WSTrust.WSTrustChannel.Issue(RequestSecurityToken
rst) at Microsoft.SharePoint.SPSecurityContext.SecurityTokenForContext(Uri context, Boolean bearerToken, SecurityToken onBehalfOf, SecurityToken actAs, SecurityToken delegateTo, SPRequestSecurityTokenProperties properties)
10/29/2015 14:39:17.56w3wp.exe (0x18B0)0x1200SharePoint FoundationClaims Authentication8306CriticalAn exception occurred when trying to issue security token: The security token username and password could not be validated.
10/29/2015 14:39:17.56w3wp.exe (0x18B0)0x1200SharePoint FoundationClaims Authenticationad1q3UnexpectedToken Cache: Failed to rebuild forms user token for user '0#.f|mymembershipprovider|user1'.
10/29/2015 14:39:17.56w3wp.exe (0x18B0)0x1200SharePoint FoundationClaims Authenticationaf30jUnexpectedToken Cache: Failed handle missing token for user '0#.f|mymembershipprovider|user1'.
I've been googling and have seen a wide variety of results and fixes for these errors. I'm getting the impression that the problem is in validating our newly created the token once the request actually makes it to the site. I've read a
few articles saying the machineKey is different between the STS web.config and web.config for the site that make a bit of sense, but that doesn't explain why this problem just started.
Any thoughts would be greatly appreciated.
Thanks,
Nate