Microsoft Azure Edge and Omnissa-Managed Enterprise App Registration

My Initial Experience

During the preparation activities for deploying a new Horizon Cloud on Azure environment, I was reading the official documentation at

https://docs.omnissa.com/bundle/UsingManagingHorizonCloud/page/DeployingaMicrosoftAzureEdge.html

and discovered the presence of a new and recommended deployment method: the “Omnissa-managed” mode.

I immediately wanted to test it, but in my Omnissa Connect console, this option wasn’t yet available.

.

I contacted support and they informed me that the feature would be released soon, but if I wanted to use it immediately, they could enable it through a Feature Flag. Obviously, I couldn’t say no to that opportunity! Once they provided my ORG ID and enabled the flag, the new option appeared while I was creating the EDGE in the Primary Provider section.

This is my journey with the Omnissa-managed method, and I’d like to share what I learned about this game-changing approach.

.

.

Introduction

Horizon Cloud on Microsoft Azure is evolving, and Omnissa has introduced a significant security enhancement that every administrator should know about. The new Omnissa-managed Enterprise App registration method represents a paradigm shift in how organizations handle service principal credentials. If you’re planning a Horizon Cloud deployment on Azure, understanding the difference between this new approach and the traditional manual method could be crucial for your security posture.

The Security Challenge

Historically, deploying Horizon Edge in Horizon Cloud on Azure required organizations to create and manage their own Azure Enterprise Applications. This approach meant handling sensitive service principal secrets—credentials that need to be carefully managed, rotated, and protected. The more systems that have access to these secrets, the higher the security risk.

The traditional single-tenant deployment method (Manual Enterprise App registration) placed the responsibility of secret management squarely on the customer organization. While this approach continues to be supported, it introduces additional operational overhead and potential security vulnerabilities.

Enter Omnissa-Managed

Omnissa has introduced a new Enterprise App registration method that fundamentally changes who manages the service principal secrets.

Key Benefits

1. Enhanced Security

Organizations no longer need to provide their sensitive secrets key information to Omnissa or manage it themselves in the context of Horizon Cloud deployment. The credentials remain under Omnissa’s direct management, reducing the attack surface and potential points of compromise.

2. Simplified Administration

Say goodbye to manual Enterprise Application creation and complex permission configurations. With Omnissa-managed registration, the setup process is streamlined. Omnissa handles the heavy lifting—you focus on deployment.

3. Reduced Operational Overhead

No more worrying about secret rotation schedules, credential lifecycle management, or complex authentication flows. Omnissa manages these operational concerns, freeing your team for other critical tasks.

4. Enterprise-Grade Security

By centralizing secret management with Omnissa, organizations benefit from enterprise-grade security practices, regular audits, and dedicated security expertise that Omnissa brings to the table.

Manual Registration: Still Available

For organizations with specific requirements or legacy configurations, the traditional single-tenancy method remains available. This manual Enterprise App registration approach allows organizations to maintain full control over their authentication setup if needed. However, unless you have specific compliance or architectural reasons, the manual approach introduces unnecessary complexity.

The Recommendation

Omnissa-managed is the recommended method for all new Horizon Cloud deployments on Azure. Omnissa has taken the guesswork out of enterprise app management and elevated the security baseline for everyone using Horizon Cloud.

If you’re currently on the manual registration path, consider planning a migration to the Omnissa-managed approach. The transition offers immediate security benefits with reduced administrative overhead.

Getting Started

Ready to leverage Omnissa-managed registration for your deployment? The process is straightforward:

1.Initiate your Horizon Edge deployment in Omnissa Connect
2.Select the Omnissa-managed option during the Primary Provider setup

3.Link your Azure subscription using the consent flow (click Consent Link)

4.Authorize Omnissa to create the Enterprise Application

Insert Azure Subscription credentials (in my case Global Admin User)

Now we can see the new enterprise application with Omnissa Logo.

.

.

.

5.Assign necessary roles (Contributor or appropriate custom roles) to the subscription

First, verify the role assignment status in Omnissa Connect:

.

.

Get the Object ID from the Omnissa Enterprise App:

.

.

Go to your subscription and select IAM (Identity & Access Management):

.

Select add role assignment

Search Contributor in Previleged admnistrator Role

Select Member and ad the Enterprise Application Object ID or name

6.Refresh and verify the role assignment in Omnissa Connect

Return to the Omnissa Connect wizard. If the role is still showing as “Role not Assigned”

