I remember fondly one of my first ever articles where I covered setting up VIDM Connectors and Workspace ONE overall. It has come so far over the last 3-4 years. One of the big challenges as we moved to the Workspace ONE suite was support for virtual apps. This week, VMware FINALLY released version 21.08 of the WS1 Access Connector to introduce support and bring us closer to sunsetting the legacy connectors.

Today we are going to cover the transition from VIDM 1903 Connectors to 2108, which is not as easy as you think it might be. We will cover the installation, setup, and migration that will bring you to the future!

So What’s New in WS1 Access Connector 21.08?

We should probably take a minute and discuss what’s new in 21.08. Simply these are the highlights!

• Introducing the Virtual App Service that lets you integrate Horizon and Citrix virtual apps. It does NOT support Horizon Cloud or ThinApp.
• RSA SecurID integration now supports a REST API-driven integration.
• Keep in mind, the Virtual App Service requires you to upload trust certificates to maintain trust between the connectors. That is a new requirement in 21.08.
• Bunch of bug fixes you can read about here.

Installing the Workspace ONE Access Connector 21.08

Unfortunately, 2108 is a separate installer and there is no clean upgrade path there. We will be simply dropping the 2108 Installer found here onto the server. The install is “mostly” straight-forward, but you should be prepared with proxy info, syslog info, certificates, etc. that will need to be uploaded during the install process.

The good news is you can re-run the installer at a later time if you need to modify anything. For example, that is how you will update your SSL certificates in the future. That is WAY more user friendly than the old method: put the certificate somewhere in the right format and restart services. Check out the Demo below!

Silent WS1 Access Connector Installation Process

You can also use command line to install connectors silently. Let’s cover that real quick.

First, you need to build the XML File. You “can” just add them into the command line during install but I prefer the XML as its cleaner (see the properties here):

<?xml version="1.0" encoding="utf-8"?>
<properties>
	<!-- List of services to be installed -->
	<property name="ADDLOCAL" value="UserAuthService,DirectorySyncService,KerberosAuthService,VirtualAppService" />

	<!-- Installation Directory -->
	<property name="INSTALLDIR" value="E:\VMware" />
	<!-- Installation Directory -->
	<property name="TARGETDIR" value="E:\VMware" />

	<!-- Provide the path for the es-config.json file which you downloaded from the Admin console. -->
	<!-- The file password will be specified through the command line argument WS1_CONFIG_FILE_PASSWORD. -->
	<property name="WS1_CONFIG_FILE_PATH" value="C:\Installer\es-config.json" />

	<!-- Proxy Configuration: 0 - No proxy, 1 - Configure Proxy -->
	<property name="WS1_IS_PROXY_ENABLED" value="1" />
	<!-- Proxy Host Name -->
	<property name="WS1_PROXY_HOSTNAME" value="proxy.mobilejon.com" />
	<!-- Proxy Port Number -->
	<property name="WS1_PROXY_PORT" value="9400" />
	<!-- Proxy Authentication type: 1 - Anonymous, 2 - Authenticated -->
	<property name="WS1_IS_PROXY_AUTHENTICATED" value="1" />
	<!-- Proxy Username if proxy is Authenticated -->
	<!-- The proxy password will be specified through the command line argument WS1_PROXY_PASSWORD. -->
	<property name="WS1_PROXY_USERNAME" value="" />

	<!-- Syslog Configuration: 0 - No Syslog, 1 - Configure Syslog -->
	<property name="WS1_IS_SYSLOG_ENABLED" value="1" />
	<!-- Syslog Host name -->
	<property name="WS1_SYSLOG_HOSTNAME" value="syslog.mobilejon.com" />
	<!-- Syslog port number -->
	<property name="WS1_SYSLOG_PORT" value="514" />

	<!-- Trust Store Certificate(s) folder path. Provide the folder path for certificates to be installed in the truststore. -->
	<property name="WS1_TRUSTSTORE_CERTS_PATH" value="C:\Installer\Certificates" />

	<!-- Port for UserAuthService -->
	<property name="WS1_USER_AUTH_PORT" value="8090" />
	<!-- Port for DirectorySyncService -->
	<property name="WS1_DIRECTORY_SYNC_PORT" value="8080" />
	<!-- Port for KerberosAuthService -->
	<property name="WS1_KERBEROS_AUTH_PORT" value="444" /> 
       <!-- Port for VirtualAppService -->
	<property name="WS1_APP_SYNC_PORT" value="8008" />

	<!-- SSL Certificate for Kerberos Auth Service: 0 - Self-signed Certificate, 1 - SSL certificate -->
	<property name="WS1_ADD_SSL_CERT" value="1" />
	<!-- File path for the SSL Certificate for Kerberos Auth Service, in .pem or .pfx format -->
	<!-- If SSL Certificate is a .pfx file, its password will be specified through the command line argument WS1_SSL_CERT_PASSWORD. -->
	<property name="WS1_SSL_CERT" value="C:\Installer\Certificates\Access.pem" />
	<!-- File path for the private key file if SSL Certificate is a .pem file -->
	<property name="WS1_PRIVATE_KEY" value="C:\Installer\Certificates\Access.key" />

	<!-- Domain Username in the format DOMAIN\UserName, required to run the Kerberos Auth and Virtual App services as a domain user. It is also used to generate the keytab file for the Kerberos Auth service. -->
	<!-- The password will be specified through the command line argument IS_NET_API_LOGON_PASSWORD -->
	<property name="IS_NET_API_LOGON_USERNAME" value="synterex\kerberosuser" />
