![]() And now we are in problem state, until we restart the ADFS service( which essentially means, flushing it's logon session and all tickets and starting from step 1).Writable DCs doe not allow AuthZ context creation for TGT issued by RODC.RODC B sees that the TGT is not his local key so it forwards to Writable DC(if connection available).ADFS then rediscover a KDC to use for Auth requests for users but now it is talking to RODC B.ADFS Service works fine as long as it uses RODC A for user authentication.ADFS Service starts and authenticate to RODC A (Gets TGT from RODC A).If your ADFS servers are in a site where you have only two or more RODCs and no writable domain controller.In this case, external authentication keeps working fine and one fine day, it stopped working until ADFS service is restarted. Slightly different and not very common.To solve this problem, you need to run script provided here. Solution is to add ADFS Service Account to the Windows Authorization Access Group.Īnother common cause is when Default Active Directory permissions are modified, in a way that 'Pre-Windows 2000 Compatibility Access' group or 'Windows Authorization Access' group do not have permissions to Read the TGAU attribute, as describe in the previousĪrticle. If 'Authenticated Users' are removed from 'Pre-Windows 2000 Compatibility Access' Group intentionally for business, security reasons, Most common cause is - 'Authenticated Users' are not member of 'Pre-Windows 2000 Compatibility Access' Group. In Windows error code 5 means Access Denied Common Causes and Solutions Scenario 1 Collected debug logging from the DC and here what we see Let us ask DC, why did this request was failed. But few seconds back, same DC authenticated the user successfully. DC returned C_PRINCIPAL_UNKNOWNĬ_PRINCIPAL_UNKNOWN - In general it means that DC failed to find the user. Now I see S4U Logon request where ticket is requested for the ADFS service and it fails. ADFS also request Service ticket for the host SPN Collected Network traces and here is what we seeĪDFS performs Basic Authentication, collect username and password from form and authenticate the user. Next question is, what is S4U Logon and why it is failing? S4ULogon is Kerberos Authentication type and the best tool to dig further for Kerberos Autentication is our old friend Network Monitor. How about ADFS Debug logging, Can we get some clue from there?Īfter reviewing ADFS Debug event logs carefully, I found one interesting event, which give us some clue. It is a successful login event, not surprising as ADFS issued MSISAuth Cookie. Interestingly, it shows successful authentication, ADFS issued MSISAuth cookie, which is issued when user's authentication is successful.Īre there any authentication failures in Security Event logs? ![]() Let us take a fiddler and see if we can find the mysterious login failure. However, if user provides incorrect password, it fails with the "Incorrect username or password." error and ADFS admin logs an error 364 There are no errors logs in the ADFS admin logs too. There are no errors or failures on the page. ![]() User provides user name and password and click on Sign in button and gets redirected to the login page again User goes to Office365 login page or application and gets redirected to the form based authentication page of the ADFS server. Users can successfully login to applications from corp network(Internal Network). An interesting troubleshooting scenario, where users login failed silently, when try to login externally using form based authentication.
0 Comments
Leave a Reply. |