Merge branch 'MicrosoftDocs:main' into main

Author: danielledennis

.openpublishing.redirection.json

@@ -31,7 +31,7 @@ Microsoft verified partners can help you onboard Microsoft Entra Permissions Man
 * **Onboarding and Deployment Support**
 
     Partners can guide you through the entire onboarding and deployment process for 
-    ermissions Management across AWS, Azure, and GCP.
+    Permissions Management across AWS, Azure, and GCP.
 
 
 ## Partner list

articles/active-directory/cloud-infrastructure-entitlement-management/partner-list.md

@@ -94,7 +94,6 @@ To apply this grant control, the device must be registered in Azure AD, which re
 The following client apps support this setting, this list isn't exhaustive and is subject to change::
 
 - Microsoft Azure Information Protection
-- Microsoft Bookings
 - Microsoft Cortana
 - Microsoft Dynamics 365
 - Microsoft Edge
@@ -114,7 +113,6 @@ The following client apps support this setting, this list isn't exhaustive and i
 - Microsoft PowerPoint
 - Microsoft SharePoint
 - Microsoft Skype for Business
-- Microsoft StaffHub
 - Microsoft Stream
 - Microsoft Teams
 - Microsoft To-Do

articles/active-directory/conditional-access/concept-conditional-access-grant.md

@@ -206,7 +206,7 @@ Networks and network services used by clients connecting to identity and resourc
 
 ### Supported location policies
 
