Article archive

Ever wondered how a company with 5,000 employees magically makes everyone's login work on every computer? Or how your work laptop just knows what printer to use, what network drive to mount, and what apps you're allowed to open? That's Active Directory doing its thing behind the scenes. Grab a coffee. We're going to demystify the single most important piece of enterprise IT you've never seen — and by the end you'll actually get it.

AADSTS53003 is the error users see when a Conditional Access policy stopped them from signing in. The error itself is deliberately vague — the actual reason is buried in the sign-in log entry for that attempt. Here's how to find the log entry, decode which policy blocked the sign-in and why, and work through the five most common causes.

Blog posts and Microsoft Learn will teach you how to configure a feature. Books are what teach you how the feature actually works, which is what you need when the configuration doesn't behave the way the docs promised. Here are the six books that had the most impact on how I think about identity — from a canonical AD reference to a distributed-systems textbook — and why each of them earned a permanent shelf position.

You've read the Microsoft docs. You've watched the videos. It hasn't stuck. The reason it hasn't stuck is that Active Directory is a hands-on discipline and reading about it is not the same as breaking and fixing it yourself. Here's the smallest useful home lab that will let you actually practise — hardware, software, topology, and the first ten exercises to run through.

You've decided to roll out phishing-resistant authentication on Microsoft Entra. Now you need to pick a security key that will actually work end-to-end for your users, survive an enterprise deployment, and not bankrupt the security budget. Here's what to look for, what to avoid, and how five popular keys compare in practice.

An access review is the feature that periodically asks someone (usually a manager) to confirm that the people who have access to a group, role, or application still need it. Sounds simple. The configuration choices that decide whether the loop actually closes — what to scope, who to ask, what happens when reviewers don't respond — are where the value lives. Here's the full picture, from what the feature is to how to operate it in production.

Three different mechanisms in Windows DNS that all route queries to another DNS server, all sound similar, and all solve different problems. Standard forwarders are the catch-all for everything the server doesn't own. Conditional forwarders route specific domains to specific upstreams. Stub zones cache the authoritative nameserver list for an external zone. Picking the wrong one produces silent resolution failures. Here's the decision tree for someone seeing these terms for the first time.

Every Windows DNS server ships with a list of thirteen root nameservers baked in. The list is the bootstrap that lets the server resolve any name on the public internet without depending on an upstream resolver. Most admins never touch it. In two specific situations — split-brain environments and resolvers that shouldn't reach public DNS at all — leaving the default in place is actively wrong. Here's what root hints actually do, when they help, and when to empty the file.

Most Windows DNS servers run on defaults that worked fine in 2008 and haven't really been revisited. A handful of those defaults — open recursion, no cache-pollution protection, no scavenging, listening on every interface — don't hold up in a modern enterprise threat environment. Here's what every server-level DNS setting actually does, and a baseline configuration sequence that takes a fresh DNS server from 'installed' to 'production-ready' in about ten minutes.

A reverse lookup zone is the database on a DNS server that answers the opposite question from a forward zone — instead of 'what's the IP for this name,' it answers 'what name belongs to this IP.' Most clients don't query reverse DNS often, but the ones that do (mail systems, RDP, audit tools, monitoring) fall over noisily when reverse zones are missing or wrong. Here's the full picture, from what a reverse zone is to how to set one up across odd subnet boundaries.

A forward lookup zone is the database on a DNS server that answers 'what's the IP address for this hostname.' In a Windows Server environment running Active Directory, the choices you make when creating that zone — primary vs secondary vs AD-integrated, who replicates it, who can update records in it — determine whether your forest is robust or fragile for years afterward. Here's the full picture, written for someone who knows DNS exists but hasn't actually configured a Windows DNS server before.

The gap between permissions granted and permissions used is the cloud security metric nobody can produce on demand. Identities have ten times the permissions they actually exercise, the over-grant accumulates silently, and the next breach lateral-moves on capabilities the compromised account never legitimately needed. Permissions Management is Microsoft's CIEM answer — and a measured rollout is what makes it useful instead of overwhelming.

