<iframe src="https://www.googletagmanager.com/ns.html?id=GTM-M74D8PB" height="0" width="0" style="display:none;visibility:hidden">
Loading
Skip to NavigationSkip to Main Content
0D51Y00006Xd52fSABOkta Classic EngineDevices and MobilityAnswered2024-12-25T09:00:17.000Z2019-08-12T19:42:34.000Z2021-03-12T11:51:35.000Z
  • FrederickA.40854 (Customer)

    Hi Jeremy,

     

    Just out of curiosity. Did you fix this? Do you have a Custom Domain in Okta?

  • BryanM.87834 (Customer)

    Was there an answer to this? We are seeing this on the latest version of Jamf against Okta when we force the network authentication with the denylocal, however we do have it to allow fallback but that seems to just loop the client back to the Jamf Connect Login screen.

    This problem seems to be over a year old. Odd thing is we don't have this issue with an older version of Jamf Connect and Okta.

    Expand Post
  • 6xkbv (6xkbv)

    I had the same issue. My problem was, I assumed that the OIDC Redirect URI was a default setting because the recommended use is in grey in the Jamf Connect Configuration app. Finally, after hammering my head on this for a few days I added "https://127.0.0.1/jamfconnect" as the OIDC Redirect URI in the plist and the login started working.

  • BryanM.87834 (Customer)

    Thanks, I have worked with Jamf support and even though we were using the URI correctly some things seemed off. We are still not seeing any authentication in our OIDCAdminClientID, even though it seems to be working.

This question is closed.
Loading
User blocked for signing in by OIDC lookup