.

Go back to the previous step and return to refresh (Omnissa Engineer should add a refresh button)

.

.

.

At this point, you’re ready to choose whether your EDGE will be an AKS (Azure Kubernetes Service) or a Virtual Machine.

The Omnissa-managed Enterprise Application has been successfully created and configured with the naming convention omnissa-horizoncloud-app-1, marked with Omnissa’s branding for easy identification.

.

.

Conclusion

The shift to Omnissa-managed Enterprise App registration represents a meaningful step forward in cloud security practices. By removing the burden of service principal secret management from customer organizations, Omnissa enables secure, simplified, and scalable Horizon Cloud deployments on Microsoft Azure.

Whether you’re planning a new deployment or evaluating your current infrastructure, the Omnissa-managed method deserves your attention. It’s security and simplicity working in harmony—exactly what modern cloud deployments should be.

Microsoft Azure Edge and Omnissa-Managed Enterprise App Registration

Enhancing VDI Security and User Experience with FIDO2/WebAuthn and Omnissa Horizon

In today’s hybrid work environments, Virtual Desktop Infrastructure (VDI) solutions like Omnissa Horizon are critical to ensuring secure and flexible access to corporate resources. Yet, as we continue to shift towards distributed workforces, traditional authentication methods such as passwords and OTP tokens increasingly show their limitations — in both security and user experience.

This is where FIDO2/WebAuthn comes into play. By integrating FIDO2/WebAuthn into your Horizon deployment, you can deliver passwordless, phishing-resistant authentication that simplifies end-user access while dramatically improving security posture.

What is FIDO2/WebAuthn?

FIDO2 is an open standard developed by the FIDO Alliance and W3C. WebAuthn (Web Authentication) is the core API that enables browsers and web applications to leverage strong authenticators such as security keys, biometric devices (like fingerprint readers), or built-in platform authenticators (like Windows Hello or Apple Face ID).

In simple terms: it replaces passwords with secure, device-bound credentials that can’t be phished or reused.

Why combine FIDO2/WebAuthn with VMware Horizon?

Here are the key benefits for Horizon administrators and end users:

1. Stronger Security

Traditional passwords are susceptible to phishing, credential stuffing, and breaches. FIDO2/WebAuthn credentials are cryptographically unique and never leave the user’s device. Even if attackers obtain user data, they cannot reuse it to gain access.

2. Seamless User Experience

Users authenticate with something they have (a device) and something they are (biometrics) or something they know (PIN). The process is fast, intuitive, and eliminates password fatigue. No more forgotten passwords or frequent resets.

3. Simplified Endpoint Management

In distributed VDI environments, especially with BYOD policies, managing traditional credentials across devices is a challenge. FIDO2/WebAuthn allows users to authenticate securely from any compliant device, reducing helpdesk workload and administrative complexity.

4. Phishing Resistance

Unlike OTP or SMS-based 2FA, FIDO2/WebAuthn authentication is bound to the specific origin (domain). Credentials cannot be used on malicious lookalike websites, significantly reducing phishing attack vectors.

5. Future-Proof Compliance

Many modern security frameworks and regulatory guidelines encourage or require phishing-resistant MFA. Deploying FIDO2/WebAuthn puts your organization ahead of compliance mandates.

How does it work with Horizon?

With Horizon’s support for modern authentication protocols (including SAML and integration with identity providers that support FIDO2/WebAuthn), you can deploy passwordless authentication workflows seamlessly:

  • Users access Horizon Client or Workspace ONE with their FIDO2 device (security key, biometrics, or platform authenticator).
  • The identity provider (IdP) validates the FIDO2/WebAuthn credentials.
  • Once authenticated, users are securely provisioned into their Horizon VDI sessions.

No passwords exchanged. No phishable credentials. Just fast, secure, and frictionless access.

Ready to try it?

Integrating FIDO2/WebAuthn with VMware Horizon is a clear step toward a more secure, modern, and user-friendly VDI environment. Whether you’re looking to reduce helpdesk tickets, strengthen security, or improve user experience, this technology is worth exploring.

Now is the time to test and adopt FIDO2/WebAuthn.

(If you want to use FIDO2 for login to VDI, see my post VMware Workspace One Access, VMware Horizon, and FIDO2 device – BIOLNX)

Environment:

  • Horizon 2503
  • Yubikey
  • Windows 11 24H2 (Guest OS for VDI)
  • Firefox and Edge
  • Horizon GPO
  • Use https://webauthn.io for authentication test