</properties>

Below, you can use this single command to install your Access Connector with your specified setup as mentioned earlier. Big call out is that your kerberos service account can ONLY use @!* as special characters:

Workspace ONE Access Connector Installer.exe /s /v" /qn IS_NET_API_LOGON_PASSWORD=HiThere! WS1_CONFIG_FILE_PASSWORD=123456 WS1_SETUP_CONFIG_FILE=C:\Installer\ConnectorConfig.xml /l*v C:\Installer\connectorinstaller.log"

Migrating your Connectors to WS1 Access 21.08

Now that you are post-install, you will use very nice “Directory and Virtual Apps Migration” wizard inside of your Access Console to transition over. I’m very glad that VMware used some common sense and delivered an excellent way to not only transition, but back out easily. You will see in the demo below how to make all of that great magic happen:

Re-hashing the Kerberos Discussion on Access Connectors

One of the major criticisms that I have had with Access Connectors is their terrible setupKerberos.bat file, which sets up your Kerberos Keytab. For those of you who aren’t aware, that keytab is basically what facilitates your Kerberos auth on your PCs (I swear if you are using Kerberos Auth on Macs I will smite you!).

Today, that script basically creates a user account with the EXACT same name as your server and sets up kerberos with it. I cannot stress enough how stupid that is in about 15 ways. There’s also the fact that they set that account with these properties:

• Password Not Required
• Password Never Expires

Well, we can’t escape that, but we can do things way better. Today, I am happy to announce the release of the MobileJon Kerberos Setup script that they should be using. I will list the code below as it isn’t too long:

# Set Root Domain
If (!$rootDomain) {
    $rootDomain = Get-ADDomain | Select -ExpandProperty DNSRoot
    $rootDomain = $rootDomain.ToUpper()
}
##Request the Service Account Name##
$sAMAccountName = Read-Host -Prompt 'Enter the Service Account Username'

##Set the SPN##
$machineDomain = (Get-WmiObject win32_computersystem).Domain
$machineName = (Get-WmiObject win32_computersystem).DNSHostName
$spn = "HTTP/"+$machineName+"."+$machineDomain
$shortSpn = "HTTP/"+$machineName
setspn -s $spn@$rootDomain $sAMAccountName

##Configure Account Settings##
Set-ADUser -Identity $sAMAccountName -PasswordNotRequired $true

Set-ADUser -Identity kerberosuser -PasswordNeverExpires $true

