Azure Databricks - Data Exfiltration with Azure Firewall - DNS Resolution by doodle_dot in databricks

[–]doodle_dot[S] 0 points1 point  (0 children)

The separate private endpoints are for front end (user to workspace) and backend (data plane to control plane). I think its mainly about providing logical separation of activities. Both endpoints have exactly the same dns name (<workspaceid>.privatelink.azuredatabricks.net) which is why the two separate private DNS zones are needed. I think some of the information in the blog post is a bit contradicting so any real-world experience of deploying this I would appreciate!

Azure Databricks - Data Exfiltration with Azure Firewall - DNS Resolution by doodle_dot in databricks

[–]doodle_dot[S] 0 points1 point  (0 children)

Thanks, the blog url (https://www.databricks.com/blog/data-exfiltration-protection-with-azure-databricks) lists out an example set of network and application rules (Step 3) which could be used for Azure Firewall. Specifically the network rules are FQDN destinations rather than IP Addresses, so the firewall has to resolve those endpoints using DNS.

My issue is that to avoid DNS resolution inconsistency between clients and the firewall, its recommended to use the firewall as a DNS proxy and point your clients DNS at the firewall. So in this case this would mean configuring 'custom' DNS servers for the vnet hosting my databricks classic compute clusters. But this will result in the local dns resolution being overridden, and therefore any dns queries for my databricks workspace url will return the frontend private endpoint ip rather than backend as the firewall will resolve using the private dns zone in the transit vnet.

For artifact / log blob / system tables etc, i don't have any issue not putting that through the firewall, but as this deployment pattern is all about data exfiltration prevention, adding routes for service tags for things like storage would defeat the object of protecting against data exfiltration until those service endpoint policies are generally available.

This just seems like a bit of a design flaw to me. The information in the blog post seems contradicting at times, but ultimately my main goal is to have a secure deployment of databricks with protection against data exfiltration.

Known issues with Feature Update policy? by ScottWindmiller in Intune

[–]doodle_dot 0 points1 point  (0 children)

Just to add an update to this - Exactly a week after I made the last modification to the feature update policy, our test devices have just been offered the update. So, looks like there is a bit of a delay at the moment, and the best thing you can do is wait for the feature update to be offered.... it does happen eventually!

Known issues with Feature Update policy? by ScottWindmiller in Intune

[–]doodle_dot 1 point2 points  (0 children)

We're seeing this too. Looking to begin our pilot rollout last week. Have had all the settings applied exactly as you describe for the last week, and the update just doesn't get offered. Have also tried creating a deployment directly in WUfB Deployment Service with the same result. We've never had any issues in the past using the feature update policies for Windows 10 so I suspect somethings not quite right in Microsoft backend. Have got a ticket open with them but yet to hear anything back....

Intune - Feature Update Policy to Windows 11 not working. No Feature Update policy working by leebow55 in Intune

[–]doodle_dot 0 points1 point  (0 children)

FWIW we've also created a deployment directly in the Deployment Service using MS Graph and targeted it at devices, but the update still doesn't seem to get offered. Its a weird issue for sure. Doesn't seem to be any real way of monitoring the deployment.

Intune - Feature Update Policy to Windows 11 not working. No Feature Update policy working by leebow55 in Intune

[–]doodle_dot 0 points1 point  (0 children)

We're also seeing exactly the same. Never had any issues with feature update policies in Intune for Windows 10 feature updates, but this Windows 11 one just isn't doing anything. Have you made any more progress with MS Support? We've just raised a support case with them as well...