Federated identity management using Active Directory Federation Services
Yes, AD FS SSO can work in environments that use both network load balancers (NLB) and application load balancers (ALB), but repeated login prompts indicate an SSO/authentication flow problem rather than an incompatibility with the load balancers.
From the provided context, repeated prompts are typically caused by AD FS not being able to complete or persist an SSO session correctly, or by the application/auth request forcing re‑authentication. Use these checks:
- Verify AD FS is healthy and sign‑in works directly
- Enable and test IdP‑initiated sign‑on internally:
Set-AdfsProperties -EnableIdPInitiatedSignonPage $true - From inside the network, browse to:
https://<FederationInstance>/adfs/ls/idpinitiatedsignon - Sign in with a valid user.
- If this fails, follow the “Users can't log in the target site or service” section to check:
- AD FS service status in Server Manager → Tools → Services → “Active Directory Federation Services” is Running.
- Endpoints are enabled in AD FS Management Console → Service → Endpoints.
- Enable and test IdP‑initiated sign‑on internally:
- Check whether the issue is at the AD FS sign‑in page or at the application
- If the error URL shows the AD FS service name (for example
fs.contoso.com), troubleshoot AD FS itself as above. - If the error URL shows the application or its IP, troubleshoot the relying party / application configuration.
- If the error URL shows the AD FS service name (for example
- Check for unexpected NTLM/forms prompts (looping logon screens)
Repeated login prompts often mean Windows Integrated Authentication (WIA) is not working as expected:
- On client browsers (Internet Options):
- Advanced → ensure Enable Integrated Windows Authentication is enabled.
- Security → Local intranet → Sites → Advanced → ensure the AD FS URL is listed.
- Security → Local intranet → Custom level → Automatic logon only in Intranet zone.
- On AD FS, verify WIA settings:
- Check
WindowsIntegratedFallbackEnabled:Get-ADFSGlobalAuthenticationPolicy | fl WindowsIntegratedFallbackEnabled- If True, forms‑based auth is expected for non‑WIA clients.
- Ensure the browser user agent is in
WIASupportedUserAgents:
Add missing user agents and update withGet-ADFSProperties | Select -ExpandProperty WIASupportedUserAgentsSet-ADFSProperties -WIASupportedUserAgents $wiaStringsas shown in the context.
- Check
- On client browsers (Internet Options):
- Check the authentication request from the application
- If the application or ALB is sending auth requests that explicitly demand forms auth or fresh login, AD FS will keep prompting:
- For WS‑Federation, see if the request includes
wauth= urn:oasis:names:tc:SAML:1.0:am:password(forces password prompt). - For SAML, see if
samlp:AuthnContextClassRefisurn:oasis:names:tc:SAML:2.0:ac:classes:Password.
- For WS‑Federation, see if the request includes
- For Microsoft Online Services, the
PromptLoginBehaviorsetting can cause repeated prompts; adjust via:Connect-MgGraph -scopes Domain.ReadWrite.All, Directory.ReadWrite.All $tdo= Get-MgDomainFederationConfiguration -DomainID <domain_id> Update-MgDomainFederationConfiguration -DomainId <domain_id> -InternalDomainFederationId $tdo.Id -PromptLoginBehavior <translateToFreshPasswordAuthentication|nativeSupport|disabled> Disconnect-MgGraph
- If the application or ALB is sending auth requests that explicitly demand forms auth or fresh login, AD FS will keep prompting:
- Validate relying party and client configuration
If the application is configured as a relying party or via Application Groups:
- Retrieve relying party and client settings and compare with what the app actually sends:
$rp = Get-AdfsWebApiApplication ResourceID # For public client $client = Get-AdfsNativeClientApplication ClientName # Or for confidential client $client = Get-AdfsServerApplication ClientName - Confirm that:
- Relying party ID matches
$rp.Identifier. - Relying party redirect URI matches
$rp.WSFedEndpointor$rp.SamlEndpoints. - Client ID matches
$client.ClientId. - Client redirect URI matches
$client.RedirectUri.
- Relying party ID matches
- For OAuth requests, ensure parameters match AD FS configuration:
https://sts.contoso.com/adfs/oauth2/authorize?response_type=code&client_id=ClientID&redirect_uri=https://www.TestApp.com&resource=https://www.TestApp.com
- Retrieve relying party and client settings and compare with what the app actually sends:
- Consider load balancer behavior
While not detailed in the context, repeated prompts in an NLB/ALB scenario are commonly triggered by:
- Requests not consistently hitting the same AD FS node (no session affinity) while using cookies bound to a specific node.
- Name resolution or routing misconfiguration between internal NLB and perimeter/WAP as described in the AD FS farm design guidance.
Ensure the federation service name (for example
fs.contoso.com) resolves consistently and that WAP or other proxies correctly forward to the AD FS farm.
If IdP‑initiated sign‑on works reliably and the prompts only occur when going through the application, focus on the relying party configuration and the authentication request parameters rather than NLB/ALB themselves.
References: