Merge branch 'main' into mde-2012/2016

Author: bmansheim

articles/active-directory-b2c/embedded-login.md

@@ -9,7 +9,7 @@ manager: CelesteDG
 ms.service: active-directory
 ms.workload: identity
 ms.topic: how-to
-ms.date: 08/17/2021
+ms.date: 06/17/2022
 ms.custom: project-no-code
 ms.author: kengaderdus
 ms.subservice: B2C
@@ -74,11 +74,11 @@ The **Sources** attribute contains the URI of your web application. Add a space
 - The URI must use the https scheme.  
 - The full URI of the web app must be specified. Wildcards are not supported.
 
-In addition, we recommend that you also block your own domain name from being embedded in an iframe by setting the Content-Security-Policy and X-Frame-Options headers respectively on your application pages. This will mitigate security concerns around older browsers related to nested embedding of iframes.
+In addition, we recommend that you also block your own domain name from being embedded in an iframe by setting the `Content-Security-Policy` and `X-Frame-Options` headers respectively on your application pages. This will mitigate security concerns around older browsers related to nested embedding of iframes.
 
 ## Adjust policy user interface
 
-With Azure AD B2C [user interface customization](customize-ui.md), you have almost full control over the HTML and CSS content presented to users. Follow the steps for customizing an HTML page using content definitions. To fit the Azure AD B2C user interface into the iframe size, provide clean HTML page without background and extra spaces.  
+With Azure AD B2C [user interface customization](customize-ui.md), you have almost full control over the HTML and CSS content presented to users. Follow the steps for customizing an HTML page using content definitions. To fit the Azure AD B2C user interface into the iframe size, provide clean HTML page without a background and extra spaces.  
 
 The following CSS code hides the Azure AD B2C HTML elements and adjusts the size of the panel to fill the iframe.
 
@@ -96,9 +96,9 @@ div.api_container{
 }
 ```
 
-In some cases, you might want to notify to your application of which Azure AD B2C page is currently being presented. For example, when a user selects the sign-up option, you might want the application to respond by hiding the links for signing in with a social account or adjusting the iframe size.
+In some cases, you may want to notify your application about the Azure AD B2C page that's currently being presented. For example, when a user selects the sign-up option, you may want the application to respond by hiding the links for signing in with a social account or adjusting the iframe size.
 
-To notify your application of the current Azure AD B2C page, [enable your policy for JavaScript](./javascript-and-page-layout.md), and then use HTML5 post messages. The following JavaScript code sends a post message to the app with `signUp`:
+To notify your application about the current Azure AD B2C page, [enable your policy for JavaScript](./javascript-and-page-layout.md), and then use HTML5 to post messages. The following JavaScript code sends a post message to the app with `signUp`:
 
 ```javascript
 window.parent.postMessage("signUp", '*');
