Zero Trust Identity Controls – Essentials Series – Episode 2
This article is contributed. See the original author and article here.
Tour your identity options when moving to the Zero Trust security model. Our last Essentials episode gave a high-level overview of the Zero Trust security model principles: identity, endpoints, applications, networks, infrastructure, and data.
Join our host, Jeremy Chapman, as he unpacks the foundational layer of the model with identity. As the primary control plane for Zero Trust, it acts as the front door for people, service accounts, and devices as each requests access to resources. Identity is at the core of the Zero Trust concepts of never trust, always verify and grant the appropriate level of access through the principle of least privilege.
Verify Explicitly
Azure AD — easily implement additional protections to verify explicitly Multi-factor authentication (MFA) — requires an additional authentication factor. Replace passwords with Microsoft Authenticator, Windows Hello, or FIDO2 keys. Activity reports in the Authentication methods — see who’s capable of MFA and passwordless authentication, how many recent registrations and by type. Usage — see the distribution of MFA sign-ins and by method, as well as the number of password changes and resets.
Least Privilege access
Conditional Access in Azure AD — uses real-time intelligence at the time of sign-in to assess the risk level, then blocks or grants access. Built-in Insights and Reporting — expose the impact of enabled policies pre- and post enforcement.
QUICK LINKS:
00:37 — Demo in Azure AD
01:47 — Azure AD Application Proxy
02:50 — How to set up multi-factor authentication
04:44 — Activity Reports for admins
05:21 — Least privileged access and conditional access
07:22 — Conditional Access Insights and Reporting
08:16 — Wrap up
Link References:
For tips and demonstrations, check out our series at https://aka.ms/ZeroTrustMechanics
Learn more at https://aka.ms/zerotrust
Unfamiliar with Microsoft Mechanics?
We are Microsoft’s official video series for IT. You can watch and share valuable content and demos of current and upcoming tech from the people who build it at Microsoft.
- Subscribe to our YouTube: https://www.youtube.com/c/MicrosoftMechanicsSeries?sub_confirmation=1
- Join us on the Microsoft Tech Community: https://techcommunity.microsoft.com/t5/microsoft-mechanics-blog/bg-p/MicrosoftMechanicsBlog
- Watch or listen via podcast here: https://microsoftmechanics.libsyn.com/website
Keep getting this insider knowledge, join us on social:
- Follow us on Twitter: https://twitter.com/MSFTMechanics
- Follow us on LinkedIn: https://www.linkedin.com/company/microsoft-mechanics/
- Follow us on Facebook: https://facebook.com/microsoftmechanics/
-Welcome back to our series for Zero Trust on Microsoft Mechanics. In our Essentials Episode, we gave a high-level overview of the principles for Zero Trust security model, spanning identity, endpoints, applications, networks, infrastructure, and data. Now in this episode, we’re going to unpack the foundational layer of the model with Identity, the primary control plane for Zero Trust, which acts as the front door for people, service accounts, and devices as each request access to resources. Identity is at the core of the Zero Trust concepts of verifying explicitly, and also granting appropriate level of access through the principle of least privilege.
-Now, this begins with Azure Active Directory and first establishing a common and unified directory service to authenticate users, devices, and processes to your resources, apps, and services. In the Microsoft 365 admin center, you’ll see your users, resource accounts, and all of your groups. Now this is powered by Azure Active Directory in the background. In fact, if I click into Azure Active Directory here under the admin centers, it’s going to take me right into Azure AD. And when I click into users, you’re going to see the same people and resource accounts and groups. As I mentioned, one of the key starting points as you move to Zero Trust is unifying the identity and access management environment with your other cloud apps and even your on-premise resources. So now I’m going to click into Enterprise Applications. And here you can see all the SaaS applications that I’ve configured in this tenant that are using an Azure AD to log in. Now, there are thousands of apps that you can choose from. And if I click into Box, for example, you’re going to see the groups that are assigned with access to this application. And under Conditional Access, you can even see some of the access policies assigned to this specific app. And we’re going to go further into Conditional Access policies in a moment.
-Before I jump into the user experience, I want to show you one more thing for connecting your web apps hosted on-premises, the Azure AD Application Proxy. Now here, I can see a few apps that I already have configured for Single Sign-in, along with connector and IP address information. But let me show you what it looks like then to log into a non-Microsoft SaaS app now that Azure AD is configured as its identity provider. So I’m here in the My Apps portal. And if you aren’t familiar with this, you can find it at myapps.microsoft.com. And it gives me a unified view of all the apps that Woodgrove, in this case, has set up for me. And most of these are SaaS apps, but you can see the ones branded Woodgrove. Those are actually on-prem apps. So those are going to work here as well. I’m going to click into ServiceNow and you’ll see that it authenticates me directly into that app.
-If I go back to My Apps, I’ll click into the one called Sales Dashboard On-Prem. And in that case, it’s using the Azure AD App Proxy that we saw earlier to connect me directly, even though that resource is on-premises. Now with Azure AD as your unified identity provider across your apps and services, you can easily implement additional protections to verify explicitly, and here multi-factor authentication, or MFA, is key. Now MFA goes beyond weak password-only authentication and requires an additional authentication factor, like a passcode relayed over an SMS or phone call. And you can even replace passwords using options such as Microsoft Authenticator, Windows Hello, or FIDO2 keys. I’m going to show you how to set this up as an admin. Then we’re going to walk through the user experiences as well as new admin reporting to monitor usage. Now to find your options to configure this in the Azure AD admin center, go to Security, then Authentication methods.
-Here you’ll find methods for FIDO2 security keys, along with the options to target users and groups. This one here is for the Microsoft Authenticator mobile app that you can use in combination with built-in biometric sensors for fingerprint or facial recognition on your phone. And you’ll even find the new Temporary Access Pass method that allows you to provide a time-limited passcode that you can use to register a passwordless sign-in method so that you don’t even need to share the password with the user. Since the account I’m using is setup for passwordless MFA with the Authenticator app, I’ll show you how this even works when logging into non-Microsoft sites directly. So for example, here with ServiceNow, I can use a tenant-specific URL to sign in directly with the service. You’ll see that the Azure AD sign-in page launches, and I’m going to type in my password and username. It’s going to then request passwordless sign-in to match the number on the screen, and then it’s going to send a notification on my phone.
-Okay, so now you can see the notifications come in, I’ll tap on that. And that’s going to open up the Authenticator app and I will then tap on the option here for 26. There we go. And that’s going to sign me in directly into ServiceNow, and I can start working from there. And for admins, we also have reporting to help you track how well your organization is doing. The Activity reports and the Authentication methods area help you to see who’s capable of MFA and passwordless authentication, how many recent registrations have been made, and by which type. Then in Usage, you can see the distribution of MFA sign-ins and by method, as well as the number of password changes and resets. And this will really help as you roll out new authentication methods and track usage over time. So now we’ve shown a few things that you can do to explicitly verify requests to your cross-cloud and on-prem resources and services.
-Another core tenant of Zero Trust is applying Least Privileged Access. So here in Conditional Access in Azure AD, it’s using real-time intelligence at the time of sign-in to assess the risk level of the user or sign-in, the device platform, along with the sign-in location, client apps and device state to make decisions, enforcing access policies in real time, either to block or to grant access. Now earlier, I showed you how ServiceNow could be accessed directly using Azure AD authentication. And in this policy, you’ll see that for ServiceNow you’ll need to log in with MFA. And because I use passwordless earlier that satisfied the requirement.
-A recent addition to Conditional Access is the ability to look at device filters. Now, these filters allow you to scope your Conditional Access policy to a group of devices. For example, you can decide to allow access to privileged resources only from secure access workstation VMs, or conversely, exempt MFA from shared meeting room devices like conference phones, Teams Meeting Room devices, or Surface Hubs. Just to show how this works, I’ll log into a VM that doesn’t meet our secure access workstation requirements, and try to reach the Azure portal. And you’ll see here that I’m blocked from going to the Azure portal. But now let me switch to a second VM that’s a secured access workstation, and you’ll see that when I try to access the Azure portal, it meets the requirements. And then it asks me to verify my identity using passwordless auth. And I’m granted access to my applications and resources in Azure.
-Now Conditional Access can also extend to specific sites and content. So for example, even though I can log into Woodgrove’s marketing site, as you can see here, if I go back to SharePoint’s home and then try to open a highly confidential site, like Project Saturn, you’re going to see that it requires step-up authentication, in my case, again, using passwordless auth, before it allows me to access the protected resource. And now here I can see Project Saturn’s site. So finally, as you roll out Conditional Access, built-in Insights and Reporting in Azure AD can expose the impact of enabled policies, both pre and post-enforcement. Now the Impact Summary is interactive. And for example, can help you identify why sign-ins are failing. And here you can see the device state, device platform, client app, sign-in risk and location. And detailed sign-in events can be found at the bottom of the page. Now, one tip here that you can use is to enforce policies as report only to gauge the impact of them before turning them on. This can help you avoid setting policies that may lock people out of resources they should be able to access.
-That was a tour of your identity options and all the considerations when moving to the Zero Trust security model. Up next, we’ll explore your options for endpoints and applications. And keep checking back to aka.ms/ZeroTrustMechanics for more in our series where I share the tips and hands-on demonstrations of how the tools for implementing the Zero Trust security model work across all the six layers of defense. Now you can also learn more at aka.ms/zerotrust. And thanks for watching.
Recent Comments