Workspace ONE and Okta Troubleshooting Blog

I’ve written several blogs on the Okta Integration with Workspace ONE and thought it would be best to consolidate troubleshooting in one place.

When you encounter an error, don’t forget to look at Dashboard -> Reports and go to Audit Events in Workspace ONE Access.

Please bookmark this blog as I will update this blog as necessary.

Troubleshooting Overview

The most important element of troubleshooting SAML is to get a SAML Tracer! Currently I use SAML Chrome Panel but there are plenty of them available:

Make sure you enable the Incognito Mode!

In order to troubleshoot you have to understand the flow. Lets review the flow:


The first step in the end to end flow is the SAML Request to Okta. This is pretty basic and not really much to troubleshoot here. If you have correctly configured the Routing Rules, you should of been redirected to Workspace ONE Access.

Take a look at the Audit Logs for Workspace ONE and make sure you see a SAML_REQUEST that is properly mapped to the the Okta Application Source:

What if you don’t see a SAML_REQUEST? If you don’t see a SAML_REQUEST, then you probably have a mistake in your Okta IDP Settings. Make sure your Issuer URI is the one that ends in idp.xml!

The Object

Okay, so you have the SAML_REQUEST but its not mapped to an object? Or perhaps the wrong object?

Make sure your application source for Okta in Workspace ONE properly maps to the Workspace ONE Access Identity Provider which is configured in Okta:

IDP Not Found??

So now you mapped the SAML_REQUEST to the correct object but you are seeing an IDP not found in the audit details. This is actually quite common and is a result of an incomplete configuration. Take a look at your (built-in) Identity Provider in Workspace ONE Access where Mobile SSO is configured. Make sure your directory is checked off. If you created an “Other” directory for the SCIM integration it needs to be selected. Make sure that All Ranges is selected as well.

Okta Logon Page?

If you have configured Okta Device Trust for Workspace ONE, then this is the expected behavior if you are on a unmanaged device.

Okay, so what if everything mapped out correctly in Workspace ONE access but on the return to Okta you are seeing the logon page? If you look at the audit logs in Okta, you’ll probably see something like:

This is probably because Workspace ONE Access is sending a username (ie. sAMAccountName) and Okta is expecting an email address or UPN.  If this is the case, edit your application source in Workspace ONE Access to send the correct username value:

Digital Workspace

You have configured Okta in Workspace ONE Access but you are not seeing the Okta applications in Workspace ONE?

It is likely that one of the three issues have occurred:

  1. Did you log into Workspace ONE Access as an end user? Okta Application will not appear in the Admin console.
  2. In the Okta Cloud URL  (Identity & Access Management -> Setup – Okta) , do not add the “-admin”. It needs to be end user uri. ie.
  3. Did you select the correct search parameter? In Workspace ONE Access, we typically have a sAMAccountName as the username (ie. jdoe) and in Okta, we typically have an email or UPN as the the username.  If this is the case, change the search parameter (Identity & Access Management -> Setup – Okta) to use email or upn.
  4. Check if your Okta API key has expired.

Okta applications previously were showing in my Workspace ONE Catalog but are no longer appearing

If it has been 30 days since anyone in your tenant has accessed the Workspace ONE console, your Okta API key might have expired. Verify the key in Okta has not expired.

Identity Provider – Okta (3rd Party IDP)

You receive the error “federationArtifact.not.found Federation Artifact not found”

This error means the SAML context that Okta is sending is not currently defined in the 3rd Party IDP. In Workspace ONE Access, go to Identity & Access Management -> Identity Providers and modify the Okta Identity Provider to include the “Unspecified” SAML Context.

You receive the error “You do not have access to this service. Contact your administrator for assistance”

