Application / SSO Setup
|Q: We're configuring SAML for <application>. After following the provided Okta instructions, we can no longer access the application. SSO is failing with <error> and we cannot login in order to disable SAML. How can we troubleshoot?||
- Regaining Access: Most SAML enabled applications offer some form of 'side door' such as a unique URL which only permits administrators to login with credentials. Examine the application's documentation to determine what method the app uses. In some cases it may be necessary to contact the app's support team in order to restore credential based access.
- Troubleshooting: Because SAML is a static configuration requiring no 'order of operations' for set up, in most circumstances troubleshooting a failed SAML configuration is simply verifying that the correct data is configured on either side of the connection (IDP and SP). For example, verify that the IDP SAML metadata is correctly configured on the SP side and vice versa. Beware of 'copy/paste' errors. Additionally, ensure that the issue is not the username match between Okta's appusername and the actual username in the app itself. Mismatched usernames will cause a properly configured SAML connection to fail.
|2||Application / SSO Setup||Q: We assigned an application to a end user and the user reports that the application is not on their Okta dashboard. What went wrong?||
Assigned Application Missing from Okta User's Page
- Context: When troubleshooting provisioning issues, the first thing to verify is scope. How many users are impacted, an individual, a group, or all users? This guidance assumes a single user is impacted.
- Troubleshooting: When provisioning a user to an application, there are a variety of scenarios that can occur to prevent a successful assignment/provisioning event. Source directory issues, permissions (user/service account), or attribute mapping issues can create a failure. In all cases, when Okta attempts to provision a user to an app, if we are unsuccessful we create a task on the Okta Admin Dashboard detailing the cause of the failure.
|3||Application Provisioning / User||Q: We're receiving calls from multiple users about sudden loss of access to (critical app). The logs show that Okta deprovisioned these users. What changed to trigger this deprovisioning event?||
Multiple users suddenly deprovisioned from application
- Context: When troubleshooting unanticipated deprovisioning events, it is vital to ascertain what criteria were used to perform the provision to the application in the first place. Were the users directly assigned to the app, individually? Were they assigned by Okta Group? By Active Directory Group? By dynamic group rules evaluating profile attributes?
- Troubleshooting: When the provision criteria is verified, investigating if this condition changed for the impacted users will generally reveal the cause.
- Troubleshooting: Most commonly, the cause will be related to the source directory, usually AD. Altering permissions (or outright disabling) the service account supporting the Okta AD Agent and/or relocating groups and OUs to locations not included in Okta's import manifest, are the usual suspects
|4||Application Provisioning / User||Q: We've had (app) in production for about 18 months. However, we just integrated it with Okta for SSO and Provisioning. Now, we're finding that while newly provisioned users are successfully having their application profiles managed from Okta, users that existed in the app before Okta can not be managed from Okta using any provisioning feature - profile updates, password sync or deprovisioning. What is causing this?||
Profile Updates Aren't Being Pushed after Enabling Provisioning
- Context: Typically this is caused by Okta being unaware of an attribute on users that were created (provisioned manually) in the App prior to the Okta Provisioning integration being enabled. This attribute is usually referred to as an ExternalID but can have a variety of names. When Okta provisions a user, this is automatically communicated. But for users created before Okta, the lack of this attribute (on the Okta side) will prevent Okta from managing profiles, password sync, and deprovisioning events.
- Troubleshooting: If the organization can afford the temporary disruption, the lowest risk strategy is to deprovision all users and push them fresh from Okta.
- Troubleshooting: For simpler apps (noncomplex profile/no group push) this can be repaired by importing users from the app, to Okta and matching them to their counterpart accounts. This synchronizes the ExternalID attribute and permits management from Okta
- Troubleshooting: The same recovery strategy can be used for more complex apps, however, be wary of an app import potentially revealing misconfiguration in app level assignments or manually altered attributes in the app which would otherwise have been managed from Okta.
- Please Note: Behavior can differ significantly on an app by app basis. Review documentation on both the Okta side and the App side to set expectations about provisioning behavior.
|5||Application Provisioning / User||Q. When we manually update a user's attributes using our Service Provider's admin console (for example, Salesforce), Okta eventually overwrites the attribute back to its old value. What is causing this?||
- Context: This is due to the application's provisioning configuration in Okta. If provisioning is enabled and the "Update User Attributes" box is checked, Okta will update *all* attributes whenever a change to any other Okta attribute is detected. For example, if the user's email address is modified in Salesforce, and that corresponding Okta user's first name is modified, Okta will trigger a profile push and will replace all mapped Salesforce attributes with the Okta values, including the manually modified email address. To allow for manual attribute updates from the service provider end, disable the "Update User Attribute" option.
|6||Directories / Active Directory||Q: Suddenly, none of our users can log into Okta/Apps. Even our admins can't login to Okta. Help! (Part 1)||
- Context: If a customer has configured Okta to use Delegated Authentication against a directory, anything that disrupts Okta's communication to that directory will have an immediate effect on all authentication to Okta and linked applications.
- Troubleshooting: The most common cause of this occurrence is a change in permissions on the Service Account which is supporting the Directory Agent. Best Practices strongly recommend using a directory Service Account that is NOT tied to a given user or employee. However, it's not uncommon for the Admin who configures Okta for the first time to provide their own account to support the Agent Service. If this person is then promoted out of their role or leaves the organization (any change that would lead to altered account permissions) this will immediately sever communication between Okta and the Directory, stopping all Authentications and of course, Imports. Simply restore the account permissions to restore access. Then, execute a change management process to reinstall all Directory Agents using the best-practices 'generic' Service Account. Note: Okta will create this account for you during the installation, if permitted to do so.
- Troubleshooting: There are a large number of alternative potential causes to consider if communication between Okta and the AD agent has ceased. Things to consider:
- Change to networking or firewalls impacting communication?
- Was the Agent installed in a proxied configuration? Is the Proxy healthy?
- Consult the local logs compiled by the agent itself, and potentially, enable verbose logging
- Consider restarting the Okta AD Agent Service, even if it appears to be running.
|7||Directories / Active Directory||Q: Suddenly, none of our users can log into Okta/Apps. Even our admins can't login to Okta. Help! (Part 2)||
- Context: Sometimes total loss of access is not related to Delegated Authentication or Agent communication errors. The other common scenario that can precipitate this situation is a change to the location of User or Group Objects in Active Directory, relocation of the OUs themselves within the structure, or (on the Okta side) a change to the User OU or Group OU import selection UI. In this case Okta is doing the correct thing in reinterpreting imported resources and it is typically the change of those locations that has unintended consequences.
- Troubleshooting: If the change was made on the AD side, Okta will become aware of it on the next Import. This can be corrected either by restoring the original configuration in AD and performing a Full Import or by altering the User OU or Group OU import selection UI in Okta to account for the changes in AD. This too, will require a Full Import to take effect.
- Troubleshooting: If the change was made on the Okta side, it is generally easiest to restore the originally targeted OUs and perform a Full Import to restore the relationship between the Okta User Objects and the AD User Objects.
- Note: These troubleshooting steps require access to Okta with an administrative account. If your organization is using best practices, you will have at least one Super Administrator in Okta that is not tied to Active Directory and this account can be used. However, if all Okta Admins are paired with AD users for authentication (and AD is unreachable) it will be necessary to contact Okta Support. We can disconnect a given user from AD permitting login for troubleshooting.
|8||Directories / Active Directory||Q: All of our AD users targeted by selected OUs in the Okta config have been successfully imported to Okta and matched or created. All except one/several. What is preventing this user/these users from being imported and created or matched?||
AD User Is Not Imported Into Okta
- Troubleshooting: When most, but not all, users are properly imported and created or matched, there can be a wide variety of causes that impact the unlucky accounts. Here are some things to consider:
- What do these users have in common otherwise? Admins? Created at the same time? Unusual profiles?
- Do the impacted users have all of the required attributes (UPN, SAMAccountName, surname (lastname), givenname (fname), and GUID)?
- Do the impacted users have isCriticalSystemObject set to TRUE?
- Doublecheck to confirm that the impacted users are indeed in a OU that is selected in Okta for import.
|9||Directories / Active Directory||Q: An Okta Import from AD deprovisioned all/some of our users. What happened?||This is essentially the same question as "Suddenly, none of our users can log into Okta/Apps. Even our admins can't login to Okta. Help! (Part 2)" Resolution steps are the same.|
|10||Directories / Active Directory||Q: Our on-premise users normally sign into Okta automatically, without needing to type their credentials into Okta or apps. Today, however, we're receiving reports that users are getting stuck at sign in and are seeing an error page or just getting dumped to the manual login page. How do we restore access rapidly? How do we troubleshoot?||
- Context: The scenario articulated here implies that the customer is using the Desktop SingleSignOn (DSSO) to abstract enduser's workstation login to Okta authentication as well. This is achieved through a Kerberos exchange leveraging an IWA (Integrated Windows Authentication) web app hosted internally on a Microsoft Web Server.
If an error occurs with the configuration, endusers will either see a standard login screen (with an auth error) permitting them to log in manually (albeit not enjoying the anticipated convenience of auto login) or they will get a server error page which offers no clear workaround path.
- Regaining Access: Rapidly restoring access can be achieved by simply turning off the DSSO feature at the Okta level. If Administrators are also struggling to gain access due to the failure mode, the Okta credential side-door can be accessed at the /login/default page. (Example: https://acme.okta.com/login/default). This side door URL can also be used by the Helpdesk to guide users into the system while troubleshooting is underway (if disabling DSSO is not an option).
- Troubleshooting: Troubleshooting DSSO, much like troubleshooting SAML, is generally a process of reviewing the configuration to make sure the pieces that should be set up, are set up. If compartmentalization in the organization restricts systems available for easy troubleshooting, simply reinstalling the configuration from the ground up (uninstall webapp, uninstall IIS, reinstall IIS with default roles, reinstall webapp) will frequently restore functionality, even if it doesn't reveal the root cause of the failure.
- Troubleshooting: Most frequent culprits are:
- altered permissions on the IIS web app pool
- altered network configuration locally or in Okta that impacts Okta's perception of the network location of the requesting user (i.e. on-prem uses DSSO, off-prem always uses credential based manual login)
- IIS service requires a restart
|11||Mobile / Native App Issues||Q. We are running an IOS or Android application that is configured to use Okta for SAML authentication. We find that our sessions are expiring after a few hours and we're forced to authenticate into Okta again, even though the time specified in our Session settings hasn't been exceeded. How can we prevent these expired sessions, and/or is there any way for the previous successful Okta authentication to be "remembered" when the session expires?||
- Context: Native IOS and Android applications do not actually store an Okta session cookie like web browsers do, as they almost always use embedded browsers instead of the device's native browser. Okta therefore has no ability to dictate how long the native application's session will last, and every redirect from the native application back to Okta will require a new authentication attempt. There are a few potential future solutions to this behavior that involve applications leveraging the device's native browser, which can store and share cookies. As more developers incorporate these solutions, native application session timeout and sign-on behavior should be much improved. We recommend contacting the author of the mobile application to request that they leverage the native application for authentication (this is known as Safari View Controller in IOS devices).
|12||Product Management||Q: How do I submit a Feature Request or emphasize the urgency of an existing Feature Request?||
Submit Product Ideas to the Okta Community
- Context: All Feature Requests are managed through the Okta Community. This strategy affords Okta customers the ability to upvote their preferred Features from the pool submitted by all customers. Moreover, it provides valuable prioritization information to Okta Product Support both in how the request is articulated and the popularity it achieves in the Community.
- Process: Okta Product Management monitors the forum and maintains the status for each request, based on overall customer interest, alignment with Okta's strategic product direction, etc. Feature Requests with the greatest number of votes will be most actively reviewed by Product Management. Status options include Declined, Under Consideration, Short-Term Roadmap, Long-Term Roadmap, and Delivered.
- Process: When submitting your request, or 'Idea', It's very important to provide as much information as possible. Particularly:
- your functional requirements for the feature
- your business justification for requesting it
- a description of the impact to your business if not implemented
- your sense of urgency around delivery (long-term or short-term need)
- Note: Customers with a Premier Plus Customer Success package my additionally work with their assigned Customer Success Manager for progress updates.