chrome enterprise premium
6 TopicsDnsOverHttpsTemplatesWithIdentifiers forcibly hashes all variables, making them useless
Hi folks, This post relates to a recent change in the DnsOverHttpsTemplatesWithIdentifiers setting, which appears to no longer allow for plaintext variables to be passed to the DNS-over-HTTPS resolver, and everything is now forcibly hashed, with no ability to turn this off and restore original behavior. While I understand the reason for this, when it comes to public DNS resolvers, this change now poses a major hindrance to end users who use private DNS resolvers, and WANT to pass plaintext identifying information (USER_EMAIL specifically) to the DNS-over-HTTPS resolver, so they can see who is responsible for the DNS traffic on the other end, in the Analytics and DNS logs that are streamed into the SIEM. Considering DNS payload is already encrypted (DOH is used) and the org admin wants to see the plaintext identifiers, this poses a major UX issue since now they cannot correlate activity easily, and requires creation of mapping files, and constant need to sync them out of band. Without this, you see useless hashes that don't serve a purpose. We feel there should be a setting that allows the admin of an organization to pass plaintext identifiers if they so choose to, as it poses no security issues for private DNS resolvers, over HTTPS. Are there any plans to restore this original behavior, or at least offer a setting to allow it to behave as it did before, and not hash these variables? Thanks147Views2likes5CommentsChrome Enterprise Premium
I'm really interested in adopting this for our business but am wondering how many businesses in this group have already adopted it but more importantly what are the top two/three security benefits or productivity gains being realised that justify the monthly cost.28Views1like0CommentsClarification on Google Workspace Context-Aware Access vs Chrome Enterprise Premium Context-Aware Access
Hi everyone, I’m hoping to get some clarification on the differences between Google Workspace Context-Aware Access (CAA) and Chrome Enterprise Premium Context-Aware Access. From what I understand, both allow conditional access controls based on user, device, and context, but I’m not fully clear on where the separation lies between them. For example: Does Workspace CAA mainly govern access to Google Workspace apps like Gmail and Drive, while Chrome Enterprise Premium CAA extends those controls to managed browsers and web apps? How do policy management and enforcement differ between the two? Are there separate admin configurations, or do they integrate within the same console? I also noticed that Context-Aware Access now supports OIDC, and that CAA for OIDC apps can be configured at the OU level. Does this capability apply to both Workspace and Chrome Enterprise CAA, or is it specific to one of them? If anyone has experience managing both solutions — or can share any official documentation that clarifies the distinctions — I’d really appreciate your insights. Thanks in advance,233Views0likes1Comment