locked
ADFS 3.0 - Login loop when correct credentials used RRS feed

  • Question

  • Hi all, I was wondering if you could help. We have a strange issue which is driving us all mad.

    We are seeing a strange problem where users who are accessing sites which hang off of ADFS cannot get past the login page. In the even viewer I can see that the users are successfully being authenticated however in the browsers they get just get the standard ADFS username and password page, like they have inputted nothing in. Its strange because ADFS is authenticating them but on the page just wipes the username and password as if nothing has happened. If they put in a wrong username or password, then they get an error. So it seems its only when they use the correct credentials they get stuck on the login page.

    Environment:

    2 x ADFS 3.0 servers being load balanced

    Configuration pointing to a SQL cluster 

    I have checked the SQL servers for errors, no errors. No errors on the load balancer, the only thing which fixes the issue is restarting the service. It happens once every day on average where someone has to login and restart the service to get rid of this issue. Any help on this one would be much appreciated

    Sunday, March 17, 2019 1:47 PM

All replies

  • Hiya,

    Are you logging into an application or just ADFS login page /adfs/ls/idpinitiatedsignon.aspx?

    If you are not login to /adfs/ls/idpinitiatedsignon.aspx, try that first. If the page is not working, you need to enable it. If that login is succesful, then you do not have a problem with basic ADFS configuration.

    Monday, March 18, 2019 8:33 AM
  • Hi Jesper, during an "outage" period we cannot login via the ADFS login page either.

    I have noticed that the service account for adfs gets between 50 and 100 errors per a second with the event ID of 4625 "An account failed to log on", the failure reason is "Unknown user name or bad password". Once the service is restarted, these errors go and the service starts working again. Im not sure what us causing this, have you ever seen this before? Once the adfs service is restarted these errors go away and logins work again.

    Monday, March 18, 2019 9:35 AM
  • Hiya,

    Check that the Security -> Logins are the same on the SQL servers and the ADFS is not missing on one of them :)

    In an SQL cluster, Security does not get replicated or copied automatically, it has to be created manually or by script.

    Monday, March 18, 2019 9:39 AM
  • thanks for your response, I just checked the sql servers which are backing the adfs service and they are reporting no security events in regards to the adfs service account. Infact the complete opposite, yesterday the outage window was from 11:30 - 12:50 and during this time the sql server was reporting sucessful logins with the adfs service account. I guess this means we can rule out the account lockout being the issue.

    I just find it strange that we literally get hundreds of security event 4625 with the value of null on the adfs service account. The caller process name is C:\Windows\ADFS\Microsoft.IdentityServer.ServiceHost.exe so its definitely the adfs service not being able to use the service account for some strange reason....

    Monday, March 18, 2019 9:59 AM
  • Next thing I would do, is verify each string in your setup.

    Use the host file, and isolate the issue. If it is related to one server or multiple servers.

    Just verify under the Security that the account has the same permissions on both nodes in the cluster. It might not get a login error, if it has Public, which allows access to the SQL server, but then the ADFS server would get the Access denied.

    Obviously you can also tried a controlled failover, to see if that triggers the issues.

    To me it sounds like either one of the ADFS servers are missing Local security settings or one of the SQL servers are missing the correct Login permissions for the SQL Server itself.

    Try testing each of the your strings controlled, so you know they both work.

    Monday, March 18, 2019 10:05 AM
  • "Just verify under the Security that the account has the same permissions on both nodes in the cluster. " - just to make sure I have understood this correctly, this is just reffering to checking the permissions the adfs service account has on the db which can be set in the sql management studio?

    There have been no changes to our environment and this current setup has been working fine since it was put in back in December. The only change we have made is we have added in a read only domain controller? I dont suppose that could cause any of these issues?

    Monday, March 18, 2019 10:22 AM
  • Hiya,

    Not on the DB itself, but on Instance level. (The DB will always move the DB permissions, but if the login itself doesn't exist on the SQL instance, it wont work)

    Open Management Studio -> Security -> Logins

    Verify account is correctly added. <domain>\<ADFS Service> and if you open it, it has correct mappings to database.

    To my knowledge, there shouldn't be any problems introducing af Read Only DC with ADFS.

    Monday, March 18, 2019 10:27 AM
  • Hi Jesper, I've just checked with our DBA and the adfs service account has the same permissions on both of the SQL servers that are in HA. We also tried a SQL failover and it didnt cause the issue to arise again.

    It seems like when adfs tries to use that service account randomly it wont work which then causes the service to completely crash. We recently turned on password sync with the Azure AD connect tool, is this something that could be causing the issue?

    Monday, March 18, 2019 11:06 AM
  • Hiya,

    And if you try the /adfs/ls/idpinitiatedsignon.aspx from each server, it also works as it should? (Bypassing load balancer)

    Nope, Azure AD Connect shouldn't change anything at all in that regards.

    Monday, March 18, 2019 11:25 AM
  • Correct, I tried this during the last outage and it still did not work. How does adfs authenticate back to ad, does it lookup against the domain roundrobin name or does it do an authentication broadcast?
    Monday, March 18, 2019 12:07 PM
  • As far as I know, it uses the Locator service to find appropriate DC from sites and services. From there it randomly chooses a fitting DC.

    It will be bound once found.

    you can always check which DC your server is using currently, by opening CMD and writing:

    echo %logonserver%


    Wednesday, March 20, 2019 6:55 AM
  • Hi Jesper,

    We have done quite alot of digging on this issue and its a strange one. During an "outage" event, we see hundreds of these events in the event log:

    An account failed to log on.
    
    Subject:
    	Security ID:		domain\service account
    	Account Name:		service account
    	Account Domain:		domain
    	Logon ID:		0x30DAAE6
    
    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:	0x1550
    	Caller Process Name:	C:\Windows\ADFS\Microsoft.IdentityServer.ServiceHost.exe
    
    Network Information:
    	Workstation Name:	adfs 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.

    We literally see hundreds of these during an outage. After the service is restarted, these errors stop and the issue is resolved. Do you have any idea what could be causing this?

    Wednesday, March 20, 2019 1:33 PM
  • Hiya,

    1: If taking a more broader approach, I would look at Domain connectivity in general. If you are able perform actions(non-adfs), while you are seeing these outages. Try to do a "Run as different account" on, say a Notepad from one of the ADFS servers, with the service account and see if it is actually able to validate against the domain.

    2: Look in the standard Application / System logs prior to all the "unknown username or bad password" logs, too see what the server is doing just before that.

    Friday, March 22, 2019 11:48 AM
  • Hi Hiya,

    Hope you would have find the cause now for Looping Login page for correct credentials.

    Could you please share the solutions.

    Regards,

    Lacos

    Thursday, January 2, 2020 7:29 PM
  • Hi there, What is the issue you are seeing? Have you recently put in a new domain controllers or made any domain changes? Thanks
    Thursday, January 2, 2020 7:45 PM
  • Surprisingly there was no changes. Still mystery around this problem and solution. we are seeing the same issue. Stuck on ADFS login page.

    • Edited by Lacos_2 Friday, January 3, 2020 5:06 AM
    Friday, January 3, 2020 5:03 AM
  • Hi Lacos,

    Very strange. When we had the ADFS login loop, it was a nightmare of a time. For us the fix was down to removing a RODC which was recently put in. 

    Are you getting errors in the event viewer when you see the loops starting? Make sure to turn on all ADFS auditing and when it next crashes. If you get the same error as I did above, then its regarding authentication with the adfs service account you are using. 

    Without knowing your environment better its hard to give advice but check for replication issues, check the service account on all DC's to see if the "password last set" attribute is the same or not. There is also a ADFS troubleshooting tool you can use which is found here by Googling "ADFS troubleshooting tools" (I would link it in but it wont let me put links in this post!) the tool looks at a whole bunch of things and could help you in your search.

    Good Luck

    • Proposed as answer by Jesper Arnecke Tuesday, January 14, 2020 1:45 PM
    Friday, January 3, 2020 9:44 AM