[Microsoft Entra ID] Conditioanl Access bulk casing fix

MicrosoftDocs · Aug 1, 2023 · be53745 · be53745
1 parent 85c0d2b
commit be53745
Show file tree

Hide file tree

Showing 30 changed files with 38 additions and 38 deletions.
diff --git a/docs/architecture/multi-tenant-user-management-introduction.md b/docs/architecture/multi-tenant-user-management-introduction.md
@@ -67,7 +67,7 @@ The following conceptual and how-to articles provide information about Azure AD
 - [B2B and Office 365 external sharing](../external-identities/o365-external-user.md) explains the similarities and differences among sharing resources through B2B, Office 365, and SharePoint/OneDrive.
 - [Properties on an Azure AD B2B collaboration user](../external-identities/user-properties.md) describes the properties and states of the external user object in Azure AD. The description provides details before and after invitation redemption.
 - [B2B user tokens](../external-identities/user-token.md) provides examples of the bearer tokens for B2B for an external user.
-- [Conditional access for B2B](../external-identities/authentication-conditional-access.md) describes how Conditional Access and MFA work for external users.
+- [Conditional Access for B2B](../external-identities/authentication-conditional-access.md) describes how Conditional Access and MFA work for external users.
 - [Cross-tenant access settings](../external-identities/cross-tenant-access-overview.md) provides granular control over how external Azure AD organizations collaborate with you (inbound access) and how your users collaborate with external Azure AD organizations (outbound access).
 - [Cross-tenant synchronization overview](../multi-tenant-organizations/cross-tenant-synchronization-overview.md) explains how to automate creating, updating, and deleting Azure AD B2B collaboration users across tenants in an organization.
 

diff --git a/docs/external-id/customers/concept-supported-features-customers.md b/docs/external-id/customers/concept-supported-features-customers.md
@@ -38,7 +38,7 @@ Although workforce tenants and customer tenants are built on the same underlying
 | **Groups** | [Groups](../../fundamentals/active-directory-groups-create-azure-portal.md) can be used to manage administrative and user accounts.| Groups can be used to manage administrative accounts. Support for Azure AD groups and [application roles](how-to-use-app-roles-customers.md) is being phased into customer tenants. For the latest updates, see [Groups and application roles support](reference-group-app-roles-support.md). |
 | **Roles and administrators**| [Roles and administrators](../../fundamentals/active-directory-users-assign-role-azure-portal.md) are fully supported for administrative and user accounts. | Roles aren't supported with customer accounts. Customer accounts don't have access to tenant resources.|
 | **Custom domain names** |  You can use [custom domains](../../fundamentals/add-custom-domain.md) for administrative accounts only. | Not currently supported. However, the URLs visible to customers in sign-up and sign-in pages are neutral, unbranded URLs. [Learn more](concept-branding-customers.md)|
-| **Conditional Access** | [Conditional Access](../../conditional-access/overview.md) is fully supported for administrative and user accounts. | A subset of the Azure AD Conditional access is available. Multifactor authentication (MFA) is supported with local accounts in customer tenants. [Learn more](concept-security-customers.md).|
+| **Conditional Access** | [Conditional Access](../../conditional-access/overview.md) is fully supported for administrative and user accounts. | A subset of the Azure AD Conditional Access is available. Multifactor authentication (MFA) is supported with local accounts in customer tenants. [Learn more](concept-security-customers.md).|
 |   **Identity protection**    |   Provides ongoing risk detection for your Azure AD tenant. It allows organizations to discover, investigate, and remediate identity-based risks.    |   A subset of the Azure AD Identity Protection risk detections is available. [Learn more](how-to-identity-protection-customers.md).    |
 |   **Application registration**     |   SAML relying parties, OpenID Connect, and OAuth2    |   OpenID Connect and OAuth2    |
 |   **Custom authentication extension**    |   Add claims from external systems.    |   Add claims from external systems.    |  

diff --git a/docs/external-id/customers/quickstart-trial-setup.md b/docs/external-id/customers/quickstart-trial-setup.md
@@ -33,7 +33,7 @@ During the free trial period, you'll have access to all product features with fe
 | **MFA** (With email OTP.)  | :heavy_check_mark: |  :heavy_check_mark:  |  
 | **Custom token augmentation** (From external sources.) |  :heavy_check_mark: |  :heavy_check_mark:  |
 | **Social identity providers**   |  :heavy_check_mark: |  :heavy_check_mark:  |
