If you are not using SIEM (Security Information & Event Management) solution within your environment, you should seriously consider one. Considering the modern cyber security threat landscape, it a handy tool for all teams.
I had a bunch of VMware Workspace ONE Access (WS1) appliances already performing the Syslog action within vRealize Log Insight. However, the partner team was using a different solution Splunk. The objective here was to forward a specific log Greenbox_web.log (It holds all the user interface interactions for WS1 – This is your main log to see all internet facing activities on the appliance) to Splunk.
Luckily the Log Forwarding capability already exists within the vRLI. However, the creation of filters was a bit time consuming as it will convert the input into regex.
Configure the log forwarding in vRLI to Splunk
Go to your vRLI instance and click on Administration –> Log Management –> Log Forwarding and select New Destination
vRLI Log Management
Configuration Details
Name – The Log Forwarder Destination freindly name – VDI-WS1-Logs-Splunk
Host – Enter the Splunk load balancing VIP address
Protocol – RAW
Transport – TCP
Filter
Hostname – starts with – WS1ManagerAppPrimary* WS1ManagerAppSecondary*
text – matches – *GreenBox* (Note within the log its <GreenBox> however, if you put in the greater/less than symbol, the conversion of this string into regex doesn’t work within vRLI.)
Please Run in the interactive Analytics query to confirm your filters are working as expected
Enter the custom port provided to you by the Splunk team
Click on Save
Destination Details
After a while. you will start seeing the events forwarded to Splunk, and the state will be marked as Active. You can use the same logic above to forward other specific logs to 3rd party tools (Doesn’t have to be Splunk only). I hope you will find this helpful information on your SIEM journey. Please let me know if I have missed any steps, and I will be happy to update the post.
Many blogs discuss and show in detail how to integrate the Azure Active Directory (AAD) with VMware Workspace ONE Access (WoA) as a 3rd party IDP, and the following are my top post on that topic:
However, in this blog post, I would like to shed more light on the SAML Authentication Flow between the Azure Active Directory (Identity Provider) and VMware Workspace ONE Access (Service Provider). When designing the WoA and AAD integration, the below flow helped me understand what is happening behind the scenes, and I thought of sharing my knowledge with you all.
SAML Authentication Flow
AuthnRequest
Issuer
NameIDPolicy
RequestAuthnContext
SAML Response that AAD sends to WoA
#ProTip – I use a Chrome/Edge extension called SAML-tracer to inspect the SAML responses back and forth within the browser.
SAML Authentication Flow
The diagram below describes the single sign-on sequence. The VMware Workspace ONE Access (the service provider) uses an HTTP Redirect binding to pass an AuthnRequest (authentication request) element to Azure AD (the 3rd party identity provider in case of WoA). Azure AD then uses an HTTP post binding to post a Response element to the cloud service.
SAML Authentication Flow – AAD and WoA
S. No.
DescriptionFlow
1.
End-user tries to access the VMware Workspace ONE Access portal
2.
VMware Workspace ONE Access finds the identity provider to authenticate the user
3.
VMware Workspace ONE Access generates a SAML 2.0 AuthnRequest and redirects the user’s browser to the Azure AD SAML single sign-on URL
4.
If the end-user is not signed in, Azure AD authenticates the user using multi-factor authentication & generates a SAML token
5.
Azure AD posts the SAML response to the WoA application via the user’s browser
6.
VMware Workspace ONE Access verifies the SAML Response
7.
VMware Workspace ONE Access completes the end-user sign-in and presents the desktop/app entitlements
Note – I have randomly created the GUID within the XML response just for demonstration purposes.
AuthnRequest
To request a end-user authentication, from WoA portal send an AuthnRequest element to Azure AD. Following is the SAML SAML 2.0 AuthnRequest from WoA portal:
The Issuer element in an AuthnRequest must exactly match one of the ServicePrincipalNames in the cloud service in Azure AD. Typically, this is set to the App ID URI that is specified during application registration. (When the Enterprise Application is created under AAD portal)
This element requests a particular name ID format in the response and is optional in AuthnRequest elements sent to Azure AD. A NameIdPolicy element looks like the following from WoA portal:
The RequestedAuthnContext element specifies the desired authentication methods. It is optional in AuthnRequest elements sent to Azure AD. Azure AD supports AuthnContextClassRef values snippet from WoA portal:
I hope you will find the above information helpful in your journey with AAD/WoA. A small request if you see any scope of improvisation or refinements. I hope you can share it back with me?
We had many Disabled accounts that were getting synced into the Workspace ONE Access (WoA) from the Directory Sync – Active Directory with IWA operation. The challenge here been no standards to cater for Disable accounts in the Active Directory. I decided to stop syncing the disabled accounts into WoA. Thanks for the exclusion filter feature that came in handy, and the following are the detailed steps.
Exclusion filter to stop syncing the Disabled accounts
Safeguards adjustment (Optional)
Why did we had to stop syncing Disable accounts?
Exclusion filter to stop syncing the Disabled accounts
Login to your WoA portal with administrative privileges and go to the following path – Identity & Access Management –> Directories –> Select the Directory with Active Directory & IWA –> Sync Settings –> Users
The above will take care of not syncing the Disable user accounts into the WoA directory. However, in our scenario, the number of disable accounts were very high, and the Safeguards kick-in to protect mass deletion.
Safeguards Adjustment (Optional)
This is an optional step depending on your environment. It might need tweaking, and I am highlighting the values that need to be tweaked if it involves mass deletion (Note – these values are for experimental purposes only). Note – Please switch the value back to default after the mass deletion activity is completed. The Safeguards feature a real blessing to control WoA Directory Sync accidents against any human/automation errors.
WoA – Safeguards
Why we had to stop syncing disable accounts?
I ran into an issue where-in users had multiple accounts with 1 active/1 disabled. The email address attributes were the same in both the accounts, which will have a conflict when the end-user tries to login. This becomes evident once we switched our identity to 3rd party IDP – Azure Active Directory, where the primary NAMEID attribute is the email address.
I hope you will find these steps helpful to stop syncing disabled accounts into WoA Access – Directory Sync.
I had the opportunity to work on an upgrade from VMware Identity Manager 3.3 (VIDM) to the new name VMware Workspace ONE Access 20.01 (WoA), and I would like to share the entire experience with you. There is guidance available on the VMware documentation and a few blogs. The idea here is not to provide you with a step by step guide instead, provide guidance on best practice, insights on active/passive site, change timings, an end-2-end mind map of activities/steps involved etc., on carrying out a successful upgrade.
Environment Overview Let take a look at the environment details to provide an high-level overview: Active Site
3 VMware Identity Manager 3.3 Linux Appliances
2 VMware Identity Manager 3.3 Connecter Linux Appliances (Used for Authentication & VMware Horizon Sync)
SQL Database on Microsoft SQL 2016 Always-on
The 3 Manager Appliances are behind an NSX Load balancer
Passive Site
3 VMware Identity Manager 3.3 Linux Appliances (Read-only mode)
2 VMware Identity Manager 3.3 Connecter Linux Appliances (Used for Authentication & VMware Horizon Sync)
SQL Database on Microsoft SQL 2016 Always-on (Replica DB’s)
The 3 Manager Appliances are behind an NSX Load balancer
The offline upgrade method was selected as the choice due to convenience and ease of setup/configuration without exposing the appliance on the internet using proxy. During both, version upgrades the offline package was kept in the /tmp directory, which deletes the files post the reboot.
Downtime Window (Choice)
We had an option of performing the entire upgrade of the above components in a single day change, or we could split the upgrade into two days as we had to go from version 3.3 –> 19.03 –> 20.01.
Initially, we tried the single downtime change window of 16 hours and had hiccups which I plan to write a separate blog post. We split the change into two days. Day 1 – Upgrade from VIDM 3.3 to 19.03 and Day 2 – Upgrade from VIDM 19.03 to WoA 20.01 on two consecutive days giving us the ability for partial rollback instead of starting from scratch again.
High-Level Upgrade Architecture Overview
Disable the IDM – Manager node one at a time under the NSX load balancer and carry out the upgrade of the manager nodes one by one. After all, the manager nodes are upgraded to the desired version then move to the connector nodes one by one. In our scenario this had to repeated during the 19.03 to 20.01 Access node upgrade.
Before you begin the upgrade – Suspend the Data Movement on your SQL Always-on the Database.
There is no downtime observed when you perform an upgrade on one manager at a time. Make sure you disable the node from the load balancer (No traffic flows to the node).
No downtime is observed when connector upgrade are carried out one by one. There were four connectors for redundancy (3 Connectors performing the Authentication Function and 1 Connector – Sync and Authentication). However, the connector chosen for the AD Sync was the last one for the upgrade and in our plan we had mentioned downtime.
The System Dashboard – Health of the cluster (Active/Passive) may flip between green and red because the elastic search services take time to stabilize due to the reboots.
If you have hotfixes provided by VMware engineering due to previous issues, please check with support whether the fixes have been incorporated into the newer version or/else make sure to ask for the hot patch for the recent version. #ProTIP – Install those hotfixes before the final reboot of the upgrade to avoid an additional service restart dedicated to the hotfix.
End to end mind map of the entire Upgrade
I have included a pdf version of the mind map to read the details with zoom on.
I hope you will find this helpful information to plan and succeed in a VMware Workspace ONE Access upgrade. A big thanks to Jishan T S, my teammate, for his continuous contributions to making this a big success and trying all the steps in the development setup multiple times.
We had a strange issue in which end-users reported a black screen when they clicked on their Desktop tile in Workspace One portal on their mobile devices on Android and iOS. The moment they clicked on the endpoint the black screen would go away and it would give the logon banner and normal Windows 10 logon.
Usual Suspects
Our investigation led to Windows Logon Banner applied via the group policy causing the black screen. We were soon able to rule out by disabling the logon banner and the black screen persisted.
The black screen only appear on mobile devices. The Desktop/Laptops you didnt observe the issue.
EUC Stack
VMware Horizon 7.6
VMware App Volumes 2.14.2
VMware Identity Manager 3.3
VMware User Environment Manager 9.4
Windows 10 1803
Resolution
We managed to open the VMware GSS case and a lot of troubleshooting was carried out from re-running the VMware OSOT tool and changing the Power Configuration policy.
The final configuration that resolved the black screen issue:
Open the master image and run PowerShell with administrative rights and execute the following commands:
Make sure you restart the master template post implementing the commands . Take a snapshot and perform “Push-Image” operation in Horizon Administror console.
I hope you will find this information useful if you encounter the Black Screen issue. A big thanks to Manivannan Arul my teammate for his continoursly effort while troubleshooting with GSS.
I have been using VMware NSX load balancer across the board. The below details will provide an overview of what to enter for the health monitors. Note – If you are using something more meaningful for your environment leave feedback in the comments section. I will try to implement the same and update the blog later.
VMware Unified Access Gateway (UAG)
Create a new Service Monitor under NSX and call is UAG_https_monitor. Refer to the screenshot for more details.
Send String: GET /favicon.ico
Response code: 200s
VMware Identity Manager or Workspace ONE Access
Create a new Service Monitor under NSX and call is VIDM_https_monitor. Refer to the screenshot for more details.
Send String: GET /SAAS/auth/login Response code: 200s
VMware Horizon Connection Servers
Update 13th Sep 2021 – For all Horizon version 7.10 and above please start using the following service monitor within NSX.
Send String: GET /favicon.ico
Response code: 200s
You can use this string for versions 7.7 or upto 7.10. Create a new Service Monitor under NSX and call is Horizon_https_monitor. Refer to the screenshot for more details.
Send String: GET /broker/xml/ Receive string: /styles/clientlaunch-default
VMware App Volumes
Create a new Service Monitor under NSX and call is AV_https_monitor. Refer to the screenshot for more details.
I hope you will find these monitors useful in monitoring the VMware EUC products.
Recent Comments