Skip navigation
1 2 Previous Next

Steve's IDM Blog

24 posts

For updates on this blog and other blogs: Follow @SteveIDM

 

I've had quite a few requests lately for assistance setting up SCIM capabilities with OneLogin and Workspace ONE.

 

In full disclosure, I've set this up in my lab but I've not done full end to end testing of all CRUD capabilities.

 

The one obvious difference in the setup and configuration with OneLogin over some of our other partners is the ability to support the Authorization Code Grant Flow.  Big Kudos to the OneLogin team.

 

Lets look at the high level steps:

  1. Create a directory instance in Workspace ONE Access
  2. Create a OneLogin Remote App Access Client.
  3. Configure VMware Workspace ONE application in OneLogin.

 

Create Directory Instance in Workspace ONE Access

In order to create a directory instance in Workspace ONE Access, we'll need to use the API because the type of directory required for this integration can not currently be done using the Admin Console. In the following steps we'll use Postman to run the necessary API calls.

  1. We will need an Oauth Token in order to use the API.  Please see my other blog on your options on getting an OAuth Token
  2. Open a new tab in Postman, Select POST and the method.
  3. For the URL, enter: https://[TENANTURL]SAAS/jersey/manager/api/connectormanagement/directoryconfigs
    Replace the Tenant URL with your URL
    https://dsas.vmwareidentity.com/SAAS/jersey/manager/api/connectormanagement/directoryconfigs
  4. In the Authorization Tab, Select either BEARER Token or OAuth 2.0 depending on the option you chose in Step 1 to get a token. Select or Paste your Token.
  5. In the Headers Tab, Set the Content-Type to "application/vnd.vmware.horizon.manager.connector.management.directory.other+json"
  6. Click on the Body Tab
  7. Use the following as a sample and Click Send:
    {
    "type":"OTHER_DIRECTORY",  
    "domains":["onelogin.com"],    
    "name":"OneLogin Directory" 
    }
  8. In the Workspace ONE Admin Console, verify that the directory is created and is associated with the correct domain.
    Screen Shot 09-25-20 at 03.03 PM.PNG

Create a OneLogin Remote App Access Client

We will now create a OneLogin Application in Workspace ONE Access which will be used by OneLogin to create/update/delete users in Workspace ONE.

  1. In the Workspace ONE Admin Console, go to Catalog -> Webapps
  2. Click New (Top Left)
  3. Enter a Name ie. OneLogin SCIM
    Screen Shot 09-25-20 at 03.09 PM.PNG
  4. Click Next
  5. On the configuration page, you will need to enter:
    SettingValue
    Authentication TypeOpen ID Connect
    Target URLEnter your OneLogin Tenant ie. https://tenant.onelogin.com
    Redirect URLhttps://admin.us.onelogin.com/provisioning/oauth_redirect_uri
    Client IDEnter a value for the Client ID: ie. OneLoginSCIM
    Client SecretEnter a value for the Client Secret ie. Test12345
    Show in User PortalNO
    Screen Shot 09-25-20 at 03.11 PM.PNG
  6. Click Next
  7. Click Next for Access Policy
  8. Click Save

 

This wizard will create a new remote app access client that will be used by OneLogin. You can see the client which was created by going to Catalog -> Settings -> Remote App Access.

 

Warning: Do NOT edit the scopes. You will not be able to re-add the Admin scope if you do.

Screen Shot 09-25-20 at 03.20 PM.PNG

 

Configure VMware Workspace ONE application in OneLogin.

 

  1. In the OneLogin admin console, search for "VMware Workspace ONE" under Applications
    Screen Shot 09-25-20 at 03.24 PM.PNG
  2. Select and Click Save
  3. Click on Configuration on the left menu
  4. Under SCIM Base URL, enter: https://[tenant].vmwareidentity.com/SAAS/jersey/manager/api/scim
    ie. https://dsas.vmwareidentity.com/SAAS/jersey/manager/api/scim
  5. Under VMware Site, enter your tenant URL. This will be used as the Oauth Authorization Server URL.
    ie. https://dsas.vmwareidentity.com
  6. Under Client ID, enter the client ID you used in the previous step
  7. Under Client Secret, enter the secret you used in the previous step.
    Screen Shot 09-25-20 at 03.31 PM.PNG
  8. Click Save
  9. Go back to the Configuration Tab

    Before you Continue, you need to make sure your Policy in Workspace ONE Access will allow you to authenticate using System Domain credentials without using the backdoor.  You will need a policy similar to below. The Password (Local Directory) needs to be a fallback.
    Screen Shot 09-25-20 at 03.42 PM 001.PNG

  10. Under API Connection, Click Authenticate
    Screen Shot 09-25-20 at 03.32 PM.PNG
  11. In the pop up, click VMware Workspace ONE
    Screen Shot 09-25-20 at 03.33 PM.PNG
  12. When prompted to Authenticate, Select System Domain
    Screen Shot 09-25-20 at 03.39 PM.PNG
  13. Enter your Credentials
  14. You should be returned back to the One Login Portal with a Successful Authorization
    Screen Shot 09-25-20 at 03.40 PM.PNG
  15. Click on the Parameters Tab
  16. We will need to map the attributes appropriately that will be sent to Workspace ONE.

    In order to map the attributes correctly, we will need to understand how users are created in in OneLogin. Take a look at your users to ensure all the required attributes are set for all users that will be provisioned to Workspace ONE Access.  Attributes such as Username, External ID and User Principal Name are typically set if you have an external directory server. If you are creating users directly in OneLogin without a directory server you will need to select different attribute mappings.

  17. Map the attributes appropriately:
    VMware Workspace ONE FieldValue
    Distinguished NameDistinguished Name
    Email AddressEmail
    External IDIf ALL users are created in OneLogin from a directory server, select ExternalID
    If some users are created locally in OneLogin, select Internal ID.
    First NameFirst Name
    Last NameLast Name
    Name IDEmail
    SCIM Username

    If ALL users are created in OneLogin from a directory server, select Username

    If some users are created locally in OneLogin (without a username) , select Email

    User DomainEnter value used as the domain when creating the directory in Workspace ONE Access
    Screen Shot 09-25-20 at 03.59 PM.PNG
    User PrincipleName

    If ALL users are created in OneLogin from a directory server, select User Principal Name

     

     

    If some users are created locally in OneLogin, select Email

  18. Click Save
  19. Click Provisioning on the left menu, and enable the Provisioning Checkbox.
  20. Click Save
  21. Assign a user the application and verify it successfully provisions
    Screen Shot 09-25-20 at 04.12 PM.PNG

For updates on this blog and other blogs: Follow @SteveIDM

 

In this blog we are going to walk through the process of integrating Zoom with Workspace ONE Access.  There are two very important prerequisites before you can setup the SAML integration with zoom:

  1. You need an approved Vanity URL.
  2. Users need to be created with an SSO Profile (unless you are using JIT)

 

Zoom Vanity URL

In your Zoom administration console, under Admin -> Account Management -> Account Profile. You can apply for the Vanity URL at the bottom of this screen. Note: It might take some time to get this approved by Zoom.

 

Screen Shot 08-27-20 at 02.01 PM.PNG

 

Zoom Users

When you create users in Zoom, they need to be created with the "SSO User" feature. Users can be created via CSV or through their API. If you are using the API to create users, you will need to include the "SSOCreate" action:

 

 

{
  "action": "ssoCreate",
  "user_info": {
    "email": "steve@vmtestdrive.com",
    "type": 1,
    "first_name": "Steve",
    "last_name": "Test"
  }
}

 

When users are created, you will see the SSO Icon:

Screen Shot 08-27-20 at 01.56 PM.PNG

Zoom Single Sign-On Setup

 

In order to configure Zoom for Single Sign-On, you will need to your IDP Metadata from Workspace ONE Access.

  1. Log into the Workspace ONE Administration Console
  2. Go to Catalog -> Web Applications and Click the Settings Button
  3. Click on SAML Metadata ->Identity Provider (IdP) Metadata

 

