00u1p42rd6MIUWFEMVAE1.559345698484607E12 (Customer) asked a question.
Hello Okta Community,
Not an Okta admin myself but working with our team to implement a new app using Okta as IDP. Sorry if any of the terms are incorrect. Here the scenario and my question:
With our current Okta implementation, when on our trusted networks we do not need to provide any MFA authentication. Instead on the back end, it contacts Okta AD Agents to validate our accounts. This is working fine.
Now with the following scenario, on a machine ON the trusted network, but using either a local account / or different AD domain account (different than the Okta AD Agents), we get to an Okta authentication prompt where we need to enter credentials. This is the desired behavior, we expect users to enter valid Okta credentials here (ie different from the account used on the machine). We enter credentials and then get to a Bad SAML error. I beleive this is coming from the machine reaching out to Okta AD agents (as we are on the trusted network) and then I guess these AD agents fail to match the currently logged in user to anything in AD.
Now my question is, is this all expected? Would'nt providing valid Okta credentials override whatever account is currently logged in? One last point I want to make, if we are OFF the trusted network, with the same scenario (local account), we can enter credentials, get MFA prompt, and use application fine.
Thank you for any help and insight, and let me know if I can provide more details.
Hi! I do want to ensure I understand your scenario correctly, so I do have some initial questions:
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!