Hi! I do want to ensure I understand your scenario correctly, so I do have some initial questions:

• Are you integrated currently with an AD domain? I am assuming you are as you reference AD Agents. The domain the machine you are logging on to should not matter. For instance, whether I logon to Okta via my work machine connected to VPN or my iPad, I am navigating to the same Okta URL and using the same username/password.
• The reason I ask about the AD domain above, is my next question is assuming that you are using AD and integrated, are you utilizing Delegated Auth? If so, the password you are logging onto with Okta is the same password as is set in your connected AD domain. Again, this is independent of the AD domain the machine you are connecting from is joined to (if one is connected at all), as I would use the same username/password regardless of connecting from work or my iPhone.

With that out of the way, and understanding that your local machine domain is a separate issue than anything associated with logging onto your Okta portal -

when we say "trusted network", are you referring to a "Network Zone" specified in Okta? In many organizations, they do specify their on-premise or VPN networks so as to enforce a different MFA requirement as opposed to connecting from outside the corporate network. These "Network Zones" are defined by subnet or individual IP. They can be used to block or allow connections, as well as used to influence sign-on conditions for your users.

Lastly, what application are you attempting to connect to? For example, there are plenty of SaaS based applications we leverage that can be accessed from anywhere. On the other hand, there are some applications that can only be accessed either via on-site or when connecting from VPN. These differences should not have an affect on whether you can logon to Okta and get your homepage, but it may very well affect your ability to connect to a specific application. Some of these requirements can be specified (via application specific sign-on policies) or may be a fundamental requirements (e.g. On-site Sharepoint).

Hopefully some of this information helps and if anything, can help clarify the presented situation and will lead us to a solution.

Hello Don!

Thank you so much for writing back. I'll say right away that once the right Okta engineer got more involved with our problem, they quickly found the solution.

Just for your sake and everyone's if someone ever looks this up:

-yes we are AD integrated

-yes we are using delegated auth.

-About the trusted network, I probably did not have the correct terminology, but yes I was clearly refereding network zones. Basically our company policy states that if the Okta requests comes from certain IP's (ie trusted network) MFA will never be enforced. For example accessing the okta dashboard from home will prompt for user/pass + MFA - while using the okta dashboard at work should single sign on without MFA.

-The application I was refering to mainly here was Netskope a web proxy client, but really I made my question more generic because the behavior we were seeing in Netskope was seen in simple things like.. the Okta dashboard, we just had means to go around it like the /signin/default okta page.

--Now, I can tell you, not in detail unfortunately, what ended up beeing the solution for us. The okta engineer had to change the 'routing policies' for this particular application, to remove the Single Sign On feature provided by the Okta AD Agents. Removing the SSO feature for this app made it mandatory to enter email/password in an Okta prompt, even for those that would have SSO'ed before, but this removed the Bad SAML error we were getting.

I told our Okta person here the best scenario would be if routing on a single app could be something like:

-Okta AD Agent - to try SSO

then if it fails

-Simple Okta auth with email / pass.

FYI the app concerned here needed credentials only one time for enrollment, so entering them is not a major dealbreaker..

Thanks again for replying and trying to help!

Ah, thank you so much for your reply to the thread and certainly glad to see that you got it worked out. As with anything, so much variation in use case and individual org configurations ensures that it can be hard to troubleshoot without all the info, but you did a great job in providing that data and with feedback. Thanks so much and good luck to you in the future! Never hesitate to bring more questions to the community.

Thanks again!