다음을 통해 공유

ADFS Troubleshooting: Users not able to login from external network (Silent Login Failure)

  • 아티클

An interesting troubleshooting scenario, where users login failed silently, when try to login externally using form based authentication. Users can successfully login to applications from corp network(Internal Network).

User Experience

User goes to Office365 login page or application and gets redirected to the form based authentication page of the ADFS server.

 

User provides user name and password and click on Sign in button and gets redirected to the login page again

 

There are no errors or failures on the page. There are no errors logs in the ADFS admin logs too. It's a silent login failure.

However, if user provides incorrect password, it fails with the "Incorrect username or password..." error and ADFS admin logs an error 364

 

Data Collection & Analysis

Let us take a fiddler and see if we can find the mysterious login failure.

 

Interestingly, it shows successful authentication, ADFS issued MSISAuth cookie, which is issued when user's authentication is successful.

Are there any authentication failures in Security Event logs?

   

It is a successful login event, not surprising as ADFS issued MSISAuth Cookie. How about ADFS Debug logging, Can we get some clue from there? 

After reviewing ADFS Debug event logs carefully, I found one interesting event, which give us some clue.

 

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. Collected Network traces and here is what we see

ADFS performs Basic Authentication, collect username and password from form and authenticate the user. So, we see AS_REQ, AS_REPS for the User. ADFS also  request Service ticket for the host SPN

 

 

Now I see S4U Logon request where ticket is requested for the ADFS service and it fails. DC returned C_PRINCIPAL_UNKNOWN

 

C_PRINCIPAL_UNKNOWN - In general it means that DC failed to find the user. But few seconds back, same DC authenticated the user successfully. Let us ask DC, why did this request was failed. Collected debug logging from the DC and here what we see

 

In Windows error code 5 means Access Denied

Common Causes and Solutions

Scenario 1

Most common cause is - 'Authenticated Users' are not member of 'Pre-Windows 2000 Compatibility Access' Group. As describe here -  https://support.microsoft.com/en-in/help/331951/some-applications-and-apis-require-access-to-authorization-information.  If 'Authenticated Users' are removed from 'Pre-Windows 2000 Compatibility Access' Group intentionally for business, security reasons, solution is to add ADFS Service Account to the Windows Authorization Access Group.

Scenario 2

Another 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 article. To solve this problem, you need to run script provided here - https://support.microsoft.com/en-us/help/331947

Scenario 3

  • Slightly different and not very common. In this case, external authentication keeps working fine and one fine day, it stopped working until ADFS service is restarted. 
  • If your ADFS servers are in a site where you have only two or more RODCs and no writable domain controller 
    •  ADFS Service starts and authenticate to RODC A (Gets TGT from RODC A)
    • ADFS Service works fine as long as it uses RODC A for user authentication.
    • ADFS then rediscover a KDC to use for Auth requests for users but now it is talking to RODC B
    • RODC B sees that the TGT is not his local key so it forwards to Writable DC(if connection available)
    • Writable DCs doe not allow AuthZ context creation for TGT issued by RODC
    • 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)
    • From solution standpoint, either do not cache ADFS service account password on RODC, so requests will always go to Writable DC or keep one RODC in the site.

Scenario 4

Another very uncommon situation where S4Ulogon can fail.

You have two forests. Contoso.local and Fabrikam.local. Your ADFS server is in Contoso.local. There is an two way external trust between Contoso and Fabrikam.

Users from Fabrikam.local experience the same issue as described in the user experience section. User's UPN is user@fabrikam.com, it is added in the UPN Suffix list of the Fabrikam domain.

When ADFS sends request to it's own DC, it fails with C_PRINCIPAL_UNKNOWN. Actually, ADFS sends the UPN as user@fabrikam.com and DC does not have this namespace neither it find any domain where it can forward the request for fabrikam.com. Due to external trust, all it aware is fabrikam.local

Solution is to change your trust form external to forest wide. 

Scenario 5

Another less common and specific scenario, where user experience is same but the root cause is different.

You are using third party single certificate for Service Communications, Token Decrypting, and Token Signing. Your existing certificate is about to  expire, you get a new certificate and add it.

Now, external user experience the symptoms as described  in the User Experience. Authentication in corp network  works just fine.

No events in ADFS Admin / System or Application logs. 

From network traces, I see that S4ULogon is successful.

