您现在访问的是微软AZURE全球版技术文档网站,若需要访问由世纪互联运营的MICROSOFT AZURE中国区技术文档网站,请访问 https://docs.azure.cn.

计划条件访问部署Plan a Conditional Access deployment

规划条件访问部署对于实现组织的应用和资源访问策略至关重要。Planning your Conditional Access deployment is critical to achieving your organization's access strategy for apps and resources.

在移动优先、云优先的世界,用户会使用各种设备和应用从任何位置访问组织的资源。In a mobile-first, cloud-first world, your users access your organization's resources from anywhere using a variety of devices and apps. 因此,关注谁可以访问资源不再能满足需求。As a result, focusing on who can access a resource is no longer enough. 还需要考虑用户的位置、正在使用的设备、要访问的资源等。You also need to consider where the user is, the device being used, the resource being accessed, and more.

Azure Active Directory (Azure AD) 条件性访问分析信号(例如用户、设备和位置)以自动完成决策并为资源强制实施组织访问策略。Azure Active Directory (Azure AD) Conditional Access analyses signals such as user, device, and location to automate decisions and enforce organizational access policies for resource. 你可以使用条件性访问策略来应用访问控制,如多重身份验证 (MFA) 。You can use Conditional Access policies to apply access controls like Multi-Factor Authentication (MFA). 条件性访问策略允许用户在需要安全时提示用户进行 MFA,并在不需要时保留用户的方式。Conditional Access policies allow you to prompt users for MFA when needed for security, and stay out of users’ way when not needed.


Microsoft 提供了标准的条件策略(称为安全默认值)可确保基本安全级别。Microsoft provides standard conditional policies called security defaults that ensure a basic level of security. 但是,组织所需要的灵活性可能超出了安全默认值能提供的。However, your organization may need more flexibility than security defaults offer. 你可以使用条件访问更精细地自定义安全默认值,并配置满足需求的新策略。You can use Conditional Access to customize security defaults with more granularity and to configure new policies that meet your requirements.


在开始之前,请确保了解条件访问的工作原理及其使用时机。Before you begin, make sure you understand how Conditional Access works and when you should use it.


部署条件访问的优点是:The benefits of deploying Conditional Access are:

  • 提高工作效率。Increase productivity. 仅在有一个或多个信号支持时,才会中断具有登录条件(如 MFA)的用户。Only interrupt users with a sign-in condition like MFA when one or more signals warrants it. 使用条件性访问策略,可以控制何时提示用户进行 MFA、访问被阻止以及何时必须使用受信任的设备。Conditional Access policies allow you to control when users are prompted for MFA, when access is blocked, and when they must use a trusted device.

  • 管理风险。Manage risk. 通过策略条件自动执行风险评估意味着,一旦识别风险登录便可立即修正或阻止。Automating risk assessment with policy conditions means risky sign-ins are at once identified and remediated or blocked. 将条件访问与标识保护耦合在一起,可以检测异常和可疑事件,使您能够在资源访问被阻止或门控时锁定目标。Coupling Conditional Access with Identity Protection, which detects anomalies and suspicious events, allows you to target when access to resources is blocked or gated.

  • 解决符合性和管理问题。Address compliance and governance. 通过条件访问,你可以审核对应用程序的访问权限,提出使用条款以获得同意,并根据符合性策略限制访问。Conditional Access enables you to audit access to applications, present terms of use for consent, and restrict access based on compliance policies.

  • 管理成本。Manage cost. 将访问策略移动到 Azure AD 可以降低对条件访问的自定义或本地解决方案的依赖及其基础结构成本。Moving access policies to Azure AD reduces the reliance on custom or on-premises solutions for Conditional Access, and their infrastructure costs.

许可要求License requirements

请参阅条件访问许可证要求See Conditional Access license requirements.

如果需要附加的功能,则还可能需要相关的许可证。If additional features are required, you might also need related licenses. 有关详细信息,请参阅 Azure Active Directory 定价For more information, see Azure Active Directory pricing.


训练资源Training resources