In your Zoom Administration Console:

  1. Go to Admin -> Advanced -> Single Sign-On
  2. Enter your Sign-in page URL. This can be found in the "md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"" tag. This URL will end in /SAAS/auth/federation/sso
    Screen Shot 08-27-20 at 02.44 PM.PNG
  3. Paste your Identity Provider Certificate (Signing). Note: Proper certificate formatting is not required.
  4. Leave the default SP Provider (SP) Entity ID
  5. In the "Issuer (IDP Entity ID)" enter the value from the WS1 Metadata. This can be found entityID field which is on the first line of the metadata. This URL will end in idp.xml.
  6. Select HTTP-POST for the binding.
  7. Select "SHA-256" for the Signature Hash Algorithm.
    Screen Shot 08-27-20 at 02.45 PM.PNG
  8. Under Security, select Sign SAML Request and Save SAML response logs on user sign-in.
  9. Under Provision User, select "Prior to Sign-in" unless you are doing JIT.
  10. Download your metadata at https://yourcompany.zoom.us/saml/metadata/sp

 

Workspace ONE Access Single Sign-On Setup

  1. Log into the Workspace ONE Administration Console
  2. Go to Catalog -> Web Apps
  3. Click New
  4. Provide a Name (ie. Zoom) and an Icon
    Screen Shot 08-27-20 at 02.25 PM.PNG
  5. Click Next
  6. Open the previously downloaded metadata and copy/paste into the URL/XML section.
    Screen Shot 08-27-20 at 02.27 PM.PNG
  7. Click Next, Next Save.
  8. Edit the Zoom Application we just created.
    Screen Shot 08-27-20 at 02.33 PM.PNG
  9. Click Next
  10. Enter the correct Username Value that will be used to match the corresponding users in Zoom.
    Screen Shot 08-27-20 at 02.31 PM.PNG
  11. Open Advanced Properties
  12. Select Sign Response, Sign Assertion and include Assertion Signature
    Screen Shot 08-27-20 at 02.35 PM.PNG
  13. Under Signature Algorithm, change the value to SHA256 with RSA
  14. Under Digest Algorithm, change the value to SHA256
    Screen Shot 08-27-20 at 02.36 PM.PNG
  15. Click Next, Next Save
  16. Assign the Zoom App to your users in Workspace ONE Access.

 

Log into Workspace ONE Access as an end user and test the application.  Use the SAML Response Logs in Zoom to help troubleshoot.

 

Screen Shot 08-27-20 at 02.39 PM.PNG

For updates on this blog and other blogs: Follow @SteveIDM

 

In Workspace ONE Access, you might have configured additional attributes and would like to populate those attributes from your source of truth such as Okta.

 

Perhaps its a single attribute:

Screen Shot 08-20-20 at 02.53 PM.PNG

Or maybe you have many attributes:

 

Screen Shot 08-20-20 at 02.55 PM.PNG

 

When these attributes are created in Workspace ONE Access, they are created in a custom schema.  The schema is in the following format:

 

urn:scim:schemas:extension:workspace:tenant:TENANT:1.0

 

The TENANT will be replaced by your actual tenant name, such as "urn:scim:schemas:extension:workspace:tenant:dsas:1.0".

 

If you are unsure, I recommend you use Postman to query the user using the GET API. ie. {{tenant_url}}/SAAS/jersey/manager/api/scim/Users?filter=userName%20eq%20%22steve%22

 

Here is a sample Postman that I'll use as my guideline. Note - this step is not required but I will use it to demonstrate my approach.

 

Screen Shot 08-20-20 at 02.59 PM.PNG

 

