Okta Help Center - Questions Skip to main content
https://support.okta.com/help/answers?criteria=allquestions&dc=questions&feedtype=popular&refurl=http%3a%2f%2fsupport.okta.com%2fhelp%2fanswers
How satisfied are you with the Okta Help Center?
Thank you for your feedback!
How satisfied are you with the Okta Help Center?
1
2
3
4
5
Very Dissatisfied
Very satisfied
Enter content less than 200 characters.
Ask Search:
Kyle EdsallKyle Edsall 
I am hoping there might be a mechanism for me to setup an alert to notify me when logins are attempted from outside geographic IP ranges that I have specified.  For instance, if someone attempts to login with their OKTA credentials from outside of the US & Canada, I would like to know about it then decide how to act.  Is this possible?
Best Answer chosen by Dylann Fezeu (Customer First Programs)
Razvan PopaRazvan Popa (Okta, Inc.)
Hi Kyle,

Currently, the information you're looking for only populates in the system logs, however you can always submit an idea here: https://support.okta.com/help/oktaideas

Kind regards,

Razvan Popa
Technical Support Engineer
Okta Global Customer Care
Best Answer chosen by Dylann Fezeu (Customer First Programs)
Justin BergezJustin Bergez (Okta, Inc.)
Hi Paul,

While we do not currently have agentless RADIUS on the roadmap, we are continually hoping to improve our product, so perhaps you would like to lend an additional voice (and vote) to this feature enhancement request (https://support.okta.com/help/ideas/viewIdea.apexp?id=087F0000000BEmi).

Every day, we are moving more and more toward our ultimate goal of hosting all services through the cloud. For instance, we currently have 1/2 of the feature request above (agentless LDAP) as an internal Beta feature, and we've already begun the process of moving RADIUS toward the cloud with the RADIUS App (https://help.okta.com/en/prod/Content/Topics/Security/Okta_Radius_App.htm) model. We're ready and anxious to get there, we just need customers like you willing to help lead the charge.

If you have follow-up questions, or need any clarification on anything, feel free to submit a ticket to Okta Support. We can always find an available support engineer, 24/7/365.

Justin M. Bergez
Sr. Technical Support Engineer | Okta, Inc.
justin.bergez@okta.com
1501885747483_PastedImage
Best Answer chosen by Dylann Fezeu (Customer First Programs)
Mihai NegoitaMihai Negoita (Okta, Inc.)
Hi Steve,

Thank you for reaching out to the Okta Community.
If the users are AD mastered and imported from AD you can enabled the " Don't send new user activation emails for this domain" option from the AD Settings in Okta.

User-added image

If not mastered by AD, you can leverage the Okta API to created users with credentials.
Here is the documentation to get you started:
• https://developer.okta.com/docs/api/getting_started/api_test_client
• https://developer.okta.com/docs/api/resources/users.html?_ga=1.97461855.1568845971.1475808013#users-api

Regards,
Mihai Negoita
Okta Customer Support.
Hans Jakob ThierschHans Jakob Thiersch 
Dear Madams and Sirs,

We are building the cloud app Meisterplan.com and are currently implementing SAML/SSO and testing this functionality with different Identity Providers.

We found out that when exporting the IDP metadata (as described in https://support.okta.com/help/Documentation/Knowledge_Article/More_Apps/How-do-we-download-the-IDP-XML-metadata-file-from-a-SAML-Template-App) the "SingleLogoutService"-entry is missing in the Metadata, 
although this endpoint is existing and working (https://itdesign.okta.com/login/signout).

As we would love to support dynamic SAML configuration for Meisterplan with Okta my question is, whether it is possible to include the SingleLogoutService-entry in the IDP metadata file (most other IdPs like OneLogin and Ping provide this information).

Thank you very much for your time and regards,
Hans Jakob Thiersch
(Product Owner Meisterplan core Product)
 
Best Answer chosen by Dylann Fezeu (Customer First Programs)
Darron HellmannDarron Hellmann (Okta)
Hi Hans

Absolutely, I assume you're referring to Okta's SAML 2.0 application template. During or after the creation of your application you can enable SLO (General -> SAML Settings -> Show Advanced Settings). By doing so and providing the service providers single log out URL, SP Issuer information and certificate , you can then generate metadata containing information on where the logout response will be sent. Please note, you can supply place holder values for these fields temporarily to generate metadata.

Example with SLO Disabled in Okta (General tab of application)

</ds:X509Certificate></ds:X509Data></ds:KeyInfo></md:KeyDescriptor><md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</md:NameIDFormat><md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat><md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://subdomain.okta.com/app/slotest_1/exkj9kdjbuN0INC860x7/sso/saml"/><md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://subdomain.okta.com/app/slotest_1/exkj9kdjbuN0INC860x7/sso/saml"/></md:IDPSSODescriptor></md:EntityDescriptor>

Example with SLO Enabled in Okta (General tab of application)

</ds:X509Certificate></ds:X509Data></ds:KeyInfo></md:KeyDescriptor><md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://subdomain.okta.com/app/slotest_1/exkj9kdjbuN0INC860x7/slo/saml"/><md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://subdomain.okta.com/app/slotest_1/exkj9kdjbuN0INC860x7/slo/saml"/><md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</md:NameIDFormat><md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat><md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://subdomain.okta.com/app/slotest_1/exkj9kdjbuN0INC860x7/sso/saml"/><md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://subdomain.okta.com/app/slotest_1/exkj9kdjbuN0INC860x7/sso/saml"/></md:IDPSSODescriptor></md:EntityDescriptor>
Benjamin CampbellBenjamin Campbell 
My Okta environment supports 5 different factors for MFA.  I require a factor upon login, but don't specify which factor. I like this as it supports our varied user environment.  However, there are options / features lacking at least as far as I can tell.

I can't seem to find settings to allow preference selections with the exception of pre-populating the previously selected MFA upon login.  Users still have to click on something to get the factor to authenticate.  This interaction is unnecessary and frankly it annoys my users.  Why not give the option to initiate user's chosen MFA option upon signing in?  Why make the user click something after already logging in?  Seems unnecessary and slows down the user's experience significantly.

Am I missing something?  A setting somewhere?  Please advise.
Best Answer chosen by Benjamin Campbell
Benjamin CampbellBenjamin Campbell
Yes, I created a support ticket.  Okta has a feature they can turn on for your Org.  It only applies to okta verify, but it works well.  It only took a few minutes to resolve and test.
Rolando AlvarezRolando Alvarez 
Where can I get a list of the last date that every user has logged in to Okta?
Best Answer chosen by Rolando Alvarez
Cody SudersCody Suders (Okta, Inc.)
Try the "Okta Password Health" report under the reports tab.  Column F on that report has the last logon date for each user.
Pawel LisPawel Lis 
Python library djangosaml2 (which internally uses pysaml2) expects <Signature> to be inside <EntityDescriptor>, but metadata.xml does not contain any <Signature>. Is there a way to include it in the output?

http://www.datypic.com/sc/ds/e-ds_Signature.html
Best Answer chosen by Pawel Lis
Pawel LisPawel Lis
There is no way to have <Signature> in metadata, so one has to set "want_response_signed" to False in pysaml2 settings.
Benjamin CampbellBenjamin Campbell 
I realize this is a loaded question, but this is directly aimed at a long term goal:  dropping memorized / keyboard-driven passwords entirely.  Okta obviously helps to significantly reduce the number of passwords a typical enterprise user has to remember.  However, I don't yet see a path to eliminating the password entirely.  I'd rather use a combination of other factors to verify a user and then leverage Okta's integration / directory syncronization / etc capabilities for posting / SSO into other services that require authentication (password needed or not).

This is my first time posting on anything Okta, so apologies if this is a repeated topic.  However a lofty goal this is, it's certainly a valid one.  Time to kill the password.
Best Answer chosen by Benjamin Campbell
Benjamin MullenBenjamin Mullen
Hi Ben,

We're trying to do the same thing. From an Okta perspective, their IDP discovery features coming out appear to be leading down a path where a user can enter a username and then receive a push notification via Okta Verify, for example.

But that seems a good 6-9 months out at least. So we looked for a 3rd party IDP that we can then set Okta to trust to allow for optional no-password login in the meantime. We've settled on a company that uses QR code scanning via a mobile app to do just this. Happy to share details privately.

We're also piloting Windows Hello as we're predominantly a Windows 10 shop. So far it's being received very well, especially from our travelers. Hoping that Chrome gets on the Web AuthN bandwagon quickly so it's not just available in Edge.

For IT users and the like that need remote server access, we're looking at a purchase for a privileged access broker that would integrate with a credential vault to bridge that gap.

Even still, an Okta user needs his/her password to edit user settings, add MFA options, or log into the Okta Mobile app. Our MDM also relies on passwords for device registration. So we're not 100% there yet.

We've taken the approach of enabling no-password authentication wherever possible, hoping to close gaps as we go. I agree with you - we can't sit idle and wait, we need to start moving away from shared secrets for authentication.

Ben
Flavel HeymanFlavel Heyman 

We required the "Security Question" MFA and I was trying to write the code to add the factor but keep receiving an error message: 

HTTP -1, Okta E0000003 (The request body was not well-formed.), ErrorId oaed7Qo2BLCQkm8YzCb8tF5KQ

Code:

com.okta.sdk.resource.user.User newUser = UserBuilder.instance()<add_stuff_here>.setActive(false).buildAndCreate(oktaClient);

Iterator<Factor> factors = newUser.listSupportedFactors().iterator();
while (factors.hasNext()) {
  Factor factor = factors.next();

  if (factor instanceof SecurityQuestionFactor) {
    SecurityQuestionFactor sqf = (SecurityQuestionFactor) factor;
    SecurityQuestionFactorProfile profile = sqf.getProfile();
    profile.setQuestion("name_of_first_plush_toy");
    profile.setAnswer("Hardcoded");
    sqf.setProfile(profile);

    newUser.addFactor(sqf);
    newUser.activate(false);
}
I wasn't sure what part of the request body was not well-formed (newUser.addFactor(sqf); is the location of the exception)
Best Answer chosen by Flavel Heyman
Flavel HeymanFlavel Heyman
Nevermind, found out how to instantiate Factors:  oktaClient.instantiate(SecurityQuestionFactor.class);