了解条件访问时,以下资源可能会很有用:The following resources may be useful as you learn about Conditional Access:


PluralSight 上的在线课程Online courses on PluralSight

规划部署项目Plan the deployment project

在环境中确定此部署的策略时,请考虑组织的需求。Consider your organizational needs while you determine the strategy for this deployment in your environment.

让合适的利益干系人参与Engage the right stakeholders

如果技术项目失败,它们通常是由于在影响、结果和责任方面不符合预期而导致的。When technology projects fail, they typically do so due to mismatched expectations on impact, outcomes, and responsibilities. 为避免这些缺陷,请确保你正在吸引正确的利益干系人,并确保项目角色明确。To avoid these pitfalls, ensure that you're engaging the right stakeholders and that project roles are clear.

规划沟通Plan communications

沟通对于任何新服务的成功都至关重要。Communication is critical to the success of any new service. 主动与用户交流他们的体验将如何变化、何时会变化以及在遇到问题时如何获取支持。Proactively communicate with your users how their experience will change, when it will change, and how to gain support if they experience issues.

规划试点Plan a pilot

当新策略针对你的环境准备就绪后,在生产环境中分阶段部署它们。When new policies are ready for your environment, deploy them in phases in the production environment. 首先在测试环境中将策略应用于一小部分用户,并验证策略是否按预期方式工作。First apply a policy to a small set of users in a test environment and verify if the policy behaves as expected. 请参阅试点的最佳做法See Best practices for a pilot.


若要推出非特定于管理员的新策略,请排除所有管理员。For rolling out new policies not specific to administrators, exclude all administrators. 这可确保管理员仍可以访问策略,并在出现重大影响时进行更改或撤销。This ensures that administrators can still access the policy and make changes or revoke it if there's a significant impact. 在应用到所有用户之前,请始终使用较小的用户组验证策略。Always validate the policy with smaller user groups before you apply to all users.

了解条件访问策略组件Understand Conditional Access policy components

条件访问策略是 if-then 语句:如果满足分配,则应用这些访问控制。Conditional Access policies are if-then statements: If an assignment is met, then apply these access controls.

配置条件访问策略时,条件称为 " 分配"。When configuring Conditional Access policies, conditions are called assignments. 条件性访问策略使你可以基于特定的分配对组织的应用强制实施访问控制。Conditional Access policies allow you to enforce access controls on your organization’s apps based on certain assignments.

有关详细信息,请参阅 生成条件性访问策略For more information, see Building a Conditional Access policy.


分配定义Assignments define the

访问控制设置确定如何强制实施策略:Access controls settings determine how to enforce a policy:

询问正确的问题以生成策略Ask the right questions to build your policies

策略回答有关谁应访问你的资源、他们应访问哪些资源以及在什么条件下访问资源的问题。Policies answer questions about who should access your resources, what resources they should access, and under what conditions. 策略可用于授予访问权限或阻止访问。Policies can be designed to grant access, or to block access. 请务必就策略要实现的目标提出正确的问题。Be sure to ask the right questions about what your policy is trying to achieve.

在生成策略之前,记录每个策略的问题答案。Document the answers to questions for each policy before building it out.

有关分配的常见问题Common questions about Assignments

用户和组Users and Groups

  • 将在策略中包括或从策略中排除哪些用户和组?Which users and groups will be included in or excluded from the policy?

  • 此策略是否包括所有用户、特定的用户组、目录角色或外部用户?Does this policy include all users, specific group of users, directory roles, or external users?