@@ -108,7 +108,7 @@ window.parent.postMessage("signUp", '*');
 
 When a user selects the sign-in button, the [web app](integrate-with-app-code-samples.md#web-apps-and-apis) generates an authorization request that takes the user to Azure AD B2C sign-in experience. After sign-in is complete, Azure AD B2C returns an ID token, or authorization code, to the configured redirect URI within your application.
 
-To support embedded login, the iframe **src** property points to the sign-in controller, such as `/account/SignUpSignIn`, which generates the authorization request and redirects the user to Azure AD B2C policy.
+To support embedded login, the iframe `src` attribute points to the sign-in controller, such as `/account/SignUpSignIn`, which generates the authorization request and redirects the user to Azure AD B2C policy.
 
 ```html
 <iframe id="loginframe" frameborder="0" src="/account/SignUpSignIn"></iframe>
@@ -134,9 +134,9 @@ The redirect URI can be the same redirect URI used by the iframe. You can skip t
 
 ## Configure a single-page application
 
-For a single-page application, you'll also need to a second "sign-in" HTML page that loads into the iframe. This sign-in page hosts the authentication library code that generates the authorization code and returns the token.
+For a single-page application, you'll also need a second "sign-in" HTML page that loads into the iframe. This sign-in page hosts the authentication library code that generates the authorization code and returns the token.
 
-When the single-page application needs the access token, use JavaScript code to obtain the access token from the iframe and object that contains it.
+When the single-page application needs the access token, use JavaScript code to obtain the access token from the iframe and the object that contains it.
 
 > [!NOTE]
 > Running MSAL 2.0 in an iframe is not currently supported.

articles/active-directory-b2c/whats-new-docs.md

@@ -13,7 +13,7 @@ manager: CelesteDG
 
 # Azure Active Directory B2C: What's new
 
-Welcome to what's new in Azure Active Directory B2C documentation. This article lists new docs that have been added and those that have had significant updates in the last three months. To learn what's new with the B2C service, see [What's new in Azure Active Directory](../active-directory/fundamentals/whats-new.md).
+Welcome to what's new in Azure Active Directory B2C documentation. This article lists new docs that have been added and those that have had significant updates in the last three months. To learn what's new with the B2C service, see [What's new in Azure Active Directory](../active-directory/fundamentals/whats-new.md) and [Azure AD B2C developer release notes](custom-policy-developer-notes.md)
 
 
 ## May 2022

articles/active-directory-domain-services/network-considerations.md

@@ -9,7 +9,7 @@ ms.service: active-directory
 ms.subservice: domain-services
 ms.workload: identity
 ms.topic: conceptual
-ms.date: 01/06/2022
+ms.date: 06/20/2022
 ms.author: justinha
 
 ---
@@ -42,7 +42,7 @@ As you design the virtual network for Azure AD DS, the following considerations
 
 A managed domain connects to a subnet in an Azure virtual network. Design this subnet for Azure AD DS with the following considerations:
 
-* A managed domain must be deployed in its own subnet. Don't use an existing subnet or a gateway subnet. This includes the usage of remote gateways settings in the virtual network peering which puts the managed domain in an unsupported state.
+* A managed domain must be deployed in its own subnet. Using an existing subnet, gateway subnet, or remote gateways settings in the virtual network peering is unsupported.
 * A network security group is created during the deployment of a managed domain. This network security group contains the required rules for correct service communication.
     * Don't create or use an existing network security group with your own custom rules.
 * A managed domain requires 3-5 IP addresses. Make sure that your subnet IP address range can provide this number of addresses.

articles/active-directory/app-provisioning/define-conditional-rules-for-provisioning-user-accounts.md

@@ -8,7 +8,7 @@ ms.service: active-directory
 ms.subservice: app-provisioning
 ms.workload: identity
 ms.topic: how-to
-ms.date: 04/11/2022
+ms.date: 06/15/2022
 ms.author: kenwith
 ms.reviewer: arvinh
 ---
@@ -96,8 +96,8 @@ Scoping filters are configured as part of the attribute mappings for each Azure
 >[!IMPORTANT] 
 > - The IsMemberOf filter is not supported currently.
 > - The members attribute on a group is not supported currently.
-> - EQUALS and NOT EQUALS are not supported for multi-valued attributes
-> - Scoping filters will return "false" if the value is null / empty
+> - Filtering is not supported for multi-valued attributes.
+> - Scoping filters will return "false" if the value is null / empty.
 
 9. Optionally, repeat steps 7-8 to add more scoping clauses.
 

articles/active-directory/app-proxy/application-proxy-configure-complex-application.md

@@ -69,7 +69,7 @@ Here is an example of the request.
 
 
 ```http
-PATCH https://graph.microsoft.com/beta/applications/{<object-id-of--the-complex-app}
+PATCH https://graph.microsoft.com/beta/applications/{<object-id-of--the-complex-app-under-APP-Registrations}
 Content-type: application/json
 
 {

articles/active-directory/authentication/howto-mfa-mfasettings.md

@@ -6,7 +6,7 @@ services: multi-factor-authentication
 ms.service: active-directory
 ms.subservice: authentication
 ms.topic: how-to
-ms.date: 03/22/2022
+ms.date: 06/20/2022
 
 ms.author: justinha
 author: justinha
@@ -30,7 +30,7 @@ The following Azure AD Multi-Factor Authentication settings are available in the
 | [Notifications](#notifications) | Enable notifications of events from MFA Server. |
 | [OATH tokens](concept-authentication-oath-tokens.md) | Used in cloud-based Azure AD Multi-Factor Authentication environments to manage OATH tokens for users. |
 | [Phone call settings](#phone-call-settings) | Configure settings related to phone calls and greetings for cloud and on-premises environments. |
-| Providers | This will show any existing authentication providers that you have associated with your account. Adding new providers is disabled as of September 1, 2018. |
+| Providers | This will show any existing authentication providers that you've associated with your account. Adding new providers is disabled as of September 1, 2018. |
 
 ![Azure portal - Azure AD Multi-Factor Authentication settings](./media/howto-mfa-mfasettings/multi-factor-authentication-settings-portal.png)
 
@@ -243,8 +243,8 @@ If your organization uses the NPS extension to provide MFA to on-premises applic
 
 | Azure AD tenant type | Trusted IP feature options |
 |:--- |:--- |
-| Managed |**Specific range of IP addresses**: Administrators specify a range of IP addresses that can bypass multi-factor authentication for users who sign in from the company intranet. A maximum of 50 trusted IP ranges can be configured.|
-| Federated |**All Federated Users**: All federated users who sign in from inside the organization can bypass multi-factor authentication. Users bypass verification by using a claim that's issued by Active Directory Federation Services (AD FS).<br/>**Specific range of IP addresses**: Administrators specify a range of IP addresses that can bypass multi-factor authentication for users who sign in from the company intranet. |
+| Managed |**Specific range of IP addresses**: Administrators specify a range of IP addresses that can bypass multi-factor authentications for users who sign in from the company intranet. A maximum of 50 trusted IP ranges can be configured.|
+| Federated |**All Federated Users**: All federated users who sign in from inside the organization can bypass multi-factor authentications. Users bypass verifications by using a claim that's issued by Active Directory Federation Services (AD FS).<br/>**Specific range of IP addresses**: Administrators specify a range of IP addresses that can bypass multi-factor authentication for users who sign in from the company intranet. |
 
 Trusted IP bypass works only from inside the company intranet. If you select the **All Federated Users** option and a user signs in from outside the company intranet, the user has to authenticate by using multi-factor authentication. The process is the same even if the user presents an AD FS claim.
 
@@ -256,7 +256,7 @@ When trusted IPs are used, multi-factor authentication isn't required for browse
 
 #### User experience outside the corporate network
 
-Regardless of whether trusted IP are defined, multi-factor authentication is required for browser flows. App passwords are required for older rich-client applications.
+Regardless of whether trusted IPs are defined, multi-factor authentication is required for browser flows. App passwords are required for older rich-client applications.
 
 #### Enable named locations by using Conditional Access
 
@@ -277,14 +277,14 @@ To enable trusted IPs by using Conditional Access policies, complete the followi
 1. Select **Configure MFA trusted IPs**.
 1. On the **Service Settings** page, under **Trusted IPs**, choose one of these options:
 
-   * **For requests from federated users originating from my intranet**: To choose this option, select the checkbox. All federated users who sign in from the corporate network bypass multi-factor authentication by using a claim that's issued by AD FS. Ensure that AD FS has a rule to add the intranet claim to the appropriate traffic. If the rule doesn't exist, create the following rule in AD FS:
+   * **For requests from federated users originating from my intranet**: To choose this option, select the checkbox. All federated users who sign in from the corporate network bypass multi-factor authentications by using a claim that's issued by AD FS. Ensure that AD FS has a rule to add the intranet claim to the appropriate traffic. If the rule doesn't exist, create the following rule in AD FS:
 
-      `c:[Type== "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork"] => issue(claim = c);`
+      `c:[Type== "https://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork"] => issue(claim = c);`
 
    * **For requests from a specific range of public IPs**: To choose this option, enter the IP addresses in the text box, in CIDR notation.
       * For IP addresses that are in the range *xxx.xxx.xxx*.1 through *xxx.xxx.xxx*.254, use notation like ***xxx.xxx.xxx*.0/24**.
       * For a single IP address, use notation like ***xxx.xxx.xxx.xxx*/32**.
-      * Enter up to 50 IP address ranges. Users who sign in from these IP addresses bypass multi-factor authentication.
+      * Enter up to 50 IP address ranges. Users who sign in from these IP addresses bypass multi-factor authentications.
 
 1. Select **Save**.
 
@@ -299,12 +299,12 @@ If you don't want to use Conditional Access policies to enable trusted IPs, you
 
    * **For requests from federated users on my intranet**: To choose this option, select the checkbox. All federated users who sign in from the corporate network bypass multi-factor authentication by using a claim that's issued by AD FS. Ensure that AD FS has a rule to add the intranet claim to the appropriate traffic. If the rule doesn't exist, create the following rule in AD FS:
 
-      `c:[Type== "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork"] => issue(claim = c);`
+      `c:[Type== "https://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork"] => issue(claim = c);` 
 
    * **For requests from a specified range of IP address subnets**: To choose this option, enter the IP addresses in the text box, in CIDR notation.
       * For IP addresses that are in the range *xxx.xxx.xxx*.1 through *xxx.xxx.xxx*.254, use notation like ***xxx.xxx.xxx*.0/24**.
       * For a single IP address, use notation like ***xxx.xxx.xxx.xxx*/32**.
-      * Enter up to 50 IP address ranges. Users who sign in from these IP addresses bypass multi-factor authentication.
+      * Enter up to 50 IP address ranges. Users who sign in from these IP addresses bypass multi-factor authentications.
 
 1. Select **Save**.
 
@@ -366,7 +366,7 @@ To enable and configure the option to allow users to remember their MFA status a
 1. Select **Per-user MFA**.
 1. Under **multi-factor authentication** at the top of the page, select **service settings**.
 1. On the **service settings** page, under **remember multi-factor authentication**, select **Allow users to remember multi-factor authentication on devices they trust**.
-1. Set the number of days to allow trusted devices to bypass multi-factor authentication. For the optimal user experience, extend the duration to 90 or more days.
+1. Set the number of days to allow trusted devices to bypass multi-factor authentications. For the optimal user experience, extend the duration to 90 or more days.
 1. Select **Save**.
 
 #### Mark a device as trusted