I have previously blogged about Entra ID Private Access for use to access various services https://msandbu.org/ztna-for-azure-private-endpoint-using-entra-private-access/ however lately I have configured it for a customer environment to provide remote access for external access for remote users. Therefore I decided to do a write-up on how we solved / designed it.
Historically we have been using Citrix to provide remote access to a Intune and AD device using much of the same configuration guidelines that were defined here –> https://learn.microsoft.com/en-us/security/privileged-access-workstations/privileged-access-deployment. However this scenario was already a bit outdated and did not take into the consideration of Zero-trust based network access to internal services, but having a high focus on locking down the workstation itself.
Therefore we wanted to make a bigger chance, firstly since we noticed that Citrix has had a lot of security vulnerabilities the last years, which itself poses a risk with external access and what if the Citrix services was hacked using a vulnerability and they were able to reach into the secure workstations? so we decided to take another approach, were we combined Windows 365 and Entra ID Private Access to provide remote access to internal services.
The big picture it looks like this. The reason for Windows 365 was that it could provide access from “approved” machines, without requiring it to install the GSA client. The Windows 365 was managed and locked down using Intune with configuration settings and the GSA client was installed on there. Access to Windows 365 machines itself could only be done by a selected Entra ID Group using Conditional Access.
All access to internal services inside the Windows 365 machine required that the GSA client was running, also that depending on which zone you were accessing you also required to elevate access using PIM to get access. This was depending on what kind of Tier you were trying to access.
One question that came up, couldn’t we just use secure Windows 365 machines without Private Access? Well we could, but it would require the Windows 365 machines to have access directly on a networking level.
All these applications that were published interally also required a device filter to lock down access from Windows 365, using device filters. This is to restrict access only from Windows 365 machines and not from “any” machine. Also the client is only supported from enrolled machines, which would also limit the use.
So depending on which application or service they needed to access they would need to go trough private access, this ensures that there is no direct link to other internal services since only defined traffic will go over the link, secondly since there is no integration with Active Directory there is no direct LOS to domain controllers. Also with traffic trough private access gives us specific logs on which applications, users and connectors that was used.
One problem that we faced was the many tools we used required some form of DC connectivity to provide SSO, so in some cases the Private Access link was then used to jump to another internal server which only allowed communication from the connectors. Each of these services that the operators needed to reach was configured in Enterprise applications and depending on tier and location a separate connector was deployed.
And if someone tries to access an internal service without PIM they will get this error message, stating that they do not have access.
Then using PIM and group based access they can elevate access when needed. This gives us insight and traceability when they elevate access and when application access is done trough private access.