云应用或操作Cloud apps or actions

  • 将策略应用到哪些应用程序?What application(s) will the policy apply to?

  • 哪些用户操作将受此策略的限制?What user actions will be subject to this policy?


  • 将在策略中包括或从策略中排除哪些设备平台?Which device platforms will be included in or excluded from the policy?

  • 组织受信任的位置有哪些?What are the organization’s trusted locations?

  • 将在策略中包括或从策略中排除哪些位置?What locations will be included in or excluded from the policy?

  • 将在策略中包括或从策略中排除哪些客户端应用类型(浏览器、移动设备、桌面客户端、使用旧式身份验证方法的应用)?What client app types (browser, mobile, desktop clients, apps with legacy authentication methods) will be included in or excluded from the policy?

  • 你是否有策略会将已建立 Azure AD 联接的设备或已建立混合 Azure AD 联接的设备从策略中排除?Do you have policies that would drive excluding Azure AD Joined devices or Hybrid Azure AD joined devices from policies?

  • 如果使用标识保护,你是否想要合并登录风险保护?If using Identity Protection, do you want to incorporate sign-in risk protection?

有关访问控制的常见问题Common questions about access controls

授予或阻止Grant or Block

是否要通过以下一项或多项要求来授予对资源的访问权限?Do you want to grant access to resources by requiring one or more of the following?

  • 要求 MFARequire MFA

  • 要求将设备标记为合规Require device to be marked as compliant

  • 要求使用已建立混合 Azure AD 联接的设备Require hybrid Azure AD joined device

  • 需要批准的客户端应用Require approved client app

  • 需要应用保护策略Require app protection policy

会话控制Session control

是否要在云应用上强制执行以下任意访问控制?Do you want to enforce any of the following access controls on cloud apps?

  • 使用应用强制执行的权限Use app enforced permissions

  • 使用条件访问应用控制Use Conditional Access App Control

  • 强制登录频率Enforce sign-in frequency

  • 使用持久性浏览器会话Use persistent browser sessions

访问令牌颁发Access token issuance

了解访问令牌的颁发方式很重要。It’s important to understand how access tokens are issued.



如果不需要赋值,并且没有有效的条件性访问策略,则默认行为是发出访问令牌。If no assignment is required, and no Conditional Access policy is in effect, that the default behavior is to issue an access token.

例如,请在以下情况下考虑使用策略:For example, consider a policy where:

如果用户属于组 1,则强制使用 MFA 访问应用 1。IF user is in Group 1, THEN force MFA to access App 1.

如果不属于组 1 的用户尝试访问应用,则不满足“if”条件,并颁发令牌。If a user not in Group 1 attempts to access the app no “if’ condition is met, and a token is issued. 若要排除不属于组 1 的用户,需要使用单独的策略来阻止所有其他用户。To exclude users outside of Group 1 requires a separate policy to block all other users.

遵循最佳做法Follow best practices

条件访问框架提供了极大的配置灵活性。The Conditional Access framework provides you with a great configuration flexibility. 不过,极大的灵活性也意味着应先仔细检查每个配置策略,然后才能发布,以免产生不良结果。However, great flexibility also means you should carefully review each configuration policy before releasing it to avoid undesirable results.

将条件性访问策略应用于每个应用Apply Conditional Access policies to every app

如果条件访问策略条件不触发访问控制,则默认情况下会发出访问令牌。Access tokens are by default issued if a Conditional Access policy condition does not trigger an access control. 确保每个应用至少已应用一个条件访问策略Ensure that every app has at least one conditional access policy applied


在单个策略中使用“阻止”和所有应用时要非常小心。Be very careful in using block and all apps in a single policy. 这可能会将管理员锁在 Azure 管理门户之外,并且无法为重要终结点(例如 Microsoft Graph)配置排除项。This could lock admins out of the Azure Administration Portal, and exclusions cannot be configured for important end-points such as Microsoft Graph.

将条件访问策略的数量降至最低Minimize the number of Conditional Access policies

为每个应用创建一个策略并不是很有效,而且会导致难以管理。Creating a policy for each app isn't efficient and leads to difficult administration. 条件访问只会对每个用户应用前 195 个策略。Conditional Access will only apply the first 195 policies per user. 我们建议你对应用进行分析,并按对相同用户具有相同的资源要求将应用分组。We recommend that you analyze your apps and group them into applications that have the same resource requirements for the same users. 例如,如果所有 Microsoft 365 应用或所有 HR 应用对同一用户具有相同的要求,请创建一个策略,并包括应用该策略的所有应用。For example, if all Microsoft 365 apps or all HR apps have the same requirements for the same users, create a single policy and include all of the apps to which it applies.

