How-To

Microsoft Entra, Zero Trust and Identity

• By Paul Schnackenburg
• 06/27/2023

It's one of the cornerstones of Zero Trust (probably the most important one) and it's the one thing every IT security professional start with: identity. "Make sure you have strong identity controls" or "identity is the new firewall." Easy to say, less easy to implement.

In this article I'll talk about identity in general, how it fits in with the other security tools and services we've covered and the different parts of Microsoft Entra, along with how they solve different identity-related problems.

Basic Building Blocks
Every organization, large and small, needs strong email security hygiene (Defender for Office 365), comprehensive endpoint protection (EDR, Defender for Endpoint), SaaS cloud apps monitoring and governance (Defender for Cloud Apps) -- all covered here. There's one more pertinent one -- Defender for Identity -- and we'll come back to it later.

But all those protections and any other third-party security services can be "felled at the knees" if a user's identity is compromised. Because to the system, that looks like a legitimate user, and that will likely bypass most defenses.

If you don't opt for a third-party Identity and Access Management (IAM) system (Okta, Ping and others), in Microsoft's world you've got Active Directory Domain Services (AD DS or just AD) on premises (23 years old) and Azure Active Directory (AAD) in the cloud. Most medium to large businesses can't get rid of AD DS due to the requirements of legacy applications and thus link AD to AAD using Azure AD Connect. A user account is created in AD, then synched to AAD so that the user can seamlessly sign in to on-premises and cloud apps. Passwords can be handled in three ways. One is using Password Hash Synch (PHS), where a hash of the AD hash of the users password is stored in the cloud, the preferred method. If that's not allowable, you can use Pass Through Authentication (PTA) where small agents are sprinkled around on servers in your environment (no inbound ports required to be open), and when a user authenticates against AAD, it checks with an agent (which checks with AD) if the password is correct. Finally, you can use AD Federation Services (AD FS), also a legacy technology, with a questionable security track record. For example many organizations owned during the Solarwinds attack were compromised through AD FS.

That covers where the identity is housed. The process of authenticating an identity can involve just username and password, or username, password and another factor -- MFA. MFA can be a phone call or text message (not advisable, slightly better than just a password, but much too easy to circumvent), a prompt or six-digit code in an authenticator app on your phone. Even stronger methods, often called "phishing resistant," involve FIDO2 USB / NFC hardware keys or biometrics such as fingerprint or facial scans. These methods can also be used for passwordless, where there's just a username combined with a phishing-resistant authentication method. Until you achieve the passwordless nirvana, use Password protection in AD and AAD to make sure that the passwords users do create aren't easily guessable.

This used to be all handled by Azure AD, but there's a new portal called Entra, which combines many different identity related services in a single pane.

Microsoft Entra
This portal has three main areas -- Azure AD, Permissions Management and Verified ID. Let's start with Permissions Management (EPM), based on the acquisition of CloudKnox. For all the details check out this article, but in a nutshell, this cloud service focuses on PaaS and IaaS permissions in AWS, GCP and Azure. Each administrative account is monitored and granted permissions are compared against permissions actually used, creating a Permissions Creep Index (PCI) from 1 to 100, with a higher value indicating increased risk. You can then right-size permission so that administrators only have the permissions they need, drastically reducing the blast radius of a compromised account, and following the least privilege pillar in Zero Trust. For those once-off situations where an admin needs high level permissions. you have a workflow where they can request them for a limited time.

Next is Verified ID, which became generally available in August 2022. This is much larger than a simple identity service from Microsoft and aims to make it easy to use (for individuals) and issue (for organizations) Decentralized Identifiers (DIDs). Instead of our digital identity being managed by social media companies and our workplaces, DIDs allow us to create identities and control the sharing of particular pieces of our data when appropriate. If an organization might be offering me a job, I can share my educational credentials (and only those) with them in a secure way, where they can verify them. When I do get the job, perhaps I'll need to share other personal data, but again, it's under my control. Entra Verified ID is a platform to issue and verify these credentials, and the free Authenticator app (for iOS and Android) can be used to house and present verifiable credentials to applications.

Azure AD in Entra
While EPM is an interesting service, and if your organization has a large IaaS / PaaS footprint in any of the large clouds, particularly if you're multi-cloud, it's a fantastic solution to minimize permissions sprawl, and Verified ID is an interesting concept with ramifications for the future, the workhorse in most businesses is still Azure AD + AD.

