Tag Archives: VMware Workspace ONE Access

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: , , ,

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: , , , , , , , ,