Hey everybody,

it’s Patrick again with a new blog post on how to install and configure Workspace ONE Access On-Premises.
Many of my customers and community friends have asked for support during the last weeks on how to get up and running with Workspace ONE Access in combination with a Microsoft Azure federation. There are some quite good community posts out there on how to configure this, but to get to the point to configure Workspace ONE Access to work with Azure (or to federate to Azure), you must install the Workspace ONE Access appliance on-premises, which might now always be too easy.

In this blog series, I will cover the following topics:

– Part 1: Import and Setup Workspace ONE Access 22.09 On-Premises (incl. troubleshooting steps)
– Part 2: Loadbalancing with NSX Advanced Loadbalancing (former AVI)
– Part 3: Configure Microsoft Azure for federation
– Part 4: Integration with Horizon On-Premises
– Part 5: Integration with Horizon Cloud on Azure

Table of Contents

What is Workspace ONE Access?

Workspace ONE Access is a product offered by VMware that provides a single sign-on (SSO) platform for accessing cloud, mobile, and web-based applications. It is part of the Workspace ONE suite of products, which aims to provide a comprehensive solution for enterprise mobility management (EMM).

Workspace ONE Access includes a number of features that can help organizations to manage and secure access to their applications and data. These features include:

  • Single sign-on (SSO) capabilities, which allow users to access all of their applications with a single set of credentials
  • Identity and access management (IAM) features, such as multi-factor authentication (MFA) and identity federation
  • Application integration and provisioning, which allows organizations to easily add and manage access to new applications
  • Mobile device management (MDM) capabilities, which allow organizations to manage and secure mobile devices that access corporate applications and data

Since a couple of months I see a huge request in enabling organizations to consume Microsoft Azure Authentication services, which have been implemented due to the way to Microsoft 365 and Azure, for Workspace ONE Access. This allows organizations to consume a single IdP for all their cloud based Apps with the additional capability of integrating on-premises VMware products and allowing them secure access with only one authenticator app, the Microsoft Authenticator in this example.

High-Level Design