设置紧急访问帐户Set up emergency access accounts

如果你错误配置了策略,则该策略会将组织锁在 Azure 门户之外。If you misconfigure a policy, it can lock the organizations out of the Azure portal. 通过在组织中创建两个或更多紧急访问帐户,可缓解意外锁定管理员造成的影响。Mitigate the impact of accidental administrator lock out by creating two or more emergency access accounts in your organization.

  • 创建专用于策略管理并从所有策略中排除的用户帐户。Create a user account dedicated to policy administration and excluded from all your policies.

设置“仅限报告”模式Set up report-only mode

可能很难预测受常见部署计划(示例如下)影响的用户的数量和名称:It can be difficult to predict the number and names of users affected by common deployment initiatives such as:

  • 阻止旧式身份验证blocking legacy authentication
  • 要求 MFArequiring MFA
  • 实施登录风险策略implementing sign-in risk policies

仅限报表模式 使管理员能够在其环境中启用条件性访问策略之前,评估这些策略的影响。Report-only mode allows administrators to evaluate the impact of Conditional Access policies before enabling them in their environment.

了解如何 在条件性访问策略中配置仅报告模式Learn how to configure report-only mode on a Conditional Access policy.

为应对中断做好计划Plan for disruption

如果你依靠单一访问控制(如 MFA 或网络位置)来保护 IT 系统,那么当该单一访问控制不可用或配置错误时,很容易发生访问失败。If you rely on a single access control, such as MFA or a network location, to secure your IT systems, you are susceptible to access failures if that single access control becomes unavailable or misconfigured. 为了降低在发生不可预见的中断时被锁定的风险,应计划策略以供组织采用。To reduce the risk of lockout during unforeseen disruptions, plan strategies to adopt for your organization.

为策略设置命名标准Set naming standards for your policies

命名标准有助于查找策略及了解其用途,而无需在 Azure 管理门户中将其打开。The naming standard helps you to find policies and understand their purpose without opening them in the Azure admin portal. 我们建议你对策略进行命名以显示:We recommend that you name your policy to show:

  • 序列号A Sequence Number

  • 策略应用到的云应用The cloud app(s) it applies to

  • 响应The response

  • 策略对谁应用Who it applies to

  • 何时应用(如果适用)When it applies (if applicable)


示例:对于从外部网络访问 Dynamics CRP 应用的营销用户要求 MFA 的策略可能是:Example; A policy to require MFA for marketing users accessing the Dynamics CRP app from external networks might be:


描述性名称可帮助你大致了解条件访问实现。A descriptive name helps you to keep an overview of your Conditional Access implementation. 如果需要在对话中引用策略,则序列号非常有用。The Sequence Number is helpful if you need to reference a policy in a conversation. 例如,当你在电话中与管理员进行交谈时,可以要求他们打开策略 CA01 来解决问题。For example, when you talk to an administrator on the phone, you can ask them to open policy CA01 to solve an issue.

紧急访问控制的命名标准Naming standards for emergency access controls

除了活动策略以外,还应实施已禁用策略,这些策略在中断或紧急情况下充当辅助性的弹性访问控制措施In addition to your active policies, implement disabled policies that act as secondary resilient access controls in outage or emergency scenarios. 应急策略的命名标准应当包括:Your naming standard for the contingency policies should include:

  • 以“ENABLE IN EMERGENCY”开头,使名称从其他策略中脱颖而出。ENABLE IN EMERGENCY at the beginning to make the name stand out among the other policies.

  • 它应当应用于的中断的名称。The name of disruption it should apply to.

  • 一个排序序列号,可以帮助管理员了解应当以何顺序启用策略。An ordering sequence number to help the administrator to know in which order policies should be enabled.


以下名称表明,如果发生 MFA 中断,此策略是要启用的四个策略中的第一个:The following name indicates that this policy is the first of four policies to enable if there's an MFA disruption:

EM01 - ENABLE IN EMERGENCY:MFA 中断 [1/4] - Exchange SharePoint:VIP 用户需要混合 Azure AD 联接。EM01 - ENABLE IN EMERGENCY: MFA Disruption [1/4] - Exchange SharePoint: Require hybrid Azure AD join For VIP users.

排除你绝不会从那里登录的国家/地区。Exclude countries from which you never expect a sign-in.

Azure Active Directory 允许你创建命名位置Azure active directory allows you to create named locations. 创建一个命名位置,其中包含绝不会发生登录的所有国家/地区。Create a named location that includes all of the countries from which you would never expect a sign-in to occur. 然后为阻止从该命名位置登录的所有应用创建策略。Then create a policy for All apps that blocks sign in from that named location. 请确保从此策略中排除你的管理员。Be sure to exempt your administrators from this policy.

规划策略部署Plan your policy deployment

当新策略为你的环境准备就绪时,请确保在发布策略之前检查每个策略,以避免产生不良结果。When new policies are ready for your environment, make sure that you review each policy before releasing it to avoid undesirable results.

通用策略Common policies

规划条件访问策略解决方案时,请评估是否需要创建策略来实现以下结果。When planning your Conditional Access policy solution, assess whether you need to create policies to achieve the following outcomes.

要求 MFARequire MFA

要求 MFA 访问的常见用例包括:Common use cases to require MFA access:

响应可能已泄密的帐户Respond to potentially compromised accounts

使用条件性访问策略,你可以通过可能泄露的标识来实现对登录的自动响应。With Conditional Access policies, you can implement automated responses to sign-ins by potentially compromised identities. 帐户泄密的可能性以风险级别的形式表示。The probability that an account is compromised is expressed in the form of risk levels. “标识保护”会计算两种风险级别:登录风险和用户风险。There are two risk levels calculated by Identity Protection: sign-in risk and user risk. 以下三个默认策略可以启用。The following three default policies that can be enabled.

需要托管设备Require managed devices

扩大用来访问云资源的受支持设备的范围有助于提高用户的工作效率。The proliferation of supported devices to access your cloud resources helps to improve the productivity of your users. 你可能不希望具有未知保护级别的设备访问环境中的某些资源。You probably don't want certain resources in your environment to be accessed by devices with an unknown protection level. 对于这些资源,要求用户只能使用受管理设备访问它们For those resources, require that users can only access them using a managed device.

需要已批准的客户端应用Require approved client apps

员工使用其移动设备执行个人和工作任务。Employees use their mobile devices for both personal and work tasks. 对于 BYOD 方案,你必须决定是要管理整个设备还是只管理其中的数据。For BYOD scenarios you must decide whether to manage the entire device or just the data on it. 如果仅管理数据和访问权限,你可以要求已批准的云应用,以保护你的企业数据。if managing only data and access, you can require approved cloud apps that can protect your corporate data. 例如,你可以要求仅通过 Outlook Mobile 而不是通过常规邮件程序访问电子邮件。for example, you can require email only be accessed via Outlook mobile, and not via a generic mail program.

阻止访问Block access

用于阻止所有访问的选项非常强大。The option to block all access is powerful. 例如,当你将应用迁移到 Azure AD,但尚未准备好让任何人登录该应用时,可以使用此选项。It can be used, for example, when you are migrating an app to Azure AD, but are not ready for anyone to sign-in to it yet. 阻止访问:Block access:

  • 覆盖用户的所有其他分配Overrides all other assignments for a user

  • 具有阻止整个组织登录到租户的强大权限Has the power to block your entire organization from signing on to your tenant


如果创建一个策略来阻止所有用户的访问,请确保排除紧急访问帐户,并考虑从策略中排除所有管理员。If you create a policy to block access for all users, be sure to exclude emergency access accounts, and consider excluding all administrators, from the policy.

