Microsoft Entra

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.

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.

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.

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.

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.

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.

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.