none
ADFS (2012 R2) fails to login domain users

    Question

  • Hi,

    I set up an ADFS server on Windows Server 2012 R2 and it seems to be working fine. For testing purposes, I uses the following url, https://<server fqn>/adfs/ls/IdpInitiatedSignon.aspx

    Logging in using any domain administrator accounts works. However when I tried to login using any accounts which are not a domain administrator, it fails.

    I get the following error shown in the web browser,

    An error occurred 
    
    An error occurred. Contact your administrator for more information. 
    
    
    Error details•Activity ID: 00000000-0000-0000-ff04-0080000000cf
    •Error time: Thu, 05 Dec 2013 11:33:08 GMT
    •Cookie: enabled
    •User agent string: Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.3; WOW64; Trident/7.0; .NET4.0E; .NET4.0C; .NET CLR 3.5.30729; .NET CLR 2.0.50727; .NET CLR 3.0.30729; InfoPath.3)


    I get the following error in the ADFS server event log,

    Log Name: AD FS/Admin
    Source: AD FS
    Event ID: 364
    Level: Error
    User: <AD FS Service account>

    Encountered error during federation passive request. Additional Data Protocol Name: msisHttpProtocol Relying Party: urn:AppProxy:com Exception details: Microsoft.IdentityServer.RequestFailedException: MSIS7066: Authentication failed for the request. ---> System.Security.SecurityException: The user name or password is incorrect. at System.Security.Principal.WindowsIdentity.KerbS4ULogon(String upn, SafeTokenHandle& safeTokenHandle) at System.Security.Principal.WindowsIdentity..ctor(String sUserPrincipalName, String type) at System.Security.Principal.WindowsIdentity..ctor(String sUserPrincipalName) at Microsoft.IdentityServer.Web.SessionTokenManager.UserInformationManagerForS4ULogon.FetchIdentityUsingS4U() --- End of inner exception stack trace --- at Microsoft.IdentityServer.Web.SessionTokenManager.UserInformationManagerForS4ULogon.FetchIdentityUsingS4U() at Microsoft.IdentityServer.Web.SessionTokenManager.SingleSignOnTokenHelper.SsoS4ULogonUpdate(SessionSecurityToken sessionSecurityToken) at Microsoft.IdentityServer.Web.SessionTokenManager.SingleSignOnTokenHelper..ctor(WrappedHttpListenerRequest request, Boolean useTemporarySsoCookie) at Microsoft.IdentityServer.Web.Protocols.ProtocolContext.get_SingleSignOnTokenHelper() at Microsoft.IdentityServer.Web.PassiveProtocolListener.OnGetContext(WrappedHttpListenerContext context) System.Security.SecurityException: The user name or password is incorrect. at System.Security.Principal.WindowsIdentity.KerbS4ULogon(String upn, SafeTokenHandle& safeTokenHandle) at System.Security.Principal.WindowsIdentity..ctor(String sUserPrincipalName, String type) at System.Security.Principal.WindowsIdentity..ctor(String sUserPrincipalName) at Microsoft.IdentityServer.Web.SessionTokenManager.UserInformationManagerForS4ULogon.FetchIdentityUsingS4U() The Zone of the assembly that failed was: MyComputer

    Please note that the username and password entered are correct.

    I see that the Activity ID is given in the error message on the web browser but so far, I can't figure out where to look for the log file.

    Any help would be greatly appreciated.

    Thanks in advance.


    • Edited by Programatix Thursday, December 05, 2013 11:36 AM
    Thursday, December 05, 2013 11:35 AM

