The best explanations of the most complex terms and concepts in the most simple way, hats off Sir for all your videos, God bless you and your family, keep making lots and all kinds of technical videos on Azure, AD and everything, sending best wishes from Kolkata, West Bengal, India 🇮🇳
Fantastic Video, thank you very much for this. Is there any further documentation on the Branch Office IPSEC connection to SSE other than the high level overview? I am particularly interested in this, may change our entire WAN strategy. Thanks again!
Hi, thanks for feedback - I will shortly be releasing a video on setting up a VNG in Azure for testing the branch office scenarios. It would give you a great test environment. At the moment branch office only works for M365
@@john_craddock one point to cover on the Private Access and SSE will be how it behaves globally. Particularly in countries with minimal Microsoft coverage such as China. Will these types of countries be recommended to roll this out?
Fantastic video John. Super helpful. Presumably for resources that are not on-prem, there will be another way to allow access? ie tunnelling to AWS VPCs. Unless the private access piece here also accepts public ips and public FQDNs.
ah interesting, this sounds very similar to Netskope. They use something called a publisher which also sits inside your AWS VPC or azure vnet.@@john_craddock
Wondering if this service will work with scenario where access needs to be provided to VNET in Azure to access private endpoints for various Azure services, did not see during the video this scenario being discussed as supported since this scenario does involve some DNS resolution modification and possible some SSL issues
Hello @artisticcheese, I haven't tried this scenario. However, if you can connect to those resources from a server on your VNET I think it should be possible.
@@john_craddock Well, the point of this setup is that end users from their desktop shall be able to connect to those resources (full VPN replacement), you fell this will not be possible in such scenarios?
@@artisticcheese all I saying is I haven't yet tried connecting to all Azure resources. If the preview is of interest to you I suggest you set up a test environment and evaluate it's capabilities.
There will be other GSA clients made available by Microsoft, remember this is in preview and a work in progress. Today, for other clients, using the M365 Profile you can use the branch office setup.
Great content! Appreciated! What I don't get: In private access setting: How does an remote client without any vpn connectivity or something even know under which IP a service is reachable? Would I have to put them into public DNS with their RFC1819 IP? Thank you very much!
Thanks for the feedback and your great question! The answer is that it's done through the power of cloud magic! The private access app is published via an Entra ID (Azure AD) Enterprise application. QuickAccess is one of those apps, and it is a temporary (transitional) app for providing access to multiple private apps. Eventually, you will want to end up with a one-to-one or selective one-to-many relationships. With one enterprise app representing one private app, you can have different CA policies and permissions for each private app. When you publish the private app, you publish the path FQDN or IP(s) and port(s), and those FQDNs and IPs are private to the environment where the private app resides. They must be resolvable by the proxy connection endpoint. The system then published the details of a private app into the private traffic profile. That profile is downloaded by the client, and the GSA client then knows to send traffic for the private IP or FQND to the Security Service Edge (SSE). After completing all the security checks, the SSE will send the traffic to the appropriate endpoint. Hopefully, after reading this, you know the answer to your second question is No!
I see - great. Thank you so much 😊 Digging somewhat deeper there are more questions coming to my mind 😅: Does the whole private access setup work with a Windows Hello for business Cloudtrust / AzureAD Kerberos implementation? As there won't be line of sight for a remote device to the DC / DNS / KDC. Testing the private access functionality I was able to access an on-prem MS SQL server with Windows authentication just fine - but only when using password. The same test while using PIN / Fingerprint failed with some "SSPI context" error. I guess that might be because of the missing line of sight to necessary AD resources? But I'm not too sure on that. 😅 Any idea on that topic that would be very much appreciated. Great work! 😊
Thanks - so helpful. 😊 A kerberos implementation would be really awesome - as the majority of on prem services to "publish" via private access might just depend on it. Please keep us up to date and keep up the great work!
We've been working to set this up for our users, and have beat our head against the wall for 2 days, we're not clear on what we are doing wrong. Do you offer any consulting services for business?
HI, first of all: Thank you. In Privat Access what i dont get is how internal urls work. if i have app.contoso.local, do i have to use hosts file or similar or does the SSE client resolve the url to the ip?
H @matzegalaxy7470i, the private access network profile is picked up by the GSA client. The client then knows to send traffic for the published private apps to the SSE. The DNS fqdn is resolved by the private connector endpoint. - I hope that helps John
