Workspace ONE - AirWatch Provisioning App

[#1]

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

This blog has been moved to

https://TheIdentityGuy.ca

[ArianZuta]

Hi Steve

Have you ever had the case where you get the following error message?

Thanks for more information on this.

Best Arian

[StevenDSa]

Did you complete Step 2 above? SAML needs to be configured on the directory services page.

[ArianZuta]

Hi Steven,

Yes I did. As discribed above.

What I changed from above was External Id to a manual value (as ${user.ExternalId} always prompted the error number 1 in your troubleshooting guide.

Best Arian

[StevenDSa]

And you are doing this on the top level OG?

[ArianZuta]

I have an onpremise environment and i am doing this on the top level OG (of type customer)

[StevenDSa]

Strange. The only reason you should get this error is because SAML is not configured on the top level OG.  Directory Type should be set to none. SAML should be configured for at least Enrollment and SSP. Also Directory Type should be checked off in Devices & Users -> General -> Enrollment.

If that doesn't work I suggest you contact VMware Support.

[ArianZuta]

Alright, thanks for your help.

[aralesahar]

Hi ArianZuta​

In order to solve this, in Workspace ONE UEM Console, Navigate to GROUPS & SETTINGS > All Settings > Devices & Users > General > Enrollment,  and mark the “Directory” checkbox for the customer Organization Group.

Arale

[kw1548]

Hi StevenDSa​

We have completed this, as well as the 1-4 parts of integrating Okta with WS1 Access but we are still seeing two issues:

1. When we try to log into the WS1 UEM instance we get different responses depending on what we are doing:
   • From the web using cnXXXX.awmdm.com we are not redirected to Okta and get "Invalid credentials, Try again."
   • When  provisioning a new macOS device with ABM/DEP we get the redirection to Okta and are able to verify the okta credentials but are then sent back to UEM and given the error "Invalid User Credentials ?? An unexpected error occured."
   • When manually enrolling a windows 10 device we get the same result as macOS ABM/DEP
2. Both the Groups and users are being synced from the AirWatch Provisioning App in WS1 Access but the users are not being assigned to those groups in WS1 UEM

Any help would be greatly appreciated!

[StevenDSa]

Hi Kw,

Regarding the first point, have you configured Hub Services to use Workspace ONE Access? You will also have to configure Directory Services (in UEM) to use SAML with Workspace ONE Access as well? This also means you will need to configure the AirWatch app inside of WS1 Access.

Regarding point 2. Please make sure in the A/W Provisioning Application that the OG specified is the top OG.  Also, the groups you are trying to push from WS1 -> UEM, are these regular groups in Okta or assignment groups in Okta. This makes a difference. Okta does not support/recommend pushing the same groups that are using for assigning the WS1 application.

[kw1548]

For reference as I forgot this in the first post - We are on UEM 2007

For Hub Services I access that normally though the the UEM apps menu (9 dots at the top right) then I am forwarded to our DOMAIN.workspaceoneaccess.com/catalog-portal/admin-console#/uem

If that is the right area that you are speaking of then it is configured as follows and does not seem to have a way to change or update the settings.

Under Workspace ONE Hub Services - System Settings we don't seem to have any way to change it. 
Currently this has only two things

• System Settings
  • Mobile Flows URL: Our URL
• UEM Integration
  • API URL: Our asXXXX.awmdm.com
  • API Certificate: Our Cert
  • Certificate Password: Our Password
  • Admin API Key: Our API Key
  • Group ID: Our top OG
  • Device Services URL: Our dsXXXX.awmdm.com/DeviceServices

We also have the Airwatch app and the AirWatch Provisioning Applications both configured in ACCESS and with the same groups assigned to them.

In UEM we are configured to use SAML and that is pointing to ACCESS.

For our second issue is all that is needed here is to switch the Okta group type then re-sync those groups?  I will have to check with our Okta admin to be sure but I would bet we are using the assignment groups.

[StevenDSa]

I don't know if I'll have the right answers for you but based on your comment "From the web using cnXXXX.awmdm.com we are not redirected to Okta and get "Invalid credentials, Try again." 

If you go to in your browser: https://cnXXXX.awmdm.com/mydevice/Login?gid=OG

You should be redirected to WS1 Access and then Redirected to Okta.  If this is not happening then you most likely have an issue in Enterprise Integration -> Directory Services (Specifically Under SAML Settings)

If you are having a problem on the return, its probably an issue with the values being passed in the response are not matching the UEM user.

[kw1548]

Using this link I am forwarded to Okta for SSO then I can see the trace to WS1 Access, and then from Access to UEM but I am still getting "Login Failed, please try again." At this point I would guess its an issue with the username values or something similar.  How would I be able to confirm this?

I did run a saml trace on this login event and can see UEM sending to Access, Then Access to Okta, Okta replys to Access and then Access forward back to UEM where we still get the same error "Invalid User Credentials ?? An unexpected error occurred."

I checked in the Applications for UEM and Access and can not find any mismatch on pass values..  I am overlooking something?

Here is the UEM Console SAML Settings

Here are the 3 Applications in Access (The first two were created and provisioned by the UEM client when setting up)

Each of them is configured as below:

The provisioning is all working as expected and configured similarly

I highlighted in red the ones I thought could be the issue but how would I go about finding out what other possible values these could have?

[StevenDSa]

Can you change your UEM settings from Redirect to Post?

[kw1548]

That did it!  Thanks!

[donion23]

Hello StevenDSa​,

I am configuring Okta SCIM users & groups to WS1 Access then WS1 Access to provision the same sets of users and groups to UEM. The first part from Okta to WS1 Access has no issue. From WS1 Access to UEM, the AirWatch Provisioning app can only provision users to UEM. Group Provisioning just stuck at provisioning and never actually provision the groups to UEM.

Any chance you know what it could cause the issue where group provioning just stuck there?

Thank you

[StevenDSa]

I've not seen that one before. Here are some suggestions:

• Make sure there is no directory configured at the customer level OG in UEM
• Make sure customer level OG is specified in WS1 Access.
• Assuming the same group does not already exist in UEM?
• Make sure Chrome autofill did not change the username/password for Provisioning tab
• Wait for it to fail (might take some time). Hopefully the error can point us in the right direction or give us the ability to deprovision.

[donion23]

Thanks so much @StevenDSa for helping. Below is my check

• Make sure there is no directory configured at the customer level OG in UEM

--> No directory is configured in UEM

Make sure customer level OG is specified in WS1 Access.

--> yes

• Assuming the same group does not already exist in UEM?

--> yep, I ensure no WS1 Authorization exist in UEM prior.

• Make sure Chrome autofill did not change the username/password for Provisioning tab

--> I disable the Chrome auto fill. Make sure the Admin Password typed in correctly. Test connection is success.

• Wait for it to fail (might take some time). Hopefully the error can point us in the right direction or give us the ability to deprovision.

---> Waited two days now

--> Further troubleshooting steps --> Check mark the WS1 Authorization group --> Deprovision --> Wait for it to be gone under Group Provisioning --> Re-add the same group for Provisioning --> It kicked into "Ready for Provision" --> then go into "Provisioning" --> stuck there and won't fail at all. No matter how long i would wait.

---> Proceed to create another seperate blank group (contain no users) in Workspace ONE Access --> Access AirWatch Provisioning app --> Group Provisioning --> Add that blank group --> still stuck at Provisioning and won't fail.

Maybe contact support? could be something is wrong with my VIDM tenant?

Andre

[donion23]

Otherwise, users are being provisioned flawlessly. Just groups won't come over