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?
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.
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
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!
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.
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
This session comes just at the right time. Great as always. Thank you so much!
Thanks for the feedback
Nobody explains anything as well you, John! Simply love it. Thanks for sharing, this made it worth to figure out what this is already 🙂
Thanks for your kind comment Alexander. It is always great to get feedback, I am really pleased you found it useful!
Wow! Just found your video and I'm very impressed with the quality of the content! Looking forward to more :)
Many thanks for taking the time to leave a comment. I a glad you found it useful.
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 🇮🇳
Many thanks for your comments - I really appreciate you letting me know the videos are useful for you - please keep watching!
Thank You very much John for the awesome session...🙏🙏.
Thank you for watching and sharing your appreciation.
Great session! Thank you so much!
This is another powerful tech from Azure AD / Entra making our apps and data even more secure.
Thanks for the feedback - this is a real game changer from Microsoft!
Awesome session John👍
Thanks Andy, always great to hear from you!
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?
Excellent
Any info regarding the license required to use this features?
Hi @kiranpeteru, thanks for your comment. The licensing will be something Microsoft announces in the future - I'd love to know too!
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.
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.
Thanks for the feedback - you can deploy a proxy endpoint to any cloud service.
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
Is there a SASE element to the solution, for example SD-WAN support for the branch office scenario?
Hi @gvoden, I don't know the Microsoft answer to this, but you manage branch to branch connectivity using site-to-site Azure connectivity.
i am new to your channel its Very impressive
Thanks @muzamilahmed6868, I am glad you like it. Thanks for the comment
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! 😊
No Kerberos at the moment, I am talking with Microsoft this week to see what I can an can't say! Following the NDA for me is really important!
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!
Thank you very much sir.
You are very welcome, I am pleased you found it useful
How about non windows client access ? . We are only taking about windows 10 or 11
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.
Thank you sir.😊
Thank you, I hope you found it useful
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 Matt, I am sure we could help you out on this. Please pop me an email info@xtseminars.co.uk. john
@@john_craddock Thanks so much John! Will do now!
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
@@john_craddock yes, that helped, thanks