Access in any tenant past a few hundred users always drifts. Someone leaves a project, nobody removes them from the SharePoint group. Six months later you discover thirty old contractors still in a finance distribution list. Entitlement Management is the answer that's supposed to make that not happen, and it works when you set it up right.

PIM is one of those features that looks simple in the demo and is humbling in production. The shape that works: eligible-only assignments, justified activations with MFA, narrow approver pools for the most sensitive roles, monitored activations, and a rule everyone forgets — break-glass accounts stay outside PIM, on purpose.

You don't actually want to require phishing-resistant MFA for every sign-in. You want it when the user reaches for a sensitive SharePoint site, activates a PIM role, or runs an action your app considers high-value. Authentication context is the dial that lets you target the step-up at the action instead of the app — and it's underused.

The two-policy pattern everyone half-implements: require MFA on medium sign-in risk, require password change on high user risk. The interesting part is the rest — what the signals actually catch, how to tune so the help desk doesn't drown, and the remediation flow that closes the loop without an analyst staring at a queue.

An operator's guide to Microsoft Entra Internet Access — the identity-aware SSE for outbound internet and SaaS traffic. What problem it solves, how it compares to Defender for Cloud Apps, the rollout sequence, and the policy patterns that actually work.

The VPN concentrator is end of life, the renewal quote is unreasonable, and somebody noticed that authenticating fifteen thousand users against a single appliance to reach forty private apps isn't a model anyone would design today. Here's the practitioner's view of replacing it with Entra Private Access, including the deployment order that doesn't strand users.

Cross-Tenant Synchronization (CTS) replaces the manual B2B invite-and-redeem dance with automatic identity provisioning between two Microsoft Entra tenants. This is the operator's view: source and target tenant configuration, sync scope, deprovisioning, and the gotchas that bite real deployments.

The pattern of generating a client secret, pasting it into GitHub Actions, and forgetting about it for two years is the credential pattern every security team wants gone. Federated Identity Credentials are how it actually goes away. Here's the trust model, the setup for GitHub, Azure DevOps, and Kubernetes, and the audit query that proves you got rid of the secrets.

The shared mailbox isn't there. Or it's there but Send As fails. Or sent items keep landing in the user's own folder. Same complaints, different layers. Here's the diagnostic order, the PowerShell that fixes the permission side, and the Outlook cache habit that resolves most of the rest.

Full Access was granted three days ago, other people see the mailbox, this one user doesn't. Restart didn't help. Patience didn't help. The fix the help-desk article suggests is to rebuild the profile, which works often enough that everyone accepts it as the answer. That isn't the actual answer. Here's what is.

The user clicks the shared mailbox and Outlook says 'You don't have permission.' Walk the access-flag hierarchy, deny-permission precedence, ACL inheritance, and the licensing trap that produces the same error message.

The permission shows up in the admin centre. Propagation has long since finished. The user still gets 'The message could not be sent.' Almost always one of three things — confused with Send on Behalf, lost in Outlook's auto-complete cache, or pointing at a stale identity after a primary SMTP change. Here's the diagnostic and the PowerShell that closes most of these tickets.

Members were added but mail isn't reaching them. Dynamic group filter was changed but the group looks the same. Walk the three sync clocks (Entra Connect, EXO directory, EXO recipient cache) and the filter scope gotchas that produce these failures.

OOF is turned on but external senders aren't getting replies. Walk the external-replies toggle, the once-per-sender rule, the spam-filter override, transport rules that suppress OOFs, and the remote domain configuration that controls everything.

The same user signs in fine from one browser and gets blocked from another on the same laptop. The policy didn't change, the user didn't change, the device didn't change. So what changed? Almost always, the device evidence the browser session carried. Here's the actual model, the five failure modes that account for most of it, and the KQL to spot the pattern at scale.

The wizard makes adding a domain to Microsoft 365 look like a checklist. Then six months later marketing wonders why their broadcasts are landing in spam. Here's the order to configure SPF, DKIM, and DMARC for an EXO tenant, the seven mistakes I see most often, and the staged DMARC enforcement that doesn't break payroll.

The password is right. OWA works first try. Outlook prompts again anyway. The loop that defeats password managers and makes people use the web app all day. It's almost always one of five things, none of which a user can diagnose, all of which take a minute to fix once you know which one it is.