Now that we know how attributes are stored in Workspace ONE Access, lets configure Okta to send these attributes

 

  1. Open the Workspace ONE Application in Okta
  2. Click on the Provisioning Tab
  3. Click on " Go to Profile Editor"
    Screen Shot 08-20-20 at 03.05 PM.PNG
  4. Click Add Attribute
    Screen Shot 08-20-20 at 03.07 PM.PNG
  5. Enter the Display Name, Variable Name and External Name exactly how it is created in WS1 Access (ie. objectGUID).
  6. Enter the custom schema as we noted above. Make sure your tenant name is included correctly.
  7. Check the user personal checkbox under Scope
    Screen Shot 08-20-20 at 03.08 PM.PNG
  8. Click Save
  9. Repeat this process for all the attributes you want to provision.
  10. Click on Mappings
  11. Click on the Okta User to VMware Workspace ONE Tab (Note: My image below is slightly different as I've renamed my application)
    Screen Shot 08-20-20 at 03.12 PM.PNG
  12. Select the correct attribute to map. In my environment, I'm mapping the ExternalID to the objectGUID
    Screen Shot 08-20-20 at 03.13 PM.PNG
    Note: You can get the AD objectGUID using: findDirectoryUser().externalId

  13. Click Save Mappings
  14. Click Apply Updates Now

NOTE: This feature in the AirWatch Provisioning Adapter is only available in Preview

 

Are you using the AirWatch Provisioning Adapter without a locally configured directory in Workspace ONE UEM and when trying to enroll your Windows 10 Devices and you are getting the following error:

 

Screen Shot 08-17-20 at 11.48 AM.PNG

 

The reason behind this error is because UEM is checking if the attribute "aadMappingAtribute" is currently set for the particular user received in the request from Azure.  If the attribute is not currently set, UEM will search the directory to retrieve this attribute based on on the value configured in UEM:

 

Screen Shot 08-20-20 at 12.25 PM.PNG

 

UEM will retrieve this value from Active Directory (typically) and store this as a binary/hex (ie. 1e7306a8-7eb8-4b6e-a22f-c3e951a5db6e) or as a string depending on the mapping attribute data type.  This is very important because UEM will not successfully map to a user if the value is Base64 encoded. So the following "vZ/lGAC9bUWiA7Egpw5fqg==" is not acceptable.

 

If this attribute is not set and you don't have an  Enterprise Systems Connector (ACC) with a directory configured, you will receive this error. If you are using the AirWatch Provisioning Adapter, you probably don't have an Enterprise Systems Connector (ACC) and directory configured.

 

Workspace ONE UEM will allow you to update this attribute manually in the Admin Console:

Screen Shot 08-20-20 at 12.33 PM.PNG

 

This however is not scalable by any means. Workspace ONE Access is releasing functionality to set this attribute when the user is created by the AirWatch Provisioning Adapter. Unfortunately, UEM will not allow this attribute to be updated via the API so only "CREATE" is supported at this time.

 

In the AirWatch Provisioning Adapter, you'll soon be able to map this attribute:

 

Screen Shot 08-20-20 at 12.42 PM.PNG

 

Please remember that this value can NOT be Based64 encoded.  The following is a guideline of possible values:

 

 

aadMappingAttribute in Workspace ONE UEMImmutable ID in AzureAcceptable
18e59fbd-bd00-456d-a203-b120a70e5faavZ/lGAC9bUWiA7Egpw5fqg==YES
00ut8unvqk5z6cgtG0h700ut8unvqk5z6cgtG0h7YES
vZ/lGAC9bUWiA7Egpw5fqg==vZ/lGAC9bUWiA7Egpw5fqg==NO

If you are a VMware Cloud Services Customer and you are trying to use the VMware Workspace ONE application in Okta to leverage SCIM management of identities in WS1, you might be running into an issue with Groups.

 

In Workspace ONE Access you will notice that groups created from Okta are associated with the System Domain but are not associated with associated with the directory that was created for Okta to provision users and groups.

 

oktagroupissue.png

The reason this is happening is because the Okta SCIM request to create a group does not contain the  domain attribute which is associated with the correct directory information in Workspace ONE Access. Unfortunately, the SCIM request to create a group in Okta cannot be customized to include this attribute.

 

To work around this issue, we will have to pre-create the group on Workspace ONE Access.

 

  1. Open a new tab in postman
  2. Add the correct authorization header (as per the main Okta SCIM Integration Blog https://communities.vmware.com/blogs/steveIDM/2019/08/13/workspace-one-okta-integration-part-3-setting-up-scim-provisioning)
  3. For the HTTP Method, select "POST"
  4. For the URL, enter: "https://[TENANT]/SAAS/jersey/manager/api/scim/Groups
  5. Under "Headers", set the Content-Type to "application/json"
  6. Use the following as a sample and Send. You will need to do this for each group you plan on linking in Okta: Replace the DisplayName with the same name as the group in Okta.  You will need to include the correct domain name associated with the directory previously created for use with Okta SCIM.
    {  
      "schemas": [  
        "urn:scim:schemas:core:1.0",
        "urn:scim:schemas:extension:workspace:1.0"
      ],  
      "displayName": "VMWCSPgroup1",  
      "urn:scim:schemas:extension:workspace:1.0": {
            "domain": "vmwaredemo.com"
        }
    
    
    } 
    
    
  7. You will now see the group created in Workspace ONE Access and associated with the correct directory.
    oktagroupissue2.png
  8. In the Okta Administration Console, please make sure this group exists in Okta before proceeding.
  9. In the VMWare Workspace ONE application (in Okta Admin Console), click on the Push Groups tab.
  10. Click on Refresh App Groups to ensure Okta has a complete list of groups in Workspace ONE Access.|
    Screen Shot 08-24-20 at 10.29 AM.PNG
  11. Click on Push Groups -> Find Groups by Name
  12. Enter the name of the group
  13. Ensure that a match is found in Workspace ONE Access with the option to Link Group:
    Screen Shot 05-28-20 at 11.55 AM.PNG
  14. Click Save
  15. Very the the Group Linking was Successful
  16. The group should now sync with Workspace ONE Access.

Admittedly, its extremely frustrating when you've synchronized several attributes from Active Directory (or another source) into Workspace ONE Access and the Admin Console only shows a bare minimum of attributes.

 

Screen Shot 04-29-20 at 10.21 AM.PNG

 

So how do I see all my attributes?  Unfortunately the answer typically requires the use of Postman.  I'm going to show you a quick little trick to see all your attributes without using Postman.

 

Step 1: Search for your User

In the top right corner of the admin console, you will see a search box. Enter the your username here and hit enter:

 

Note: This procedure requires you to search for the user as opposed to going to User & Groups and selecting a user.

 

In the search results, select your user:

 

Step 2: Copy/Edit your URL

Take a look at the URL, it should look something like this (including a Path variable):

 

Replace "/admin/userGroups?path=/users/" with "/jersey/manager/api/scim/Users/"

 

Now your URL should like something like this:

 

Click Enter

 

Step 3: View your Results

 

You should see a result set that contains all your attribute data:

 

Step 4: Format your Results (Optional)

 

This step is completely optional and makes your response easier to read.  I like to use Notepad++ with the JSON Viewer Plugin.

 

I'm currently using this JSON Viewer

A JSON viewer plugin for notepad++. Displays the selected JSON string in a tree view.

Author: Kapil Ratnani

Homepage: https://github.com/kapilratnani/JSON-Viewer

 

Paste your response into Notepad++.

 

From the plugins menu - Click JSON Viewer -> Format JSON

 

You should now see your results in an easier to read format:

 

For updates on this blog and other blogs, follow me on Twitter: @SteveIDM

 

We mostly talk about SAML with Workspace ONE but i'm asked occasionally if Workspace ONE Access can support OpenID Connect? The answer is yes, of course it can.  Just keep in mind before you start to configure OpenID Connect, Workspace ONE Access only supports the email, profile and user scopes.There is no support for custom scopes nor the ability to modify the attributes that are returned in the provided scopes.

 

Workspace ONE Access supports the Authorization Code Grant as well as Client Credentials. For OIDC, we only support Authorization Code.

 

Lets walk through the process to setup an OIDC Application. We are going to use the OpenID Debugger application from Auth0.

 

Create the SAAS Application

 

  1. In the Workspace ONE Administration Console, go to Catalog -> Webapps
  2. Click New
  3. Provide a Name: ie. OpenID TestApp
    Screen Shot 12-18-19 at 02.33 AM.PNG
  4. Click Next
  5. Select OpenID Connect from the Drop List
    Screen Shot 12-18-19 at 02.33 AM 001.PNG
  6. Complete the fields as per your application requirements.  The following is a sample for Auth 0 Client Connect App.
    AttributeValue
    Target URL
    This is just a web link to the target application
    https://openidconnect.net/
    Redirect URL
    If you need more than one redirect URL's you can add them later. Only one will be accepted here.
    https://openidconnect.net/callback
    Client ID
    Enter any Client ID that will be used in the calling application. Do Not Use Spaces or special characters.
    MyOIDCTester
    Client Secret
    Enter a secret that will be used by the calling application.
    ThisIsMySecretKey
    Screen Shot 12-18-19 at 02.35 AM.PNG
  7. Click next
  8. Click Save
  9. Assign this application to your users.

 

Modify the Remote App Access Client

A remote app access client will automatically get created. We will need to modify this client.

 

  1. Go to Catalog -> Settings
  2. Click on Remote App Access
  3. In the Client List, look for the Client ID that was used in the earlier step. In my example, I used "MyOIDCTester"
  4. Click on the Client ID
  5. Under Scopes, Click Edit
  6. Select Email and Profile

    Note: This will remove the Admin scope. If you really need to keep the admin scope you will need to perform this step using the API.

  7. Click Save
  8. If you want to prompt the user to authorize the user grants, you will need to do the following steps: I will skip this step for now.
    1. Click Edit beside Client Configuration
    2. Select "Prompt Users for Access"

 

Testing with the Auth0 OpenID Connect Debugger

  1. Go to https://openidconnect.net/
    Screen Shot 12-18-19 at 03.33 AM.PNG

  2. Click on Configuration
    AttributeValue
    TemplateCustom
    Discovery URL

    https://[tenant]//SAAS/auth/.well-known/openid-configuration

    ie.

    https://dsas.vmwareidentity.com/SAAS/auth/.well-known/openid-configuration

    Authorization Token Endpoint

    https://[tenant]//AAS/auth/oauth2/authorize

    ie.

    https://dsas.vmwareidentity.com/SAAS/auth/oauth2/authorize

    Token Endpoint

    Token Keys Endpoint

    https://[tenant[/SAAS/auth/oauthtoken

    ie.

    https://dsas.vmwareidentity.com/SAAS/auth/oauthtoken

    OIDC Client IDMyOIDCTester
    OIDC Client SecretThisIsMySecretKey
    Scopeemail profile user openid
    Screen Shot 12-18-19 at 04.15 AM.PNG
  3. Click Save
  4. Click Start
  5. When prompted to Authentication, select your domain based credentials (Do no use System Domain)
  6. If you selected "Prompt Users for Access" they will be prompted and required to Allow Access:
  7. You will now see your Authorization Code in the OIDC Debugger. Click Exchange to get your Access Token.
  8. You will now see your Bearer Token, ID Token and your Refresh Token.
  9. Click Next
  10. The ID Token will contain information regarding the identity. Click "View on JWT.IO" to see your JSON Tokens.
  11. You JWT Token will be displayed with your profile and user data:

For updates on this blog and other blogs, follow me on Twitter: @SteveIDM

 

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 SAML_REQUEST

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. https://vmware.oktapreview.com
  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: steve@one-identity.ca) " 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 "${user.email}"

 

 

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.

 

SCIM

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.
Screen Shot 04-22-19 at 03.22 PM.PNG

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:
Screen Shot 04-22-19 at 04.20 PM.PNG
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 vidmpreview.com 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.

Screen Shot 05-01-19 at 09.04 AM.PNG

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 ".+?(?=@)"

Screen Shot 05-01-19 at 09.14 AM.PNG

You can then use "EmailNickName" in your Certificate Payload

Screen Shot 05-01-19 at 09.12 AM.PNG

In an earlier blog post,  I walked through various options on how to use Microsoft Authenticator with Workspace ONE Access (formerly known as VMware Identity Manager). In the final option, we talked about using the Microsoft Azure MFA Server.  However, as of July 1st, 2019, Microsoft is no longer offering the MFA Server for new deployments.

 

Microsoft does however provide another option to leverage Azure MFA by using the Network Policy Server extension for Azure.

 

In the blog I will walk through the process of configuring a Network Policy Server along with the NPS Extension.

 

 

 

Install and Configure the Network Policy Server

  1. Using the Server Manager -> Add Role and Features
    Screen Shot 09-25-19 at 01.42 PM.PNG
  2. Click Next
  3. Select Role-Based or feature-based Installation
  4. Select the Server from the Server Pool and click next
  5. Add the Network Policy and Access Services
    Screen Shot 09-25-19 at 01.43 PM.PNG
  6. Add the dependency features.
  7. Add the Network Policy Server
    Screen Shot 09-25-19 at 01.44 PM.PNG
  8. Complete the rest of the wizard to install the Network Policy Server.

 

Download and Install the NPS Extension

  1. Go to Download NPS Extension for Azure MFA from Official Microsoft Download Center
  2. Download the NPS Extension for Azure MFA Installer.
  3. Run the installer
    Screen Shot 09-25-19 at 01.49 PM 002.PNG
  4. Click Install

 

Configure the NPS Extension

  1. Run Windows Powershell as an Administrator
  2. At the powershell prompt, cd to "c:\Program Files\Microsoft\AzureMfa\Config"
  3. Run ".\AzureMfaNpsExtnConfigSetup.ps1"
  4. You will be prompted to authenticate with Azure.
  5. After successful authentication, you will be prompted to enter your tenant id. This is your Directory ID which can be copied from your Azure Console:
    directoryid.png
  6. This script will create a self signed certificate for you.

 

Configure your NPS Server

  1. Access your NPS Server (via Admin Tools)
  2. Under standard configuration, select "Radius server for Dial-up or VPN Connections"
  3. Click Configure VPN or Dial-up
  4. Select "Virtual Private Network (VPN) Connections"
  5. Provide a friendly name ie. Workspace ONE
  6. Click Next
  7. Under Radius Clients -> Click Add
  8. Provide a friendly Name, IP Address and a Shared Secret
  9. Click OK and Next
  10. Select Microsoft Encrypted Authentication version 2 (MS-CHAPv2)
  11. Click Next
  12. Under Groups, - Select a group that includes your MFA Users.
  13. Click Next for IP Filters
  14. Click Next for Encryption Settings
  15. Click Next for Realm Name (leave blank)
  16. Click Finish
  17. Click on Policies -> Connection Request Policies
  18. Double Click on the new "Workspace ONE Policy"
  19. Change the type to Unspecified
  20. Click on the Condition Tab
  21. Delete the NAS Port Type and Click Add
  22. Select "Access Client IPv4Address"
  23. Enter the IP Address of the Connector Server
  24. Click OK
  25. Click on Policies -> Network Policies
  26. Double Click on the new "Workspace ONE Policy"
  27. Change the Type to Unspecified
  28. Under Conditions, you should just have the group condition
  29. Under Constraints, select "Microsoft Encrypted Authentication version 2 (MS-CHAP-v2)"
  30. Click OK.

 

Configure Workspace ONE Access

  1. Log into your Workspace ONE Access Admin Console
  2. Go to Identity & Access Manager -> Setup
  3. Click on your Connector Worker -> Auth Adapters
    Screen Shot 10-14-19 at 04.17 PM.PNG
  4. Click on Radius Adapter
  5. Enter your Radius Host, Ports and Secret
    Note: Do not enter an accounting port.  I was not able to get this to work with the NPS Server.





  6. Select MSChapv2 as the encryption type.
  7. Click Save
  8. In the Workspace ONE Access Console, go to Identity Providers and edit the Built-In provider.
  9. Enable the Cloud Based Radius Adapter
  10. Click Save.
  11. You can now use the Cloud Radius Adapter in your Access Policies.

If you have read my previous blog on configuring Okta Device Trust for Workspace ONE you will know that Okta has not yet implemented device trust for Windows and MacOS. I also mentioned in the previous blog that if you want to leverage device trust for Windows and MacOS that you will need to use the original method with just routing rules.

 

In my previous blog I didn't go into the details on how you would configure device trust for both IOS/Android and Windows/MacOS. Its not really as straight forward as you would think because once you have configured an Identity Provider in Okta to use device trust, it will always send the device trust authentication context which will always result in an authentication failure for Windows and MacOS (assuming its being evaluated for Certificate and Device Compliance - AirWatch).

 

Note: This blog will not go into steps to configure Workspace ONE UEM or Workspace ONE Access to perform Certificate Based Authentication. We will assume that this has already been done.

 

There are a couple extra steps you will need to do.  Lets walk through the steps.

 

Create a New Identity Provider

 

First you will need to create another Identity Provider for Workspace ONE.

 

  1. Log into the Okta Administration Portal and go to Security -> Identity Providers
  2. Click Add Identity Provider -> Add SAML 2.0 IDP
  3. Configure this Identity Provider exactly as you've configured the previous one
  4. Click on Show Advanced Settings
  5. Make sure the Request Authentication Context is set to None
  6. Click Add Identity Provider
  7. Expand the Identity Provider you just created and download the metdata

 

Create a new Workspace ONE Application for Okta

 

  1. In Workspace ONE Access, got to Catalog and Click New
  2. Provide a name for this application (ie. Okta Device Trust for Windows/MacOS)
  3. Paste the metadata you downloaded in the previous step.
  4. Click Next, Next, Save
  5. Click Edit for the application you just created
  6. Click Configuration
  7. Modify to the username value to match the username format in Okta.
    Screen Shot 10-02-19 at 12.35 PM.PNG
  8. Click Access Policies
  9. Select the same policy you assigned to the Okta Application Source
    Screen Shot 10-02-19 at 12.36 PM.PNG
  10. Click Next - Save
  11. Assign the application to your users.
  12. Click on Identity and Access Management -> Policies
  13. Edit your Okta Policy
  14. Create a Policy Rule for MacOS to use Certificate and Device Compliance.
    Screen Shot 10-02-19 at 12.38 PM.PNG

 

Modify your Routing Rules in Okta

 

Finally, we can now add this new configuration into the routing rules in Okta

 

  1. Log into the Okta Admin Console
  2. Click on Security -> Identity Providers
  3. Click on Routing Rules
  4. Click Add Routing Rule
  5. Add a rule that will evaluate Windows and MacOS for your required applications and select the new "Workspace ONE - No Device Trust" identity provider we created in the first step.
    Screen Shot 10-02-19 at 12.52 PM.PNG
  6. Verify that there are no other rules that will take precedence over your newly created rule.

In this blog we are going to discuss adding Multi-Factor Authentication using Okta Verify with VMware Horizon by leveraging the Okta Radius Agent.

For more information on this integration, please see https://www.okta.com/integrations/mfa-for-virtual-desktops/vmware/

 

We are going to walk through 3 separate deployment options to leverage the Okta Radius Client:

 

  1. Using Workspace ONE Access (formerly known as VMware Identity Manager)
  2. Using Unified Access Gateway (UAG)
  3. Using Horizon Connection Servers

 

Let's start with installing and configuring the Okta Radius Agent.

 

Installing the Okta Radius Agent

For detailed instructions please see: https://help.okta.com/en/prod/Content/Topics/Directory/Agent_Installing_the_Okta_Radius_Agent.htm

 

  1. Download the Okta RADIUS Agent from the Okta Admin Portal by going to Settings -> Downloads
    Screen Shot 09-06-19 at 03.11 PM.PNG
  2. Once downloaded, launch the installer.
  3. On the intro screen, click next
  4. Click Next accept the license agreement:
  5. Select the correct installation patch and click Install.
  6. Create a Secret that will be used when configuring the radius clients.
    Screen Shot 09-06-19 at 03.13 PM 003b.png
  7. If you require a proxy complete this section otherwise click next
  8. Click Next
  9. Enter your tenant name (Note: Do not enter the full URL) with the appropriate instance
    Screen Shot 09-06-19 at 03.19 PM 001.PNG
  10. You will be redirected to your Okta tenant to Authenticate
    Screen Shot 09-06-19 at 03.19 PM.PNG
  11. Click Allow Access
    Screen Shot 09-06-19 at 03.20 PM.PNG
  12. You can then complete the installation.

 

Configure the Okta Radius Agent

 

The configuration for the Okta Radius Agent will be done within the Okta Admin Portal

 

  1. Click on Applications -> Applications
  2. Click New Application
  3. Search for "VMware Horizon View (RADIUS)" and Click Add
  4. Click Next
  5. Enter the UDP Port (1812)
  6. Enter the radius secret you used previously
  7. Select the correct username to match your environment.
    This is a very important step. For an optimal user experience, this should match your horizon credentials. If you have multiple AD domains in your horizon environment this should include the domain (ie. UPN or EMAIL).
  8. Click Done
  9. Click on the VMware Horizon View (RADIUS) application.
  10. Click Edit for the Advanced Radius Settings
  11. If you want to enable PUSH Notification, make sure the top two boxes are checked

 

Using Workspace ONE Access (formerly known as VMware Identity Manager)

 

  1. In the Workspace ONE Access Admin Console, go to Identity & Access Management -> Setup -> Connectors
  2. Click on your Worker to edit your connector configuration
  3. Click on Auth Adapters
  4. Click on the Radius Auth Adapter
  5. This will launch a configuration page running on your connector server.
    You will need connectivity to your connector server to complete this step.
    If you are presented an access denied page you might need to temporary change your policy to Password.
  6. Add your Radius Server Host name, Port and Shared Secret. (Leave the Authentication Type as PAP)
    Screen Shot 09-10-19 at 10.08 AM.PNG

  7. Click Save
  8. Return to the WS1 Access Admin Console and verify the Radius Auth Method is enabled. (You might need to refresh)
  9. Go to Identity & Access Management
  10. Click on Identity Providers
  11. Click on your Built-In Identity Provider
  12. Under Connector Authentication Methods, select Radius (Cloud Deployment)
  13. Click Save
  14. Click on Policies
  15. Edit your appropriate policy to include "Radius (cloud deployment)". In my example, I'm modifying the Win10 rule in the Default Policy.
    Screen Shot 09-10-19 at 10.15 AM.PNG
  16. Click Save, Next and Save.
  17. Open an Incognito Window and we'll test the configuration
    Note: If you ever lock yourself out, you can always go to: https://[TENANT].vmwareidentity.com/SAAS/auth/0 to login using your System Domain Account.
  18. You will be prompted to enter your Okta Credentials
  19. You should be prompted to approve the authentication on your Okta Verify Application
    Apowersoft_Screenshot_2019_09_10_13_30_12.jpg

Using Unified Access Gateway (UAG)

 

In environments where a Unified Access Gateway is deployed, most customers will typically want to configure MFA here as this appliance typically sits on the network edge. We can configure UAG to prompt for MFA using Okta Verify and then pass the credentials to Horizon to complete the authentication into the view client.

 

Note: If you have multiple AD domains, you will need to ensure your login through Okta contains the domain name (ie. UPN/Email).

 

  1. Log into your UAG Admin Console
  2. Under Authentication Settings, click the gear icon for RADIUS
  3. Enable RADIUS, Select PAP and enter the host name and port for the Okta Radius Agent.
  4. Click Save
  5. Expand Edge Service Settings and edit the Horizon Settings
  6. Click on "More" (at the bottom)
  7. Under Auth Methods, select radius-auth
  8. You will also need to enable "Enable Windows SSO" to prevent a subsequent login into the horizon client.
  9. Click Save
  10. Test your configuration by logging into the Horizon Portal. You will be prompted for your Okta username and password
    Screen Shot 09-10-19 at 02.09 PM.PNG
  11. You will then be prompted to approve the Okta Verify request on your device.

 

 

Using Horizon Connection Servers

 

Radius can be configured directly on the Horizon Connection Servers. This allows for MFA to be configured for both internal and external users (assuming internal users are not going through UAG).

 

Note: If you have multiple AD domains, you will need to ensure your login through Okta contains the domain name (ie. UPN/Email).

 

  1. Log into your Horizon Admin console
  2. Edit your Connection Server Settings
  3. Under Advanced Authentication, select Radius
  4. Select "Use the same username and password for RADIUS and Windows Authentication
  5. On the Authenticator drop down, select Create New Authenticator
  6. Enter your host name, port and secret for the Okta Radius Agent
    Screen Shot 09-10-19 at 01.41 PM.PNG
  7. Click OK
  8. Click OK.
  9. Test your configuration by logging into the Horizon Portal. You will be prompted for your Okta username and password
  10. You will then be prompted to approve the Okta Verify request on your device.

So in the latest integration between Workspace ONE Access (aka. VMware Identity Manager) and Okta, we've added the device trust capabilities into the Okta Administration Portals.  I've noticed there has been some confusion on what this integration really does and why it's been added to the solution.

 

Which method should you use? In order to determine which method you should use we need to look at both options.

 

Lets walk through how the process worked previously:

 

  1. User goes to a SaaS Application
  2. The SaaS application will redirect the user to Okta
  3. Okta Routing Rules will proxy the SAML Authentication request to Workspace ONE access based on the predefined rules.
  4. Workspace ONE Access will determine if the device is managed (based on Mobile SSO/Certificate) and if the device is compliant (based on the enrolment in Workspace ONE UEM)
    1. If the device meets correct conditions (both Managed and Compliant) it will send a SAML Authentication Response back to Okta where any additional sign-on policies will be triggered and the user will be returned to the SaaS application.
    2. If the device does not meet the correct conditions (both Managed and Compliant) the user will most likely be displayed an "Access Denied" error with any appropriate "Compliance" messaging.

The benefit of this option is that it can provide a detailed explanation of why the authentication failed. We can also configure Workspace ONE Access to integrate with an MFA solution to step up the authentication.  The downside of using the existing method is that you need to configure authentication policies in both systems and the action to deny or MFA will apply to all application that Okta is routing to Workspace ONE Access.

 

Configuring Okta Device Trust

 

In the on going partnership between VMware and Okta, the strategy is to offload the authentication to Okta. This provides a strong value in configuring authentication policies in just one place.

 

Once you configure device trust in Okta, you have the ability to configure sign-on policies on a per app basis. This provides a lot of value as there are some applications that you would want to straight out deny access and some that might be okay as long as we did a step up authentication.

 

If you have configured a policy to DENY access, the user will be presented with the below message. They will have the ability to secure their device by enrolling in Workspace ONE UEM.

 

Let's walk through the steps required to set this up and we'll look under the covers of what is happening during the SAML exchange between the two systems.

 

First lets start in the Okta Portal,

 

First you need to enable Device Trust. Under Security -> Device Trust, click EDIT for either IOS or Android.

  1. Enable IOS Device Trust
  2. Select "VMware"
  3. Select "SAML-based (Workspace ONE UEM + vIDM)
  4. Click Next
  5. Select the correct Identity Provider
  6. Provide a name such as "Workspace ONE"
  7. Enter either your Web Enrolment Link or a linked to the appropriate app store to download the Workspace ONE Intelligent Hub.
  8. Click Save

 

Now we can modify our sign-on policies for our applications. In your application specific sign-on policy, add a rule for either "IOS/Android" and select your appropriate device trust option and the correct action (DENY or MFA).

 

Finally, we have to configure the Identity Provider to send the correct flags to Workspace ONE Access in order to trigger the Device Trust.

 

In Security -> Identity Providers, you need to enable the Device Trust Authentication Context.  (Note: This is under Advanced Settings). I'll explain shortly what this option is doing.

 

 

Configuring Workspace ONE Access for Okta Device Trust

 

We have to modify a couple setting in our Okta Application Source in order to support Okta Device Trust.

 

  1. Edit your Okta Application Source
  2. Under Configuration, expand Advanced Properties
  3. Enable Device SSO Response
  4. Enable Force AuthN Request. This setting will allow Workspace ONE to accept an ForceAuthN in a SAML AuthN request and process the Device Trust Authentication Context. There are some implications of enabling this setting. We'll discuss those later.
  5. Enable the Authentication Failure Notification. This setting will send a failure notification to Okta instead of display an error message on the Workspace ONE Access side.
  6. Click Next, Next, Save.

 

Understanding the SAML Exchange

 

When you make the changes above, the SAML messages between the two systems are modified.

 

When you configure the "Device Trust" authentication context in Okta, it will set a ForceAuthn flag = "True" in the AuthN request.

 

It will also add a device trust Authentication Context to the request:

 

Workspace ONE Access will respond to Okta with the Authentication Class Reference that was used to authenticate the user along with the Device Posture Check.  The Post Check returned will tell Okta whether the device is currently managed:

 

 

Implications of ForceAuthn

 

There are some important implications when using ForceAuthN in the Authentication Request.  There are some Authentication Methods that are not supported. The most prominent ones are "Device Compliance" and your 3rd Party IDP authentication methods.

 

If you are using the Okta Device Trust, this means that you can NOT use the "Device Compliance" authentication method in Workspace ONE Access.

 

 

Device Compliance vs Device Posture

 

This is a very important distinction and might have an impact on which option your chose to enable Device Trust. In the current implementation (configuring Mobile SSO/Cert + Device Compliance) in Workspace ONE Access, it will validate that the device is managed and it will check the compliancy of the device in Workspace ONE UEM.  In the initial release of Okta Device Trust, it will only check if the device is managed. Although this might seem like a big omission on the first release, depending on your compliance policies, you can imply that if a device is not compliant it will fail the posture check. (Removing MobileSSO profile on non-compliance).

 

Windows 10 and MacOS

 

In the first release of Okta Device Trust for Workspace ONE, they provided support for IOS and Android only. If you want Device Trust for Windows 10 and MacOS, you need to use the current method of configuring Cert + Device Compliance in Workspace ONE Access.

For updates on this blog and other blogs: Follow @SteveIDM

 

In the third installment of the Okta Integration with Workspace ONE, we are going to cover SCIM Provisioning from Okta to Workspace ONE.

 

In the first release of this functionality, there will be a lot of manual steps. I fully expect a more seamless process in future releases.

 

Minimum Requirements:

  • Workspace ONE UEM SAAS or version 19.09 for dedicated/on-premise.
  • Workspace ONE Access SAAS
    • Note: Although some aspects of the integration will work for on-premise customers, not all functionality is currently available.

 

Note: When creating users in Workspace ONE from Okta, they will be created as new users in Workspace ONE Access and UEM. Any previous users synchronized from AD will not get over written. Users that are currently enrolled with AD credentials will need to re-enroll with Okta credentials (if you are switching from AD to Okta).

 

This process will require some proficiency and knowledge in using Postman to manage identities in Workspace ONE Access (formerly known as VMware Identity Manager).  Please check out my blog on using Postman to Manage Workspace ONE Identities.

https://communities.vmware.com/blogs/steveIDM/2019/05/09/using-postman-to-manage-workspace-one-identities

Here is a high level overview of the process:

Screen Shot 10-15-19 at 11.44 AM.PNG

  1. Okta is configured to use Workspace ONE Provisioning Application
  2. Okta will SCIM the user to Workspace ONE Access
  3. The AirWatch Provisioning Adapter in Workspace ONE Access will provision the user to Workspace ONE UEM.

 

This blog will not going into detail on the provisioning to UEM. Please see the following blog on provisioning to UEM:

Workspace ONE - AirWatch Provisioning App

Step 1:  Create a Remote App Access Client

  1. Log into Workspace ONE Access
  2. Click on Catalog (Down Arrow) and then Settings
  3. Click on Remote App Access
  4. Click Create Client
  5. Select "Service Client Token"
  6. Enter a Client ID ie. OktaSCIM
  7. Expand Advanced
  8. Click Generate Shared Secret
  9. Update the Access Token TTL to something longer then the default. Note: If you choose 1 year, you will need to update the Okta configuration every year with a new bearer token.


  10. Copy the shared secret. You will need this later.
  11. Click Add

 

Step 2:  Configure Postman to use your OAuth Token

 

Note: Depending on your version of Postman, these steps below might be slightly different.

 

  1. Open a new Tab in Postman
  2. For the HTTP Method, select "POST"
  3. For the URL, enter: https://[TENANTURL]SAAS/jersey/manager/api/connectormanagement/directoryconfigs
    Replace the Tenant URL with your URL
    https://dsas.vmwareidentity.com/SAAS/jersey/manager/api/connectormanagement/directoryconfigs
  4. In the authorization section, select "OAuth 2.0" as the type:
  5. Click Get New Access Token
  6. Provide a Token Name (ie. Workspace ONE)
  7. Under Grant Type, select "Client Credentials"
  8. "Under Access Token URL", enter https:[Tenant URL]/SAAS/auth/oauthtoken
  9. ie. https://dsas.vmwareidentity.com/SAAS/auth/oauthtoken
  10. Under Client ID, enter your Client ID from step 1.
  11. Under Secret, enter your secret from step 1.
  12. Under Scope, enter 'admin'
  13. Click Request Token
  14. On the left hand side, Select "Request Headers" and click "Preview Request".

  15. You should see a message saying headers were updated correctly:
  16. Click the Headers Tab and verify that the bearer token was added as a temporary header.
  17. If the bearer token was not added, return to the Authorization Tab and select your token from the available tokens drop down list and preview the request again.

 

Step 3:  Create an "Other" Directory for your Okta Users.

  1. Under "Headers", Set the Content-Type to "application/vnd.vmware.horizon.manager.connector.management.directory.other+json"
    Screen Shot 10-15-19 at 11.49 AM.PNG
  2. Click on the Body tab
  3. Use the following as a sample and Click Send

 

{  
"type":"OTHER_DIRECTORY",  
"domains":["Okta.com"],  
"name":"Okta Universal Directory"  
}  

 

You should see a similar result

Screen Shot 10-15-19 at 11.50 AM.PNG

 

Step 4:  Add the VMware Workspace ONE App in Okta

 

 

  1. Log into the Okta Admin Console
  2. Click on Applications -> Applications
  3. Click Add Application
  4. Search for the "VMware Workspace ONE"
  5. Select VMware Workspace ONE under Integrations:

  6. Click Add


  7. Enter your Workspace ONE URL in the field labeled "Base URL"
    ie. https://dsas.vmwareidentity.com
  8. Click Done
  9. Click on the Provisioning Tab and Click Configure API Integration
  10. Select Enable API Integration
  11. Paste your bearer token that was created in the earlier step with postman.

    Note: This is the token you obtained via Postman and NOT the secret you generated in the Access Console.
  12. Click Test API Credentials
  13. Ensure you have a "Success" before proceeding.
  14. Click Save
  15. Click on the Edit Button
  16. Select Enable for Create and Deactivate and click Save
  17. If you used a different domain then "okta.com" when creating your directory (using Postman), you will need scroll down and edit the domain attribute so it matches your domain.



  18. You can now assign users and groups to the application

    Note: Users needs to be assigned the application (either directly or via a group assignment) before you can push groups (along with memberships) to Workspace ONE.


Known Issues:

  1. When pushing groups from Okta to Workspace ONE, Okta has a feature called "Push Now". If you run into an error when using this capability, click the Retry All Groups button:

    Screen Shot 01-11-20 at 12.52 AM.PNG

 

For additional troubleshooting see:

https://communities.vmware.com/blogs/steveIDM/2019/10/21/workspace-one-and-okta-troubleshooting-blog

For updates on this blog and other blogs: Follow @SteveIDM

 

There are times during troubleshooting where you like to see a particular attribute in Workspace ONE Identity (VMware Identity Manager) and its not displayed in the web portal or times when you would like to update a particular attribute or delete a JIT user.

 

DISCLAIMER:  Please use the API with caution as this can potentially cause issues if not used appropriately. Please do NOT use in Production. Please use at your own risk.

 

In this blog we'll walk through a few useful API calls to help in your troubleshooting. For a complete list of API calls and documentation:

 

VMware Identity Manager API - VMware API Explorer - VMware {code}

 

Please download and install the latest version of Postman.

 

In this blog we'll go use the following API's:

  • Get Specific User Details
  • Update SCIM User
  • Delete SCIM User
  • Create SCIM User

 

Step 1: Getting your OAuth Token

 

In order do use the SCIM based API you need an OAuth token. I'm going to walk through two different ways of getting a token to use in your environment.

 

If you are going to access a particular environment quite often using postman I would suggest you go with Option 1. If its unlikely you will access a particular environment that often then you should go with Option 2.

 

Option 1: Creating an OAuth Application

  1. Log into Workspace ONE Identity Admin Console
  2. Click on the Catalog (down arrow) and select Settings
    Screen Shot 05-08-19 at 01.16 PM.PNG
  3. Click "Remote App Access"
  4. Click Create Client
    Screen Shot 05-08-19 at 01.18 PM.PNG
  5. Select "Service Access Token" from the Drop down menu
  6. Provide a Client ID ie. Postman
  7. Expand Advanced
  8. Click Generate Shared Secret (or provide one)
  9. Click Add
    Screen Shot 05-08-19 at 02.30 PM.PNG
  10. We will configure Postman in the next section.

 

Option 2: Using your browser cookies

 

  1. Make sure you have a way of accessing your browser cookies. I use a Chrome plugin called "Edit this cookie"
    Screen Shot 05-08-19 at 02.40 PM.PNG
  2. Log into your Workspace ONE Identity Admin Console
  3. Click the Cookie Icon in the chrome address bar
  4. Search for the "HZN" cookie
    Screen Shot 05-08-19 at 02.43 PM.PNG
  5. Copy the value for HZN.
  6. We will configure Postman in the next section.

 

Step 2: Configure Postman to use your OAuth Token

Depending which option you chose in the previous step, follow the instructions below to add your OAuth Token

 

Option 1: Creating an OAuth Application

  1. Open a new Tab in Postman
  2. In the authorization section, select "OAuth 2.0" as the type:
    Screen Shot 05-08-19 at 02.50 PM.PNG
  3. Click Get New Access Token
    Screen Shot 05-08-19 at 02.52 PM.PNG
  4. Provide a Token Name (ie. Workspace ONE)
  5. Under "Auth URL", enter https:[Tenant URL]/SAAS/auth/oauth2/authorize
    ie. https://dsas.vmwareidentity.com/SAAS/auth/oauth2/authorize
  6. "Under Access Token URL", enter https:[Tenant URL]/SAAS/auth/oauthtoken
    ie. https://dsas.vmwareidentity.com/SAAS/auth/oauthtoken
  7. Under Client ID, enter your Client ID from step 1.
  8. Under Secret, enter your secret from step 1.
  9. Under Scope, leave blank.
  10. Under Grant Type, select "Client Credentials"
    Screen Shot 05-08-19 at 02.58 PM.PNG
  11. Click Request Token
  12. Click on WorkspaceONE under Existing Tokens
  13. Select Use Token
    Screen Shot 05-08-19 at 03.00 PM.PNG
  14. If you click on the headers tab you will see the "Authorization" header has been added with the correct token.

 

Option 2: Using your browser cookies

 

  1. Open a new Tab in Postman
  2. Click on the Headers Section
  3. Add the Header Key "Authorization"
  4. In the Value, type "Bearer" then paste the value of the HZN cookie.
    Screen Shot 05-08-19 at 03.10 PM.PNG

 

Getting User Details

Now that you have your OAuth token, we can use this token to query Workspace ONE Identity.

 

  1. For the HTTP Method, select "GET"
  2. Enter the following for the URL: https://[TENANTURL]/SAAS/jersey/manager/api/scim/Users?filter=username%20eq%20%22MyUserID%22
  3. Replace MyUserID with a username in your environment
    ie. https://dsas.vmwareidentity.com/SAAS/jersey/manager/api/scim/Users?filter=username%20eq%20%22sdsa%22
  4. This will return a complete result set of attributes for the particular user.
    Screen Shot 05-08-19 at 03.23 PM.PNG

Updating User Details

In order to update user details via the API, you will need to collect some information from the Get User Details.

 

In my example, I'm going to update the "userPrincipalName" in Workspace ONE Access for one of my users.

  1. Perform a "Get" on the particular user and retrieve the schema information. Please note, this will be different for each tenant as the tenant name is part of the schema.
    Screen Shot 05-08-19 at 03.34 PM.PNG
  2. Copy this section to notepad.
  3. Retrieve the section which contains the attribute(s) you want to update
    Screen Shot 05-08-19 at 03.35 PM.PNG
  4. Copy the ID of the User
    Screen Shot 05-08-19 at 03.38 PM.PNG
  5. Open a new Tab in Postman
  6. Add the Authorization Header as per the previous section.
  7. For the HTTP Method, select "PATCH"
  8. For the URL, enter: https://[TENANTURL]/SAAS/jersey/manager/api/scim/Users/[ID]
    Replace the Tenant URL with your URL
    Replace the ID with the ID from the step 4 in this section.
    ie. https://dsas.vmwareidentity.com//SAAS/jersey/manager/api/scim/Users/884b7e7d-6a7b-4985-b113-56235826e8a6
  9. Select Body
  10. Enter the JSON in raw text that we'll post to Workspace ONE
  11. Select "JSON (application/json)" as the Content-Type
    Screen Shot 05-08-19 at 04.02 PM.PNG
  12. Click Send
  13. You should receive a "204 No Content" response
    Screen Shot 05-08-19 at 04.03 PM.PNG
  14. If you perform a GET User again you should see the value has changed.

 

Delete Users

If you are using JIT to onboard users into Workspace ONE Identity you've probably noticed there is no way to delete users in the web portal. They only way to delete is with the API.

  1. Perform a "Get" on the particular user and retrieve the ID
    Screen Shot 05-09-19 at 10.47 AM.PNG
  2. Open a new Tab in Postman
  3. Add the Authorization Header as per the previous section.
  4. For the HTTP Method, select "DELETE"
  5. For the URL, enter: https://[TENANTURL]/SAAS/jersey/manager/api/scim/Users/[ID]
    Replace the Tenant URL with your URL
    Replace the ID with the ID from the step 4 in this section.
    ie. https://dsas.vmwareidentity.com//SAAS/jersey/manager/api/scim/Users/f6f89782-0a2a-4cc8-84a8-057f1da6ecde
  6. Click Send
    Screen Shot 05-09-19 at 10.50 AM 001.PNG
  7. You should receive a "204 No Content" response
    Screen Shot 05-08-19 at 04.03 PM.PNG
  8. If you perform a GET User again you should see no results found.
    Screen Shot 05-09-19 at 10.53 AM.PNG

 

Create Users

Creating Users in Workspace ONE Access require a lot more steps. I reluctantly decided to document the steps as this should really be done by the out of the box connectors. The process is slightly different between System Directory, Local Directory, and Other.  The "Other" directory is created automatically when setting up the UEM/WS1 Integration.

 

Creating Users in the System Directory

  1. Open a new Tab in Postman
  2. Add the Authorization Header as per the previous section.
  3. For the HTTP Method, select "POST"
  4. For the URL, enter: https://[TENANTURL]/SAAS/jersey/manager/api/scim/Users
    Replace the Tenant URL with your URL
    Replace the ID with the ID from the step 4 in this section.
    ie. https://dsas.vmwareidentity.com//SAAS/jersey/manager/api/scim/Users
  5. Set the Content-Type to "application/json"
  6. Use the following as a sample:
{
  "schemas": [
    "urn:scim:schemas:core:1.0",
    "urn:scim:schemas:extension:workspace:tenant:sva:1.0",
    "urn:scim:schemas:extension:workspace:1.0",
    "urn:scim:schemas:extension:enterprise:1.0"
  ],
  "userName": "testing4@mydomain.com",
  "name": {
    "givenName": "first4",
    "familyName": "last4"
  },
  "emails": [
    {
      "value": "testing4@mydomain.com"
    }
  ],
  "password": "Password$!"
}

 

Creating Users in a Local Directory

 

  1. Open a new Tab in Postman
  2. Add the Authorization Header as per the previous section.
  3. For the HTTP Method, select "POST"
  4. For the URL, enter: https://[TENANTURL]/SAAS/jersey/manager/api/scim/Users
    Replace the Tenant URL with your URL
    Replace the ID with the ID from the step 4 in this section.
    ie. https://dsas.vmwareidentity.com//SAAS/jersey/manager/api/scim/Users
  5. Set the Content-Type to "application/json"
  6. Use the following as a sample:
{
  "schemas": [
    "urn:scim:schemas:core:1.0",
    "urn:scim:schemas:extension:workspace:tenant:sva:1.0",
    "urn:scim:schemas:extension:workspace:1.0",
    "urn:scim:schemas:extension:enterprise:1.0"
  ],
  "userName": "testing5@mydomain.com",
  "name": {
    "givenName": "first5",
    "familyName": "last5"
  },
  "emails": [
    {
      "value": "testing5@mydomain.com"
    }
  ],
  "password": "Password$!",
   "urn:scim:schemas:extension:workspace:1.0": {
        "internalUserType": "LOCAL",
        "domain": "mydomain.com"
      }


}

 

Creating Users in an Other Directory

 

The steps to create a user in an other directory is almost identical to the local directory except that we need to know the "domain" associated with the directory and we need an ExternalID. The External ID should be a unique value. It is recommended that you use a GUID for this value.  See Online UUID Generator Tool as a example of a proper GUID. Note: In Postman you can use the function " {{$guid}}" to automatically generate one.

 

 

  1. Open a new Tab in Postman
  2. Add the Authorization Header as per the previous section.
  3. For the HTTP Method, select "GET"
  4. For the URL, enter: https://[TENANT URL]/SAAS/jersey/manager/api/connectormanagement/directoryconfigs?includeJitDirectories=true
    Replace the Tenant URL with your URL
    Replace the ID with the ID from the step 4 in this section.
    ie. https://dsas.vmwareidentity.com/SAAS/jersey/manager/api/connectormanagement/directoryconfigs?includeJitDirectories=true
  5. Click Send
  6. In the response, search for your "Other Directory" and copy the userStoreID
  7. Screen Shot 05-09-19 at 05.25 PM.PNG
  8. Open a new Tab in Postman
  9. Add the Authorization Header as per the previous section.
  10. For the HTTP Method, select "POST"
  11. For the URL, enter: https://[TENANTURL]/SAAS/jersey/manager/api/scim/Users
    Replace the Tenant URL with your URL
    Replace the ID with the ID from the step 4 in this section.
    ie. https://dsas.vmwareidentity.com//SAAS/jersey/manager/api/scim/Users
  12. Set the Content-Type to "application/json"
  13. Use the following as a sample and don't forget to create a Unique External ID.
{
  "schemas": [
    "urn:scim:schemas:core:1.0",
    "urn:scim:schemas:extension:workspace:tenant:sva:1.0",
    "urn:scim:schemas:extension:workspace:1.0",
    "urn:scim:schemas:extension:enterprise:1.0"
  ],
  "externalId": "c58085e6-c97a-4df3-8e4a-e376913fab17",
  "userName": "testing6@mydomain.com",
  "name": {
    "givenName": "test6",
    "familyName": "last6"
  },
  "emails": [
    {
      "value": "testing6@mydomain.com"
    }
  ],
  "urn:scim:schemas:extension:workspace:1.0": {
        "internalUserType": "PROVISIONED",
        "domain": "1dsavm.com",
        "userPrincipalName": "testing6@mydomain.com"
      }
}

 

Creating an Other Directory

When you configure UEM to integrate with Identity Manager an "Other" Directory should be automatically created. If in the case it is not created, you can create one via the API as well.

  1. Open a new Tab in Postman
  2. Add the Authorization Header as per the previous section.
  3. For the HTTP Method, select "POST"
  4. For the URL, enter: https://[TENANTURL]/SAAS/jersey/manager/api/connectormanagement/directoryconfigs
    Replace the Tenant URL with your URL
    Replace the ID with the ID from the step 4 in this section.
    ie. https://dsas.vmwareidentity.com/SAAS/jersey/manager/api/connectormanagement/directoryconfigs
  5. Set the Content-Type to "application/vnd.vmware.horizon.manager.connector.management.directory.other+json"
  6. Use the following as a sample
{
"type":"OTHER_DIRECTORY",
"domains":["SteveTestDomain2"],
"name":"SteveTest2"
}

 

Troubleshooting

It would be impossible to discuss every combination of errors that can be returned using the API. Here are a few common ones:

 

  1. If you receive the error "User is not authorized to perform the task.".
    This error typically means that your Oauth Token has expired. Regenerate your OAuth Token.  If you have used the browser cookies method to get your token, ensure that your HZN cookie is from the administrative interface.
  2. When doing an update user, you receive the error ""???UNSUPPORTED_MEDIA_TYPE???""
    This error means that you are sending a blank or incorrect Content-Type. Check to make sure the content-type is set to "application/json"

The release of Workspace ONE 19.03 brought in a very seamless integration of Okta Applications.

 

If you have integrated the two solutions previously you will recall the number of steps required to create and entitle new applications in Workspace from Okta. This integrations you to create and entitle applications in Okta and have them seamless appear in Workspace ONE along with your Native and Virtual Applications.

 

Lets walk through the steps to integrate the two solutions.

 

In this blog we are going to assume that you have existing connectors for Workspace ONE UEM and Workspace ONE Identity. We are also assuming you have your Workspace ONE Identity access policies already configured for Mobile SSO, Certificate or Password (Cloud Deployment).

 

Part 2: Unified Digital Workspace

The objective of this section to automatically sync all SAML enabled applications from Okta to Workspace ONE. This configuration will eliminate the manual steps required to both create and entitle Okta applications in Workspace ONE.

 

Step 1: Create an Okta API Key

  1. Log into the Okta Admin Console
  2. Go to Security -> API
  3. Click on Tokens
    Screen Shot 05-08-19 at 10.32 AM.PNG
  4. Click Create Token
  5. Provide a name for the token
    Screen Shot 05-08-19 at 10.34 AM.PNG
  6. Click Create Token
  7. Click the Copy Token button
    Screen Shot 05-08-19 at 10.35 AM.PNG
    Note:  Its very important you copy and save this token somewhere. Once you close this window you will not be able to retrieve this value again. You will have to delete the token and create a new one.

 

Step 2: Configure Workspace ONE with Okta API Information

  1. Log into the Workspace ONE Admin Console
  2. Click on Identity & Access Management -> Setup -> Okta
    Screen Shot 05-08-19 at 10.41 AM.PNG
    Note: If you are using Chrome, please be aware of Chrome auto filling any fields.

  3. Enter your Okta Cloud URL.
    Note: Do NOT use the Admin URL!!
    Screen Shot 05-08-19 at 12.19 PM.PNG

  4. Paste your Okta API Token
  5. Select the username search parameter that will match in Okta.
  6. Click Save

 

NOTE: Okta Applications will NOT appear in the Workspace ONE Admin Console

 

Step 3: Testing

  1. Log into Workspace ONE with a directory account.
  2. You should now see all your Okta Applications along with any other applications configured in Workspace ONE.

Screen Shot 05-08-19 at 12.38 PM.PNG

                                                                    down_arrow_clip_art_7569.jpg

Screen Shot 05-08-19 at 12.38 PM 001.PNG