Verify the value being sent in the Name ID is properly configured to match a user in Workspace ONE Access. In Workspace ONE Access, go to Identity & Access Management -> Identity Providers and modify the Okta Identity Provider. Verify what the mapping is for “Unspecified”. If the mapping is set to username, we might have a mismatch. Either check with a SAML Tracer or go to Dashboard -> Reports and go to Audit Events. Look for the “LOGIN failed ()” event and you’ll see the username beside it. If you click on details, you will see something like “IDP (id: 541991) does not have JIT enabled when creating user (nameId: ” You have two options in the case:

  1. Modify the value in Identity & Access Management -> Identity Providers -> Okta Identity Provider so “Unspecified” is equal to Email or UserPrincipalName.
  2. Modify the Sign-On Policy for the Workspace ONE app in Okta to send the Email Prefix/Username Prefix

When you logout of Workspace ONE it will log you back in.

In the “VMware Workspace ONE” application in OKta, click on Sign-On and make sure Single Logout is enabled. You will have to upload your signing certificate from Workspace ONE Access. Once you have enabled this you will need to re-export the metadata and update the 3rd Party IDP in Workspace ONE Access. Don’t forget to enable Single Logout Out (Keep the other two field blank).

Identity Provider – Workspace ONE (Routing Rules)

When using routing rules and after successfully authenticating with Workspace ONE you receive a 400 Error Code: GENERAL_NONSUCCESS

Verify in the 3rd Party IDP setting in Okta that you’ve configured the correct Issuer URI. It should end in “SAAS/API/1.0/GET/metadata/idp.xml”

When using routing rules and after successfully authenticating with Workspace ONE you receive an Okta Logon Page

In the Okta Application Source in Workspace ONE, make sure you are sending the correct value in the Username Value. In most cases, Workspace ONE usernames are sAMAccountName and will not match the username in Okta. You should change the value to either “${user.userPrincipalName}” or “${}”

Device Trust

After successfully authenticating with Workspace ONE you receive a 400 Error Code: GENERAL_NONSUCCESS

  • Verify in the Identity Provider section in Okta that you the “Request Authentication Context” is set to “Device Trust”
  • You can also get this message if Mobile SSO has failed.

On an non trusted device (Unmanaged) you receive the error “Kerberos NEGOTIATE failed or was cancelled by the user”

In Workspace ONE Access, edit the Okta Application Source (Catalog -> WebApps-> Settings -> Application Source), under Configuration – Advanced Properties, make sure Enable Authentication Failure Notification is set to Yes.

On a trusted device (Managed), you are stuck a loop between Okta and Workspace ONE Access

In Workspace ONE Access, edit the Okta Application Source (Catalog -> WebApps-> Settings -> Application Source), under Configuration – Advanced Properties, make sure Device SSO Response and Enabled ForceAuthN Request are both set to yes.

On a trusted device (Managed) you get an Okta Logon page with a “Device Must be Secured by Workspace ONE”

In the Workspace ONE policies, verify that you only have one authentication policy method for each platform. You can not use Mobile SSO + Device Compliance in a Workspace ONE Policy.

In the Okta Administration Console, go to Reports – > System Log.  Look for the log entry “Authentication of device via SAML IDP”. Verify that the result coming from Workspace ONE Access is trusted by looking at the outcome:

  • If this result is False:

    • Verify that Mobile SSO is configured correctly by logging into the Workspace ONE Access Console using a mobile browser.
    • If you have multiple identity providers configured in Okta, Verify that Routing Rules and Device Trust are using the same Identity Provider.
    • Check the audit logs in Workspace ONE Access to verify that Mobile SSO is matching to the correct user.
    • Verify that Workspace ONE Access is sending the correct value back to Okta? Username or Email?
    • If testing on IOS, you can follow this blog on capturing your SAML Response in the HTTP Headers:


You receive the error: “Errors reported by remote server: Required user attributes:[distinguishedName] are missing.”

You have the DN as a required attribute in Workspace ONE Access. You will need to uncheck this value in Identity & Access Management -> Setup -> User Attributes

You receive the error: “Errors reported by remote server: User creation is not supported for specified directory id”

You are attempting to create a user in a directory that is not of type “Other”. Verify when you completed the pre-requisites that you did not use a domain that is used by another directory. Its possible the domain was used for JIT. If this is the case you will need to create another directory of type other with a unique domain.

You receive the error: “Errors reported by remote server: User domain name specified for the user resource doesn’t belong to the directory.”

The domain you configured in the attribute mapping in Okta does not match the domain for the directory created in Workspace ONE Access.

Mobile SSO

You are prompted for a username/password or the Workspace ONE Domain chooser when doing Mobile SSO

The problem here is that Mobile SSO has failed and Workspace ONE Identity is triggering the fallback authentication mechanism. For the purpose of troubleshooting, I recommend removing the fallback mechanism. In the IOS  Policy, remove Certificate Authentication and Password (Local Directory). When you test again you will be prompted with an error message instead.

You are prompted with an error  message “Access denied as no valid authentication methods were found”

  • Check to make sure the “Ios_Sso” profile was pushed to the device. By default, when the profile is created it does not have an assignment group. If not, create an smart group and assign the profile and publish.

You received the error “The required field “Keysize” is missing” when deploying the IOS Mobile SSO Profiles

Something went wrong with the import of the KDC Certificate from Workspace ONE Identity to UEM.
a)Log into Workspace ONE Identity -> Identity & Access Management -> Identity Providers -> Built-In and download the KDC Certificate:
b) Now switch back to UEM, Devices -> Profiles & Resources -> Profilesc) Edit the IOS Profile
d) Click Credentials and re-upload the KDC Certificate.

You received the message “Kerberos NEGOTIATE failed or was cancelled by the user”

Unfortunately this is a catch all error message for mobile sso failures can could be many things. I’ll try to cover some of the common reason here:

a) In Workspace ONE UEM, check your IOS Mobile SSO profile -> Single Sign-on. Verify the Realm is correct. For production it should be “VMWAREIDENTITY.COM”. However if you have localized cloud tenant this can be different (VMWAREIDENTITY.EU, VMWAREIDENTITY.ASIA,  VMWAREIDENTITY.CO.UK, VMWAREIDENTITY,COM.AU, VMWAREIDENTITY.CA, VMWAREIDENITY.DE).  For non-production, you might be on the domain. If this is the case, it should be “VIDMPREVIEW.COM”

b) When you use the wizard to create the Mobile SSO configuration, it will automatically add the application bundle id’s where Mobile SSO is allowed. You will need to either enter all your application bundle id’s into the profile or optionally delete them all. If you don’t specify the bundle id’s, it will allow them all.  I recommend for a POC, you leave this blank.

c) Mobile SSO on IOS is based on Kerberos. The kerberos negotiation works of Port 88 on UDP. Ensure that your firewall is not blocking this port.

d) When trying to provision the Mobile SSO profile you receive an error that the PrincipalName contains an invalid value.

This means that you have probably created the Workspace ONE UEM account with an email as the Username. When the Mobile SSO certificate payload was created, it uses the username as the principal name on the certificate. Unfortunately you can not have the “@” character in the principle name. You have two choices to resolve this issue:

a) When provisioning users from Okta to Workspace ONE Access, use the email prefix as the username.

b) Use a lookup in Workspace ONE UEM to parse the prefix of the email address and use that in the certificate payload:

Group & Settings -> All Settings -> Devices & Users -> General -> Lookup Fields

Add Custom Field

Create a Name such as EmailNickName and use a regex such as “.+?(?=@)”

You can then use “EmailNickName” in your Certificate Payload

One thought on “Workspace ONE and Okta Troubleshooting Blog

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s