Setting up WS1 Access & UEM, can’t enroll devices or login with directory user

[adoer]

Hello,

We are trying to go through a trial to determine if WS1 is the right tool for us, however, after completing the OKTA <> WS1 Access, Setting up the Airwatch Provisioning App, and then setting up everything within UEM (In terms of domain checks, branding, etc). I have configured everything according to Steve's Blog & cross referencing the support documentation for the two products previously listed.

I cannot login via SAML to WS1 Access via the Directory based user. Even though the user in question is assigned the provisioning app. With this, I also can't enroll devices via ds*****.awmdm.com/enroll as it states the same error when trying to login. Would anyone be able to offer insight? 

I also have an issue when trying to click Okta apps that are being displayed via Workspace One Access, as these result with 400 General_nonsuccess, but, I have not set routing rules so that is more than likely an intended configuration issue at the moment.

Attached are some screenshots of our instance. Let me know if these are helpful or if anything else may be needed.

 

 

 

 

 

[Noordan]

I think there is two applications that you may need.
The first is the airwatch provisioning application that should create users in UEM.
The second application that you may need is the one that is called Airwatch. This application gives the user access to log in to the UEM thru Access, and I think it is that application you are missing

[adoer]

Thanks! That is what I thought - but I hadn't actually seen anyone write documentation on this. Once I set that up, I get the following unfortunately, and I am not sure what is signifying this timeout, as I don't see anything explicitly failing and in some cases, it immediately responds with this error with less than <1 seconds.

 If I pull up a SAML Trace, I don't particularly see anything abnormal in the trace logs, and if I pull up a network inspection while logging in, everything seems to be under 500 ms responds times, with no 404's or otherwise that would indicate a bad connection - I only see 200 and 302s.

[Noordan]

Please make sure that you are using your device services URL in the configuration of the airwatch app in ws1 Access and not your console URL to be able to enroll devices and access SSP

[adoer]

So I have tried to use the following URLs in the configuration:

ds****.awmdm.com

cn****.awmdm.com

Unfortunately, each time I get the SAML Timeout message from the previous post for every URL in this situation. Checking our Site URLs in System > Advanced, I don't see anything specifically wrong with this config:

 

My assumption here is that these parameters fill back into the variables that are listed in the actual SSO Urls, but if I also try and manually specify the URL above in the SSO lines, it presents the same time-out message as in the previous post.

[Noordan · Accepted solution]

hm.. I can see in your screenshots from UEM console that you are using redirect for the response. But by default the Airwatch application in WS1 access are using http-post. have you tried to change redirect -> Post for the response in UEM console?

https://{AWServerName}/IdentityService/SAML/AssertionService.ashx?binding=HttpPost

[adoer]

Sweet, that seems to have done it. 🙂