Tag Archives: Azure Active Directory

Restrict Cloud Apps (ServiceNow, GitHub Enterprise, Atlassian Cloud & Office 365) access to Windows 365 Cloud PC/Azure Virtual Desktop

15 Dec

A good security practice would restrict the access of business-critical applications only to trusted devices within the organizations. On personal and untrusted devices, there should deny access to business applications. This strategy helps in Data Loss Prevention and company information compromise, which is vital in today’s landscape.

In our scenario, we will allow Access to Cloud Apps – ServiceNow, GitHub & Atlassian Cloud only on the Windows 365 Cloud PC/Azure Virtual Desktop (AVD) and all other devices will block access. To achieve this outcome, we shall be using Azure Active Directory (AAD) Conditional Access Policies & further use device filtering on “Cloud PC”


  • You have Enterprise Apps integrated with Azure Active Directory (ServiceNow, GitHub Enterprise, Atlassian Cloud & Office 365)
    • Make sure these applications are working with Azure AD credentials and assigned multi-factor authentication
  • Azure AD Group with end-users to whom you want to apply the restrictions
  • Necessary Azure AD P1 or P2 license

Portals on AAD Conditional Access Policy (CAP)

Following are all the portals where you can configure the CAP via different consoles. However, the outcome is going to be the same.

Microsoft Endpoint Manager admin Center (Microsoft Intune)

Azure Portal – Azure Active Directory – Security – Conditional Access

Microsoft Entra admin center

New Policy

Details of all the configurations we are entering within the policy and followed by screenshots:

  • Name of the CAP – Restrict CloudApps access to CPCs
  • Assignments
    • Users or workloads Identities – AAD group, called Win365-Users
    • Cloud apps or action
      • Include – Select – ServiceNow, GitHub Enterprise, Atlassian Cloud & Office 365
      • Exclude – Select – Windows 365, Azure Virtual Desktop and Microsoft Remote Desktop
    • Conditions – Filter for devices – We are selecting model ‘Cloud PC’
  • Access Controls – Block Access
  • Enable Policy – Report-only

AAD Group used for restrictions

Inlcude Cloud Apps (ServiceNow, GitHub Enterprise, Atlassian Cloud & Office 365)

Exclude Windows 365 and AVD

Conditions (Select Model Cloud PC)

Access Controls (Block Access)

Before rolling out in production at this phase, only use the report-only mode. Once satisfied with your testing, you can select Enable Policy – On. Final click on Create

Insights & Reporting

You can notice my user name shows the blocking policy is applying when I access the CloudApp -Office365 from a personal device.

I hope you will find this helpful information for restricting Cloud Apps access to only Cloud PC. Please let me know if I have missed any steps or details, and I will be happy to update the post.

Aresh Sarkari

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.


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"


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>


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"


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:

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

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"
    <Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">https://sts.windows.net/se13edsadsadasdasdasd2342342dasdas/</Issuer>
        <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" />
    <Assertion xmlns="urn:oasis:names:tc:SAML:2.0:assertion"
        <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
                <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">
                        <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
                        <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
                    <DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256" />
            <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"
        <Conditions NotBefore="2021-08-04T02:34:04.318Z"
            <Attribute Name="http://schemas.microsoft.com/identity/claims/tenantid">
            <Attribute Name="http://schemas.microsoft.com/identity/claims/objectidentifier">
            <Attribute Name="http://schemas.microsoft.com/identity/claims/identityprovider">
            <Attribute Name="http://schemas.microsoft.com/claims/authnmethodsreferences">
            <Attribute Name="email">
            <Attribute Name="ExternalID">
            <Attribute Name="userName">
            <Attribute Name="userPrincipalName">
        <AuthnStatement AuthnInstant="2021-08-04T02:38:59.239Z"

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?

Aresh Sarkari