Chris Brumm's Blog |

Private DNS Hygiene in GSA — Suffixes, Segments, and the Order Things Resolve In

Why the apex isn't just another subdomain, why a *. in front of a suffix buys you nothing, why DNS suffixes live only on Quick Access, and what a single-label name does to Kerberos — all of it a story about the order name resolution and traffic steering happen in

The previous post was about what happens to a Private DNS lookup on the authentication plane – how, once Private DNS is configured, resolving an internal name becomes an access to the Quick Access app, and therefore something Conditional Access gets an opinion about. This one is about the other half: what you feed into Quick Access in the first place – the suffixes, the application segments, the FQDNs and IP ranges.

When DNS Lookups Trigger MFA — Private DNS and Conditional Access in GSA

Why a sign-in frequency on Quick Access can turn internal DNS lookups into unexpected MFA prompts – and how the profile/Quick-Access split explains it

Back in 2024 I wrote a deep dive on DNS in Entra Private Access, and it turned into one of the posts I still get the most messages about – apparently I am not the only one who finds name resolution in a ZTNA world more interesting than it has any right to be. That post was all about how names get resolved: the NRPT, the 6.6.255.254 forwarder, split DNS, and disconnected environments.

Token Replay Protection and the Compliant Network Check

In this part of the series about the Microsoft Traffic Profile in GSA we discuss the Compliant Network check and token replay scenarios

This post is part of a series on the Microsoft Traffic Forwarding Profile in Global Secure Access: Why you should enable the Microsoft Traffic Forwarding Profile Token Replay Protection and the Compliant Network Check (this post) Universal Tenant Restrictions Coexistence with other Secure Web Gateways Logging If you haven’t read the first post yet, it covers the basics of the Microsoft Traffic Forwarding Profile, how to enable it, and what the four security benefits are: Why you should enable the Microsoft Traffic Forwarding Profile.

Why you should enable the Microsoft Traffic Forwarding Profile

This blog post is the start of my series about the Microsoft Traffic Profile in GSA, covering overview, architecture and deployment

This post is part of a series on the Microsoft Traffic Forwarding Profile in Global Secure Access: Why you should enable the Microsoft Traffic Forwarding Profile (this post) Token Replay Protection and the Compliant Network Check Universal Tenant Restrictions Coexistence with other Secure Web Gateways Logging The case for enabling it The Microsoft Traffic Forwarding Profile tends to get overlooked in two different situations. In organizations that are already running a GSA project – typically starting with Entra Private Access – it often gets deprioritized because the focus is on getting the connector infrastructure in place and migrating VPN users.

A second look at Microsoft Entra Private Access for Active Directory domain controllers

This blog post is about the new Private Access Sensor for Domain Controller and the option to restrict Kerberos SSO to clients using Entra Private Access

🆕 This is the updated version of my blog about Entra Private Access for Active Directory for Domain Controllers. You can find the old version → here ←. New features include the central admin UI and logging! Intro In many environments - often for historical reasons - there is no strict separation of client and server networks. And if there is a firewall between the networks, the rule sets often allow direct communication with the domain controllers in the environment.

Chris Brumm's Blog