-CAE only has insight into [IP-based named locations](../conditional-access/location-condition.md#ip-address-ranges). CAE doesn't have insight into other location conditions like [MFA trusted IPs](../authentication/howto-mfa-mfasettings.md#trusted-ips) or country-based locations. When a user comes from an MFA trusted IP, trusted location that includes MFA Trusted IPs, or country location, CAE won't be enforced after that user moves to a different location. In those cases, Azure AD will issue a one-hour access token without instant IP enforcement check. 
+CAE only has insight into [IP-based named locations](../conditional-access/location-condition.md#ipv4-and-ipv6-address-ranges). CAE doesn't have insight into other location conditions like [MFA trusted IPs](../authentication/howto-mfa-mfasettings.md#trusted-ips) or country-based locations. When a user comes from an MFA trusted IP, trusted location that includes MFA Trusted IPs, or country location, CAE won't be enforced after that user moves to a different location. In those cases, Azure AD will issue a one-hour access token without instant IP enforcement check. 
 
 > [!IMPORTANT]
 > If you want your location policies to be enforced in real time by continuous access evaluation, use only the [IP based Conditional Access location condition](../conditional-access/location-condition.md) and configure all IP addresses, **including both IPv4 and IPv6**, that can be seen by your identity provider and resources provider. Do not use country location conditions or the trusted ips feature that is available in Azure AD Multi-Factor Authentication's service settings page.

articles/active-directory/conditional-access/concept-continuous-access-evaluation.md

@@ -6,7 +6,7 @@ services: active-directory
 ms.service: active-directory
 ms.subservice: conditional-access
 ms.topic: how-to
-ms.date: 08/22/2022
+ms.date: 02/23/2023
 
 ms.author: joflore
 author: MicrosoftGuyJFlo
@@ -17,7 +17,7 @@ ms.collection: M365-identity-device-management
 ---
 # Conditional Access: Block access by location
 
-With the location condition in Conditional Access, you can control access to your cloud apps based on the network location of a user. The location condition is commonly used to block access from countries/regions where your organization knows traffic shouldn't come from.
+With the location condition in Conditional Access, you can control access to your cloud apps based on the network location of a user. The location condition is commonly used to block access from countries/regions where your organization knows traffic shouldn't come from. For more information about IPv6 support, see the article [IPv6 support in Azure Active Directory](/troubleshoot/azure/active-directory/azure-ad-ipv6-support).
 
 > [!NOTE]
 > Conditional Access policies are enforced after first-factor authentication is completed. Conditional Access isn't intended to be an organization's first line of defense for scenarios like denial-of-service (DoS) attacks, but it can use signals from these events to determine access.

articles/active-directory/conditional-access/howto-conditional-access-policy-location.md

@@ -35,7 +35,6 @@ ms.custom: mode-api
 > * [Node.js](https://nodejs.org/en/download/)
 > * [Visual Studio Code](https://code.visualstudio.com/download) or another code editor
 > 
-> 
 > ### Download and configure the sample app
 > 
 > #### Step 1: Configure the application in Azure portal

articles/active-directory/conditional-access/location-condition.md

@@ -9,7 +9,7 @@ ms.service: active-directory
 ms.subservice: develop
 ms.topic: conceptual
 ms.workload: identity
-ms.date: 05/07/2020
+ms.date: 02/21/2023
 ms.author: henrymbugua
 ms.reviewer: saeeda, jeferrie
 ms.custom: "devx-track-csharp, aaddev"
@@ -29,9 +29,9 @@ This article applies to MSAL.NET 3.x. For MSAL.NET 2.x, see [Azure AD B2C specif
 
 The authority format for Azure AD B2C is: `https://{azureADB2CHostname}/tfp/{tenant}/{policyName}`
 
-- `azureADB2CHostname` - The name of the Azure AD B2C tenant plus the host. For example, *contosob2c.b2clogin.com*.
-- `tenant` - The domain name or the directory (tenant) ID of the Azure AD B2C tenant. For example, *contosob2c.onmicrosoft.com* or a GUID, respectively.
-- `policyName` - The name of the user flow or custom policy to apply. For example, a sign-up/sign-in policy like *b2c_1_susi*.
+- `azureADB2CHostname` - The name of the Azure AD B2C tenant plus the host. For example, _contosob2c.b2clogin.com_.
+- `tenant` - The domain name or the directory (tenant) ID of the Azure AD B2C tenant. For example, _contosob2c.onmicrosoft.com_ or a GUID, respectively.
+- `policyName` - The name of the user flow or custom policy to apply. For example, a sign-up/sign-in policy like _b2c_1_susi_.
 
 For more information about Azure AD B2C authorities, see [Set redirect URLs to b2clogin.com](../../active-directory-b2c/b2clogin.md).
 
@@ -77,7 +77,7 @@ catch (MsalUiRequiredException ex)
                         .WithAccount(account)
                         .WithParentActivityOrWindow(ParentActivityOrWindow)
                         .ExecuteAsync();
-}  
+}
 ```
 
 In the preceding code snippet:
@@ -116,12 +116,12 @@ private async void EditProfileButton_Click(object sender, RoutedEventArgs e)
 
 For more information on the ROPC flow, see [Sign in with resource owner password credentials grant](v2-oauth-ropc.md).
 
-The ROPC flow is **not recommended** because asking a user for their password in your application is not secure. For more information about this problem, see [What’s the solution to the growing problem of passwords?](https://news.microsoft.com/features/whats-solution-growing-problem-passwords-says-microsoft/).
+The ROPC flow is **not recommended** because asking a user for their password in your application isn't secure. For more information about this problem, see [What’s the solution to the growing problem of passwords?](https://news.microsoft.com/features/whats-solution-growing-problem-passwords-says-microsoft/).
 
 By using username/password in an ROPC flow, you sacrifice several things:
 
 - Core tenets of modern identity: The password can be fished or replayed because the shared secret can be intercepted. By definition, ROPC is incompatible with passwordless flows.
-- Users who need to do MFA won't be able to sign in (as there is no interaction).
+- Users who use multi-factor authentication (MFA) won't be able to sign in as there's no interaction.
 - Users won't be able to use single sign-on (SSO).
 
 ### Configure the ROPC flow in Azure AD B2C
@@ -137,21 +137,19 @@ AcquireTokenByUsernamePassword(
             SecureString password)
 ```
 
-This `AcquireTokenByUsernamePassword` method takes the following parameters:
+The `AcquireTokenByUsernamePassword` method takes the following parameters:
 
-- The *scopes* for which to obtain an access token.
-- A *username*.
-- A SecureString *password* for the user.
+- The _scopes_ for which to obtain an access token.
+- A _username_.
+- A SecureString _password_ for the user.
 
 ### Limitations of the ROPC flow
 
 The ROPC flow **only works for local accounts**, where your users have registered with Azure AD B2C using an email address or username. This flow doesn't work when federating to an external identity provider supported by Azure AD B2C (Facebook, Google, etc.).
 
 ## Google auth and embedded webview
 
-If you're using Google as an identity provider, we recommend you use the system browser as Google doesn't allow [authentication from embedded webviews](https://developers.googleblog.com/2016/08/modernizing-oauth-interactions-in-native-apps.html). Currently, `login.microsoftonline.com` is a trusted authority with Google and will work with embedded webview. However, `b2clogin.com` is not a trusted authority with Google, so users will not be able to authenticate.
-
-We'll provide an update to this [issue](https://github.com/AzureAD/microsoft-authentication-library-for-dotnet/issues/688) if things change.
+If you're using Google as an identity provider, we recommend you use the system browser as Google doesn't allow [authentication from embedded webviews](https://developers.googleblog.com/2016/08/modernizing-oauth-interactions-in-native-apps.html). Currently, `login.microsoftonline.com` is a trusted authority with Google and will work with embedded webview. However, `b2clogin.com` isn't a trusted authority with Google, so users won't be able to authenticate.
 
 ## Token caching in MSAL.NET
 
@@ -186,6 +184,6 @@ For more information about specifying which claims are returned by your user flo
 
 More details about acquiring tokens interactively with MSAL.NET for Azure AD B2C applications are provided in the following sample.
 
-| Sample | Platform | Description|
-|------ | -------- | -----------|
-|[active-directory-b2c-xamarin-native](https://github.com/Azure-Samples/active-directory-b2c-xamarin-native) | Xamarin iOS, Xamarin Android, UWP | A Xamarin Forms app that uses MSAL.NET to authenticate users via Azure AD B2C and then access a web API with the tokens returned.|
+| Sample                                                                                                      | Platform                          | Description                                                                                                                       |
+| ----------------------------------------------------------------------------------------------------------- | --------------------------------- | --------------------------------------------------------------------------------------------------------------------------------- |
+| [active-directory-b2c-xamarin-native](https://github.com/Azure-Samples/active-directory-b2c-xamarin-native) | Xamarin iOS, Xamarin Android, UWP | A Xamarin Forms app that uses MSAL.NET to authenticate users via Azure AD B2C and then access a web API with the tokens returned. |

articles/active-directory/conditional-access/media/location-condition/sign-in-logs-showing-ip-address-filter-for-ipv6.png

@@ -431,7 +431,7 @@ The Microsoft Graph endpoint (`https://graph.microsoft.com`) exposes REST APIs t
 Run the following method to [create a new federated identity credential](/graph/api/application-post-federatedidentitycredentials) on your app (specified by the object ID of the app).  The *issuer* identifies GitHub as the external token issuer.  *subject* identifies the GitHub organization, repo, and environment for your GitHub Actions workflow.  When the GitHub Actions workflow requests Microsoft identity platform to exchange a GitHub token for an access token, the values in the federated identity credential are checked against the provided GitHub token.
 
 ```azurecli
-az rest --method POST --uri 'https://graph.microsoft.com/applications/f6475511-fd81-4965-a00e-41e7792b7b9c/federatedIdentityCredentials' --body '{"name":"Testing","issuer":"https://token.actions.githubusercontent.com/","subject":"repo:octo-org/octo-repo:environment:Production","description":"Testing","audiences":["api://AzureADTokenExchange"]}' 
+az rest --method POST --uri 'https://graph.microsoft.com/applications/f6475511-fd81-4965-a00e-41e7792b7b9c/federatedIdentityCredentials' --body '{"name":"Testing","issuer":"https://token.actions.githubusercontent.com","subject":"repo:octo-org/octo-repo:environment:Production","description":"Testing","audiences":["api://AzureADTokenExchange"]}' 
 ```
 
 And you get the response:
@@ -443,15 +443,15 @@ And you get the response:
   ],
   "description": "Testing",
   "id": "1aa3e6a7-464c-4cd2-88d3-90db98132755",
-  "issuer": "https://token.actions.githubusercontent.com/",
+  "issuer": "https://token.actions.githubusercontent.com",
   "name": "Testing",
   "subject": "repo:octo-org/octo-repo:environment:Production"
 }
 ```
 
 *name*: The name of your Azure application.
 
-*issuer*: The path to the GitHub OIDC provider: `https://token.actions.githubusercontent.com/`. This issuer will become trusted by your Azure application.
+*issuer*: The path to the GitHub OIDC provider: `https://token.actions.githubusercontent.com`. This issuer will become trusted by your Azure application.
 
 *subject*: Before Azure will grant an access token, the request must match the conditions defined here.
 - For Jobs tied to an environment: `repo:< Organization/Repository >:environment:< Name >`