0 – Configure an account on WebAuthn.io

Insert the Yubikey on a physical PC

Go to https://webauthn.io

Insert the username and set the preferred authentication method

Select a security key (Yubikey)

Enter the security key assigned to Yubikey

A finger pressing a usb drive into a computer AI-generated content may be incorrect.

1 – Check  Active Directory GPO

The default configuration for “Allow FIDO2 authenticator access” (under Agent Configuration) is Not Configured, and with this configuration, the FIDO2 WebAuthn is enabled.

2 – Test authentication 

Now we can connect to VDI and access with edge to https://webauthn.io

After selecting, authenticate in the next window, select the security key. (This window is up from your client (PC), not from VDI)

A finger pressing a usb drive into a computer AI-generated content may be incorrect.

Spoiler 1

If you want to disable this function, you need to set the Allow FIDO2 authenticator access GPO with the value “Disabled”

And when you try to connect

Spoiler 2

We can use the “FIDO2 allow list” GPO to select which browser to use with the WebAuthN and disable another browser.

For example, enable only Firefox application

In this video, I show you how FIDO2 WebAuthN works and how to exclude certain browsers

https://youtu.be/cWKBxt8BVXU

 

Enhancing VDI Security and User Experience with FIDO2/WebAuthn and Omnissa Horizon

Upgrade Unified Access Gateway

VMware Horizon infrastructures often have the Unified Access Gateway (UAG) component to enable a secure connection from outside your corporate network to VDI.

This positioning makes the UAG subject to frequent updates, today we will see how to update it.

Download the ISO file of the version we want to update from the VMware Customer Site:

File 
Information 
Unified Access Gateway 2203 for vSphere, Amazon AWS and Google Cloud (Non-FIPS) 
DOWNLOAD NOW 
File size: 2.63 
File type: Ova 
Read More 
Unified Access Gateway (UAG) 2203 for vSphere (FIPS) 
DOWNLOAD NOW 
File size: 2.14 Ga 
File type: ova 
Read More 
Unified Access Gateway WAG) 2203 for Microsoft Azure 
DOWNLOAD Now 
File size: 2.54 GB 
File type: zip 
Read More 
Unified Access Gateway WAG) 2203 PowerShell Scripts 
DOWNLOAD NOW 
File size: 79.4 KB 
File type: zip 
Read More 
MDS checksums. SHAI checksums and SdA256 checksums

Check compatibility with your Horizon infrastructure:

Product Interoperability Matrix (vmware.com)

Add to My Favorite List 
Hide Interoperability 
Compatible IV Incompatible 
Com*tible Put End of 
a 
Put End of 
Not S upgnrted 
VMwere Horizon 
2111 
2106 
2103 
2012 
T 132 - VMwere Horizon 7 
713 1 - VMwere Horizon 7 
T 13 0 - VMwere Horizon 7 
Hide Legacy Releases O 
Past End ot General Support Past End at Technical Guidance 
VMware Unified Access Gateway 
2203 
and 
21112 
and 
2111.1 
and 
2106.2 
and 
2103.1 
and 
2103 
2012 
and 
2009 
3.10

Download the INI file containing the current UAG configuration

  • Access the Unified Access Gateway interface
    • HTTPS://<fqdnUAG>:9443

Using the credentials of the admin user

or 
VMware 
Unified Access Gateway 
dmin Username 
Admin Password 
Login

Once logged in, download the .ini file

A picture containing chart

Description automatically generated

OCSP Settings 
Support Settings 
Support Settings 
Edge Service Session Statistics 
Log Archive 
Log Level Settings 
Export Unified Access Gateway Settings

Retrieving the information needed to complete the configuration file:

  • Certificate for public access and password
  • Certificate for the admin center and its password
  • SAML component XML if integration with AZURE MFA
  • Information on where to deploy (vCenter, Cluster, virtual network, datastore ) the Virtual Appliance of the new UAG

The data indicated will serve me to fill in the fields of the downloaded ini file

Notepad 
File Edit Format 
[General] 
netlnternet= 
View 
Help 
ipø=192.168.247.54 
diskMode= 
ip1=192,168,246.54 
defaultGateway=192.168.247.1 
target= 
ds= 
routes 
2.168.246.1,192.168.4.0/24 192.168.246.1,172.25.2.0/23 192.168.246.1,172.25.6 
netmaskØ=255.255.255. or 
netManagement etwor 
net3ackendNetwork 
• pØA110cationMode=STATICV4 
name= 
deploymentOption=twonic 
forceNetmaskØ=255.255.255. or 
forceNetmask1=255.255.255. or

