ADFS (2012 R2) fails to login domain users

All replies

• 

  

  0

  Sign in to vote

  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

  
  

  • Edited by Yan Li_ Friday, December 6, 2013 7:44 AM edit

  Friday, December 6, 2013 7:42 AM
• 

  

  0

  Sign in to vote

  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
• 

  

  0

  Sign in to vote

  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
• 

  

  1

  Sign in to vote

  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

  • Proposed as answer by doalwa Wednesday, July 24, 2019 8:49 AM

  Saturday, December 21, 2013 9:05 PM
• 

  

  0

  Sign in to vote

  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 5, 2014 1:40 AM
• 

  

  0

  Sign in to vote

  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 6, 2014 8:34 AM
• 

  

  10

  Sign in to vote

  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
• 

  

  0

  Sign in to vote

  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
• 

  

  0

  Sign in to vote

  Great find Aaron - saved me any number of painful hours troubleshooting here!

  Monday, April 14, 2014 4:14 AM
• 

  

  0

  Sign in to vote

  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
• 

  

  0

  Sign in to vote

  Was an update ever released or a script to update the attribute?

  Wednesday, April 30, 2014 3:52 AM
• 

  

  0

  Sign in to vote

  Thanks a lot! Adding the Authenticated Users to the Pre-Windows 2000 group fixed the problem!

  Tuesday, May 6, 2014 12:31 AM
• 

  

  0

  Sign in to vote

  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 5, 2014 5:11 PM
• 

  

  0

  Sign in to vote

  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
• 

  

  0

  Sign in to vote

  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
• 

  

  5

  Sign in to vote

  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
• 

  

  0

  Sign in to vote

  Any news on this hotfix ?

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

  Wednesday, October 8, 2014 12:36 PM
• 

  

  0

  Sign in to vote

  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
• 

  

  0

  Sign in to vote

  It worked for me as well

  ---

  Jacob

  Monday, September 28, 2015 2:46 PM
• 

  

  0

  Sign in to vote

  Same here. Thanks!

  Monday, November 9, 2015 3:14 PM
• 

  

  0

  Sign in to vote

  Thanks Aaron, it fixed my issue as well.
  

  Wednesday, January 27, 2016 10:51 PM
• 

  

  0

  Sign in to vote

  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
• 

  

  1

  Sign in to vote

  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
• 

  

  0

  Sign in to vote

  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
• 

  

  2

  Sign in to vote

  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
  
  
  

  • Edited by Dejan Štefulj Tuesday, January 31, 2017 2:29 PM

  Tuesday, January 31, 2017 2:24 PM
• 

  

  0

  Sign in to vote

  I know this is an old thread but it may be worth pointing out that that test URL is often mistyped. This has caught me out many times.

  Just make sure you are using an "i" rather than a lower case "L" as the first character of idpInitiatedSignon.aspx.

  Friday, July 19, 2019 9:23 AM
• 

  

  0

  Sign in to vote

  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

  I know it's been a few years :-) But I stumbled upon a similar problem today. We have ADFS setup on a Windows Server 2016 server and sync about 20 users for SSO with Office365.

  So far, we never had any problems. A few days ago, one of our sales people was added to our Office365 security group and consequently synced to Azure AD.

  We were able to assign an Office365 license to him. However, he was unable to login at office.com.

  After putting in his email adresse, Microsoft correctly forwarded his login to our ADFS signin page. When he entered his password, nothing happened however..no error message, nothing.

  In the security log of our ADFS server there where two events created every time he tried loging in. Event ID 4624 stating that his user was logged in, followed immediately by Event ID 4625 stating "Unkown username or invalid password" (paraphrasing from german here!)

  After I granted our ADFS service account read privileges on his AD user account, he could finally login.

  I'm not sure why this is suddenly becoming a problem for newly created users. When I check other working user accounts, the ADFS service account does not explicitly have read privilegs on those accounts either.

  Who knows...I'm just glad it's finally working, thanks for you post which took me in the right direction!

  Wednesday, July 24, 2019 8:57 AM