Whether your accounts are sourced from AD or created directly in the cloud, there are many features to help secure, manage, monitor and govern identities across many different services. Apart from being the underlying directory for Azure and Microsoft 365, AAD also integrates with thousands of SaaS applications for Single Sign On (SSO) and even provisioning of user accounts. James is a new hire in Sales, by adding him to the Sales security group, an account in Salesforce is automatically created for him and given the right permissions. When James signs into his PC and opens myapplications.microsoft.com (no extra sign-in required), he's presented with all applications he's been given access to, and simply by clicking a tile, he's signed into that app. When James is moved to another department, simply taking him out of one group and adding him to another presents him with a new set of applications seamlessly. And when he leaves the organization, disabling his account stops access to every single SaaS application he had access to.

Access to specific applications, from a personal device vs. a company controlled one, for example, should be controlled with Conditional Access policies, and collaborating with external users is handled with Azure AD B2B. For Teams specifically you can use B2B Direct Connect to simplify this, including trusting the MFA policies in their tenant when accessing yours, obviating the need for double MFA prompts. Another interesting new feature, which became generally available the day this article was finished, is cross-tenant synchronization. Here you connect tenants together (perhaps in a merger scenario), and accounts created in one tenant can be synched to the other one, including being able to access applications.

Now let's focus on some of the newer features and how they tie in to the overall goal of increasing security and making governance easier. Often, the first place a new hire's details are entered into a system isn't in AAD (or AD), but rather in an HR system. The concept here is simple: Follow the accounts lifecycle from when they're hired, and they change roles in the organization until they leave, using HR-driven provisioning, Workday and SAP SuccessFactors, which are supported today.

I mentioned James's group membership automatically provisioning an account in Salesforce. But what if there's many other group / Teams / applications and other resources required for a role -- this is where entitlement management comes in. Here you can package many disparate resources together, delegate the ability to create these packages to non-administrators, and either assign packages based on group membership, or create approval workflows for staff to request access. You can also combine this with external access and define organizations whose users can request access to packages in your tenant. And you can time limit access by package.

For all different access scenarios, you can use access reviews to run regular investigations for both internal and external users as to whether they still need access to a particular application / site or Team -- again aiming for least privilege access. Together these features comprise identity lifecycle management, the aim of which is to automate the lifecycle of an identity. For integration with logic apps in Azure for connectivity to hundreds of other systems and automation of Joiner / Mover / Leaver steps, look to Lifecycle Workflows.

We already covered MFA, and how important it is from a security perspective, and touched on the fact that not all MFA is equally secure. A new feature, Authentication strengths, allow you to build policies (or use the built-in ones) to define what type of MFA you require, and then use Conditional Access policies to define for example: "if you want to access this sensitive application, from this network, and this geographical location, you must perform this type of MFA."

So far, we've been talking about user accounts and their management, but equally important and often overlooked are workload identities (applications, services, scripts or containers). Today these outnumber user accounts by 5 to 1, projected to be 20 to 1 in a few years. And because there's no human signing in, these accounts are favored by attackers because they often have high privileges, and fly under the radar of monitoring systems. Fairly new is the ability to target these accounts with Conditional Access policies, continuously assess their access and get notifications from Identity Protection when there's anomalous activity.

Speaking of Identity Protection, it uses machine learning in AAD to monitor every single sign-in to assign a risk score. Coming from the same device, at the same time of the day, and the same location as normal = low score. Right credential, but from a device we've never seen before and an unusual location = high risk, please perform an MFA to prove that it's really you, traveling with a new device. The same goes for overall user account risk, and again you can use Conditional Access policies to enforce password resets for accounts deemed high risk.

Finally, specifically for your administrators, use Privileged Identity Management so that their user accounts are normal users, except when they need to perform administrative tasks when they'll have to elevate, which can involve an MFA prompt, approval from someone else and so on.

Many of the features discussed here roll up into Entra Identity governance, which aims to automate many of these steps to simplify account management overall. There's an upcoming free event focused on Entra -- registration here.

Defender for Identity
If you have Microsoft 365 E5 (or E5 Security) licensing, please deploy Defender for Identity (MDI). It monitors your AD Domain Controllers and your AD Federation Services servers, and as an attacker on your network must move laterally and elevate their privileges, they will touch AD. When they do, not only will you be notified, MDI can also take automated action to disable accounts and so on.

Conclusion
While they have similar names, Azure AD in Entra and AD on premises are very different. The former changes rapidly and is a natural single place for all identity management for organizations with Azure and Microsoft 365 deployments. Not taking advantage of the features available at your licensing level is a mistake and as you have seen, there are many different services aiming to manage and secure varied business scenarios.