Entra - Internet Access for Windows (A first look)
In succession to my previous blog post on Microsoft Entra Private Access, today, we'll be focusing on its counterpart, Microsoft Entra Internet Access. Entra Internet Access is an identity-aware Secure Web Gateway (SWG) solution for cloud-based (Saas) applications and the wider internet, which works to protect against malicious internet traffic, undesirable content, and various threats from the open internet.
This blog post is the second in a three-part series where we will be taking a first look into the different components of the new Microsoft Global Secure Access (SSE) solution:
2. Entra Internet Access (You're here now)
3. Entra Internet Access for Microsoft 365 (Coming soon)
If you didn't know already, Microsoft's newly announced SSE solution comprises two fundamental components, one being Microsoft Entra Private Access and the other being Microsoft Entra Internet Access, the prior offering a modern cloud-based replacement to VPN connections to provide remote access into internal and on-premises resources, and the latter offering a cloud-centric proxy service for the wider Internet and Microsoft 365. The SSE solution also encompasses Defender for Cloud Apps and bridges that previously treacherous gap between Network Access and Identities by fully integrating with Microsoft Entra and Conditional Access. Additionally, as we've grown to expect with anything Microsoft cloud-oriented, the solution also leverages a single-pane-of-glass and zero-trust approach to securing, validating, and managing Network Access alongside the Identities accessing those encompassing private & public resources.
Entra Internet Access works to secure and protect end-user access to the wider Internet, whether that translates to general web traffic and browsing, accessing cloud-based SaaS applications, or non-interactive web traffic. This security effort protects organisations against internet threats, malicious network traffic, and generally unsafe and undesirable content. The service does this by simplifying and modernising traditional network security to protect users, apps, and resources using advanced mechanisms of web filtering. Web Filtering can be targeted categorically, i.e., via pre-defined categories such as "Gambling" or "Social Media", but can also be implemented at a granular level by specifying Fully Qualified Domain Names (FQDNs) and URLs, which also support wildcards. All web traffic is subsequently tunnelled through the SSE solution via the Global Secure Access agent which is to be installed across end-user clients, or can alternatively be tunnelled through the remote networks capability which represents on-premises networks that have been directed through the Global Secure Access endpoint. It's highly recommended that the Global Secure Access agent is adopted and installed on endpoints where possible.
Microsoft's Internet Access solution also seamlessly integrates with identity-centric access controls, such as those integrated into and with Entra ID, which extends the capabilities of Conditional Access to any external destination, website, or SaaS application, even those not federated with Entra ID, introducing granular device, user, network, and sign-in risk conditions for internet access.
Additionally, thanks to Microsoft's globally distributed proxy service which is backed by their private wide-area network, the number of necessary network hops is reduced so that traffic routing to and from external resources and applications is optimised, providing best-in-class performance whilst eliminating single points of failures for inbound and outbound access to the internet.
Internet Access can also prevent malicious and inadvertent data exfiltration for Microsoft 365 applications through advanced cross-tenant protection capabilities such as Tenant Restrictions v2 and other data loss prevention capabilities. Additionally, Internet Access also offers protection from token theft and can prevent users from bypassing the Secure Service Edge solution through the use of the new "Compliant Network" metric within Conditional Access, facilitated by the Global Secure Access solution. However, both of these components are more suited to Internet Access for Microsoft 365, which will be covered within the third and final blog post within this series and not in this particular post.
Finally, Microsoft Entra Internet Access doesn't necessarily have to be implemented as a sole solution or full replacement for a third-party service as it can be deployed side-by-side with non-Microsoft SSE products too, enabling an administrator to decide when to rely on Entra Internet Access along with its native integration with Microsoft 365 identity & security controls, and when to direct other traffic through an existing SSE solution that may be in situ.
All sounds cool, right?
Let's jump into Microsoft Entra Internet Access: -
Prerequisites
Licensing Whilst Entra Internet Access is in Public Preview, only Microsoft Entra ID P1 licenses are required. At the time of writing, we are still uncertain about how the licensing model will look once the solution transitions into general availability, so watch this space.
Device
At the time of writing, devices must be running a 64-bit version of Windows 10/11, and must either be Hybrid Entra ID Joined or Fully Entra ID Joined.
Network There are a few requirements from a networking perspective that must be met to ensure a successful implementation of Entra Internet Access. DNS over HTTPS (Secure DNS) must be disabled to tunnel traffic based on the defined rules (FQDNs) within the configured traffic forwarding profiles. For more information, see Configure the DNS client to support DoH. Additionally, built-in DNS Clients for Chrome and Edge should also be disabled. Further information on these prerequisites can be found here: - How to configure Global Secure Access (preview) Web content filtering - Global Secure Access | Microsoft Learn
Provisioning the Service
The first step within the process oversees the initial enablement of the wider Global Secure Access service within the tenant.
1. Within the Microsoft Entra blade, navigate to Global Secure Access, and then click "Get started". Once greeted by the "Welcome to Global Secure Access" page, verify you meet the defined prerequisites within Section 1, and then click "Activate" under Section 2.
2. Once the service has been activated, navigate to Global Secure Access again, expand "Connect", and then click "Traffic Forwarding". Within the Traffic forwarding page, enable the "Microsoft 365 access profile" and the "Internet access profile".
3. To benefit from full Conditional Access integration with Entra Internet Access, as well as integration with Continuous Access Evaluation and Identity Protection, all of which are highly recommended and fundamental components & benefits of the SSE solution, Source IP Restoration will need to be enabled.
Source IP restoration restores the source IP addresses from the original egress IP, which in turn improves security logs such as those in Entra ID sign-in logs, and upholds integration with Conditional Access components such as Named Locations, as well as Identity Protection elements such as location-oriented risks.
To enable Source IP restoration, still within the Entra blade, navigate to Global Secure Access, expand "Global Settings", and then click "Session Management". Once within the Session Management page, select the "Adaptive Access" tab, toggle to "Enable Global Secure Access signalling in Conditional Access", and then click Save.
Configuring Web Content Filtering policies
Now that the service is provisioned, it's time to define our web content filtering policies. Web filtering policies are essentially logical groupings of different web content, either defined via their Web Category and/or Fully Qualified Domain Names (FQDNs). Each defined policy also has a configurable action assigned to it, of either Allow or Block, which does exactly as you'd expect, permits or forbids the in-scope traffic defined within the policy.
At present, there are over 70 web categories to choose from, such as Social Networking, Gambling, Chat, Games, and Malware, as well as plenty of categories to target Adult, Illegal, and Legal Liability type content.
Finally, it is possible for one single web content filtering policy to host multiple rules, such as multiple web categories and/or multiple FQDNs.
In this example, we will create four separate policies for illustrative purposes: -
Policy 1 (Block - Social Media) =Â Blocks access to all Social Networking websites.
Policy 2 (Allow - LinkedIn) = Allows access to LinkedIn.
Policy 3 (Block - Games & Gambling) = Blocks access to Gaming & Gambling websites.
Policy 4 (Allow - Marketing Social Media) = Allows access to Instagram & Facebook.
1. Within the Microsoft Entra blade, navigate to Global Secure Access, expand "Secure", and then click "Web content filtering policies". Within the Web content filtering page, click "Create policy" to start defining our first policy.
2. Enter a name for the Web Content Filtering policy you are configuring, preferably something that correlates & makes sense with the content being targeted and the desired action for it. In this first example, as we're configuring Policy 1 to block Social networking websites, we will call it "Block - Social Media".
Next, define the preferred Action for the web content policy, which will either be: -
Allow =Â Will allow access to the specific web content.
Block = Will block access to the specified web content.
As we'll be blocking access to Social Media within this policy, we'll select the Action "Block".
Optionally, you can also specify a useful description for the policy.
3. Within the "Policy Rules" tab, click "Add Rule".
4. Within the fly-out window pane, enter a useful and relatable name for the rule. In this example, we will go with "Social Media" as this is the content category we will be targeting within this rule.
Once a name has been defined, we need to determine the type of destination, which at the time of writing, can be either of the following: -
webCategory =Â Allows you to select from a generous number of pre-defined Web Categories.
fqdn = Allows you to manually enter the Fully Qualified Domain Name/s of the external resource in question, such as the website domain name/s, inclusive of wildcards.
In this example, we'll select "webCategory".
5. As we've chosen the "webCategory" destination type, we now need to review and select any suitable pre-defined web categories. In this example, we have searched for the term "social" and then have selected the returned "Social Networking" web category as this makes the most sense for our requirements.
6. Once all the required content has been defined within the web content filtering policy, bearing in mind you can have multiple rulesets within one policy by repeating steps 3-5 as many times as required, click next to progress to the "Review" tab.
7. Within the "Review" tab, review the configured web content filtering policy and then click "Create policy" to complete the process.
8. We'll now repeat steps 1-7 to create the remaining Web Content Filtering policies outlined at the beginning of this section.
Allow - LinkedIn
Block - Games & Gambling
Allow - Marketing Social Media
9. Now that we've configured all our necessary Web Content Filtering policies, we can move onwards to the next section.
Creating Security profiles
In this section, we'll be defining and configuring the next step of the solution, being Security Profiles. Security Profiles are essentially groups of Web Content Filtering policies (the policies we configured in the previous section) and are required to assign and deploy the solution to end-users via Conditional Access, which is what will be enforcing the controls we've specified. These profiles can contain multiple web content filtering policies, and one profile can be assigned across multiple Conditional Access policies; however, each Conditional Access policy can only have one profile assigned at a time.
There's a pivotal metric that we must be aware of when configuring and managing Security Profiles which is the "priority" metric. Security profiles themselves have a priority assigned at the overarching profile level, but so do each of the encompassing Web Content Filtering policies too. By leveraging priorities we can prevent conflicts whilst also ensuring that the correct and expected access is always granted and/or blocked as per design for each user.
The priority metric at the Security Profile level controls which Security Profiles should take precedence over other profiles when multiple are present & deployed to users, and priorities at the Web Content Filtering policy level control which policy should take precedence over others when multiple are present within the same security profile.
It's recommended to start defining priorities at a number higher than 1, such as 100, as well as to leave a reasonable gap between subsequent priorities thereafter, such as gaps of 100. This enables administrators to easily manage, tweak, and add configurations in the future without having to completely structure the implementation, essentially future-proofing it for new requirements. It's important to remember that the lower the number, the higher the priority - For example, a priority of 100 will always take precedence over a priority of 200.
Finally, it's important to note that the last possible priority number of 65000 is considered the "default" priority and the one profile/policy you choose to assign with this priority will automatically be deployed to end-users by default without it needing to be assigned to a Conditional Access policy. Like any other priority value, you can only have one of these priorities. This is the only priority level that will behave like this, therefore, all other profiles will need to be linked to Conditional Access policies to be deployed.
In our example, we will configure the following Security profiles: -
This configuration will block Social Media, Gaming, and Gambling web content for the entire company by default via the Security Profile that leverages the default 65000 priority. However, there will be an exception for the Human Resources & Marketing departments, where the former will have access to LinkedIn and the latter will have access to Instagram and Facebook. This is primarily facilitated by the prioritisation of the Security Profiles defined above, as well as the future deployment of Conditional Access which will be scoped to only the users within each department, ensuring only those users are permitted to access the defined exceptions.
1. Within the Microsoft Entra blade, navigate to Global Secure Access, expand "Secure", and then click "Security profiles". Within the Security profiles page, click "Create profile" to start defining our first profile.
https://entra.microsoft.com/#view/Microsoft_AAD_IAM/AppProxyOverviewBlade/fromNav/globalSecureAccess
2. Enter a name for the Security profile, preferably something that makes sense with the content you are targeting, and if suitable, perhaps the department/users you are scoping. In this first example, as we're configuring the first Security Profile for the HR department, we will call it "Human Resources".
Next, determine whether the profile should be enabled or disabled - As we want to utilise this policy later, we will choose "enabled".
Finally, specify a desired priority for the Security Profile, bearing in mind the best practice approach and information specified at the beginning of this section. Remember, this is the priority for the entire Security Profile itself.
Optionally, you can also specify a useful description for the policy.
3. Moving onto the "Link policies" tab, click "Link a policy".
Here, there are options to either create a new Web Content Filtering policy if required, or choose an existing one that has already been defined. As we've already configured our Web Content Filtering policies, we'll select "Existing policy".
4. Within the fly-out window pane, we'll use the "Policy name" dropdown to select an existing Web Content Filtering policy which we've previously defined. In line with our intentions defined earlier for this Security Profile, we'll select "Allow - LinkedIn".
Next, we'll specify a priority for the Web Filtering rule itself within this profile, again whilst aligning with the best practice approach and instructions specified at the beginning of this section. Remember, this is separate from the priority assigned at the Security Profile level in that it only applies to the rules within this profile if there are multiple.
Finally, we'll choose an "Enabled" state for the rule.
5. Once all the required content has been defined within the Security Profile, bearing in mind you can have multiple content filtering policies within one Security profile by repeating steps 3-4 as many times as required, click next to progress to the "Review" tab.
6. Within the "Review" tab, review the configured Security Profile and then click "Create policy" to complete the process.
7. Â We'll now repeat steps 1-6 to create the remaining Security profiles we outlined at the beginning of this section.
Marketing
Default All Company
8. Now that we've configured all the necessary Security Profiles for our use case, we can move onwards to the next section.
Conditional Access
This next section covers Conditional Access, specifically relating to the deployment, assignment, and scoping of the previously configured Security profiles, each of which contains our defined Web Content Filtering rules. Except for the default Security profile (if present and configured) which has a priority of 65000, all Security Profiles must be deployed via Conditional Access to take effect. The capability of Conditional Access that we're particularly interested in to scope these profiles is the "Session Controls" section.
So far, we've touched on using Conditional Access to deploy the Security profiles to end-users, and therefore, the web content filtering capability, which is the primary use case we're focusing on. However, as we are leveraging Conditional Access, we can also take advantage of the numerous other controls it offers. For example, we can benefit from its granularity and conditions, such as the ability to assign subsets of profiles to different users and groups, the ability to deploy different policies per device type, and even enforce minimum requirements around sign-in risks.
However, it's critical to understand that "Grant" controls are not generally recommended for Entra Internet Access as they don't have the desired effect when put in front of Security Profiles & Web Content Filtering policies - At least at the time of writing - For example, enforcement of a compliant device or the enforcement of MFA would only take effect for the first connection to the SSE Service / Internet, and not for the specifically or individually targeted web content. This same concept applies to the grant vs. block control, where explicit grant should always be used even if the desired outcome is to block the in-scope web content. This is because the web content filtering rules will take care of any blocking of content as per their configuration, whereas the CA policy only cares about the actual deployment and enablement of any linked profiles and policies.
At a basic level, excluding any optional conditions and granularity controls, this is how Conditional Access policies "should" look when they are being used for Entra Internet Access, specifically to deploy Security profiles / Web Content Filtering policies: -
Users =Â Should reflect the desired users and/or groups for the Security Profile which will be linked later.
Target resources = Should reflect the "Global Secure Access" resource with the "Internet Access" traffic profile selected.
Grant = Should be configured to "Grant" only, not "Block", and as described previously, any controls within Grant are not generally recommended.
Session = Should reflect the desired Security Profile within the "Use Global Secure Access security profile" option.
Finally, the Entra SSE / Global Secure Access solution also introduces a new option within the Location condition of Conditional Access, being "All Compliant Network locations". This condition essentially enables an administrator to include or exclude compliant network locations within a Conditional Access policy, which in turn helps protect against token protection. For example, an organisation could block all non-compliant network locations from accessing their Microsoft 365 resource and applications along with federated third-party SaaS applications. This compliant network metric automatically incorporates the traffic traversing through the Global Secure access solution but only for your tenant / instance and users - This traffic can originate from clients themselves via the installed Global Secure Access agent, or via remote networks which represent on-premises networks that have been directed through Global Secure access. We'll delve into this compliant network metric further when we explore Internet Access for Microsoft 365, which will be covered in the third and final blog post within this series.
For this walk-through, we'll create 2 conditional access policies as outlined below. Remember, we do not need a Conditional Access policy for the "Default All Company" Security profile with the 65000 priority as this deploys to all users by default without assignment.
1. Within the Microsoft Entra blade, navigate to "Protection" and then click "Conditional Access". Within the Conditional Access blade, click "Create new policy" to start defining our first policy.
2. Within the new Conditional Access policy wizard, we'll start by defining a useful name for the policy, which in this case will reflect our first web content filtering policy for the HR department.
Next, within the "Users" section, we'll scope the policy to an Entra ID security group that only has HR employees as members.
3. Within the "Target resources" section, we'll select the "Global Secure Access" resource, and then the "Internet traffic" profile underneath.
4. Within the "Conditions" section, you can optionally choose to further scope and/or specify additional conditions that should be met for the policy to apply. For example, you may want this policy, and therefore the assigned Security profile / Web filtering policy, to only apply to specific device platforms such as Windows.
5. Within the "Session" section, locate the option "Use Global Secure Access security profile", and then select the Security Profile that should be deployed / scoped within this policy. In this case, as we're targeting the HR department still, we'll select the "Human Resource" Security profile that we defined previously.
6. Finally, review the configured Conditional Acces policy, and once content, enable it and then click "Create".
7. We'll now repeat steps 1-6 to create the second and final Conditional Access policy which we outlined at the beginning of this section.
Web - Marketing
8. Now that we've configured all our necessary Conditional Access policies, we can progress onwards to the next section.
Deploying the Global Secure Access client
The final step before we can test & prove our Internet Access implementation is to deploy the Global Secure Access client to our end-user endpoints.
Much like most clients and applications, the Global Secure Access client is no different in that it can be downloaded and installed manually per device but also deployed centrally via tooling such as Group Policy, Microsoft Endpoint Configuration Manager (MECM), and Intune.
In this example, we are going to use Intune along with the Win32 Application Management & packaging capability to deploy the Global Secure Access client to our test device.
1. First, within the Microsoft Entra blade, source the Global Secure Access client for Windows by navigating to Global Secure Access, expanding "Connect", and then clicking "Client download". Within the Client download page, expand "Windows" and click to download the listed client.
2. Once downloaded, use the Win32 Application Management capability to package the downloaded client executable. If you're unsure of how to use the Win32 Application Management tool, please refer to Microsoft's documentation here: - Prepare a Win32 app to be uploaded to Microsoft Intune | Microsoft Learn
3. Once successfully packaged, upload & add the newly bundled .intunewin file to Intune as a Win32 Application. Again, if you're unsure how to do this, please refer to Microsoft's documentation here: - Add and assign Win32 apps to Microsoft Intune | Microsoft Learn
Within Intune, navigate to the Windows Apps page and click "Add".
4. Within the fly-out pane, select "Windows app (Win32)" as the application type.
 5. Next, upload the newly bundled .intunewin file to the application by clicking "Select app package file" and then using the fly-out pane to browse and upload the file in question.
6. Within the "Program" tab, enter the following as your commands: -
Install command = GlobalSecureAccessClient.exe /quiet
Uninstall command =Â GlobalSecureAccessClient.exe /uninstall /passive /quiet
Additionally, set "Allow available uninstall" to "No".
If you'd like to specify any other supported arguments within either command, please refer to the below: -
7. Within the "Detection rules" tab, specify the following: -
Rules format = Manually configure detection rules
And then add a new rule using the following information: -
Rule type = File
Path = C:\Program Files\Global Secure Access Client
File or folder =Â GlobalSecureAccessTunnelingService.exe
Detection method = File or folder exists
Associated with a 32-bit app on 64-bit clients =Â NoÂ
8. Finally, populate any other required/optional tabs & fields as per requirements and then assign & deploy the application to the desired users or devices accordingly.
Upon a successful deployment and installation, the end-user will be prompted to authenticate with their M365 Credentials. These credentials should already be populated if the endpoint is either Entra ID or Hybrid Entra ID joined, so the user will just simply need to click the relevant pre-authenticated account. This will only occur upon the initial completion of the installation.
9. Finally, we can further verify a successful install by navigating to the Quick Access tray and verifying that the client is present and running.
Testing Internet Access
Now that the Entra Internet Access solution has been enabled and configured, we're going to test the solution. In this demonstration, we have an Entra ID (Azure AD) Joined endpoint.
As a reminder, please refer to the below configuration definition that we are aligning to: -
1. In this first test, we have a user that is not a member of the Human Resources or Marketing departments, thus they are only in-scope for the "Default All Company" Security profile and encompassing web filtering policies.
As a result, we can see that the user is unable to access any gaming, gambling, or social networking websites: -
National Lottery (Games & Gambling)
LinkedIn (Social Networking)
Instagram (Social Networking)
The above screenshots illustrate the response an end-user receives when attempting to access a forbidden and blocked external resource using the HTTPS protocol. When HTTP is used instead, they receive the following response in place of the above: -
And just to prove that the blocking also occurs in a non-Microsoft Edge browser, we have an example from Google Chrome too: -
2. In this next test, we have a user that is a member of the Human Resource department, thus they are in-scope for both the "Default All Company" and "Human Resources" Security profiles and encompassing web filtering policies.
As expected, because the "Human Resources" Security profile carries a higher priority and precedence over the "Default All Company" profile, the user in HR can successfully access the Social Networking website LinkedIn.com.
3. In this final test, we have a user that is a member of the Marketing department, thus they are in-scope for both the "Default All Company" and "Marketing" Security profiles and encompassing web filtering policies.
As expected, because the "Marketing" Security profile carries a higher weighting and precedence over the "Default All Company" profile, the user in Marketing can successfully access the Social Networking website Instagram.com.
4. And there we have it, we have successfully blocked a sample of undesirable web content for all users by default, whilst also introducing some granular exceptions for specific users and web content where it has been deemed appropriate and necessary.
Reporting & Logs
There are two locations where we can find reporting & log components for Entra Internet Access, one being client-side, and the other being service-side.
Client Logs
Within the "Advanced diagnostics" component of the Global Secure Access client, if we browse to the "Traffic" tab, we gain an overview of all traffic that has recently traversed the Global Secure Access client and solution for this individual endpoint only. From here, we can review the data, collect it, and export it to a CSV.
For example, in the below screenshot, we can see some of the web traffic originating from our previous testing.
Entra Logs
Within the Microsoft Entra blade, navigate to Global Secure Access, expand "Monitor", and then click "Traffic logs". Here, we can gain an overview of all traffic that has traversed the Global Secure Access solution for all connected endpoints, as well as the resulting action. From here, we can review the data and export it to a CSV or JSON file.
The Future
With Microsoft expanding into the Security Service Edge space with cutting-edge services such as Entra Internet Access that seamlessly integrate with their comprehensive Identity (Entra) stack, this is a game-changer when it comes to bridging the gaps between network access, identities, and security - All whilst introducing a single-pane of glass and zero-trust approach. With this in mind, the future certainly looks promising for Entra Internet Access, and we can only expect that the solution will be heavily adopted as time progresses due to its comprehensive approach to network access and security and ease of configuration, management, and deployment.
It is important to note, as always with any technology in preview, that there will be limitations present and potentially further developments or changes planned before the solution reaches general availability. This is only Phase 1 of the solution, meaning there is likely lots more to come. Examples of some new and exciting upcoming features that are still in development can be found below: -
The ability to restrict outbound and inbound traffic based on IP addresses, ports, and protocols using granular policy conditions and context -aware cloud firewall.
The ability to identify and block malicious network activity through Intrusion Detection and Protection Systems alongside threat intelligence to target known malicious endpoints.
The ability to inspect encrypted traffic with granular TLS inspection across TCP and UDP traffic.
Additionally, regarding the Global Secure Access client itself, it doesn't look like it can auto-update itself, which means "manual" input is required to update the client currently, i.e., through superdense rules and/or a series of manual actions. I'm sure this is something Microsoft will introduce later though.
Another benefit would be the ability to silence the initial sign-in / authentication prompt once the client first successfully installs, assuming there is a logged-in user with a PRT Token on a Hybrid-Joined or Fully-Joined Entra ID device.
Finally, what will likely be a make-or-break decision for many organisations is still unknown, and that is the pricing / costing model once the solution transitions out of Public Preview and into General Availability.
In conclusion, this is yet another comprehensive, effective, and easy-to-deploy network access and security solution that integrates seamlessly with the Entra Identity stack - Another welcomed addition to the Entra family!
Comments