I summarize the info required in this table

Sector Field Description
General netInternet PortGroup on which to certify the network card that communicates to the internet world *
General diskmode Thin or Thick
General Source Absolute path where the ISO resides
General Target Path of the vSphere infrastructure where we will deploy the virtual appliance
General Ds Datastore where the VM will be created
General netManagementNetwork Portgroup on which to certify the network adapter for UAG management *
General netBackendNetwork Portgroup on which to certify the network adapter for UAG management *
General Name Virtual Machine Name
General uagName Hostname of the UAG (normally to be left that of the UAG to be replaced)
SSLCert pfxCerts Property Path where the SSL Certificate generated by a public CA in password protected PFX format used to access VDI by Horizon Clients resides
SSLCertAdmin pfxCerts Property Path where the SSL Certificate generated by a CA (normally Microsoft and Private) used to secure and validate access to the UAG Management Interface resides
IDPExternalMetadata1 metadataXmlFile Property XML file of the Identity Provider (In this case Azure AD) to enable Azure MFA for access

*VMware recommends at least two network adapters in two different segments for production environments

  • One for internet traffic (I call it the EXT-DMZ)
  • One for traffic to the internal LAN (I call it the INT-DMZ)

It is possible to create environments with 1 or 3 network adapters, in the first case VMware recommends only one card only for test environments, and in the second to also differentiate the management traffic that otherwise, in the two-card configuration would pass through the card that communicates with the internal LAN.

Notepad 
File Edit Format View Help 
l[Generate1] 
net Internet—DPG - EXT•4Zjjj) 
ipe=192.168.247.55 
diskMode—thick 
source—E : - unified - access - gateway- 22.03. 1955Ø 91_OVFI Ø. Ova 
ip1=192,168,246.55 
default-Gateway=192.168.247.1 
target—vi : / /vcaØ7 
ds=vsanDatastore 
routes1=172.16.e.Ø/16 192.168.246.1,192.168.4.0/24 192.168.246.1,172.25.2.0/23 192.168.246.1,172 
netmaskØ=255.255.255. and 
netManagementUetwork 
net8ackendNetwork=DPG - INT - C*IZ 
ipeA110cationMode=STATICV4 
name-VilJAGØ3-22Ø3 
deploymentOption=twonic 
forceNetmaskØ=255.255.255. and 
forceNetmask1-255.255.255. and 
ip1A110cationMode=STATICV4 
net-maski=255,255,255. and 
authenticationT imeout—3ØØØØe 
fipsEnab1ed—fa1se 
sys L ogType=UDP 
uagName=viuage3 
clockSkewT01erance=6Øe

At this point we can proceed with the deployment of the virtual appliance:

  • The first step is Shutdown the old UAG Virtual Appliance (I suppose do you have at least two UAGs with a Load Balancer in front and at least a DNS round-robin for balancing the traffic to the Connection server)

.\uagdeploy.ps1 -iniFile UAG_Settings_VIUAG04.ini

Administrator: Windows PowerShell 
uag ep oy2203> 
uag ep oy. PSI

Allow CEIP

Insert password for PFX Certificate File

Insert a new (or reuse the old) password for the Root account (for access to UAG OS) and Admin account (for access to UAG WEB admin console)

Waiting to complete the UAG Deploy (You can check the process from the vCenter task)

Now the new UAG virtual appliance is up and running!! Test it and apply the same step for all UAG virtual appliances of your VMware Horizon Infrastructure.

Upgrade Unified Access Gateway

VMware, CVE-2021-44228 and log4j (version 2)

Since the end of last week, a new critical vulnerability has spread, present in many programs (Many VMware applications use this Java Logging including vCenter, Horizon, etc.)

“an exploit in the popular Java logging library log4j (version 2) was discovered that results in Remote Code Execution (RCE) by logging a certain string.” as indicated in this link:

https://www.lunasec.io/docs/blog/log4j-zero-day/

After a few hours, the CVE also released its bulletin (CVE-2021-44228).

https://cve.mitre.org/cgi-bin/cvename.cgi?name=2021-44228

On the day of 10/12/2021, VMware released its security advisor (VMSA-2021-0028) with the workarounds to limit the vulnerability pending the release of patched versions to fix it:

https://www.vmware.com/security/advisories/VMSA-2021-0028.html

So good application everyone!

By the way, for the uninitiated:

What is CVE? CVE, short for Common Vulnerabilities and Exposures, is a list of publicly disclosed computer security flaws. When someone refers to a CVE, they mean a security flaw that’s been assigned a CVE ID number.
Security advisories issued by vendors and researchers almost always mention at least one CVE ID. CVEs help IT professionals coordinate their efforts to prioritize and address these vulnerabilities to make computer systems more secure.

VMware, CVE-2021-44228 and log4j (version 2)

Hardening VMware vSphere 7

Non sono certo io a dover spiegare che parlare di security è ormai entrato nel day by day dei consulenti dei manager IT. Anche VMware da alcuni anni sta rilasciando  guide di come rafforzare l’hardening degli ambienti vSphere. Ormai è da diffidare di chi considera l’installazione  di ESXi e vCenter come dei semplici avanti avanti avanti ….

Riporto qui sotto il link alla guida di VMware per l’hardening degli ambienti vSphere 7 comprensivo anche dei dettagli dei parametri da configurare e  dei comandi per modificarli.
Hardening VMware vSphere 7

Antispam in cloud cosa aspettarsi

Negli ultimi anni si sente sempre di più parlare di cloud e di servizi in cloud. In questo post non voglio entrare nel dettaglio di cos’è  il cloud e se esistono veramente dei servizi che si posso definire in cloud, voglio solamente focalizzarmi su un di quei servizi, che con l’avvento del cloud e quindi del suo utilizzo in cloud  aumenta la sua efficacia e aumentano le sue potenzialità.
Stiamo parlando dell’antispam.
L’utilizzo  di un antispam nella nuvola ci permette di parlare non solo di blocco delle mail indesiderate ma anche di
  • Riduzione del traffico in ingresso
  • Mail continuity
  • Backup mail o archive mail
Riduzione del traffico in ingresso
Spostando il servizio di antispam dalla propria infrastruttura al cloud il traffico delle mail viene filtrato prima che raggiunga il nostro server di posta,  e quindi la banda occupata in ingresso  diminuisce annullando quasi del tutto quel traffico indesiderato generato dalla mail di spam. Quindi solo le mail puilite arrivano in ingresso al nostro server interno
Mail continuity (A volte già incluso in altri casi da pagare in aggiunta al servizio di antispam)
Quante volte ci è capitato di avere il server di posta offline (Aggiornamento, crash del sistema operativo etc.. ) e dover rispondere  al nostro amministratore delegato che la mail che sta aspettando  non  può arrivare e  non sappiamo quando arriverà. Con la mail continuity nel  caso  di offline del nostro mail server interno, la posta rimane sul nostro antispam in cloud, e quindi  può essere consultata dall’amministratore di sistema e con alcuni mail security cloud provider  ogni nostro singolo utente può accedere a una web mail e vedere la propria posta (Si può passare da un minimo di 3/4 giorni di “capacità” del servizio in cloud anche a due e piu’ settimane)
Mail Backup o Archive (Servizio che in alcuni casi può essere compreso  oppure  puo’ essere in  aggiunto coma add-on a pagamento)
Il passo di  avere in un datacenter  di altro livello, quindi in un posto “al sicuro”, un contenitore che ci controlla lo spam e ci pemrmette una sorta di HA della mail  ci porta  anche a valutare la possibilità di poter archiviare/salvare la mail  temporaneamente o all’infinito nel cloud. Altro plus, in alcune versioni, la possibilità di delegare al nostro utente finale la visione  e il recupero  delle  mail.
 
Non ho citato, ma ovviamente è da considerare come vantaggio  la diminuzione dell’attivita’ dell’amministratore IT nella gestione del servizio.
 CLOUD = no server da mantenere (che sia fisico o virtuale), no servizio antispam da mantenre (aggiornamento o upgrade di versione)
Mantenendo ovviamente le caratteristiche di base in un classico antispam:
Controllo delle mail in ingresso e in uscita
Controllo antivirus (in molti casi anche con piu’ di un motore)
Gestione personalizzate di blacklist e del livello di filtro dello spam
Gestione della quarantena a livello dell’amministratore ma anche dell’utente finale.
Quindi il cloud è sicuramente per il servizio di antispam un valore aggiunto.
Antispam in cloud cosa aspettarsi