In the above picture you can find a quick draft of what we try to achieve with the infrastructure. We will start at the bottom, where we can find the internal server components required for the solution to work.
First of all, we need to have at least one Windows Server acting as Domain Controller + DNS Server. Additionally, we need at least one MS SQL Server (more servers for MS SQL Always ON capabilities – I will not walk through the enablement in this article series, however I will link some good material at the point of configuration as an option.

The so called “WS1 (Workspace ONE) Access Connector stated on the lower left corner is required to synchronise user identities and groups to the Workspace ONE Access service at a later point in time. This machine is not required from the get go, but we will cover the specifics a bit later in this article.

In the upper area, we see the DMZ network, where we will deploy three Workspace ONE Access appliances behind a load balancer, which is in our case the NSX Advanced Loadbalancer (former AVI). After the initial setup, we will integrate Microsoft Azure as Third-Party identity provider to allow users to consume Azure authentication services and use Workspace ONE Access authentication as fall back method.

In another part of this article series, I will enable the integration with Horizon (on-premises) and Horizon Cloud on Azure.

You might ask yourself, why are we putting the Workspace ONE Access appliances into a DMZ network, let me give you some arguments for it:

  1. Security: The DMZ is a network segment that is isolated from the rest of the network and is typically used to host external-facing services. By placing Workspace ONE Access in the DMZ, an organization can better protect its internal network from external threats.

  2. Accessibility: Placing Workspace ONE Access in the DMZ can also make it more accessible to external users, such as remote workers or partners. This can be particularly useful if the organization is using Workspace ONE Access to provide single sign-on (SSO) access to cloud-based applications.

  3. Load balancing: If an organization is expecting a high volume of traffic to Workspace ONE Access, they may want to consider placing it in the DMZ in order to take advantage of load balancing and other network infrastructure features that are typically available in this network segment.

It’s important to note that there are also potential security and other considerations to keep in mind when placing Workspace ONE Access or any other service in the DMZ.

Component Summary - Internal Network

Component Summary - DMZ Network

Prerequisites

Before we can get started with the import of our first appliance, we must make sure that we have the following prerequisites in place (besides having the mentioned components like a Domain Controller, Firewalls etc.).

DNS configuration (required for Load Balancing)

If you plan to run more than one instance of Workspace ONE Access, it’s wise to setup the required DNS records before getting started to build out the infrastructure. A reason is, that Workspace ONE Access relies a lot on DNS entries (we will see this especially when we progress with the initial setup).

In my example I will have three Workspace ONE Access appliances, so I will create three A-Records in my DNS Server and one for the Load Balancing VIP (make sure that this will be the FQDN used for internal and external access). In addition to the A-Record, make sure that the corresponding PTR-Record (Reverse Lookup) is enabled as well for all mentioned appliances + VIP.

VIP FQDN: access.avdlogix.com // VIP: 192.168.3.100
Access 1 Appliance: vm-access-01.avdlogix.com // IP: 192.168.3.101
Access 2 Appliance: vm-access-02.avdlogix.com // IP: 192.168.3.102
Access 3 Appliance: vm-access-03.avdlogix.com // IP: 192.168.3.103

Certificate signed by Third-Party CA

In my case I use a wild card certificate provided by my service provider. In case that you want to use a dedicated certificate for your domain, ensure that you include ALL FQDNs of the appliances in the SAN (Subject Alternative Name) of your certificate, including the external accessible name.

Otherwise, the following requirements are valid for the certificate:

  1. SSL/TLS certificate: Workspace ONE Access requires a Secure Sockets Layer (SSL) or Transport Layer Security (TLS) certificate to secure communication between the client and the server. This certificate should be issued by a trusted certificate authority (CA) and should be valid for the domain name of the Workspace ONE Access server.

  2. Client certificate: If client certificate authentication is enabled, Workspace ONE Access requires that client devices have a valid certificate installed. This certificate should be issued by a trusted CA and should be valid for the domain name of the client device.

  3. Identity provider certificate: If Workspace ONE Access is configured to integrate with an external identity provider (IDP), such as Active Directory or LDAP, it may require a certificate to secure communication with the IDP. This certificate should be issued by a trusted CA and should be valid for the domain name of the IDP server. (This will be the case for us, when it comes to the connection with Microsoft Azure, which will be covered at a later stage in this series).

 

LDAP Service Account (Bind User)

When performing the inital setup of the Workspace ONE Access appliance, we must ensure to have a Service Account set up correctly, to ensure that we can synchronise user identities and groups to our Workspace ONE Access instance.

Important note: Make sure the following attributes are filled out – otherwise the sync and usage of the account might fail:
– Firstname
– Lastname
– Displayname
– E-Mail Address

General information: When trying to sync users to Workspace ONE Access, the connector drops an error if the E-Mail address field isn’t filled out! Make sure that this is the case for all users being synchronised to WS1 Access.

Database preparation tasks

If you want to use Workspace ONE Access with a single instance, this might not be a relevant prerequisite for you, as you can use the internal database, however for most production environments and especially those load balanced, the following requirements for the Microsoft SQL database are valid:

– SQL Server Version 2014 – 2019 (supported)
– Hardware sizing (based on the number of users being synchronised)
– Firewall openings (for the appliances to connect to the database)
More information on the firewall ports and database prerequisites can be found on the VMware Docs page: https://docs.vmware.com/en/VMware-Workspace-ONE-Access/22.09/workspace_one_access_install/GUID-E81B6B1B-A3D1-40D0-806A-3D31502C53A5.html

Database creation (for Windows Authentication mode)

When the MS SQL database server is setup / in place, we must create the database and probably a related service user to create the connection. If you want to go for Windows integrated authentication, use the following script to create the database.

Attention! This script will create a database with the collation “Latin1_General_CS_AS” which is Case Sensitive! It’s not recommended to run databases with different colations on the same server. In case that you have a different colation by default, this is supported as well. If you intend to change the colation, this is supported, but will ONLY work when you edit the “runtime-config.properties” file with the new colation type. More information on how to change the runtime-config.properties can be found in this article: https://docs.vmware.com/en/VMware-Workspace-ONE-Access/20.10/workspace_one_access_install/GUID-EA58B440-AA65-4BC0-82B1-0957A070EB79.html

				
					/*
Values within angle brackets (< >) are example values. When replacing the example value,
remove the angle brackets. The database name is case sensitive, and the name must be one word with no spaces. 
Make sure you enter the database name the same in all instances.
*/


CREATE DATABASE <saasdb>
COLLATE <Latin1_General_CS_AS>;
ALTER DATABASE <saasdb> SET READ_COMMITTED_SNAPSHOT ON;
GO

IF NOT EXISTS
(SELECT name
FROM master.sys.server_principals
WHERE name=N'<domain\username>')
BEGIN
CREATE LOGIN [<domain\username>] FROM WINDOWS;
END
GO

USE <saasdb>; 
IF EXISTS (SELECT * FROM sys.database_principals WHERE name=N'<domain\username>')
DROP USER [<domain\username>]
GO

CREATE USER [<domain\username>] FOR LOGIN [<domain\username>] 
WITH DEFAULT_SCHEMA=saas;
GO

CREATE SCHEMA saas AUTHORIZATION "<domain\username>"
GRANT ALL ON DATABASE::<saasdb> TO "<domain\username>";
GO

ALTER ROLE db_owner ADD MEMBER "<domain\username>";
GO


				
			

Database creation (for SQL server integrated authentication)

If you don’t want to use Windows Authentication for your SQL server (as in my example), you can create the database and authenticate using an SQL internal user. You can use the following script to create the database. Attention! This script tries to grant ALL permissions on the database, which might cause issues. Follow the steps underneath the script to complete the setup.

				
					/*
Values within angle brackets (< >) are example values. When replacing the example value,
remove the angle brackets. The database name is case sensitive, and the name must be one word with no spaces. 
Make sure you enter the database name the same in all instances.
*/


CREATE DATABASE <saasdb>
COLLATE Latin1_General_CS_AS;
ALTER DATABASE <saasdb> SET READ_COMMITTED_SNAPSHOT ON;
GO

BEGIN
CREATE LOGIN <loginusername> WITH PASSWORD = N'<password>';
END
GO

USE <saasdb>; 
IF EXISTS (SELECT * FROM sys.database_principals WHERE name=N'<loginusername>')
DROP USER [<loginusername>]
GO

CREATE USER [<loginusername>] FOR LOGIN [<loginusername>]
WITH DEFAULT_SCHEMA=saas;
GO

CREATE SCHEMA saas AUTHORIZATION <loginusername>
GRANT ALL ON DATABASE::<saasdb> TO <loginusername>;
GO

ALTER ROLE [db_owner] ADD MEMBER <loginusername>;
GO


				
			

These steps describe the creation in pictures:
1. Login to the Microsoft SQL Server Management Studio and run a “New Query“.

2. Replace the values in <> with your environment specific settings. This could like this. Once, you’re done, click “Execute” in the upper left corner.

How to fix the SQL Server error

"The ALL permission is deprecated and maintained only for compatibility. It DOES NOT imply ALL permissions defined on the entitity."

In case that the creation completes with an error: “The ALL permission is deprecated and maintained only for compatibility. It DOES NOT imply ALL permissions defined on the entitity.” You must make sure to assign the proper rights for the newly created user on the database. Follow these steps to remediate the issue (these steps are valid also for the Windows Authentication method, in case you experience the same issues).
1. Right-click the database you just created and click “Properties”.

2. Select the permissions tab on the left side and select the user account you just created / assigned. Now go through the list and select the GRANT permission for all mentioned permission objects. When all items are ticked, click OK to complete.

This will ensure that the service account created will get all the required permissions to be able to create the database. If you don’t do this step you might experience issues during the setup.

Deploy Workspace ONE Access OVF

After all the prerequisites are met, we can finally start to deploy the Workspace ONE Access appliance. To start, we must download the latest appliance versions from VMware’s customer connect portal by using the following URL. https://customerconnect.vmware.com/downloads/details?downloadGroup=WS1A_ONPREM_220910&productId=1340&rPId=98456

Attention! User account for Customer Connect portal required. The link points to the version 22.09.1. In case of a newer version, simply select the version from the drop down field after signing in.

Once the OVF file has been downloaded, sign into your vCenter server appliance. Right-click your cluster name (in my case AVDLogix) and select “Deploy OVF Template…

Now select “Local file” and upload the OVF template from the customer connect portal. Hit next to proceed.