{"id":90992,"date":"2020-04-30T09:00:29","date_gmt":"2020-04-30T16:00:29","guid":{"rendered":"https:\/\/www.microsoft.com\/en-us\/security\/blog\/\/?p=90992"},"modified":"2023-11-15T11:18:24","modified_gmt":"2023-11-15T19:18:24","slug":"zero-trust-deployment-guide-azure-active-directory","status":"publish","type":"post","link":"https:\/\/www.microsoft.com\/en-us\/security\/blog\/2020\/04\/30\/zero-trust-deployment-guide-azure-active-directory\/","title":{"rendered":"Zero Trust Deployment Guide for Microsoft Azure Active Directory"},"content":{"rendered":"
Microsoft is providing a series of deployment guides for customers who have engaged in a Zero Trust security strategy<\/a>. In this guide, we cover how to deploy and configure Azure Active Directory (Azure AD) capabilities to support your Zero Trust<\/a> security strategy.<\/p>\n For simplicity, this document will focus on ideal deployments and configuration. We will call out the integrations that need Microsoft products other than Azure AD and we will note the licensing needed within Azure AD (Premium P1 vs P2), but we will not describe multiple solutions (one with a lower license and one with a higher license).<\/p>\n Azure AD provides critical functionality for your Zero Trust strategy. It enables strong authentication, a point of integration for device security, and the core of your user-centric policies to guarantee least-privileged access. Azure AD\u2019s Conditional Access capabilities are the policy decision point for access to resources based on user identity, environment, device health, and risk\u2014verified explicitly at the point of access. In the following sections, we will showcase how you can implement your Zero Trust strategy with Azure AD.<\/p>\n A Zero Trust<\/a> strategy requires that we verify explicitly, use least privileged access principles, and assume breach. Azure Active Directory can act as the policy decision point to enforce your access policies based on insights on the user, device, target resource, and environment. To do this, we need to put Azure Active Directory in the path of every access request\u2014connecting every user and every app or resource through this identity control plane. In addition to productivity gains and improved user experiences from single sign-on (SSO) and consistent policy guardrails, connecting all users and apps provides Azure AD with the signal to make the best possible decisions about the authentication\/authorization risk.<\/p>\n Giving the right access at the right time to only those who need it is at the heart of a Zero Trust philosophy:<\/p>\n Provide Azure AD with a rich set of credentials and controls that it can use to verify the user at all times.<\/p>\n Provide Azure AD with a rich set of credentials and controls that it can use to verify the user.<\/p>\n We hope the above guides help you deploy the identity pieces central to a successful Zero Trust strategy. Make sure to check out the other deployment guides in the series by following the Microsoft Security blog<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":" Microsoft is providing a series of deployment guides for customers who have engaged in a Zero Trust security strategy to configure Azure Active Directory (Azure AD) capabilities. <\/p>\n","protected":false},"author":96,"featured_media":90994,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"ep_exclude_from_search":false,"_classifai_error":"","footnotes":""},"content-type":[3659],"topic":[3689],"products":[3702,3703],"threat-intelligence":[],"tags":[3742],"coauthors":[2308],"class_list":["post-90992","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","content-type-best-practices","topic-zero-trust","products-microsoft-entra","products-microsoft-entra-id","tag-azure","review-flag-1694638265-576","review-flag-1-1694638265-354","review-flag-2-1694638266-864","review-flag-3-1694638266-241","review-flag-integ-1694638263-281","review-flag-new-1694638263-340"],"yoast_head":"\nAzure AD at the heart of your Zero Trust strategy<\/h3>\n
Establish your identity foundation with Azure AD<\/h3>\n
\n
\nMaintaining a healthy pipeline of your employees\u2019 identities as well as the necessary security artifacts (groups for authorization and devices for extra access policy controls) puts you in the best place to use consistent identities and controls, which your users already benefit from on-premises and in the cloud:<\/p>\n\n
\nAs mentioned earlier, SSO is not only a convenient feature for your users, but it\u2019s also a security posture, as it prevents users from leaving copies of their credentials in various apps and helps avoid them getting used to surrendering their credentials due to excessive prompting. Make sure you do not have multiple IAM engines in your environment. Not only does this diminish the amount of signal that Azure AD sees and allow bad actors to live in the seams between the two IAM engines, it can also lead to poor user experience and your business partners becoming the first doubters of your Zero Trust<\/a> strategy. Azure AD supports a variety of ways you can bring apps to authenticate with it:<\/p>\n\n
\nOnce you have your users\u2019 identities in Azure AD, you can now use Azure AD to power pushing those user identities into your various cloud applications. This gives you a tighter identity lifecycle integration within those apps. Use this detailed guide<\/a> to deploy provisioning into your SaaS applications.<\/li>\n
\n<\/strong>As you build your estate in Azure AD with authentication, authorization, and provisioning, it\u2019s important to have strong operational insights into what is happening in the directory. Follow this guide<\/a> to learn how to to persist and analyze the logs from Azure AD either in Azure or using a SIEM system of choice.<\/li>\n<\/ul>\nEnacting the 1st<\/sup> principle: least privilege<\/h3>\n
\n
\n<\/strong>Planning your Conditional Access policies in advance and having a set of active and<\/em><\/strong> fallback policies is a foundational pillar of your Access Policy enforcement in a Zero Trust deployment. Take the time to configure your trusted IP locations in your environment. Even if you do not use them in a Conditional Access policy, configure these IPs informs the risk of Identity Protection mentioned above. Check out our deployment guidance<\/a> and best practices<\/a> for resilient Conditional Access policies.<\/li>\n
\nWith privileged access, you generally take a different track to meeting the end users where they are most likely to need and use the data. You typically want to control the devices, conditions, and credentials that users use to access privileged operations\/roles. Check out our detailed guidance<\/a> on how to take control of your privileged identities and secure them. Keep in mind that in a digitally transformed organization, privileged access is not only administrative access, but also application owner or developer access that can change the way your mission critical apps run and handle data. Check out our detailed guide on how to use Privileged Identity Management (P2) to secure privileged identities<\/a>.<\/li>\n
\nUser consent to applications is a very common way for modern applications to get access to organizational resources. However, we recommend you restrict user consent and manage consent requests<\/a> to ensure that no unnecessary exposure of your organization\u2019s data to apps occurs. This also means that you need to review prior\/existing consent in your organization<\/a> for any excessive or malicious consent.<\/li>\n
\nWith applications centrally authenticating and driven from Azure AD, you should streamline your access request, approval, and recertification process to make sure that the right people have the right access and that you have a trail of why users in your organization have the access they have. Using entitlement management, you can create access packages that they can request as they join different teams\/project and that would assign them access to the associated resources (applications, SharePoint sites, group memberships). Check out how you can start a package<\/a>. If deploying entitlement management is not possible for your organization at this time, we recommend you at least enable self-service paradigms in your organization by deploying self-service group management<\/a> and self-service application access<\/a>.<\/li>\n<\/ul>\nEnacting the 2nd<\/sup> principle: verify explicitly<\/h3>\n
\n
\n<\/strong>This is a foundational piece of reducing user session risk. As users appear on new devices and from new locations, being able to respond to an MFA challenge is one of the most direct ways that your users can teach us that these are familiar devices\/locations as they move around the world (without having administrators parse individual signals). Check out this deployment guide<\/a>.<\/li>\n
\n<\/strong>If you are managing the user\u2019s laptop\/computer, bringing that information into Azure AD and use it to help make better decisions. For example, you may choose to allow rich client access to data (clients that have offline copies on the computer) if you know the user is coming from a machine that your organization controls and manages. If you do not bring this in, you will likely choose to block access from rich clients, which may result in your users working around your security or using Shadow IT. Check out our resources for Azure AD Hybrid Join<\/a> or Azure AD Join<\/a>.<\/li>\n
\nThe same can be said about user mobile devices as laptops. The more you know about them (patch level, jailbroken, rooted, etc.) the more you are able to trust or mistrust them and provide a rationale for why you block\/allow access. Check out our Intune device enrollment guide<\/a> to get started.<\/li>\n
\nWith Azure AD now supporting FIDO 2.0 and passwordless phone sign-in, you can move the needle on the credentials that your users (especially sensitive\/privileged users) are using on a day-to-day basis. These credentials are strong authentication factors that can mitigate risk as well. Our passwordless authentication deployment guide<\/a> walks you through how to roll out passwordless credentials in your organization.<\/li>\n<\/ul>\nEnacting the 3rd<\/sup> principle: assume breach<\/h3>\n
\n
\nWhile enabling other methods to verify users explicitly, you should not forget about weak passwords, password spray and breach replay attacks. Read this blog<\/a> to find out why classic complex password policies are not tackling the most prevalent password attacks. Then follow this guidance to enable Azure AD Password Protection for your users in the cloud first<\/a> and then on-premises as well<\/a>.<\/li>\n
\n<\/strong>One of the most common attack vectors for malicious actors is to use stolen\/replayed credentials against legacy protocols, such as SMTP, that cannot do modern security challenges. We recommend you block legacy authentication<\/a> in your organization.<\/li>\n
\nEnabling identity protection<\/a> for your users will provide you with more granular session\/user risk signal. You\u2019ll be able to investigate risk and confirm compromise or dismiss the signal which will help the engine understand better what risk looks like in your environment.<\/li>\n
\nTo illustrate, let\u2019s take a look at controls in Exchange Online and SharePoint Online (P1): When a user\u2019s risk is low but they are signing in from an unknown device, you may want to allow them access to critical resources, but not allow them to do things that leave your organization in a non-compliant state. Now you can configure Exchange Online and SharePoint Online to offer the user a restricted session that allows them to read emails or view files, but not download them and save them on an untrusted device. Check out our guides for enabling limited access with SharePoint Online<\/a> and Exchange Online<\/a>.<\/li>\n
\nUsing signals emitted after authentication and with MCAS proxying requests to application, you will be able to monitor sessions going to SaaS Applications and enforce restrictions. Check out our MCAS and Conditional Access integration guidance<\/a> and see how this can even be extended to on-premises apps<\/a>.<\/li>\n
\nMicrosoft Cloud App Security is a UEBA product monitoring user behavior inside<\/em> SaaS and modern applications. This gives Azure AD signal and awareness about what happened to the user after they authenticated and received a token. If the user pattern starts to look suspicious (user starts to download gigabytes of data from OneDrive or starts to send spam emails in Exchange Online), then a signal can be fed to Azure AD notifying it that the user seems to be compromised or high risk and on the next access request from this user; Azure AD can take correct action to verify the user or block them. Just enabling MCAS monitoring will enrich the identity protection signal. Check out our integration guidance<\/a> to get started.<\/li>\n
\n<\/strong>Once you\u2019ve successfully deployed and configured Azure ATP, enable the integration<\/a> with Microsoft Cloud App Security to bring on-premises signal into the risk signal we know about the user. This enables Azure AD to know that a user is indulging in risky behavior while accessing on-premises, non-modern resources (like File Shares) which can then be factored into overall user risk to block further access in the cloud. You will be able to see a combined Priority Score<\/a> for each user at risk to give a holistic view of which ones your SOC should focus on.<\/li>\n
\nMicrosoft Defender ATP allows you to attest to Windows machines health and whether they are undergoing a compromise and feed that into mitigating risk at runtime. Whereas Domain Join gives you a sense of control, Defender ATP allows you to react to a malware attack at near real time by detecting patterns where multiple user devices are hitting untrustworthy sites and react by raising their device\/user risk at runtime. See our guidance on configuring Conditional Access in Defender ATP<\/a>.<\/li>\n<\/ul>\nConclusion<\/h3>\n