Archive | Workspace ONE Access RSS feed for this section

Forward specific logs from VMware vRealize Log Insight (vRLI) to Splunk

26 Aug

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
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
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.

Thanks,
Aresh Sarkari

Tags: , , , ,

SAML Authentication Flow – Azure Active Directory and VMware Workspace ONE Access

28 Sep

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.Description Flow
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:

<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
                    AssertionConsumerServiceURL="https://askaresh.com/SAAS/auth/saml/response"
                    Destination="https://login.microsoftonline.com/adsadas-2312asdasd-asdasda-2312asdda/saml2"
                    ForceAuthn="false"
                    ID="_sdasdwqezxdasdasd2313asdas"
                    IssueInstant="2021-08-04T00:24:08.092Z"
                    ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
                    ProviderName="askaresh.com"
                    Version="2.0"
                    >
 
</samlp:AuthnRequest>

Issuer

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)

<saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">https://askaresh.com/SAAS/API/1.0/GET/metadata/sp.xml</saml:Issuer>

NameIDPolicy

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:

<samlp:NameIDPolicy AllowCreate="false"
                        Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"/>

RequestAuthnContext

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:

<samlp:RequestedAuthnContext>
    <saml:AuthnContextClassRef xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">urn:oasis:names:tc:SAML:2.0:ac:classes:Password</saml:AuthnContextClassRef>
</samlp:RequestedAuthnContext>

SAML Response AAD sends to WoA portal (Step 5-6)

The SAML Repsonse that AAD sends back to WoA portal:

<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
                ID="_2132sdasdasdas-asdasd-aeeqwq-adsa"
                Version="2.0"
                IssueInstant="2021-08-04T02:39:06.365Z"
                Destination="https://askaresh.com/SAAS/auth/saml/response"
                InResponseTo="_ad123123213qws12312asa1"
                >
    <Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">https://sts.windows.net/se13edsadsadasdasdasd2342342dasdas/</Issuer>
    <samlp:Status>
        <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" />
    </samlp:Status>
    <Assertion xmlns="urn:oasis:names:tc:SAML:2.0:assertion"
               ID="_324sadasdsa-adsa-asd1312-adsasdas"
               IssueInstant="2021-08-04T02:39:06.365Z"
               Version="2.0"
               >
        <Issuer>https://sts.windows.net/123asdasdas-adsa-asdsad-asdsad-4523213432asd/</Issuer>
        <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
            <SignedInfo>
                <CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
                <SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256" />
                <Reference URI="#_54fb024a-f2f0-4495-99c7-f47e3fd37701">
                    <Transforms>
                        <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
                        <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
                    </Transforms>
                    <DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256" />
                    <DigestValue>3213asdasdase3432sdsadasd2342432423675=</DigestValue>
                </Reference>
            </SignedInfo>
            <SignatureValue>SIGNATUREDATA==</SignatureValue>
            <KeyInfo>
                <X509Data>
                    <X509Certificate>CERTDATA==</X509Certificate>
                </X509Data>
            </KeyInfo>
        </Signature>
        <Subject>
            <NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">aresh@askaresh.com</NameID>
            <SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
                <SubjectConfirmationData InResponseTo="_aasdwqewqsadsadasdsa-asdasd-asdasd"
                                         NotOnOrAfter="2021-08-04T03:39:04.318Z"
                                         Recipient="https://askaresh.com/SAAS/auth/saml/response"
                                         />
            </SubjectConfirmation>
        </Subject>
        <Conditions NotBefore="2021-08-04T02:34:04.318Z"
                    NotOnOrAfter="2021-08-04T03:39:04.318Z"
                    >
            <AudienceRestriction>
                <Audience>https://askaresh.com/SAAS/API/1.0/GET/metadata/sp.xml</Audience>
            </AudienceRestriction>
        </Conditions>
        <AttributeStatement>
            <Attribute Name="http://schemas.microsoft.com/identity/claims/tenantid">
                <AttributeValue>adsad1-adsasdsa-adasdasd-adasdsa-12321321</AttributeValue>
            </Attribute>
            <Attribute Name="http://schemas.microsoft.com/identity/claims/objectidentifier">
                <AttributeValue>123dsfssdfw12312asdasdadasdxsas21s</AttributeValue>
            </Attribute>
            <Attribute Name="http://schemas.microsoft.com/identity/claims/identityprovider">
                <AttributeValue>https://sts.windows.net/131sdfsdfsdfsdcs13123123dsfsdfsdfxcr21e23rwadsadsa/</AttributeValue>
            </Attribute>
            <Attribute Name="http://schemas.microsoft.com/claims/authnmethodsreferences">
                <AttributeValue>http://schemas.microsoft.com/ws/2008/06/identity/authenticationmethod/password</AttributeValue>
            </Attribute>
            <Attribute Name="email">
                <AttributeValue>aresh@askaresh.com</AttributeValue>
            </Attribute>
            <Attribute Name="ExternalID">
                <AttributeValue>8711aaae-b7b3-4202-8faf-f2408ffd7cf9</AttributeValue>
            </Attribute>
            <Attribute Name="userName">
                <AttributeValue>aresh@askaresh.com</AttributeValue>
            </Attribute>
            <Attribute Name="userPrincipalName">
                <AttributeValue>aresh@askaresh.com</AttributeValue>
            </Attribute>
        </AttributeStatement>
        <AuthnStatement AuthnInstant="2021-08-04T02:38:59.239Z"
                        SessionIndex="_123123-adsasdsa-ad213123dsaasdsa"
                        >
            <AuthnContext>
                <AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</AuthnContextClassRef>
            </AuthnContext>
        </AuthnStatement>
    </Assertion>
