Merge pull request #177239 from MicrosoftDocs/master

10/22 PM Publish

Author: huypub

.github/workflows/stale.yml

@@ -19,8 +19,7 @@ jobs:
         close-pr-label: auto-close
         exempt-pr-labels: keep-open
         operations-per-run: 1200
-        ascending: true
-        start-date: '2021-08-10'
+        ascending: false
         stale-pr-message: >
           This pull request has been inactive for at least 14 days.
           If you are finished with your changes, don't forget to sign off. See the [contributor guide](https://review.docs.microsoft.com/help/contribute/contribute-how-to-write-pull-request-automation) for instructions.

.openpublishing.redirection.json

@@ -5483,11 +5483,6 @@
       "redirect_url": "/azure/partner-solutions/overview",
       "redirect_document_id": false
     },
-    {
-      "source_path_from_root": "/articles/partner-solutions/apache-kafka-confluent-cloud/index.md",
-      "redirect_url": "/azure/partner-solutions/apache-kafka-confluent-cloud/overview",
-      "redirect_document_id": false
-    },
     {
       "source_path_from_root": "/articles/fxt-edge-filer/fxt-add-nodes.md",
       "redirect_url": "/azure/fxt-edge-filer/add-nodes",

articles/active-directory-b2c/service-limits.md

@@ -12,6 +12,7 @@ ms.topic: reference
 ms.date: 06/02/2021
 ms.author: kengaderdus
 ms.subservice: B2C
+ms.custom: "b2c-support"
 ---
 
 # Azure Active Directory B2C service limits and restrictions
@@ -42,8 +43,8 @@ The following table lists the administrative configuration limits in the Azure A
 |String Limit per Attribute      |250 Chars          |
 |Number of B2C tenants per subscription      |20         |
 |Levels of [inheritance](custom-policy-overview.md#inheritance-model) in custom policies     |10         |
-|Number of policies per Azure AD B2C tenant      |200          |
-|Maximum policy file size      |400 KB          |
+|Number of policies per Azure AD B2C tenant (user flows + custom policies)     |200          |
+|Maximum policy file size      |1024 KB          |
 
 <sup>1</sup> See also [Azure AD service limits and restrictions](../active-directory/enterprise-users/directory-service-limits-restrictions.md).
 

articles/active-directory-b2c/user-overview.md

@@ -8,7 +8,7 @@ manager: CelesteDG
 ms.service: active-directory
 ms.workload: identity
 ms.topic: conceptual
-ms.date: 10/01/2021
+ms.date: 10/22/2021
 ms.author: kengaderdus
 ms.subservice: B2C
 ms.custom: b2c-support
@@ -21,7 +21,7 @@ In Azure Active Directory B2C (Azure AD B2C), there are several types of account
 The following types of accounts are available:
 
 - **Work account** - A work account can access resources in a tenant, and with an administrator role, can manage tenants.
-- **Guest account** - A guest account can only be a Microsoft account or an Azure AD user that can be used to access applications or manage tenants.
+- **Guest account** - A guest account can only be a Microsoft account or an Azure AD user that can be used to share administration responsibilities such as [managing a tenant](tenant-management.md).
 - **Consumer account** - A consumer account is used by a user of the applications you've registered with Azure AD B2C. Consumer accounts can be created by:
   - The user going through a sign-up user flow in an Azure AD B2C application
   - Using Microsoft Graph API

articles/active-directory/authentication/how-to-authentication-sms-supported-apps.md

@@ -32,6 +32,7 @@ SMS-based authentication is available to Microsoft apps integrated with the Micr
 | Microsoft Stream | ● |   |
 | Microsoft Power Apps | ● |   |
 | Microsoft Azure | ● | ● |
+| Microsoft Authenticator |   | ● |
 | Azure Virtual Desktop | ● |  | 
 
 *_SMS sign-in isn't available for office applications, such as Word, Excel, etc., when accessed directly on the web, but is available when accessed through the [Office 365 web app](https://www.office.com)_

articles/active-directory/authentication/multi-factor-authentication-faq.yml

@@ -247,11 +247,18 @@ sections:
           
           A workaround for this error is to have separate user accounts for admin-related and non-admin operations. Later, you can link mailboxes between your admin account and non-admin account so that you can sign in to Outlook by using your non-admin account. For more details about this solution, learn how to [give an administrator the ability to open and view the contents of a user's mailbox](https://help.outlook.com/141/gg709759.aspx?sl=1).
           
+      - question: |  
+          What are the possible reasons why a user fails, with the error code "LsaLogonUser failed with NTSTATUS -1073741715 for MFA Server"?
+        answer: |
+          Error 1073741715 = Status Logon Failure -> The attempted logon is invalid. This is due to either a bad username or authentication.
+
+          A plausible reason for this error: If the primary credentials entered are correct, there might be a mismatch between the supported NTLM version on the MFA server and the domain controller. MFA Server supports only NTLMv1 (LmCompatabilityLevel=1 thru 4) and not NTLMv2 (LmCompatabilityLevel=5).
+          
 additionalContent: |
   ## Next steps
     If your question isn't answered here, the following support options are available:
           
     * Search the [Microsoft Support Knowledge Base](https://support.microsoft.com) for solutions to common technical issues.
     * Search for and browse technical questions and answers from the community, or ask your own question in the [Azure Active Directory Q&A](/answers/topics/azure-active-directory.html).
     * Contact Microsoft professional through [Azure Multi-Factor Authentication Server support](https://support.microsoft.com/oas/default.aspx?prid=14947). When contacting us, it's helpful if you can include as much information about your issue as possible. Information you can supply includes the page where you saw the error, the specific error code, the specific session ID, and the ID of the user who saw the error.
-    * If you're a legacy PhoneFactor customer and you have questions or need help with resetting a password, use the [[email protected]](mailto:[email protected]) e-mail address to open a support case.
+    * If you're a legacy PhoneFactor customer and you have questions or need help with resetting a password, use the [[email protected]](mailto:[email protected]) e-mail address to open a support case.

articles/active-directory/conditional-access/TOC.yml

@@ -39,7 +39,7 @@
     href: service-dependencies.md
   - name: Location conditions
     href: location-condition.md
-  - name: Filters for devices
+  - name: Filter for devices
     href: concept-condition-filters-for-devices.md
   - name: What if tool
     href: what-if-tool.md

articles/active-directory/conditional-access/concept-condition-filters-for-devices.md

@@ -1,12 +1,12 @@
 ---
 title: Filter for devices as a condition in Conditional Access policy - Azure Active Directory
-description: Use Filter for devices in Conditional Access to enhance security posture
+description: Use filter for devices in Conditional Access to enhance security posture
 
 services: active-directory
 ms.service: active-directory
 ms.subservice: conditional-access
 ms.topic: conceptual
-ms.date: 06/03/2021
+ms.date: 10/22/2021
 
 ms.author: joflore
 author: MicrosoftGuyJFlo
@@ -17,31 +17,31 @@ ms.collection: M365-identity-device-management
 ---
 # Conditional Access: Filter for devices
 
-When creating Conditional Access policies, administrators have asked for the ability to target or exclude specific devices in their environment. The condition Filter for devices give administrators this capability. Now you can target specific devices using [supported operators and properties for device filter](#supported-operators-and-device-properties-for-filters) and the other available assignment conditions in your Conditional Access policies.
+When creating Conditional Access policies, administrators have asked for the ability to target or exclude specific devices in their environment. The condition filter for devices give administrators this capability. Now you can target specific devices using [supported operators and properties for device filters](#supported-operators-and-device-properties-for-filters) and the other available assignment conditions in your Conditional Access policies.
 
 :::image type="content" source="media/concept-condition-filters-for-devices/create-filter-for-devices-condition.png" alt-text="Creating a filter for device in Conditional Access policy conditions":::
 
 
 ## Common scenarios
 
-There are multiple scenarios that organizations can now enable using Filter for devices condition. Below are some core scenarios with examples of how to use this new condition.
+There are multiple scenarios that organizations can now enable using filter for devices condition. Below are some core scenarios with examples of how to use this new condition.
 
 - Restrict access to privileged resources like Microsoft Azure Management, to privileged users, accessing from [privileged or secure admin workstations](/security/compass/privileged-access-devices). For this scenario, organizations would create two Conditional Access policies:
    - Policy 1: All users with the directory role of Global administrator, accessing the Microsoft Azure Management cloud app, and for Access controls, Grant access, but require multifactor authentication and require device to be marked as compliant.
-   - Policy 2: All users with the directory role of Global administrator, accessing the Microsoft Azure Management cloud app, excluding filters for devices using rule expression device.extensionAttribute1 equals SAW and for Access controls, Block.
+   - Policy 2: All users with the directory role of Global administrator, accessing the Microsoft Azure Management cloud app, excluding a filter for devices using rule expression device.extensionAttribute1 equals SAW and for Access controls, Block.
 - Block access to organization resources from devices running an unsupported Operating System version like Windows 7. For this scenario, organizations would create the following two Conditional Access policies:
    - Policy 1:  All users, accessing all cloud apps and for Access controls, Grant access, but require device to be marked as compliant or require device to be hybrid Azure AD joined.
-   - Policy 2: All users, accessing all cloud apps, including filters for devices using rule expression device.operatingSystem equals Windows and device.operatingSystemVersion startsWith "6.1" and for Access controls, Block.
+   - Policy 2: All users, accessing all cloud apps, including a filter for devices using rule expression device.operatingSystem equals Windows and device.operatingSystemVersion startsWith "6.1" and for Access controls, Block.
 - Do not require multifactor authentication for specific accounts like service accounts when used on specific devices like Teams phones or Surface Hub devices. For this scenario, organizations would create the following two Conditional Access policies:
    - Policy 1: All users excluding service accounts, accessing all cloud apps, and for Access controls, Grant access, but require multifactor authentication.
-   - Policy 2: Select users and groups and include group that contains service accounts only, accessing all cloud apps, excluding filters for devices using rule expression device.extensionAttribute2 not equals TeamsPhoneDevice and for Access controls, Block.
+   - Policy 2: Select users and groups and include group that contains service accounts only, accessing all cloud apps, excluding a filter for devices using rule expression device.extensionAttribute2 not equals TeamsPhoneDevice and for Access controls, Block.
 
 ## Create a Conditional Access policy
 
 Filter for devices is an option when creating a Conditional Access policy in the Azure portal or using the Microsoft Graph API.
 
 > [!IMPORTANT]
-> Device state and Filter for devices cannot be used together in Conditional Access policy.
+> Device state and filter for devices cannot be used together in Conditional Access policy.
 
 The following steps will help create two Conditional Access policies to support the first scenario under [Common scenarios](#common-scenarios). 
 
@@ -64,7 +64,7 @@ Policy 1: All users with the directory role of Global administrator, accessing t
 1. Confirm your settings and set **Enable policy** to **On**.
 1. Select **Create** to create to enable your policy.
 
-Policy 2: All users with the directory role of Global administrator, accessing the Microsoft Azure Management cloud app, excluding filter for devices using rule expression device.extensionAttribute1 equals SAW and for Access controls, Block.
+Policy 2: All users with the directory role of Global administrator, accessing the Microsoft Azure Management cloud app, excluding a filter for devices using rule expression device.extensionAttribute1 equals SAW and for Access controls, Block.
 
 1. Select **New policy**.
 1. Give your policy a name. We recommend that organizations create a meaningful standard for the names of their policies.
@@ -88,7 +88,7 @@ Policy 2: All users with the directory role of Global administrator, accessing t
 
 ### Filter for devices Graph API
 
-The filter for devices API is available in Microsoft Graph v1.0 endpoint and can be accessed using https://graph.microsoft.com/v1.0/identity/conditionalaccess/policies/. You can configure filter for devices when creating a new Conditional Access policy or you can update an existing policy to configure filter for devices condition. To update an existing policy, you can do a patch call on the Microsoft Graph v1.0 endpoint mentioned above by appending the policy ID of an existing policy and executing the following request body. The example here shows configuring a filter for devices condition excluding device that are not marked as SAW devices. The rule syntax can consist of more than one single expression. To learn more about the syntax, see [dynamic membership rules for groups in Azure Active Directory](https://docs.microsoft.com/azure/active-directory/enterprise-users/groups-dynamic-membership). 
+The filter for devices API is available in Microsoft Graph v1.0 endpoint and can be accessed using https://graph.microsoft.com/v1.0/identity/conditionalaccess/policies/. You can configure a filter for devices when creating a new Conditional Access policy or you can update an existing policy to configure the filter for devices condition. To update an existing policy, you can do a patch call on the Microsoft Graph v1.0 endpoint mentioned above by appending the policy ID of an existing policy and executing the following request body. The example here shows configuring a filter for devices condition excluding device that are not marked as SAW devices. The rule syntax can consist of more than one single expression. To learn more about the syntax, see [dynamic membership rules for groups in Azure Active Directory](https://docs.microsoft.com/azure/active-directory/enterprise-users/groups-dynamic-membership). 
 
 ```json
 {
@@ -105,7 +105,7 @@ The filter for devices API is available in Microsoft Graph v1.0 endpoint and can
 
 ## Supported operators and device properties for filters
 
-The following device attributes can be used with filters for devices condition in Conditional Access.
+The following device attributes can be used with the filter for devices condition in Conditional Access.
 
 | Supported device attributes | Supported operators | Supported values | Example |
 | --- | --- | --- | --- |
@@ -120,11 +120,11 @@ The following device attributes can be used with filters for devices condition i
 | profileType | Equals, NotEquals | A valid profile type set for a device. Supported values are: RegisteredDevice (default), SecureVM (used for Windows VMs in Azure enabled with Azure AD sign in.), Printer (used for printers), Shared (used for shared devices), IoT (used for IoT devices) | (device.profileType -notIn [“Printer”, “Shared”, “IoT”] |
 | systemLabels | Contains, NotContains | List of labels applied to the device by the system. Some of the supported values are: AzureResource (used for Windows VMs in Azure enabled with Azure AD sign in), M365Managed (used for devices managed using Microsoft Managed Desktop), MultiUser (used for shared devices) | (device.systemLabels -contains "M365Managed") |
 | trustType | Equals, NotEquals | A valid registered state for devices. Supported values are: AzureAD (used for Azure AD joined devices), ServerAD (used for Hybrid Azure AD joined devices), Workplace (used for Azure AD registered devices) | (device.trustType -notIn ‘ServerAD, Workplace’) |
-| extensionAttribute1-15 | Equals, NotEquals, StartsWith, NotStartsWith, EndsWith, NotEndsWith, Contains, NotContains, In, NotIn | extensionAttributes1-15 are attributes that customers can use for device objects. Customers can update any of the extensionAttributes1 through 15 with custom values and use them in filters for devices condition in Conditional Access. Any string value can be used. | (device.extensionAttribute1 -eq ‘SAW’) |
+| extensionAttribute1-15 | Equals, NotEquals, StartsWith, NotStartsWith, EndsWith, NotEndsWith, Contains, NotContains, In, NotIn | extensionAttributes1-15 are attributes that customers can use for device objects. Customers can update any of the extensionAttributes1 through 15 with custom values and use them in the filter for devices condition in Conditional Access. Any string value can be used. | (device.extensionAttribute1 -eq ‘SAW’) |
 
 ## Policy behavior with filter for devices
 
-Filter for devices condition in Conditional Access evaluates policy based on device attributes of a registered device in Azure AD and hence it is important to understand under what circumstances the policy is applied or not applied. The table below illustrates the behavior when filters for devices condition are configured. 
+The filter for devices condition in Conditional Access evaluates policy based on device attributes of a registered device in Azure AD and hence it is important to understand under what circumstances the policy is applied or not applied. The table below illustrates the behavior when a filter for devices condition are configured. 
 
 | Filter for devices condition | Device registration state | Device filter Applied 
 | --- | --- | --- |