Access denied after a sharing change, broken inheritance, external sharing disabled at the tenant level, and the Conditional Access policy that produces the same error. Walk the four layers of SharePoint permission and the OneDrive sync states that surface as access errors.

Someone can't get into Outlook. Conditional Access blocked them. Most of us reach for the policy editor first, and that's the wrong tab. Here's how to read the sign-in log the way the engine actually wrote it, with KQL, AADSTS codes, and the short decision tree that closes most CA tickets in five minutes.

Passkey registration in Microsoft Entra looks like four taps in the demo. The production reality is a credential-issuance workflow with four checks running underneath. Here's the decision tree, the platform-specific failures I see most often, and a Graph-driven inventory of what your users have actually registered.

The passkey option isn't in Security info. Or it's there but the registration fails silently. Or it works for one colleague and not the next on the same device. Seven different failures wearing the same coat. Here's how to identify which one, with a Graph-based diagnostic script and the policy design that prevents most of them from happening at all.

MFA in a small tenant is a Saturday evening. In a real one with hybrid identity, legacy clients, service accounts, and a help desk that's already backed up, it's a months-long programme. Here's the ring-based rollout that gets you to phishing-resistant MFA without an inbox full of lockout tickets.

An operator's view of Microsoft Entra Backup and Recovery — what it can and cannot do, where it differs from on-prem AD backup, an incident response playbook for accidental bulk changes, and a separation-of-duties workflow for multi-team recovery approval.

Someone gets disabled in Entra and stays in Teams for forty-five minutes. Someone else's session vanishes in under sixty seconds. The difference is whether both ends speak CAE, plus a few things the documentation describes in isolation. Here's the operational model that explains both.

A technical guide to Password Hash Synchronization, Pass-Through Authentication, and federation with AD FS or PingFederate, centered on where validation really happens.

A technical guide to SAML, WS-Federation, OAuth 2.0, and OpenID Connect, focused on trust transfer, actor roles, and what the backend is validating.

A technical guide to Kerberos, NTLM, LDAP bind, passkeys, certificate-based authentication, and Windows Hello for Business, focused on what each method proves and how the backend validates it.

A technical guide to the major authentication protocols and sign-in models used in Microsoft environments, including Kerberos, NTLM, LDAP bind, SAML, WS-Federation, OAuth 2.0, OpenID Connect, passkeys, certificate-based authentication, AD FS, and Microsoft Entra sign-in models.

A technical guide to Microsoft Entra Agent ID, including the agent identity model, Conditional Access enforcement, identity governance, risk detection, and network-level controls for AI agents.

A technical guide to Microsoft Entra passkey sign-in, including same-device and cross-device flows, compatibility dependencies, and rollout design.

A technical guide to Microsoft Entra passkey profiles, AAGUID restrictions, attestation behavior, and the control-plane logic behind passkey governance.

A detailed technical guide to AADSTS50020 in Microsoft Entra ID, including resource-tenant identity resolution, invitation redemption, cross-tenant access, and external identity design.

A detailed technical guide to Microsoft Entra join and registration failures on Windows, including device registration service flow, pending objects, dsregcmd analysis, and downstream impact on compliance and PRT.

A detailed technical guide to Microsoft Entra Primary Refresh Token failures on Windows, including dsregcmd analysis, device trust, broker behavior, network dependencies, and remediation design.

A detailed technical guide to why Microsoft Entra can block a sign-in from an Intune-compliant device, including device identity proof, browser support, client certificate behavior, and Conditional Access evaluation.

A technical guide to Microsoft Entra passkeys for administrators, including passkey types, registration flows, Authentication Methods policy, Conditional Access, and deployment design.

A technical troubleshooting guide for Microsoft Entra passkeys covering registration failures, Conditional Access loops, Bluetooth issues, orphaned passkeys, compatibility gaps, and Authenticator-specific problems.

An engineering-level explanation of access tokens and refresh tokens in Microsoft Entra ID, including token ownership, lifetime, renewal, revocation, and common troubleshooting patterns.

A top-to-bottom engineering explanation of how Microsoft Entra Conditional Access evaluates scope, combines controls, and influences token issuance.