Notes from the field: VMware Access connector support LDAP Signing and Channel Binding

Quite recently I’ve encountered a random synchronization error that VMware Access connector could not synchronize and would error out with the following error: “Connector communication failed because of invalid data: The specified Bind DN and password could not be used to successfully authenticate against the directory”

At first I stumbled upon the known issues list: https://docs.vmware.com/en/VMware-Workspace-ONE-Access/19.03/rn/VMware-Identity-Manager-1903-Release-Notes.html#knownissues and checked if the computer name was the same as the name in the domain field and that was all correct.

Eventually it came to light that the LDAP Signing and Channel Binding hardening were implemented according to the latest Microsoft update. Well then you can also get this sort of behavior. The solution is present in an hotfix for the connector software.

Knowledge base article can be found here: https://kb.vmware.com/s/article/77158 and the hotfix can be found after logging in at my vmware and the components of Access/Identity Manager

Notes from the field: Configuring SentinelOne SSO with VMware Workspace ONE Access

SentinelOne’s configuration can be achieved after you have a valid account and support login. Afterwards its pretty easy to configure the SSO part.

In the cloud console of SentinelOne go to Settings>>Integrations>>SSO

Configure the following items for SSO usage:

IDP Redirect URL:

https://workspaceoneaccessurl:443/SAAS/API/1.0/GET/apps/launch/app/uniqueapplicationid

IssuerID:

https://workspaceoneaccessurl/SAAS/API/1.0/GET/metadata/idp.xml

Configure the rest of the items at your own requirements but don’t forget to upload the IDP public certificate of Workspace ONE Access.

Make copies of the Assertion Consumer Service URL and SP Entity ID to use in Workspace ONE Access.

For the configuration part of Workspace ONE Access just add a new manual SAML 2.0 application and provide the following information:

Single Sign On URL: This is the Assertion Consumer Service URL of SentinelOne

Recipient URL: This is the Assertion Consumer Service URL of SentinelOne

Application ID: this is the SP Entity ID URL of SentinelOne

Username Format: Unspecified

Username Value: ${user.email}

Don’t forget you only get an application id in Workspace ONE Access if you’ve created an application. So first up create the application with bogus input to get your id and update it accordingly.

Notes from the field: Configuring Autotask PSA with VMware Workspace ONE Access

Autotask PSA SSO configuration can be found at the following url: https://ww13.autotask.net/help/Content/AdminSetup/1FeaturesSettings/ResourcesUsers/Security/SSSO_OIDC.htm

For the configuration part of Workspace ONE Access SSO you can see the available API at this url: https://code.vmware.com/apis/57/idm#/

The problem is that Autotask PSA SSO doesn’t work/supports the setup of VMware Workspace ONE Access. I worked around this issue by having a federated setup to our Office 365 tenant and adding the Autotask application there and ultimately publishing the application as a custom application link and still provide the requested SSO.

Add a Web Application Link in Workspace ONE Access and provide the following as your target url:

https://myapps.microsoft.com/o365tenant/signin/applicationname/uniqueguidoftheapplication

Notes from the field: Configuring OpsGenie (without Atlassian Access) with VMware Workspace ONE Access

OpsGenie can use SAML SSO without the use of Atlassian Access, see the following url: https://docs.opsgenie.com/docs/single-sign-on-with-opsgenie

For the configuration part of Workspace ONE Access just add a new manual SAML 2.0 application and provide the following information according to above article:

  • Single Sign On URL https://app.opsgenie.com/auth/saml?id=”uniquesamlidprovided
  • Recipient URL https://app.opsgenie.com/auth/saml?id=”uniquesamlidprovided
  • Application ID https://app.opsgenie.com/auth/saml?id=”uniqesamlidprovided
  • Username Format = Unspecified

Username Value = ${user.email}

Notes from the field: Configuring Atlassian Access with Workspace ONE Access

Atlassian Access is the SSO portal being used for SSO access across Jira, Confluence etc. for the configuration part see the following url: https://confluence.atlassian.com/cloud/saml-single-sign-on-943953302.html

For the configuration part of Workspace ONE Access just add a new manual SAML 2.0 application and provide the following information according to above article:

  • Single Sign On URL https://auth.atlassian.com/login/callback?connection=saml”uniquesamlidprovided
  • Recipient URL https://auth.atlassian.com/login/callback?connection=saml”uniquesamlidprovided
  • Application ID https://auth.atlassian.com/saml/”uniqesamlidprovided
  • Username Format = Unspecified
  • Username Value = ${user.email}
  • Relay State URL = https://id.atlassian.com/login

Add the custom attribute mappings for firstname, lastname and userprincipalname.

Notes from the field: UEM/vIDM integration caveats

Not too long ago I encountered some issues when configuring UEM and IDM integration. When providing the vIDM URL in UEM for configuring the integration it would error out with below error:

After some troubleshooting it appeared that the access policies where not properly configured as in the last rule in the default access application ruleset was blocking access. Resolution was editing the default policy and ending it with the password method which is associated with the built-in workspace IDP, after that the integration part is working as expected.

Another configuration task which caught me by surprise was that after the configuration is set up between UEM and vIDM the following errors occurred:

Turned out that the integration between UEM and vIDM is depending on Active Directory integration. The basic system domain accounts (even full admins) won’t work in this scenario. Resolution is configuring an domain account with the necessary admin rights in both tenants and then it will work as expected.

Hope this helps!

Notes from the field: vIDM and o365 modern authentication delay

Just a quick win blog to mention and give a heads-up that when you are in the process of configuring vIDM and o365 you might encounter native clients prompting for authentication and a big ass delay when you flip over the authentication and the requested domain from managed to federated with vIDM. This might be up to eight hours!!! Thanks to the #community #vExpert that I got this answer quite fast because I recalled that Laurens van Duijn put something similar in the vExpert Slack group mentioning that he saw this kind of behavior.

So in summary, do it on a Friday and inform your users.

Big shout out to Laurens van Duijn and be sure to follow him on twitter and his blog

Twitter: @LaurensvanDuijn

Blog: https://vdr.one/