All replies

  • Hi,

    Hope the below links be helpful for you:

    ADFS Proxy 364 Event

    http://stephenhirst.azurewebsites.net/?p=2412

    ADFS – Event ID 364

    http://thepointyside.wordpress.com/2013/08/12/adfs-event-id-364/

    In addition, ADFS related issue, please post in the below forum:

    http://social.msdn.microsoft.com/Forums/vstudio/en-US/home?forum=Geneva

    Regards,

    Yan Li


    Regards, Yan Li


    Friday, December 06, 2013 7:42 AM
    Moderator
  • I'm having a very similar issue with ADFS on 2012 R2. The contents of my event log are slightly different, but the symptoms are exactly the same. If a domain admin logs in, ADFS successfully authenticates, but when any non-admin account logs in, it fails. The webpage says "an error occurred" with very little informationa, and I get the event log saying the user name or password are incorrect, but like Programatix, I know they are correct, and have tried multiple accounts.

    Has anyone found a resolution yet? (sorry Yan Li, your links didn't help me)

    Encountered error during federation passive request.

    Additional Data

    Protocol Name:
    Saml

    Relying Party:
    http://fs.<domain>.org/adfs/services/trust

    Exception details:
    Microsoft.IdentityServer.RequestFailedException: MSIS7066: Authentication failed for the request. ---> System.Security.SecurityException: The user name or password is incorrect.

       at System.Security.Principal.WindowsIdentity.KerbS4ULogon(String upn, SafeTokenHandle& safeTokenHandle)
       at System.Security.Principal.WindowsIdentity..ctor(String sUserPrincipalName, String type)
       at System.Security.Principal.WindowsIdentity..ctor(String sUserPrincipalName)
       at Microsoft.IdentityServer.Web.SessionTokenManager.UserInformationManagerForS4ULogon.FetchIdentityUsingS4U()
       --- End of inner exception stack trace ---
       at Microsoft.IdentityServer.Web.SessionTokenManager.UserInformationManagerForS4ULogon.FetchIdentityUsingS4U()
       at Microsoft.IdentityServer.Web.SessionTokenManager.SingleSignOnTokenHelper.SsoS4ULogonUpdate(SessionSecurityToken sessionSecurityToken)
       at Microsoft.IdentityServer.Web.SessionTokenManager.SingleSignOnTokenHelper..ctor(WrappedHttpListenerRequest request, Boolean useTemporarySsoCookie)
       at Microsoft.IdentityServer.Web.Protocols.ProtocolContext.get_SingleSignOnTokenHelper()
       at Microsoft.IdentityServer.Web.Authentication.AuthenticationPolicyEvaluator.RetrieveFirstStageAuthenticationDomain(Boolean& validAuthMethodsInToken)
       at Microsoft.IdentityServer.Web.Authentication.AuthenticationPolicyEvaluator.EvaluatePolicy(Boolean& isLastStage, AuthenticationStage& currentStage, Boolean& strongAuthRequried)
       at Microsoft.IdentityServer.Web.PassiveProtocolListener.GetAuthMethodsFromAuthPolicyRules(PassiveProtocolHandler protocolHandler, ProtocolContext protocolContext)
       at Microsoft.IdentityServer.Web.PassiveProtocolListener.GetAuthenticationMethods(PassiveProtocolHandler protocolHandler, ProtocolContext protocolContext)
       at Microsoft.IdentityServer.Web.PassiveProtocolListener.OnGetContext(WrappedHttpListenerContext context)

    System.Security.SecurityException: The user name or password is incorrect.

       at System.Security.Principal.WindowsIdentity.KerbS4ULogon(String upn, SafeTokenHandle& safeTokenHandle)
       at System.Security.Principal.WindowsIdentity..ctor(String sUserPrincipalName, String type)
       at System.Security.Principal.WindowsIdentity..ctor(String sUserPrincipalName)
       at Microsoft.IdentityServer.Web.SessionTokenManager.UserInformationManagerForS4ULogon.FetchIdentityUsingS4U()
    The Zone of the assembly that failed was:
    MyComputer

    Friday, December 13, 2013 3:50 PM
  • Hello,

    i have the same issues. I have a Windows 2012R2 ADFS server. All users are Federated with Office 365 (lync). Works for all users. Now i are setting up Workfolders and workplace join. This works fine for old users that are years in the organisation, users that are created in the last few years dont work. Also new created users don't work. Exact as message above. Cannot figure out what it is. Did change the upn to another domain, and changed it back, reset password for the users, all don't work.

    I test with https://fs.xxx.net/adfs/ls/IdpInitiatedSignon.aspx

    from internal and external locations.

    Eventlogs reports:

    Encountered error during federation passive request.

    Additional Data

    Protocol Name:

    Saml

    Relying Party:

    Exception details:

    Microsoft.IdentityServer.RequestFailedException: MSIS7066: Authentication failed for the request. ---> System.Security.SecurityException: The user name or password is incorrect.

       at System.Security.Principal.WindowsIdentity.KerbS4ULogon(String upn, SafeTokenHandle& safeTokenHandle)

       at System.Security.Principal.WindowsIdentity..ctor(String sUserPrincipalName, String type)

       at System.Security.Principal.WindowsIdentity..ctor(String sUserPrincipalName)

       at Microsoft.IdentityServer.Web.SessionTokenManager.UserInformationManagerForS4ULogon.FetchIdentityUsingS4U()

       --- End of inner exception stack trace ---

       at Microsoft.IdentityServer.Web.SessionTokenManager.UserInformationManagerForS4ULogon.FetchIdentityUsingS4U()

       at Microsoft.IdentityServer.Web.SessionTokenManager.SingleSignOnTokenHelper.SsoS4ULogonUpdate(SessionSecurityToken sessionSecurityToken)

       at Microsoft.IdentityServer.Web.SessionTokenManager.SingleSignOnTokenHelper..ctor(WrappedHttpListenerRequest request, Boolean useTemporarySsoCookie)

       at Microsoft.IdentityServer.Web.Protocols.ProtocolContext.get_SingleSignOnTokenHelper()

       at Microsoft.IdentityServer.Web.PassiveProtocolListener.OnGetContext(WrappedHttpListenerContext context)

    System.Security.SecurityException: The user name or password is incorrect.

       at System.Security.Principal.WindowsIdentity.KerbS4ULogon(String upn, SafeTokenHandle& safeTokenHandle)

       at System.Security.Principal.WindowsIdentity..ctor(String sUserPrincipalName, String type)

       at System.Security.Principal.WindowsIdentity..ctor(String sUserPrincipalName)

       at Microsoft.IdentityServer.Web.SessionTokenManager.UserInformationManagerForS4ULogon.FetchIdentityUsingS4U()

    The Zone of the assembly that failed was:

    MyComputer


    ----------

    security audit logs reports:

    An account failed to log on.

    Subject:

    Security ID:  contonso\ADFSManaged$

    Account Name: ADFSManaged$

    Account Domain: CONTOSO

    Logon ID: 0x146609C

    Logon Type: 3

    Account For Which Logon Failed:

    Security ID: NULL SID

    Account Name:

    Account Domain:

    Failure Information:

    Failure Reason: Unknown user name or bad password.

    Status: 0xC000006D

    Sub Status: 0xC0000064

    Process Information:

    Caller Process ID: 0xed0

    Caller Process Name: C:\Windows\ADFS\Microsoft.IdentityServer.ServiceHost.exe

    Network Information:

    Workstation Name: S02

    Source Network Address: -

    Source Port: -

    Detailed Authentication Information:

    Logon Process: C

    Authentication Package: Kerberos

    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.

    Doing this for users that are longer in the organisation the test login works.

    Any ideas?

    Regards

    Wednesday, December 18, 2013 7:12 PM
  • Hello,

    update on this issue. I figured out wat was causing this. I use a managed service account for the adfs service, because this is best practice.

    It looks like the Managed Service account has too less permission to read the user properties to let them authenticate. When i add the managed service account and give it read permission to a user that didnt work i can logon succesfully. I can offcourse add this right to the whole OU where the users are in to fix it for all users.

    I this a security issue? Give i now to less or too much security too this account. Can someone give me advise what permissions to give.

    Regards

    Saturday, December 21, 2013 9:05 PM
  • Henri-

    I tested your theory in my environment, and can confirm the same results. If I give the ADFS Managed Service account Read rights to a user account, that user can then authenticate to Office 365 via federated services. I hope someone out there can point to the reason why the correct permissions are not being assigned throughout the domain. Like you, I don't want to manually assign rights to the AD infrastructure.

    One other thing I noticed was that on the 3 accounts that can successfully authenticate in our environment, they have the MSOL_XXXXXXXX account assigned special permissions, as where the rest of the domain accounts do not have the MSOL_XXXXXXXX account assigned any permissions. I don't know how or why these user accounts have those permissions and others don't, but I have a feeling it is because at one time (or currently) those specific accounts are/were domain admins.

    Any insight is appreciated.

    Sunday, January 05, 2014 1:40 AM
  • Hi,

    the users that worked before the permission change where also in the past domain admins. You can check this at yours with adsi edit. When the admincount value is there at the user properties they where admin in the past.

    That users worked without the change, because on that object authenticated users have read access on the user object.

    Regards.

    • Proposed as answer by Aaron.H Friday, March 28, 2014 9:07 PM
    • Unproposed as answer by Aaron.H Friday, March 28, 2014 9:07 PM
    Monday, January 06, 2014 8:34 AM
  • I believe I have solved it for my domain. After a lot of digging through AD DS permissions, and comparing them to a fresh 2012 domain installation, I discovered that the Pre-Windows 2000 Compatible Access group in my production domain did not have Authenticated Users as a member like the new lab domain did. Once I added Authenticated Users to the Pre-Windows 2000 group, I was able to authenticate using regular domain accounts to ADFS.

    Anyone having this problem want to verify if your domain has the same situation?

    • Proposed as answer by Aaron.H Friday, March 28, 2014 9:11 PM
    Friday, March 28, 2014 9:11 PM
  • All I have a premier case open on this issue as well.

    What I have determined (could be multiple causes) is the ADFS will fail user login if the PDC role does not have a badPwdCount attribute set. Microsoft (called me back while I wrote this) and confirmed that ADFS always calls to the PDC to check that attribute. They will be releasing a hot fix to correct the issue.

    I will post my script in a bit but the workaround is cause the account to lockout then unlock it (or let the lockout expire) that will cause the badPwdCount attribute to be created on the user object on the PDC and allow them to login. Note before someone asks, the badPwdCount is per DC it does NOT replicate, thats part of why you see this behavior. If you created the account via UI or script targeting the PDC the issue would not occur as the field IS populated on the DC it was created on.

    Monday, March 31, 2014 10:27 PM
  • Great find Aaron - saved me any number of painful hours troubleshooting here!
    Monday, April 14, 2014 4:14 AM
  • Will you have a chance to post said script?

    We are running into a similar situation here, though only for users in a (two way) trusted domain.... (Funny enough another ADFS 2.0 setup works flawlessly)

    Monday, April 28, 2014 1:58 PM
  • Was an update ever released or a script to update the attribute?
    Wednesday, April 30, 2014 3:52 AM
  • Thanks a lot! Adding the Authenticated Users to the Pre-Windows 2000 group fixed the problem!
    Tuesday, May 06, 2014 12:31 AM
  • Still waiting on a hot fix..

    Function LockOut-ADCredentials {
      Param($username, $password, $domain, $attemptstolockout)
      try {
        $i = 0
        while ($i -lt $attemptstolockout) {

            Add-Type -AssemblyName System.DirectoryServices.AccountManagement
            $ct = [System.DirectoryServices.AccountManagement.ContextType]::Domain
            $pc = New-Object System.DirectoryServices.AccountManagement.PrincipalContext($ct, $domain)
            New-Object PSObject -Property @{
              UserName = $username;
              IsValid = $pc.ValidateCredentials($username, $password).ToString()
            }
            $i++
          }
          catch{
          }
        Unlock-ADAccount $username -Server "$((Get-ADDomainController -Discover -Service PrimaryDC).HostName)"
      }
    }

    $Users = @()
    $Users = (Get-QADUser -OrganizationalUnit 'your/ou/path' -Enabled -LdapFilter "(!(badPwdCount=*))" -Service "$((Get-ADDomainController -Discover -Service PrimaryDC).HostName)")

    foreach ($User in $Users){
      LockOut-ADCredentials $User.SamAccountName "Any0oldRanD0MPwd5t4-a" "YOURDOMAIN" 5
    }

          
    Thursday, June 05, 2014 5:11 PM
  • Thanks Aaron!

    FYI: I just added the service account (which was created manually rather than a managed service account) for adfs to the Pre-Windows 2000 group and that resolved my issue, so you don't have to add the Authenticated Users group if you don't want to.

    Tuesday, June 10, 2014 5:33 PM
  • I had the same problem in one domain (a seperate test-domain), but not in our production-domain... I never figured out what caused this in my test-domain, and eventually just moved development to production... I tried the suggestions above, but it didn't help.
    • Proposed as answer by ramz_dc Tuesday, September 22, 2015 7:32 PM
    • Unproposed as answer by ramz_dc Tuesday, September 22, 2015 7:38 PM
    Thursday, June 12, 2014 9:56 AM
  • Hello,

    Don't know if you guys solved it by now but i wanted to let you know the Pre-windows 2000 Group membership didn't work for me. However when i added the ADFS group managed service account to the ' Windows Authorization Access Group'  it worked instantly. According to the description of this group ('Members of this group have access to the computed tokenGroupsGlobalAndUniversal attribute on User objects') this is expected behaviour:-)

    • Proposed as answer by L-E Johansson Tuesday, October 11, 2016 1:12 PM
    Friday, August 22, 2014 9:07 AM
  • Any news on this hotfix ?

    (Adding Authenticated Users to the Pre-Windows 2000 Compatible Access group also solved the problem.)

    Wednesday, October 08, 2014 12:36 PM
  • Thanks yoda-ict,

    Add ADFS group managed service account to the ' Windows Authorization Access Group'  fixed "An account failed to log on" error on the ADF server 

    Logon Type:                                        3

     

    Account For Which Logon Failed:

                   Security ID:                          NULL SID

                   Account Name:                  

                   Account Domain:               

     

    Failure Information:

                   Failure Reason:                    Unknown user name or bad password.

                   Status:                                  0xC000006D

                   Sub Status:                           0xC0000064

     

    Process Information:

                   Caller Process ID:  0x1268

                   Caller Process Name:           C:\Windows\ADFS\Microsoft.IdentityServer.ServiceHost.exe

     

    Network Information:

                   Workstation Name:             TEST

                   Source Network Address:    -

                   Source Port:                         -

     

    Detailed Authentication Information:

                   Logon Process:                    W

                   Authentication Package:    Negotiate

                   Transited Services:               -

                   Package Name (NTLM only):             -

                   Key Length:                          0

     

    Monday, June 29, 2015 11:34 AM
  • It worked for me as well

    Jacob

    Monday, September 28, 2015 2:46 PM
  • Same here. Thanks!
    Monday, November 09, 2015 3:14 PM
  • Thanks Aaron, it fixed my issue as well.
    Wednesday, January 27, 2016 10:51 PM
  • added Authenticated Users to the Pre-Windows 2000 group

    Just got off with Microsoft and this is also what they did to fix our issue. Wish I found this post a few days ago.

    • Edited by mhlay Tuesday, February 16, 2016 4:43 PM
    Tuesday, February 16, 2016 4:42 PM
  • Hi,

    using Windows 2012 R2, I never had problem with ADFS using normal NT account for the service.

    Unfortunately, I needed to reinstall ADFS and the managed account has been choosen during a too quick install.

    The Pre-Windows 2000 group was not the solution (It already contained Authenticated users).

    Giving read permissions to the managed account on all user objets at the root of AD works well. The "Windows Authorization Access group" seems to work also!

    It does not seem to be simpler to use "managed accounts"!


    Thierry DEMAN. Exchange MVP. MCSE:Messaging 2013,MCSE:Server Infrastructure 2012(83 MCPs). MCSA Office 365 https://mvp.microsoft.com/en-us/mvp/Thierry%20Deman-7660 http://base.faqexchange.info

    Monday, April 25, 2016 9:57 AM
  • I had issue where loging in to o365 portal from outside of company over adfs would not work. It would only refresh the page and nothing would happen. Got loads of KDC_ERR_C_PRINCIPAL_UNKNOWN. The solution was to add adfs account to "Windows Authorization Access group" and it worked instantly.
    Thursday, July 28, 2016 12:37 PM
  • If anybody is having problem with similar error page when trying to test a Sign in on the newer version of AD FS (Windows Server 2016 for example), please note that the endpoint /adfs/ls/IdPInitiatedSignOn.aspx is disabled by default.

    There is no error log in the Event viewer that would point you to right direction, but the solution for this problem is to enable this endpoint by PowerShell cmdlet:
    Set-AdfsProperties -EnableIdPInitiatedSignonPage $true
    PS the error logs actually exists and are hidden in Event Viewer > Applications and Services Log > AD FS


    Tuesday, January 31, 2017 2:24 PM