
RaviS.80313 (Customer) asked a question.
Default routing to IWA Agent Authentication instead of Agentless DSSO Authentication
Enabled Agentless DSSO authentication type but by default few users it's redirecting to on-prem IWA Authentication type. We didn't see any discrepancies from their logs.

Hi @RaviS.80313 (Customer) , Thanks for taking the time to reach out to the Okta Community!
Double check the routing rules configuration under your Okta Admin Dashboard→ Security→ Identity Providers→ Routing Rules Tab. Docs can be found here:
https://help.okta.com/en/prod/Content/Topics/Security/configure-routing-rules.htm
First, if you have multiple routing rules make sure that the affected users don't somehow fall under a rules that is higher in priority than the one you expected.
Then you can go step by step and confirm the usual culprits like IP/Network Zones configuration and "USER MATCHES" condition in case you have a custom Regex or attribute configured.
The other rule conditions should also be validated if the above has be already confirmed.
Hope it helps!
Hi MihaiNegoita,
Thanks for your swift response. As per your suggestion we have validated our routing rule and it's configured as per Okta recommendation.
As per our analysis
We need your support is there anything(Attribute,Policy) we need to specifically handled in Incognito browser window for AgentlessDSSO Authentication Implementation.
If you need any additional information then please let me know.
Hi @RaviS.80313 (Customer) , I was able to track down a similar situation. Seems to be expected behavior:
Please take a look at the following:
https://support.okta.com/help/s/article/After-recent-Google-Chrome-update-from-80-to-81-version-IWA-broken-in-incognito-mode?language=en_US
Hope it helps!
Hi Mihai Negotia,
Thanks for your response. We will explore this option. We have one more doubt since few users are facing this issue why Okta was not capturing this failures(step: agentlessDSSOPrecheck) in Okta logs because with the help of developer tool option in browser window we could see this step was showing red color and status code was : 401 Unauthorized when it comes with regular window status code was 200 and successful.
Hi Mihai Negotia,
We have verified the AmbientAuthenticationInPrivateModesEnabled and the value was set it 1 in chrome browser. Actually the user when he connected from Chrome browser the agentlessDSSOPrecheck step completed successfully with status code 200 but the same user when he connected from Chrome InCognito window the agentlessDSSOPrecheck got failed and the status code is 401 in browser trace.
Kindly let us know anything else is causing this issue