你可以阻止用户访问的其他常见情况如下:Other common scenarios where you can block access for your users are:

  • 阻止某些网络位置访问你的云应用。Block certain network locations to access your cloud apps. 你可以使用此策略来阻止你知道不应该有流量输出的某些国家/地区。You can use this policy to block certain countries where you know traffic shouldn't come from.

  • Azure AD 支持旧式身份验证。Azure AD supports legacy authentication. 但是,旧式身份验证不支持 MFA,而许多环境需要后者来解决标识安全问题。However, legacy authentication doesn't support MFA and many environments require it to address identity security. 在这种情况下,你可以使用旧式身份验证阻止应用访问你的租户资源。In this case, you can block apps using legacy authentication from accessing your tenant resources.

生成和测试策略Build and test policies

在部署的每个阶段,请确保评估结果符合预期。At each stage of your deployment ensure that you're evaluating that results are as expected.

当新策略准备就绪后,将其分阶段部署到生产环境中:When new policies are ready, deploy them in phases in the production environment:

  • 向最终用户提供内部变更通知。Provide internal change communication to end users.

  • 从少量的用户着手,验证策略的行为是否符合预期。Start with a small set of users and verify that the policy behaves as expected.

  • 将策略的范围扩大,使之包括更多的用户时,继续排除所有管理员。When you expand a policy to include more users, continue to exclude all administrators. 排除管理员可以确保在需要更改的情况下,仍有人可以访问该策略。Excluding administrators ensures that someone still has access to a policy if a change is required.

  • 仅在进行全面测试后,才能将策略应用到所有用户。Apply a policy to all users only after it's thoroughly tested. 确保你拥有至少一个该策略不适用的管理员帐户。Ensure you have at least one administrator account to which a policy doesn't apply.

创建测试用户Create test users

创建一组反映生产环境中真实用户的测试用户。Create a set of test users that reflect the users in your production environment. 创建测试用户可以验证策略的工作方式是否符合预期,避免其影响实际用户并潜在性地干扰他们对应用和资源的访问。Creating test users allows you to verify policies work as expected before you impact real users and potentially disrupt their access to apps and resources.

某些组织出于此目的创建了测试租户。Some organizations have test tenants for this purpose. 但是,可能很难在测试租户中重新创建所有条件和应用来全面测试策略的结果。However, it can be difficult to recreate all conditions and apps in a test tenant to fully test the outcome of a policy.

创建测试计划Create a test plan

测试计划非常重要,它可以在预期结果与实际结果之间进行比较。The test plan is important to have a comparison between the expected results and the actual results. 进行测试之前,始终应该持有某种预期。You should always have an expectation before testing something. 下表概述了示例测试用例。The following table outlines example test cases. 基于条件性访问策略的配置方式调整方案和预期结果。Adjust the scenarios and expected results based on how your Conditional Access policies are configured.

策略Policy 方案Scenario 预期结果Expected Result
在非工作时间要求执行 MFARequire MFA when not at work 经授权的用户在受信任的位置/工作时登录到应用Authorized user signs into App while on a trusted location / work 不提示用户执行 MFAUser is not prompted to MFA
在非工作时间要求执行 MFARequire MFA when not at work 经授权的用户不在受信任的位置/工作时登录到应用Authorized user signs into App while not on a trusted location / work 提示用户执行 MFA,他们可以成功登录User is prompted to MFA and can sign in successfully
要求执行 MFA(针对管理员)Require MFA (for admin) 全局管理员登录到应用Global Admin signs into App 提示管理员执行 MFAAdmin is prompted to MFA
有风险的登录Risky sign-ins 用户使用未经批准的浏览器登录应用User signs into App using an unapproved browser 提示管理员执行 MFAAdmin is prompted to MFA
设备管理Device management 经授权的用户尝试从已授权的设备登录Authorized user attempts to sign in from an authorized device 授予访问权限Access Granted
设备管理Device management 经授权的用户尝试从未授权的设备登录Authorized user attempts to sign in from an unauthorized device 阻止访问Access blocked
有风险用户的密码更改Password change for risky users 经授权的用户尝试使用已泄密的凭据登录(高风险登录)Authorized user attempts to sign in with compromised credentials (high risk sign in) 根据策略提示用户更改密码或阻止访问User is prompted to change password or access is blocked based on your policy

