locked
ADFS Questions RRS feed

  • Question

  • Hi There

    I have recently taken over a site where ADFS has been setup. All appears to work as it seemingly does what Ive been told its supposed to do. Authentication for our CRM server web interface. Server is 20012 R2 

    The logs tell a different story, there are 9 audit failures a second from the ADFS server for the ADFS service account. The account does not get locked out. I am able to stop and start the service successfully. When stopping the service obviously all the logs stop. I rebooted the DC and ADFS server. When I logged into the DC all the logs were fine(thought YAY). Then when i logged into the ADFS, i saw failures, when I went back to the DC to have a look, the failures had started once i had logged in.

    This is also kill the processor as the lsass.exe process runs high constantly on the ADFS.

    Token validation failed.  

    Additional Data 

    Token Type: 
    http://schemas.microsoft.com/ws/2006/05/identitymodel/tokens/UserName 
    %Error message: 
    domain\user-The user name or password is incorrect 

    Exception details: 
    System.IdentityModel.Tokens.SecurityTokenValidationException: domain\user---> System.ComponentModel.Win32Exception: The user name or password is incorrect
       at Microsoft.IdentityServer.Service.Tokens.LsaLogonUserHelper.GetLsaLogonUserHandle(SafeHGlobalHandle pLogonInfo, Int32 logonInfoSize, SafeCloseHandle& tokenHandle, SafeLsaReturnBufferHandle& profileHandle)
       at Microsoft.IdentityServer.Service.Tokens.LsaLogonUserHelper.GetLsaLogonUserInfo(SafeHGlobalHandle pLogonInfo, Int32 logonInfoSize, DateTime& nextPasswordChange, DateTime& lastPasswordChange, String authenticationType, String issuerName)
       at Microsoft.IdentityServer.Service.Tokens.LsaLogonUserHelper.GetLsaLogonUser(UserNameSecurityToken token, DateTime& nextPasswordChange, DateTime& lastPasswordChange, String issuerName)
       at Microsoft.IdentityServer.Service.Tokens.MSISWindowsUserNameSecurityTokenHandler.ValidateTokenInternal(SecurityToken token)
       --- End of inner exception stack trace ---
       at Microsoft.IdentityServer.Service.Tokens.MSISWindowsUserNameSecurityTokenHandler.ValidateTokenInternal(SecurityToken token)
       at Microsoft.IdentityServer.Service.Tokens.MSISWindowsUserNameSecurityTokenHandler.ValidateToken(SecurityToken token)

    System.ComponentModel.Win32Exception (0x80004005): The user name or password is incorrect
       at Microsoft.IdentityServer.Service.Tokens.LsaLogonUserHelper.GetLsaLogonUserHandle(SafeHGlobalHandle pLogonInfo, Int32 logonInfoSize, SafeCloseHandle& tokenHandle, SafeLsaReturnBufferHandle& profileHandle)
       at Microsoft.IdentityServer.Service.Tokens.LsaLogonUserHelper.GetLsaLogonUserInfo(SafeHGlobalHandle pLogonInfo, Int32 logonInfoSize, DateTime& nextPasswordChange, DateTime& lastPasswordChange, String authenticationType, String issuerName)
       at Microsoft.IdentityServer.Service.Tokens.LsaLogonUserHelper.GetLsaLogonUser(UserNameSecurityToken token, DateTime& nextPasswordChange, DateTime& lastPasswordChange, String issuerName)
       at Microsoft.IdentityServer.Service.Tokens.MSISWindowsUserNameSecurityTokenHandler.ValidateTokenInternal(SecurityToken token)


    Ryan Williams

    Friday, August 12, 2016 3:23 AM