##Generate the Keytab
$password = Read-Host -Prompt 'Enter the Service Account Password' -AsSecureString
$keytabFile = 'C:\temp\new\krb5.keytab'
ktpass.exe -mapuser $sAMAccountName@$rootDomain -princ $spn@$rootDomain  -crypto All -ptype KRB5_NT_PRINCIPAL -pass $password -out $keytabFile
ktpass.exe -princ $spn@$rootDomain -crypto AES128-SHA1 -ptype KRB5_NT_PRINCIPAL -pass "$password" -in "$keytabFile" -out "$keytabFile" -setupn -setpass | Out-Null
"exit code (ktpass-2): $LastExitCode" 
ktpass.exe -princ $spn@$rootDomain -crypto AES256-SHA1 -ptype KRB5_NT_PRINCIPAL -pass "$password" -in "$keytabFile" -out "$keytabFile" -setupn -setpass | Out-Null
"Mapped principal $spn@$rootDomain into $sAMAccountName@$rootDomain, exit code (ktpass-3): $LastExitCode"
ktpass.exe -princ $shortSpn@$rootDomain -mapuser $sAMAccountName@$rootDomain -crypto RC4-HMAC-NT -ptype KRB5_NT_PRINCIPAL -pass "$password" -in "$keytabFile" -out "$keytabFile" -setupn -setpass | Out-Null
"Mapped short $shortSpn@$rootDomain into $sAMAccountName@$rootDomain, exit code (ktpass-4): $LastExitCode"
ktpass.exe -princ $shortSpn@$rootDomain -crypto AES128-SHA1 -ptype KRB5_NT_PRINCIPAL -pass "$password" -in "$keytabFile" -out "$keytabFile" -setupn -setpass | Out-Null
"Mapped short $shortSpn@$rootDomain into $sAMAccountName@$rootDomain, exit code (ktpass-5): $LastExitCode" 
ktpass.exe -princ $shortSpn@$rootDomain -crypto AES256-SHA1 -ptype KRB5_NT_PRINCIPAL -pass "$password" -in "$keytabFile" -out "$keytabFile" -setupn -setpass | Out-Null
"Mapped principal $shortSpn@$rootDomain into $sAMAccountName@$rootDomain, exit code (ktpass-6): $LastExitCode" 

Transitioning your RSA Connector for Workspace ONE Access Connectors

In a late addition, I did some engineering to get the RSA Connector working on Access. After your migration, you might see stuff like “FAIL VERIFY_ERROR” which is the least helpful thing on earth.

The main thing to be aware of is that the legacy integration with RSA used IP address mappings to connect to the RSA Authentication Agents you created for VIDM. With the new REST integration, you MUST have authentication agents using a client ID matching the FQDN of your Workspace ONE Access Connector. This code below found on my Github, will help you validate that easily:

#----------------------------------------------------------[Declarations]----------------------------------------------------------
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
#-----------------------------------------------------------[Functions]------------------------------------------------------------
$headers = New-Object "System.Collections.Generic.Dictionary[[String],[String]]"
$headers.Add("client-key", "CLIENTKEY")
$headers.Add("Content-Type", "application/json")
$body = "`n{`n  `"authnAttemptTimeout`": 10,`n  `"clientId`": `"vidm01.mobilejon.com`",`n  `"subjectName`": `"mobilejon`",`n  `"lang`": `"en_US`",`n  `"assurancePolicyId`": `"aea87a57-f349-4fee-b615-15447d88e7b9`",`n  `"sessionAttributes`": [],`n  `"subjectCredentials`": [`n    {`n      `"methodId`": `"SECURID`",`n      `"collectedInputs`": [`n        {`n          `"name`": `"SECURID`",`n          `"value`": `"03538482`",`n          `"dataType`": `"STRING`"`n        }`n      ]`n    }`n  ],`n  `"context`": {`n    `"messageId`": `"50542c7b-86f3-45a9-8d6b-7500b9130047`"`n  },`n  `"keepAttempt`": false`n}"
$response = Invoke-RestMethod 'https://rsaserver.mobilejon.com:5555/mfa/v1_1/authn/initialize' -Method 'POST' -Headers $headers -Body $body
$response | ConvertTo-Json

Once updating things, you should be golden! If you do need to troubleshoot, do not forget to add the SecureID Loggers to the log4j2-override.xml in the User Auth Service/Conf folder:

<Loggers>
    <Logger name="com.vmware level="INFO"/>
    <Logger name="com.vmware.vidm.eas.adapters.secureid" level="TRACE"/>
    </Loggers>

Final Thoughts

So, there you have it! I’m very happy to see that we have finally made some real progress. The new connectors are WAY more stable than their counterparts. We can also see them driving toward a more REST API-friendly model for their integrations. That strategically will deliver more robust offerings we move forward and try to deliver amazing experiences. It’s time to upgrade! Get onto those Non-Prod environments and check things out!