-| **Identity Protection** (Conditional access for adaptive risk-based policies.)  | :x: |  :heavy_check_mark:  |
+| **Identity Protection** (Conditional Access for adaptive risk-based policies.)  | :x: |  :heavy_check_mark:  |
 | Default, least-access privileges for CIAM end-users. |  :heavy_check_mark: |  :heavy_check_mark:  |
 | **Rich authorization** (Including group and role management.)  |  :heavy_check_mark: |  :heavy_check_mark:  | 
 | **Customizable** (Sign-in/sign-up experiences - background, logo, strings.) |  :heavy_check_mark: |  :heavy_check_mark:  |

diff --git a/docs/fundamentals/compare.md b/docs/fundamentals/compare.md
@@ -37,7 +37,7 @@ Most IT administrators are familiar with Active Directory Domain Services concep
 | Mid-tier/Daemon services|Services running in on-premises environments normally use AD service accounts or group Managed Service Accounts (gMSA) to run. These apps will then inherit the permissions of the service account.| Azure AD provides [managed identities](../managed-identities-azure-resources/index.yml) to run other workloads in the cloud. The lifecycle of these identities is managed by Azure AD and is tied to the resource provider and it can't be used for other purposes to gain backdoor access.|
 | **Devices**|||
 | Mobile|Active Directory doesn't natively support mobile devices without third-party solutions.| Microsoft’s mobile device management solution, Microsoft Intune, is integrated with Azure AD. Microsoft Intune provides device state information to the identity system to evaluate during authentication. |
-| Windows desktops|Active Directory provides the ability to domain join Windows devices to manage them using Group Policy, System Center Configuration Manager, or other third-party solutions.|Windows devices can be [joined to Azure AD](../devices/index.yml). Conditional access can check if a device is Azure AD joined as part of the authentication process. Windows devices can also be managed with [Microsoft Intune](/intune/what-is-intune). In this case, Conditional Access, will consider whether a device is compliant (for example, up-to-date security patches and virus signatures) before allowing access to the apps.|
+| Windows desktops|Active Directory provides the ability to domain join Windows devices to manage them using Group Policy, System Center Configuration Manager, or other third-party solutions.|Windows devices can be [joined to Azure AD](../devices/index.yml). Conditional Access can check if a device is Azure AD joined as part of the authentication process. Windows devices can also be managed with [Microsoft Intune](/intune/what-is-intune). In this case, Conditional Access, will consider whether a device is compliant (for example, up-to-date security patches and virus signatures) before allowing access to the apps.|
 | Windows servers| Active Directory provides strong management capabilities for on-premises Windows servers using Group Policy or other management solutions.| Windows servers virtual machines in Azure can be managed with [Azure AD Domain Services](../../active-directory-domain-services/index.yml). [Managed identities](../managed-identities-azure-resources/index.yml) can be used when VMs need access to the identity system directory or resources.|
 | Linux/Unix workloads|Active Directory doesn't natively support non-Windows without third-party solutions, although Linux machines can be configured to authenticate with Active Directory as a Kerberos realm.|Linux/Unix VMs can use [managed identities](../managed-identities-azure-resources/index.yml) to access the identity system or resources. Some organizations, migrate these workloads to cloud container technologies, which can also use managed identities.|
 

diff --git a/docs/fundamentals/whats-new-archive.md b/docs/fundamentals/whats-new-archive.md
@@ -560,7 +560,7 @@ In the Azure portal, the required permissions list is under API Permissions with
 
 ---
 
-### Public Preview - Conditional access Authentication strengths 
+### Public Preview - Conditional Access Authentication strengths 
 
 
 
@@ -572,7 +572,7 @@ We're announcing Public preview of Authentication strength, a Conditional Access
 
 ---
 
-### Public Preview - Conditional access authentication strengths for external identities
+### Public Preview - Conditional Access authentication strengths for external identities
 
 
 **Type:** New feature  

diff --git a/docs/id-governance/identity-governance-applications-define.md b/docs/id-governance/identity-governance-applications-define.md
@@ -35,7 +35,7 @@ Organizations with compliance requirements or risk management plans have sensiti
 
 In this section, you'll write down the organizational policies you plan to use to determine access to the application. You can record this as a table in a spreadsheet, for example
 
-|App Role|Prerequisite for access|Approvers|Default duration of access|Separation of duties constraints|Conditional access policies|
+|App Role|Prerequisite for access|Approvers|Default duration of access|Separation of duties constraints|Conditional Access policies|
 |:--|-|-|-|-|-|
 |*Western Sales*|Member of sales team|user's manager|Yearly review|Cannot have *Eastern Sales* access|Multifactor authentication (MFA) and registered device required for access|
 |*Western Sales*|Any employee outside of sales|head of Sales department|90 days|N/A|MFA and registered device required for access|