配置测试策略Configure the test policy

Azure 门户中,你将配置条件访问策略,Azure Active Directory > 安全 > 条件性访问。In the Azure portal, you configure Conditional Access policies under Azure Active Directory > Security > Conditional Access.

如果要了解有关如何创建条件性访问策略的详细信息,请参阅以下示例: 条件访问策略,以便在用户登录到 Azure 门户时提示进行 MFAIf you want to learn more about how to create Conditional Access policies, see this example: Conditional Access policy to prompt for MFA when a user signs in to the Azure portal. 此快速入门可帮助你:This quickstart helps you to:

  • 熟悉用户界面Become familiar with the user interface

  • 初步认识条件访问的工作原理Get a first impression of how Conditional Access works

在仅限报告模式下启用策略Enable the policy in report-only mode

若要评估策略的影响,首先在仅限报告模式下启用策略。To assess the impact of your policy, start by enabling the policy in report-only mode. 仅限报告策略在登录期间评估,但不会强制实施授权控制和会话控制。Report-only policies are evaluated during sign-in but grant controls and session controls aren't enforced. 在仅限报告模式下保存策略后,可以在登录日志中看到对实时登录的影响。Once you save the policy in report-only mode, you can see the impact on real-time sign-ins in the sign-in logs. 从登录日志中选择一个事件,然后导航到“仅限报告”选项卡,以查看每个仅限报告策略的结果。From the sign-in logs, select an event and navigate to the Report-only tab to see the result of each report-only policy.

仅限报告模式report only mode

选择该策略,还可以查看如何使用“策略详细信息”屏幕来评估策略的分配和访问控制。Selecting the policy, you can also see how the assignments and access controls of the policy were evaluated using the Policy details screen. 若要将策略应用到登录,必须满足每个配置的分配。In order for a policy to apply to a sign-in, each of the configured assignments must be satisfied.

使用见解和报告工作簿了解策略的影响Understand the impact of your policies using the Insights and Reporting workbook

你可以在见解和报告工作簿中查看条件访问策略的总体影响。You can view the aggregate impact of your Conditional Access policies in the Insights and Reporting workbook. 若要访问该工作簿,需要 Azure Monitor 订阅,并且需要将登录日志流式传输到 Log Analytics 工作区To access the workbook, you need an Azure Monitor subscription and you will need to stream your Sign-in logs to a Log Analytics workspace.

使用假设工具模拟登录Simulate sign-ins using the what-if tool

验证条件访问策略的另一种方法是使用假设工具,该工具模拟哪些策略将应用于在假设环境下登录的用户。Another way to validate your Conditional Access policy is by using the what-if tool, which simulates which policies would apply to a user signing in under hypothetical circumstances. 选择要测试的登录属性(例如,用户、应用程序、设备平台和位置),并查看要应用的策略。Select the sign-in attributes you want to test (such as user, application, device platform, and location) and see which policies would apply.


尽管模拟运行可让你充分了解条件访问策略的影响,但它不会取代实际的测试运行。While a simulated run gives you a good idea of the impact a Conditional Access policy has, it does not replace an actual test run.

测试策略Test your policy

在测试计划中通过测试用户执行每个测试。Perform each test in your test plan with test users.

务必测试策略的排除条件。Ensure you test the exclusion criteria of a policy. 例如,你可能从要求执行 MFA 的策略中排除了某个用户或组。For example, you may exclude a user or group from a policy that requires MFA. 测试系统是否会提示已排除的用户执行 MFA,因为其他策略的组合可能会要求这些用户执行 MFA。Test if the excluded users are prompted for MFA, because the combination of other policies might require MFA for those users.

回滚策略Roll back policies

