Some of our accounts are randomly disconnected from third-party app using ADFS service

Question

Hello,

We are using an app that requires authentication via federation services and we are regularly facing logout issues. Some users, usually contractors that works with us and that have limited access to resources in terms of security groups, are randomly disconnected from the service and face the issue that is described in this post : https://blog.gagepennisi.com/2016/01/adfs-logon-page-loop-issue.html

To add context, before applying the changes mentionned in the post, everyone was facing the random logout and loop on the ADFS login page. Since the changes have been made it is only contractors. Another symptom is that when a contractor is disconnected, if I logout manually and try to reconnect, I face the same loop on ADFS login page. Usually, restarting the ADFS service on the ADFS server is enough to get out of this "ADFS login page loop" but we are trying to completely get rid of this issue before deploying the app to more users. Is there anyone that has faced the same issue ?

Any help would be appreciated.

Regards

Answer 1

Hi Alexandre Bissieux,

The recurring redirect loop you are experiencing happens because the relying party application rejects an authentication token missing mandatory group claims, sending the user back to ADFS, which then silently re-issues the exact same incomplete token using the user's existing session cookie. Since your previous configuration changes resolved this for standard users but not contractors, the root cause is almost certainly an Active Directory permission inheritance issue. Contractor accounts are frequently placed in restricted Organizational Units where security permission inheritance is intentionally disabled. Consequently, the domain-level read access previously granted to your ADFS service account does not flow down to these specific user objects, preventing ADFS from reading the tokenGroupsGlobalAndUniversal attribute required to build a complete token.

To resolve this, you must correct the security descriptors on the container holding your contractor accounts. Open Active Directory Users and Computers, enable Advanced Features under the View menu, and navigate to the contractor OU. Access the Security tab in the OU properties and open the Advanced permission settings . You will need to either restore permission inheritance on this OU or manually grant your ADFS service account explicit Read access applied to Descendant User objects, specifically ensuring it has the rights to Read Logon Information and Read Group Membership. Once the ADFS service account can consistently read these attributes, it will issue valid tokens and stop the application loop.

Hope this answer brought you some useful information. Should you have any questions, feel free to leave a comment.

VP

Answer 2

The behavior matches an AD FS passive client loop and token-issuance issue rather than a simple sign-out. Focus should be on AD FS loop detection, IIS/AD FS authentication configuration, and Kerberos/SPN configuration.

Use the following steps to narrow down and remediate:

1. Check for AD FS loop detection events

• AD FS has a loop detection cookie (MSISLoopDetectionCookie) and will throw an error like: MSIS7042: The same client browser session has made '{0}' requests in the last '{1}' seconds.
• Review AD FS event logs around the time of the loops to confirm whether loop detection is being triggered and which relying party is involved.
• If needed for testing, loop detection thresholds can be adjusted, or temporarily disabled, using PowerShell:

    Set-AdfsProperties -LoopDetectionMaximumTokensIssuedInterval 5 -LoopDetectionTimeIntervalInSeconds 20
    Set-AdfsProperties -EnableLoopDetection $false
  

  Do not leave loop detection disabled in production.

2. Verify the relying party is consuming tokens correctly

• Looping typically occurs when the relying party application does not successfully consume the token and sends the browser back to AD FS repeatedly for a new token.
• Coordinate with the third‑party app vendor to confirm:
  • The AD FS token is accepted and validated.
  • The app’s session cookie or internal session state is not expiring or being rejected for specific users (for example, contractors with different claims or group memberships).

3. Validate AD FS IIS authentication configuration

• Misconfigured IIS authentication on AD FS can cause repeated prompts, failed integrated auth, and loops.
• Ensure the AD FS virtual directories are using the default authentication configuration:
  • Default Web Site/adfs: Anonymous authentication
  • Default Web Site/adfs/ls: Anonymous authentication and Windows authentication
• If settings were changed as part of previous troubleshooting, reset them to the defaults using the IIS guidance in Configuring Authentication in IIS 7.

4. Check Kerberos/SPN configuration for the AD FS service

• If Kerberos fails, AD FS may fall back to other methods or fail in ways that manifest as loops or repeated prompts.
• On one AD FS server in the farm:
  1. Open Services and locate AD FS (2.0) Windows Service.
  2. On the Log On tab, note the service account.
  3. Run an elevated Command Prompt and verify the SPN for the AD FS service endpoint:

          SetSPN –f –q host/<AD FS service name>
     

     where <AD FS service name> is the FQDN of the AD FS service endpoint.
• If the SPN is missing or incorrect, correct it on the AD FS service account as per the documented procedure.

5. Review Extended Protection for Authentication and network devices

• Extended Protection for Authentication can cause issues when there is SSL offload/bridging, load balancers, or inspection devices in front of AD FS.
• If such devices are in the path, and especially if only some users (for example, contractors on different networks or devices) are affected, consider testing with Extended Protection disabled:
  • For passive clients (IIS):
    • For Default Web Site/adfs and Default Web Site/adfs/ls on all AD FS servers:
      1. In IIS Manager, open Authentication.
      2. Select Windows Authentication → Advanced Settings.
      3. Set Extended Protection to Off.
  • For active clients (PowerShell on primary AD FS server):

        Add-PsSnapIn Microsoft.Adfs.Powershell
        Set-ADFSProperties –ExtendedProtectionTokenCheck "None"
    

• If this resolves the issue, work with network/security teams to adjust SSL or inspection configuration, then re‑enable Extended Protection following the documented steps.

6. Confirm browser and client behavior for affected users

• Contractors may use different browsers, devices, or security software that interfere with cookies or integrated auth.
• Ensure they use a browser that supports integrated Windows authentication where required, and that cookies and third‑party cookies are not being blocked for the AD FS and application domains.

7. Monitor after changes instead of restarting AD FS

• Restarting the AD FS service temporarily clears state and breaks the loop, but does not address the root cause.
• After each configuration change (IIS auth, SPN fix, Extended Protection, or relying party configuration), test with an affected contractor account and monitor AD FS logs and the application’s logs to confirm that tokens are issued once and consumed successfully.

---

References:

• AD FS troubleshooting: Loop detection
• A federated user is repeatedly prompted for credentials during sign-in to Microsoft 365, Azure or Intune
• ADFS 2.0 error: 401 The requested resource requires user authentication