diff --git a/docs/id-governance/identity-governance-applications-deploy.md b/docs/id-governance/identity-governance-applications-deploy.md
@@ -21,7 +21,7 @@ ms.collection: M365-identity-device-management
 
 
 In previous sections, you [defined your governance policies for an application](identity-governance-applications-define.md) and [integrated that application with Azure AD](identity-governance-applications-integrate.md).  In this section, you configure the Azure AD Conditional Access and entitlement management features to control ongoing access to your applications.  You establish
-* Conditional access policies, for how a user authenticates to Azure AD for an application integrated with Azure AD for single sign-on
+* Conditional Access policies, for how a user authenticates to Azure AD for an application integrated with Azure AD for single sign-on
 * Entitlement management policies, for how a user obtains and keeps assignments to application roles and membership in groups
 * Access review policies, for how often group memberships are reviewed
 
@@ -31,7 +31,7 @@ Once these policies are deployed, you can then monitor the ongoing behavior of A
 
 In this section, you establish the Conditional Access policies that are in scope for determining whether an authorized user is able to sign into the app, based on factors like the user's authentication strength or device status.
 
-Conditional access is only possible for applications that rely upon Azure AD for single sign-on (SSO).  If the application isn't able to be integrated for SSO, then continue in the next section.
+Conditional Access is only possible for applications that rely upon Azure AD for single sign-on (SSO).  If the application isn't able to be integrated for SSO, then continue in the next section.
 
 1. **Upload the terms of use (TOU) document, if needed.** If you require users to accept a term of use (TOU) prior to accessing the application, then create and [upload the TOU document](../conditional-access/terms-of-use.md) so that it can be included in a Conditional Access policy.
 1. **Verify users are ready for Azure Active Directory Multi-Factor Authentication.** We recommend requiring Azure AD Multi-Factor Authentication for business critical applications integrated via federation. For these applications, there should be a policy that requires the user to have met a multi-factor authentication requirement prior to Azure AD permitting them to sign into the application.  Some organizations may also block access by locations, or [require the user to access from a registered device](../conditional-access/howto-conditional-access-policy-compliant-device.md).  If there's no suitable policy already that includes the necessary conditions for authentication, location, device and TOU, then [add a policy to your Conditional Access deployment](../conditional-access/plan-conditional-access.md).

diff --git a/docs/id-governance/identity-governance-overview.md b/docs/id-governance/identity-governance-overview.md
@@ -80,7 +80,7 @@ In addition to the features listed above, additional Microsoft Entra features fr
 |Lifecycle Workflows|Admins can enable the automation of the lifecycle process based user conditions.|[Lifecycle Workflows](what-are-lifecycle-workflows.md)|
 |Access requests|End users can request group membership or application access. End users, including guests from other organizations, can request access to access packages.|[Entitlement management](entitlement-management-overview.md)|
 |Workflow|Resource owners can define the approvers and escalation approvers for access requests and approvers for role activation requests.  |[Entitlement management](entitlement-management-overview.md) and [PIM](../privileged-identity-management/pim-configure.md)|
-|Policy and role management|Admin can define Conditional Access policies for run-time access to applications.  Resource owners can define policies for user's access via access packages.|[Conditional access](../conditional-access/overview.md) and [Entitlement management](entitlement-management-overview.md) policies|
+|Policy and role management|Admin can define Conditional Access policies for run-time access to applications.  Resource owners can define policies for user's access via access packages.|[Conditional Access](../conditional-access/overview.md) and [Entitlement management](entitlement-management-overview.md) policies|
 |Access certification|Admins can enable recurring access recertification for: SaaS apps, on-premises apps, cloud group memberships, Azure AD or Azure Resource role assignments. Automatically remove resource access, block guest access and delete guest accounts.|[Access reviews](access-reviews-overview.md), also surfaced in [PIM](../privileged-identity-management/pim-create-azure-ad-roles-and-resource-roles-review.md)|
 |Fulfillment and provisioning|Automatic provisioning and deprovisioning into Azure AD connected apps, including via SCIM, LDAP, SQL and into SharePoint Online sites. |[user provisioning](../app-provisioning/user-provisioning.md)|
 |Reporting and analytics|Admins can retrieve audit logs of recent user provisioning and sign on activity. Integration with Azure Monitor and 'who has access' via access packages.|[Azure AD reports](../reports-monitoring/overview-reports.md) and [monitoring](../reports-monitoring/overview-monitoring.md)|

diff --git a/docs/id-governance/privileged-identity-management/groups-role-settings.md b/docs/id-governance/privileged-identity-management/groups-role-settings.md
@@ -101,7 +101,7 @@ For example, users might use an Intune-compliant device to activate group member
 
 To prevent this situation, you can scope Conditional Access policies to enforce certain requirements for eligible users directly. For example, you can require users who are eligible for certain group membership/ownership to always use Intune-compliant devices.
 