ADFS Debug logging came to rescue, I must admit, ADFS debug logging never disappoint you. Here is the error message:-

  Log Name: AD FS Tracing/Debug

  Source: AD FS Tracing

  Date: 7/15/2017 2:57:29 PM

  Event ID: 67

  Task Category: None

  Level: Error

  Keywords: ADFSProtocol

  User: Contoso\svc_adfs

  Computer: adfs01.contoso.local

  Description:

  Ignore corrupted SSO cookie.

SSO cookie is issued by ADFS and it is complaining that it is corrupted? So, something is failing at Cyrpto layer. It makes sense since, the last change made was - certificate renewed. So, let us dump the certificate and see if we get some clue. Here is the command to dump certificate

  Certutil -v -store MY

  Here is the output

       

Valid KeySpecs for ADFS certificates

  • Service Communication = 1
  • Token Decrypting = 1
  • Token Signing = 1 and 2

How to solve this issue? We need to remove certificate from computer store and re-add using the certutil command and add back in ADFS. Here are steps:-

  • Export the certificate with private key into PFX Format.
  • Delete the certificate from ADFS server and WAP server
  • From an elevated command prompt, run following command to add the certificate back

  Certutil -importpfx "NameOfExportedPFXFile.pfx"  AT_KEYEXCHANGE

From the MMC, ensure permissions on the private key for the ADFS Service account, if missing add it manually.

Assign certificate by running following commands:-

  AddADFSCertificate -CertificateType Token-Signing -Thumbprint <ValueOfThumbrpint> -IsPrimary

  AddADFSCertificate -CertificateType Token-Decrypting -Thumbprint <ValueOfThumbprint> -IsPrimary

Restart ADFS Service.

Scenario 6 

Issue: User receiving “bad username or password” message when attempting external log in via WAP into ADFS with Windows Integrated Authentication (WIA) or forms-based authentication. Internal ADFS authentication

Set up: ADFS implemented with Server 2016 or Server 2019 and is using Server 2016 or Server 2019 for Web Application Proxy (WAP) with extranet account lockout feature.

Logs: On the ADFS server at the time of the logon attempt your see the following Error event:

Log Name: AD FS/Admin
Source: AD FS
Date: 1/20/2021 4:20:00 PM
Event ID: 364
Task Category: None
Level: Error
Keywords: AD FS
User: CONTOSO\adfs_service_account
Computer: ADFS_01.CONTOSO.com
Description: Encountered error during federation passive request.

Additional Data

Protocol Name: Saml
Relying Party: https://app.office.com

Exception details: Microsoft.IdentityServer.AuthenticationFailedException: System error. ---> System.IdentityModel.Tokens.SecurityTokenValidationException: System error.
at Microsoft.IdentityServer.Web.WSTrust.SecurityTokenServiceManager.ValidateSecurityToken(SecurityToken userToken, SecurityToken deviceToken)
--- End of inner exception stack trace ---
at Microsoft.IdentityServer.Web.WSTrust.SecurityTokenServiceManager.ValidateSecurityToken(SecurityToken userToken, SecurityToken deviceToken)
at Microsoft.IdentityServer.Web.PassiveProtocolListener.OnGetContext(WrappedHttpListenerContext context)
System.IdentityModel.Tokens.SecurityTokenValidationException: System error.
at Microsoft.IdentityServer.Web.WSTrust.SecurityTokenServiceManager.ValidateSecurityToken(SecurityToken userToken, SecurityToken deviceToken)

Failure cause: ADFS extranet account lockout has been configured with ExtranetLockoutRequirePDC = True and the PDC is unreachable/unavailable.

Failure determination:

  1. Run Get-AdfsProperties and review the ExtranetLockoutRequirePDC setting to determine if it is set to “True”.
  2. Use the command nltest /dsgetdc:contoso.com /pdc /force run on the ADFS servers to determine if the PDC is reachable/available. An error of 1355 indicated the PDC is unreachable.

Err.exe 1355
# for decimal 1355 / hex 0x54b :
  ERROR_NO_SUCH_DOMAIN                                          winerror.h
# The specified domain either does not exist or could not be
# contacted.

Possible causes of 1355 error:
a. PDC DNS record missing or general DNS failure. (DC Discovery failure)
b. UDP 389 is being blocked between the ADFS server and he PDC (DC Discovery failure)
c. General networking issue where route and or NAT is missing or misconfigured not allowing UDP 389 traffic.

Remediation of issue:

  1. Temporarily set ExtranetLockoutRequirePDC to $False and test to determine if this resolves the ADFS extranet logon failure. Is it not recommended to leave this setting disabled long term.
  2. Determine the cause of the PDC being unavailable to the ADFS server.