locked
ADFS Error Message when performing integration with SAML Application RRS feed

  • Question

  • Hi all,

    Here is my system architecture when performing SAML Authentication.

    User -> ADFS Proxy -> ADFS.

    I found that there is an SAML error when I type wrong username and which is not showing the ADFS login error page with wrong username/password. But it just throw back to the SAML application.

    By the way, if I go into

    User -> ADFS

    I found the error appear in ADFS error login prompt for wrong username.

    Do anyone have any insight for it?

    I am using ADFS 4.0.


    Friday, June 1, 2018 8:48 AM

All replies

  • Attached is the error log

    Exception details:
    Microsoft.IdentityServer.Service.AccountPolicy.ADAccountLookupException: MSIS8022: Unable to find the specified user account.
       at Microsoft.IdentityServer.Service.AccountPolicy.AccountLockoutPolicy.IsAccountThrottled(String userName)
       at Microsoft.IdentityServer.Service.AccountPolicy.ThreatDetector.AnalyzePreAuthRequest(RequestContext requestContext, SecurityTokenHandler tokenHandler, SecurityToken userToken, SecurityToken deviceToken, IList`1 detectionModuleGeneratedClaims)
       at Microsoft.IdentityServer.Web.WSTrust.SecurityTokenServiceManager.GetEffectivePrincipal(SecurityTokenElement securityTokenElement, SecurityToken deviceSecurityToken, SecurityTokenHandlerCollection securityTokenHandlerCollection)
       at Microsoft.IdentityServer.Web.WSTrust.SecurityTokenServiceManager.Issue(RequestSecurityToken request, IList`1& identityClaimSet, List`1 additionalClaims)
       at Microsoft.IdentityServer.Web.Protocols.PassiveProtocolHandler.SubmitRequest(MSISRequestSecurityToken request, IList`1& identityClaimCollection)
       at Microsoft.IdentityServer.Web.Protocols.PassiveProtocolHandler.RequestBearerToken(MSISRequestSecurityToken signInRequest, Uri& replyTo, IList`1& identityClaimCollection)
       at Microsoft.IdentityServer.Web.Protocols.PassiveProtocolHandler.RequestSingleSignOnToken(ProtocolContext context, SecurityToken securityToken, SecurityToken deviceSecurityToken)
       at Microsoft.IdentityServer.Web.Protocols.Saml.SamlProtocolHandler.BuildSsoSecurityToken(SamlSignInContext context, SecurityToken securityToken, SecurityToken deviceSecurityToken, SecurityToken& ssoSecurityToken)
       at Microsoft.IdentityServer.Web.Protocols.Saml.SamlProtocolHandler.BuildSignInResponseCoreWithSecurityToken(SamlSignInContext context, SecurityToken securityToken, SecurityToken deviceSecurityToken)
       at Microsoft.IdentityServer.Web.Protocols.Saml.SamlProtocolHandler.Process(ProtocolContext context)
       at Microsoft.IdentityServer.Web.PassiveProtocolListener.ProcessProtocolRequest(ProtocolContext protocolContext, PassiveProtocolHandler protocolHandler)
       at Microsoft.IdentityServer.Web.PassiveProtocolListener.OnGetContext(WrappedHttpListenerContext context)

    Friday, June 1, 2018 9:22 AM
  • Finally, I found the solution for this problem.

    This is caused by turning on the ADFSextranet Logout function which will cause the problem on ADFS 4.0

    I think there is a bug when handling SAML request.

    The problem has gone after we disable this feature.

    Set-AdfsProperties -EnableExtranetLockout $false

    Monday, June 11, 2018 2:12 AM
  • It's not really a bug. That's how it is intended to work and you can ignore the message as long as it shows up only for non existing users.

    When the Extranet Lockout is enabled, ADFS needs to query the badPwdCount attribute of the user, so it tries to look for it in AD before even trying to authenticate. If the user does not exist, you get the error message you see.

    What's not intended is to be redirected to your SP if the authentication fails though (at least, not AFAIK).

    Are you using SAML or WS-Trust?


    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    Monday, June 11, 2018 1:36 PM
  • Hi Pierre,

    Thanks for your reply!

    We are using both SAML and WSFED.

    But the problem just happen to SAML one but not for WSFED.

    Friday, June 22, 2018 2:49 AM
  • Hi Pierre,

    We are seeing the same error (Microsoft.IdentityServer.Service.AccountPolicy.ADAccountLookupException: MSIS8022: Unable to find the specified user account.) with a legitimate user account.  They can login to their workstation fine, but not ADFS.  As a test, I did disable Extranet Lockout, and restarted the ADFS service, but it did not make a difference.

    From the ADFS server, I can run Get-ADUser and find the user without issue.

    Any thoughts on what else I could check to alleviate this?  Resetting the user password does not seem to make a difference.

    Thank you,

    Monday, July 30, 2018 5:20 PM
  • Do you mind sharing the details? Maybe you have a duplicate UPN or something?

    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    Wednesday, August 1, 2018 2:10 PM
  • I am unable to find a duplicate UPN for the user.  Below is the exception from ADFS.  I can confirm the account exists in the local active directory.

    Exception details: <o:p></o:p>

    Microsoft.IdentityServer.AuthenticationFailedException: uuid-242c94e7-b40e-4bce-92ab-95f94de12e81-7574-id ---> System.IdentityModel.Tokens.SecurityTokenValidationException: uuid-242c94e7-b40e-4bce-92ab-95f94de12e81-7574 ---> System.IdentityModel.Tokens.SecurityTokenValidationException: id ---> Microsoft.IdentityServer.Service.AccountPolicy.ADAccountLookupException: MSIS8022: Unable to find the specified user account.<o:p></o:p>

       at Microsoft.IdentityServer.Service.LocalAccountStores.ActiveDirectory.ActiveDirectoryCpTrustStore.UpdateAuthenticationContext(IAuthenticationContext context)<o:p></o:p>

       at Microsoft.IdentityServer.Service.Tokens.MsisLocalCpUserNameSecurityTokenHandler.NormalizeIdentity(SecurityToken token)<o:p></o:p>

       --- End of inner exception stack trace ---<o:p></o:p>

       at Microsoft.IdentityServer.Service.Tokens.MsisLocalCpUserNameSecurityTokenHandler.NormalizeIdentity(SecurityToken token)<o:p></o:p>

       at Microsoft.IdentityServer.Service.AccountPolicy.ThreatDetector.NormalizeIdentityIfNeeded(SecurityTokenHandler tokenHandler, SecurityToken securityToken)<o:p></o:p>

       --- End of inner exception stack trace ---<o:p></o:p>

       at Microsoft.IdentityServer.Service.AccountPolicy.ThreatDetector.NormalizeIdentityIfNeeded(SecurityTokenHandler tokenHandler, SecurityToken securityToken)<o:p></o:p>

       at Microsoft.IdentityServer.Service.AccountPolicy.ThreatDetector.AnalyzePreAuthRequest(RequestContext requestContext, SecurityTokenHandler tokenHandler, SecurityToken userToken, SecurityToken deviceToken, IList`1 detectionModuleGeneratedClaims)<o:p></o:p>

       at Microsoft.IdentityServer.Web.WSTrust.SecurityTokenServiceManager.GetEffectivePrincipal(SecurityTokenElement securityTokenElement, SecurityToken deviceSecurityToken, SecurityTokenHandlerCollection securityTokenHandlerCollection)<o:p></o:p>

       at Microsoft.IdentityServer.Web.WSTrust.SecurityTokenServiceManager.Issue(RequestSecurityToken request, IList`1& identityClaimSet, List`1 additionalClaims)<o:p></o:p>

       at Microsoft.IdentityServer.Web.Protocols.PassiveProtocolHandler.SubmitRequest(MSISRequestSecurityToken request, IList`1& identityClaimCollection)<o:p></o:p>

       --- End of inner exception stack trace ---<o:p></o:p>

       at Microsoft.IdentityServer.Web.Protocols.PassiveProtocolHandler.SubmitRequest(MSISRequestSecurityToken request, IList`1& identityClaimCollection)<o:p></o:p>

       at Microsoft.IdentityServer.Web.Protocols.PassiveProtocolHandler.RequestBearerToken(MSISRequestSecurityToken signInRequest, Uri& replyTo, IList`1& identityClaimCollection)<o:p></o:p>

       at Microsoft.IdentityServer.Web.Protocols.PassiveProtocolHandler.RequestSingleSignOnToken(ProtocolContext context, SecurityToken securityToken, SecurityToken deviceSecurityToken)<o:p></o:p>

       at Microsoft.IdentityServer.Web.Protocols.WSFederation.WSFederationProtocolHandler.BuildSsoSecurityToken(WSFederationSignInContext context, SecurityToken securityToken, SecurityToken deviceSecurityToken, SecurityToken& ssoSecurityToken)<o:p></o:p>

       at Microsoft.IdentityServer.Web.Protocols.WSFederation.WSFederationProtocolHandler.BuildSignInResponseCoreWithSecurityToken(WSFederationSignInContext context, SecurityToken securityToken, SecurityToken deviceSecurityToken)<o:p></o:p>

       at Microsoft.IdentityServer.Web.Protocols.WSFederation.WSFederationProtocolHandler.BuildSignInResponse(WSFederationSignInContext federationPassiveContext, SecurityToken securityToken, SecurityToken deviceSecurityToken)<o:p></o:p>

       at Microsoft.IdentityServer.Web.Protocols.WSFederation.WSFederationProtocolHandler.Process(ProtocolContext context)<o:p></o:p>

       at Microsoft.IdentityServer.Web.PassiveProtocolListener.ProcessProtocolRequest(ProtocolContext protocolContext, PassiveProtocolHandler protocolHandler)<o:p></o:p>

       at Microsoft.IdentityServer.Web.PassiveProtocolListener.OnGetContext(WrappedHttpListenerContext context)<o:p></o:p>


    Wednesday, August 1, 2018 2:16 PM
  • is that possible that the ADFS service account does not have the permission to read the account?

    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    Wednesday, August 1, 2018 3:10 PM
  • Hi Pierre - that is a great suggestion.  I just checked and confirmed that the ADFS service account does have full control of the user object in the local Active Directory.  I compared it with another working account in the same OU, and did not see a difference.
    Wednesday, August 1, 2018 3:14 PM
  • So this issue just occurs for one specific user?

    Thursday, August 2, 2018 6:30 AM
  • Yes - that's correct.  One user, and I have attempted to change their password as well.  ADFS just acts like the user does not exist. 
    Thursday, August 2, 2018 3:53 PM