-To learn more about Conditional Access authentication context, see [Conditional access: Cloud apps, actions, and authentication context](../conditional-access/concept-conditional-access-cloud-apps.md#authentication-context).
+To learn more about Conditional Access authentication context, see [Conditional Access: Cloud apps, actions, and authentication context](../conditional-access/concept-conditional-access-cloud-apps.md#authentication-context).
 
 ### Require justification on activation
 

diff --git a/...governance/privileged-identity-management/pim-how-to-change-default-settings.md b/...governance/privileged-identity-management/pim-how-to-change-default-settings.md
@@ -101,7 +101,7 @@ Both policies can enforce the same or different requirements depending on your n
 
 Another option is to scope Conditional Access policies that enforce certain requirements to eligible users directly. For example, you can require users who are eligible for certain roles to always use Intune-compliant devices.
 
-To learn more about Conditional Access authentication context, see [Conditional access: Cloud apps, actions, and authentication context](../conditional-access/concept-conditional-access-cloud-apps.md#authentication-context).
+To learn more about Conditional Access authentication context, see [Conditional Access: Cloud apps, actions, and authentication context](../conditional-access/concept-conditional-access-cloud-apps.md#authentication-context).
 
 ### Require justification on activation
 

diff --git a/...ce/privileged-identity-management/pim-resource-roles-configure-role-settings.md b/...ce/privileged-identity-management/pim-resource-roles-configure-role-settings.md
@@ -95,7 +95,7 @@ For example, users might use an Intune-compliant device to activate the role. Th
 
 To prevent this situation, you can scope Conditional Access policies to enforce certain requirements for eligible users directly. For example, you can require users who are eligible for certain roles to always use Intune-compliant devices.
 
-To learn more about Conditional Access authentication context, see [Conditional access: Cloud apps, actions, and authentication context](../conditional-access/concept-conditional-access-cloud-apps.md#authentication-context).
+To learn more about Conditional Access authentication context, see [Conditional Access: Cloud apps, actions, and authentication context](../conditional-access/concept-conditional-access-cloud-apps.md#authentication-context).
 
 ### Require justification on activation
 

diff --git a/docs/identity-platform/apple-sso-plugin.md b/docs/identity-platform/apple-sso-plugin.md
@@ -308,7 +308,7 @@ Use the following configuration to enable Just in Time Registration for iOS/iPad
 
 Learn more about Just in Time Registration [here](https://techcommunity.microsoft.com/t5/intune-customer-success/just-in-time-registration-for-ios-ipados-with-microsoft-intune/ba-p/3660843). 
 
-#### Conditional access policies and password changes
+#### Conditional Access policies and password changes
 Microsoft Enterprise SSO plug-in for Apple devices is compatible with various [Azure AD Conditional Access policies](/azure/active-directory/conditional-access/overview) and password change events. `browser_sso_interaction_enabled` is required to be enabled to achieve compatibility. 
 
 Compatible events and policies are documented in the following sections:

diff --git a/...y-platform/includes/error-handling-and-tips/error-handling-claims-challenges.md b/...y-platform/includes/error-handling-and-tips/error-handling-claims-challenges.md
@@ -8,7 +8,7 @@ ms.topic: include
 # Purpose:
 # Ingested by Microsoft identity platform articles in /articles/active-directory/develop/* that document the error handling Conditional Access and claims challenges for the different platforms.
 ---
-## Conditional access and claims challenges
+## Conditional Access and claims challenges
 
 When getting tokens silently, your application may receive errors when a [Conditional Access claims challenge](../../v2-conditional-access-dev-guide.md) such as MFA policy is required by an API you're trying to access.
 

diff --git a/docs/identity/authentication/concept-mfa-licensing.md b/docs/identity/authentication/concept-mfa-licensing.md
@@ -53,7 +53,7 @@ The following table provides a list of the features that are available in the va
 | Trusted IPs | | | | ● | ● |
 | Remember MFA for trusted devices | | ● | ● | ● | ● |
 | MFA for on-premises applications | | | | ● | ● |
-| Conditional access | | | | ● | ● |
+| Conditional Access | | | | ● | ● |
 | Risk-based Conditional Access | | | | | ● |
 
 ## Compare multi-factor authentication policies

diff --git a/docs/identity/authentication/tutorial-enable-azure-mfa.md b/docs/identity/authentication/tutorial-enable-azure-mfa.md
@@ -188,7 +188,7 @@ If you no longer want to use the Conditional Access policy that you configured a
 
 1. Search for and select **Azure Active Directory**, and then select **Security** from the menu on the left-hand side.
 
-1. Select **Conditional access**, and then select the policy that you created, such as **MFA Pilot**.
+1. Select **Conditional Access**, and then select the policy that you created, such as **MFA Pilot**.
 
 1. select **Delete**, and then confirm that you want to delete the policy.