All replies

  • Hiya,

    I guess it's in the ADFS log and not the security or application logs of the ADFS server?

    a few things to investigate.

    1: What is the password lockout for the account configured. If someone just disabled account lockout, it's beginning to smell.

    2: Do you have any extensions installed for your CRM solution. ClickDimension or similar which could be or was previously integrated.

    Friday, August 12, 2016 7:31 AM
  • Password policy is set to disable accounts after 5 failed attempts. I tested locking the account and it does lock after 5 failed attempts.

    I am new to CRM and ADFS so I'll need quite a bit of guidance to run the proper checks. I had a look for ClickDimensions and nothing similar from what I can see.

    That log is from the ADFS server, AD FS, Admin.

    This is from the security log on the adfs. (similar log comes up on the DC, Event ID 4771 though)

    An account failed to log on.

    Subject:
    Security ID: Domain\User
    Account Name: User
    Account Domain: MH
    Logon ID: 0x3827CCE

    Logon Type: 3

    Account For Which Logon Failed:
    Security ID: NULL SID
    Account Name: User
    Account Domain: Domain

    Failure Information:
    Failure Reason: Unknown user name or bad password.
    Status: 0xC000006D
    Sub Status: 0xC000006A

    Process Information:
    Caller Process ID: 0xee8
    Caller Process Name: C:\Windows\ADFS\Microsoft.IdentityServer.ServiceHost.exe

    Network Information:
    Workstation Name: Server
    Source Network Address: -
    Source Port: -

    Detailed Authentication Information:
    Logon Process: W
    Authentication Package: Negotiate
    Transited Services: -
    Package Name (NTLM only): -
    Key Length: 0

    This event is generated when a logon request fails. It is generated on the computer where access was attempted.

    The Subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.

    The Logon Type field indicates the kind of logon that was requested. The most common types are 2 (interactive) and 3 (network).

    The Process Information fields indicate which account and process on the system requested the logon.

    The Network Information fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases.

    The authentication information fields provide detailed information about this specific logon request.
    - Transited services indicate which intermediate services have participated in this logon request.
    - Package name indicates which sub-protocol was used among the NTLM protocols.
    - Key length indicates the length of the generated session key. This will be 0 if no session key was requested.


    Ryan Williams


    • Edited by Ryansta Sunday, August 14, 2016 10:20 PM
    Sunday, August 14, 2016 10:01 PM
  • Seem to have solved the issue.

    The password was changed by the previous IT admin. The old password was luckily kept. I changed it back to the old password and all the errors stopped :) :) :)

    I read the password length could be an issue for the service account or that the password is stored in the database when initially setup. The initial password obviously falls into both of those so I am unsure if it was length related or stored in the database.

    Anyone know which one if could have been?


    Ryan Williams

    Sunday, August 14, 2016 11:41 PM
  • The problem about that theory, is that it was claimed to be working. If it indeed was using incorrect password, the ADFS service would not star, hence no service working.

    Is it ADFS 2.0, 2.1 or 3.0 ?

    If it is 2.0 or 2.1, it might be that the account was updated in Services, but not IIS Application Pool.

    I have not heard that password lenght would be a problem, however the SAMaccountname could cause misunderstandings if more than... 20 charaters I believe it is. Nor have any memory about the service account password would be stored in the ADFS database. (that would definently be bad practise to do so)

    Monday, August 15, 2016 11:23 AM
  • The service was definitely started, I restarted them a number of times as well as rebooted servers. The account also never locked out.

    It is ADFS 3.0. 

    Really not sure why it solved the problem then. Where does the service account password get stored for ADFS? Services and?


    Ryan Williams

    Monday, August 15, 2016 11:49 AM
  • I get to learn something every day. It's a good question your raising and a little digging shows something interesting on the matter.

    https://technet.microsoft.com/en-us/library/hh994565(v=ws.11).aspx

    LSA secrets on the hard disk drive
    A Local Security Authority (LSA) secret is a secret piece of data that is accessible only to SYSTEM account processes. Some of these secrets are credentials that must persist after reboot, and they are stored in encrypted form on the hard disk drive. Credentials stored as LSA secrets might include:
        - Account password for the computer’s AD DS account
        - Account passwords for Windows services that are configured on the computer
        - Account passwords for configured scheduled tasks
        - Account passwords for IIS application pools and websites

    Thursday, August 18, 2016 6:15 PM
  • I get to learn something every day. It's a good question your raising and a little digging shows something interesting on the matter.

    https://technet.microsoft.com/en-us/library/hh994565(v=ws.11).aspx

    LSA secrets on the hard disk drive
    A Local Security Authority (LSA) secret is a secret piece of data that is accessible only to SYSTEM account processes. Some of these secrets are credentials that must persist after reboot, and they are stored in encrypted form on the hard disk drive. Credentials stored as LSA secrets might include:
        - Account password for the computer’s AD DS account
        - Account passwords for Windows services that are configured on the computer
        - Account passwords for configured scheduled tasks
        - Account passwords for IIS application pools and websites


    Mind this applies for all accounts, not just ADFS :)
    Thursday, August 18, 2016 8:18 PM