如果需要回滚新实施的策略,请使用以下一个或多个选项:In case you need to roll back your newly implemented policies, use one or more of the following options:

  • 禁用策略。Disable the policy. 禁用某个策略可确保当用户尝试登录时不应用该策略。Disabling a policy makes sure it does not apply when a user tries to sign in. 想要使用该策略时,可以随时重新启用它。You can always come back and enable the policy when you would like to use it.


  • 从策略中排除用户或组。Exclude a user or group from a policy. 如果某个用户无法访问应用,你可以选择从策略中排除该用户。If a user is unable to access the app, you can choose to exclude the user from the policy.



应该慎用此选项,仅在用户受信任的情况下才使用。This option should be used sparingly, only in situations where the user is trusted. 应该尽快将该用户加回到策略或组中。The user should be added back into the policy or group as soon as possible.

  • 删除策略。Delete the policy. 如果不再需要该策略,请将其删除If the policy is no longer required, delete it.

管理对云应用的访问权限Manage access to cloud apps

使用以下管理选项控制和管理你的条件访问策略:Use the following Manage options to control and manage your Conditional Access policies:

显示用于 CA 策略的“管理”选项的屏幕截图,其中包括命名位置、自定义控件、使用条款、VPN 连接性以及所选的经典策略。

命名位置Named locations

使用条件访问策略的位置条件可将访问控制设置绑定到用户的网络位置。The location condition of a Conditional Access policy enables you to tie access controls settings to the network locations of your users. 使用命名位置可以创建 IP 地址范围、国家和地区的逻辑分组。With Named Locations, you can create logical groupings of IP address ranges or countries and regions.

自定义控件Custom controls

自定义控件可将用户重定向到兼容的服务,以满足 Azure AD 之外的身份验证要求。Custom controls redirect your users to a compatible service to satisfy authentication requirements outside of Azure AD. 若要满足此控制要求,用户浏览器将重定向到外部服务,执行任何需要的身份验证,然后重定向回 Azure AD。To satisfy this control, a user's browser is redirected to the external service, performs any required authentication, and is then redirected back to Azure AD. Azure AD 将验证响应,如果用户已成功完成身份验证或验证,该用户将继续留在条件访问流中。Azure AD verifies the response and, if the user was successfully authenticated or validated, the user continues in the Conditional Access flow.

使用条款Terms of use

在访问环境中的某些云应用之前,你可能希望通过使用条款 (ToU) 来获取用户的同意。Before accessing certain cloud apps in your environment, you can get consent from the users by them accepting your Terms of use (ToU). 请按照以下快速入门创建使用条款Follow this Quickstart to create Terms of Use.

条件访问疑难解答Troubleshoot Conditional Access

如果用户遇到条件性访问策略问题,请收集以下信息以便于进行故障排除。When a user is having an issue with a Conditional Access policy, collect the following information to facilitate troubleshooting.

  • 用户主体名称User principle Name

  • 用户显示名称User display name

  • 操作系统名称Operating system name

  • 时间戳(近似为正常)Time stamp (approximate is ok)

  • 目标应用程序Target application

  • 客户端应用程序类型(浏览器与客户端)Client application type (browser vs client)

  • 相关 ID(这对于登录是唯一的)Correlation ID (this is unique to the sign-in)

如果用户收到了包含“更多详细信息”链接的消息,则可以为你收集大部分此类信息。If the user received a message with a More details link, they can collect most of this information for you.


收集信息后,请参阅以下资源:Once you have collected the information, See the following resources:

  • 条件访问导致的登录问题 - 使用错误消息和 Azure AD 登录日志了解与条件访问相关的意外登录结果。Sign-in problems with Conditional Access – Understand unexpected sign-in outcomes related to Conditional Access using error messages and Azure AD sign-ins log.

  • 使用假设工具 - 了解为什么在特定情况下将策略应用于用户或未应用于用户,或者策略是否适用于已知状态。Using the What-If tool - Understand why a policy was or wasn't applied to a user in a specific circumstance or if a policy would apply in a known state.

后续步骤Next Steps

详细了解多重身份验证Learn more about Multi-factor authentication

详细了解标识保护Learn more about Identity Protection

使用 Microsoft Graph API 管理条件性访问策略Manage Conditional Access policies with Microsoft Graph API