</samlp:Response>

Reference Link

The above flow I learnt from an excellent Microsoft page – Azure Single Sign On SAML Protocol – Microsoft identity platform | Microsoft Docs. Without this article, it wouldn’t have been possible to understand this under the hood.

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?

Thanks,
Aresh Sarkari

Tags: , , , , , ,

Stop syncing Disabled user accounts into the VMware Workspace ONE Access – Directory Sync

6 Sep

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

Add the filter to exclude the disabled users:

userAccountControl – contains – 514
Note – 514 = Disabled Accounts

userAccountControl – contains – 66050
Note – 66050 = Disabled, Password Doesn’t Expire

Note – I found this helpful blog which described all the UAC attributes/values in detail – UserAccountControl Attribute/Flag Values | Jack Stromberg

WoA – 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.

Thanks,
Aresh Sarkari

Tags: , , ,

Upgrade VMware Identity Manager 3.3 to VMware Workspace ONE Access 20.01

28 Apr

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.

VIDM TO WoA Upgrade Approach

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.

High-Level VIDM to WoA Upgrade Architecture

Observations from the upgrade

  • Check the VMware Product Interoperability Matrix and Product release notes at least two times before working upon the 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.

Upgrade VIDM to WoA mind map.
Offline Upgrade VIDM to WoA – Mind Map
offline-upgrade-vidm-3.3-to-woa-20.01.1Download

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.

Thanks,
Aresh Sarkari

Black Screen on mobile devices during logon – VMware Horizon and VMware Workspace One

17 Dec

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:

powercfg -change -monitor-timeout-ac 0
powercfg -change -monitor-timeout-dc 0

(Note – Here 0 means Never)

ScreenSettings

Power and Screen Settings – Windows 10

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.

Thanks,
Aresh Sarkari

Continue reading →

Tags: ,

VMware EUC – Horizon, UAG, VIDM and AppVolumes – NSX Load Balancing – Health Check Monitors

2 Feb

There is no single place to find a consolidated list of Load balancer health check monitors (aka Service Monitors in NSX) for the VMware EUC products:

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.

UAG Service Monitor

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.

VIDM Service Monitor
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.

image
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.

AV Service Monitor

I hope you will find these monitors useful in monitoring the VMware EUC products.

Thanks,
Aresh Sarkari

Tags: , , , , , , , ,